水曜日, 3月 11日, 2015

麻雀とシステムと想定外

私の持論は「よいシステムエンジニアは麻雀が強い」です。
優秀なエンジニアを見ると、その人が麻雀しない人でも「この人、麻雀したら強いだろうな」って思います。

麻雀というゲームを知らない方のために簡単に説明すると、麻雀は3種類の数牌が1~9まで4枚ずつ、東西南北(麻雀では東南西北)の風牌が4枚ずつ、白發中の三元牌が4枚ずつあって、手牌13枚に1枚引くもしくは相手が捨てた牌で、4つの順子(シュンツ、連番)か暗刻(アンコー、同じ牌×3)と対子(トイツ、同じ牌×2)の組み合わせを作れば和了(ホーラ、ロン、上がり)です。
その組み合わせの種類によって「役」というのがあって、強い役を作ると獲得する点数が多くなります。
ロンの前の状態が聴牌(テンパイ)、聴牌の前は一聴向(イーシャンテン)、その前が二聴向(リャンシャンテン)、三聴向、四聴向と続きます。

つまり麻雀とは

  • 聴向を進める
  • 役をより強い役に向かわせる

ゲームとなります。

「完成」に近づけ、「より強固なものを作る」のです。
ほら、システム開発に似ているでしょう?
(ちょっと強引ですか、そうですか)

まず麻雀が強い人は、牌を引いてきたときに「if」で考えていません。
必ず「case」の塊で考えています。
ケースで決まった行動をするから、迷うことなく即、打牌します。
そのケースをいかに多く用意できるか。
これで強さの大部分が決まります。

基本的な行動はテンプレートにして用意してあり、さらに現状を分析して細かくケースを組み立てます。
ケースを構成する要素は自分手牌の状態だけではありません。
河(ホー、自分や他者が捨てた牌)の状態、残り枚数、対戦相手の思考など、刻々と状況は変わります。

どのケースにも当てはまらない場合、引いてきた牌をそのまま河に捨てます。

ここで、先ほど「麻雀とは」で(ワザと)書いてこなかったゲームの要素が加わります。

  • 相手に振り込まない(相手に和了させない)
  • 回す、降りる(相手に和了させないために自分の手を進めるのをやめる)

自分がいくら聴向が進んでも、相手に上がられてしまったらしょうがないのです。
ときには降りることも必要です。
そこまで考えてケースを組みます。

緻密に組まれたケースには想定外はほとんどないのです。
それでも想定外は起きます。
だからゲームは面白い。
「常勝チャンプなんてありえない」と前田日明も言っていました。

ところがシステムはゲームではありません。
想定外は起きてはいけないのです。
それでも想定外は起きます。
最悪、システムを止める、ということになります。
想定外が起きたときに、被害を最小に抑える施策をし、なるべくシステムを止めないで対策出来るようにしなければなりません。

システムを止めても、被害が収まらない。
そんなシステムはこの世にあっちゃいけない、と思うのですよ。
システム屋としては。

火曜日, 3月 3日, 2015

ドキュメントを書きましょう

私が最初に入社した会社は親会社が策定したドキュメントフォーマットがきちんと整っていて、何をどこにどれだけのものを書けばよいか、規模によってどれを客先に納品するかなど決まっていました。
そんな会社で育ったせいか、ドキュメントというのはとても重要だと、その会社を辞めた後でも思っています。

それがいつからでしょう。
システムも「うまい、早い、安い」でないと仕事が取れなくなって、受注価格を下げるようになって、工数削減で何を犠牲にするかで「ドキュメント」をきっちり書かなくなることが多くなったように思います。

  1. 「どうせ詳細設計なんか書いても、お客さんが見てもわからないから」
  2. 「コード書いたほうが早い」
  3. 「工程が進むうちに設計書と実装がどんどんかけ離れていって、メンテナンスするのが困難だから」

そんな声をよく聞きます。

1.はそれでもよいと思います。
なぜなら、設計書は家を建てるところでいう所の「図面」だと思うのです。
図面はお客さんよりもそれを見て大工さんが作れなければ意味がないです。
図面を引かない家に住みたいですか?そういう話だと思います。

2.はわかるような気がします。
決定した仕様を技術者の言葉に翻訳するのが設計書、コンピュータの言葉に翻訳するのがコード。
同じことを、二つの言葉に、しかも同期をとって翻訳しなければならないのです。
面倒ですね。コードだけなら一つでいいですね。
でも、例えば「このアプリケーションはどんな処理をやっているのか」の概要を知るために「コードを見てください」ってのはどうでしょう。
それが納品した客先だったり、保守運用の会社だったりすると「コードを見ろ」はお粗末ですね。
そこで「そこそこの設計書」をどこでも書くと思います。

でもそれが3.の「設計書と実装の乖離」につながり、同期をとろうと思えば「メンテナンスする」というコスト高の原因になってくるのだと思います。

さて、ここまで問題は出しても解決策を書いてきませんでした。
というか、自分が言いたい解決策は表題通り「ドキュメントは書きましょう」ということなんですけどね。
そこはコストとして削れるところではない、と主張したいわけです。

もう一度書きます。
「図面を引かない家に、あなたは住みたいですか?」

ドキュメントのメンテナンスを効率よくするための解決策、一緒に考えましょう。
DOAとか、なんとか、かんとか。

土曜日, 2月 28日, 2015

お仕事(システム開発)関連のブログ始めてみました

もう20年以上、システム業界でエンジニアをやってきました。

お金勘定やら要員調整なんかやるのが嫌で、前の会社を辞めて技術一本でやってきたので、マネージメントなんかは全然ですけどね。

20年もやっているともう「ベテラン」などと呼ばれたりする、そんな年代のシステムエンジニアの一人が、やってみたこと、思うこと、ちょっとした小技など書きためていけたら、もしかしたら世のシステムエンジニア達の役に立つこともあるかなぁ、なんて思ったりしてます。

まぁ、お気楽にやらせてもらいますね。
もちろん守秘義務に引っかかることは書きませんよ!