「きちんと○○していたらトラブルは防げた」をきちんと表現する

ソフトウェア業界においてなんらかのトラブルがあると、トラブルの内容と共に、「きちんとテストしないからだ」「きちんと設計しないからだ」というコメントが報じられる。非常に無意味なコメントのように思う。

まるで関わった人たちの不注意、もしくは故意に失敗させたかのような言い方だが、実際はスキル不足、時間不足、予算不足の複合要因であろうことは想像に難くない。失敗原因を取り除けば成功するのではなくて、何かを足さないとうまくいかないということだ。

例えば、スキルのある人材の投入、スケジュールの延長、予算の追加確保等であるが、どれもプロジェクトの状況に流されていては得ることはできないものばかりである。プロジェクト内のスタッフは出来るだけ与えられたものだけを使って自分達の力だけでなんとかしようとするが、なんともならない場合に失敗という結果になる。

そう考えると、「きちんと○○していたらトラブルは防げた」というのは、「外部の力を利用していたらトラブルは防げた」、「スケジュールを延長していたらトラブルを防げた」、「予算をもう少し確保できていればトラブルを防げた」というような表現になるのではないだろうか。

無いものねだりのようにも聞こえるが、プロジェクトが失敗するのと、事前に失敗を予測して対応するのとの二者択一なので、どちらかを選択する以外にない。選択肢が無いと思っているプロジェクト管理者は失敗の道を無意識で選んでいるだけである。

さて、上記の具体的なコメントと、「きちんと○○していたら～」とを比べると、責任の所在が現場から上層部に移ってきたような気はしないだろうか。プロジェクトの失敗が現場にあるかのようなコメントはよろしくないのでなるべく正確な表現を期したいところである。

もちろんのことながら、開発者がたまに他のプロジェクトの話を聞いて、「それはきちんと設計してないから悪い」というような言葉もなるべくやめにしたい。具体的な発言で前向きに評価していけるのがベストではないかと思う。

経営者と優秀なプログラマの見解は１８０度違うかもしれない

「ふっかつのじゅもんがちがいます。」 ペアプロと上司でないマネージャはすっぱいブドウ から引用
----
しかしながらペアプログラミングはすっぱいブドウだ。優秀なプログラマならば誰だってペアプロが効率的であることが直感的に分かるはずだ。僕の知る限り優秀なプログラマは大抵就業時間の30%くらいしか労働しない。残り70%を使えるのは北斗神拳の伝承者くらいのものだ。（30%は言い過ぎかもしれない。こんなに働ける人は稀だ！）

（中略）

ペアプロで作業することを（技術者出身でない）CEOに納得させることは不可能に近いくらい困難であることが分かる。そのためには、自分が70%遊んでいることを自供するか、さもなければ相当トリッキーな手段を使うかしなければならないからだ。
----

経営者は優秀なプログラマがいっつも遊んでいるように見えることを知っている。知っていて何も言わないのは成果がちゃんと上がっているからである。プログラマが思っているより経営者はいろいろ見ているのである。

なので、ペアプログラミングしてよりパフォーマンスがあがると思うのであれば、勝手に始めてもたぶん何も言われないと思う。それで成果が出ない場合、成果が出ないことについて怒られるだろうが。

自発的にプログラマからペアプログラミングしたいという声が出てくる分には全く問題ないだろう。逆に経営者側から、プログラマにもっと働いてもらいたいのでペアプログラミング導入する、というような場合がやっかいである。

ペアプログラミングは、導入すればすぐ成果が出るというタイプのものではない。ひっつければ勝手に生産性があがるというわけではなく、プログラマのスキルの差がありすぎる場合や、急なペアの環境に慣れない人のことも考慮する必要がある。上から押し付けてもうまくいかない。

ただ、マネジメントの立場から、プログラマに対して提案することは当然ありだ。プログラムに集中してもらい、少ない人材を効果的に使いたいのであれば、経営者はプログラマをほったらかしにするだけでなくて、もう少し周辺環境に気を配ってもいいはずである。それこそ人材の有効利用だろう。

デスマーチとはプロジェクトが抱える責任を全てプログラマにおしつけるということ

ソフトウェア開発のデスマーチの惨状を聞くと、ほとんど例外なくプログラマが徹夜で頑張っている。逆に言うと、プログラマが徹夜で頑張るしかないプロジェクトほどデスマーチになる確率が高いと言えるだろう。

プログラムを書かなければソフトウェアが完成しないのはその通りだと思うが、遅れた原因はプログラマにだけあるとは思えないのに、なぜプログラマだけが苦行に耐えないといけないのだろうか。

従来の開発方法の場合、原因ははっきりしていて、前工程が遅れて、納期は変わらないから、プログラミングの工程に全てのしわ寄せが来るのである。

やっかいなのはプログラミングの工程自体はスケジュール通りに始まっているというケースである。仕様が確定していないのになぜか並行で工程が進んでしまう。こうなると関係者はスケジュールはやや遅れているが問題ない（平行で動いているので効率的とまで思ってしまう）という認識になりやすい。

クリティカルパス（※）ってなんでしたっけと小一時間問い詰めたい気分になるのだが、とにかく仕様が出来ていないのにプログラムが作れるはずもなく、どんどんと遅れだしていつものデスマーチが始まる。

デスマーチとはプロジェクトが抱える責任を全てプログラマにおしつけるということなのである。必要なのは最後にプログラマが踏ん張ってなんとかすることでなくて、やばそうな状態を回避できるように早めに手を尽くすことである。

自分の仕事ではないのは百も承知でも政治的なレイヤーに口を挟まないと被害だけを被ることになる。顧客側も開発側も、中間で遅れているスケジュールが最後に取り戻せると思っているのがそもそもおかしいのである。

そんなことやりたくないからプログラマやってるんです、と言われそうな気もするし、そういう気質の人は多いわけだが、プログラマの義務として言うべきタイミングで言うべきことを言わないといけないと思う。無言で頑張るだけがプログラマの仕事ではないはずだ。責任取れないのであれば回避の手段ぐらいは持たないといけないのだ。

※「クリティカルパス」　プロジェクトの完成を遅らせないためには絶対に遅らせてはならない工程の組み合わせのことです。言い換えると、前が終わらないと次に進めない工程の組において最も長くなる工程のことであり、クリティカル･パスの長さはプロジェクト全体の長さを意味します。
http://www.mitsue.co.jp/case/glossary/y_023.html 　より引用

開発プロセスを決めるということは進捗管理方法を決めるということ

開発プロセスに対する幻想を破壊する
http://www.atmarkit.co.jp/farc/rensai/process01/process01.html

----
　開発プロジェクトにおける開発プロセスとはまさに、登山における最初のルートです。開発チームの経験、技術、関係各社（者）の状況から、最適と思われる開発プロセスを“作る”のです。この開発プロセスを作るときに、毎回ゼロから作るのではなく、基本的な作業の流れと、個々の作業の実施要綱をあらかじめ標準プロセスとして用意しておき、それを適宜修正しながら活用すると、初心者でも忘れ物をしないくらいにはできます。標準プロセスとは、その程度のものと考えるのがよいのです。
----

ソフトウェア開発における「開発プロセス」とは、個人の作業を規定するもの、という認識が一般的なようだが、ちょっと違和感を感じている。開発プロセス＝開発者を縛るものという理解ではなかなか現場にうまく浸透しないだろう。

素晴らしい開発プロセスがあったとして、その開発プロセスを使うと何が素晴らしいのだろうか。素晴らしい開発プロセスを利用すると、「誰がやっても成功する」というわけではない。「誰がやっていても、外から見てどれくらい進んでいるかがわかる」ということが出来るのが、素晴らしい開発プロセスだと思う。

要するに開発プロセス＝進捗確認方法という位置付けである。そこには成功とか失敗とかいう言葉はなく、同じ開発プロセスを使っても、１つ１つのプロセスの作業が遅ければ納期に間に合わなくて失敗だし、優秀な人でも高コストになって納期に間に合ったが予算オーバーで失敗ということも当然ありえる。

開発プロセスを決めることで、進捗確認が外から見えるようになり、プロジェクトをどうするかの判断が逐次可能になるというのは、経営者やマネージャーや発注側の立場から見ると非常にありがたい。開発プロセスがあれば成功するのではなくて、失敗しそうなプロジェクトのリカバリーをしやすくすることが出来る。それ以上の期待はしてはいけないし、期待したいのなら開発プロセス以外に求めて欲しいところだ。

また、１つ注意したいのは、ソフトウェア開発の特徴として進捗は前に進むだけでなく後ろに戻ることがある。要は仕様変更により開発内容が変わったり、いくつか作ったものがいらなくなったりするのである。しかし、そのことが悪いと言っているのではなく、進捗が動くことが外から把握できる、ということが大事なのである。

開発プロセスを決めて、進捗をトラッキングできるようになれば、その進捗の履歴をたどることで、仕様変更にどう対応するべきか、どこで人員がピークになるのか、進捗が止まっているように見えるのは開発プロセスが悪いのかどうか等が解るようになるのではないだろうか。ある軸が定まっていると他の評価がやりやすくなると言えるだろう。

ついでに言うと、作業の標準化というのは、開発プロセスで決めることではなくて、プロジェクトチーム内で説明したり教育して浸透させていくべきことであり、頭ごなしにおしつけるものではない。それを今まで開発プロセスと呼んで来たのであれば、単純に開発TIPSとでも呼ぶべきであり、経営陣にまで影響がある開発プロセスとは切り離す方がよいと思う。

技術者のための開発プロセスではなくて、会社全体のための開発プロセスであるという意識がないと、開発プロセスという名前だけが一人歩きしてしまうし誰も使わない。せっかく何か作るのであればちゃんと使えるものにしないといけませんね。

プログラムを分割することと図形に補助線を入れることはなんとなく似ている（気がする）

著者： 三田 紀房

タイトル： ドラゴン桜 (1)

ドラゴン桜という漫画が面白い。受験漫画というよりは、勉強とは本来どうあるべきかについて、示唆に富んでいる。初心者プログラマが今後いろいろなことを学習するにおいても非常に参考になると思う。

初心者プログラマがプログラムを書く上で最初につまずくのは、自分でプログラムを書く時に分割できずに、一つの関数にべたーっと書いてしまうことである。最初はそれで構わないのだが、どんどん拡張していくに従って、何がなんだかわからなくなってきて、書けなくなってしまう。

そこで先輩プログラマが、「分割しないからだめなんだ。分割はプログラムを作る上での基本だぞ」と言ったところで、どう分割していいかわからないのだから意味がない。

その昔を思い出すと、中学や高校の数学（幾何）の時間に、図形に補助線を入れると簡単に解けると習ったが、どこに補助線を入れればいいのかよく分からないというのが最初の印象だった。

点と点を繋ぐ補助線なら誰でも引ける。だがそれ以上（点と線上のどこか、図形外のどこか）になると、どこにでも引けそうな気がして、動けなくなる。プログラムも似たようなものではないだろうか。分割された後のプログラムを見れば理解はできるが、いざ自分で分割するとなると、どこも同じように思えてしまう。

プログラムをどう分割するかは経験則だ、と言ってしまうとそれ以上先には進まない。数学の図形の補助線は、ある程度までなら学習を繰り返すことで、補助線の書き方もパターン化できる。プログラムの分割についても同じことが言えるのではないだろうか。

分割を考えるには、プログラムを処理の固まりとして考える必要がある。抽象化ではなく、具体的なプログラムにおける固まりである。処理速度を優先すると、なかなか固まりが見えてこないので、処理の中身に意識を向けたほうがよい。

オブジェクト指向言語だと固まりを固まりのまま扱いやすい。そこから一歩進むと抽象化なりデザインパターンという話にも繋がっていく。どういう固まりが他のどの固まりと繋がっているか、その固まりはもっと小さな固まりにしたほうがよいのかどうか。ポイントはいくつかあるが、要はプログラムを眺めた時に固まりを意識できるかどうかである。

固まりを意識できれば、固まりと固まりの間は分割できそう、と思えるようになる。そこから先はテクニックを要するが、やりたいことが決まっていれば、もし誰かに質問しても的確な答えが得られるだろう。「何を分割したらいいか分かりません」という抽象的な質問には答えにくいが、「こういう風に分割したいんですが、この変数はどうやって渡せばいいでしょうか？」は具体度が増している。

分割統治、分割統治とお題目のように言われて、分割することだけを意識していると、いつまでたってもプログラムを分割できない。分割ありきではなくて、固まりありきなのだ。何もないところに補助線は引けない。どうでもいいところを分割してもしょうがない。簡単そうなものは実は難しいという典型的な例だが、コツを掴んでプログラミングに励んでほしい。

設計が出来る人は管理者に、実装が出来る人は設計者になるため、実装できない人がプログラマになる

ピーターの法則という有名な法則がある。「社会はあらゆるポストが無能な人間によって占められて安定する。」という趣旨の法則だが、有能な人は無能になるまで昇進し続けるので、役職的に無能な人ばっかりになるという恐ろしい法則だ。

ソフトウェア開発の現場で仕事をしていると、優秀な人がどんどん上の役職に上がっていって、プログラミング能力のある人がプログラムを書かなくなったり、ドキュメント書かせると非常に上手い人が管理職になってスケジュールと予算ばっかり管理していたりと、優秀な人が揃っているのに開発スタッフが足りない状態になることがある。

そうすると何が起こるかというと、人を雇い入れるわけだが、優秀な人は高いしそもそもいないので、安くて意欲のある人を採用する。しかしそれほど経験がないという場合がほとんどなので、プログラム経験があまり無い人がプログラムを書くことになる。まさにピーターの法則ぴったりだ。

ピーターの法則に従わないようにするにはどうすればよいだろうか。アジャイル開発モデルを見ると、チーム全員が設計と実装を分け隔てなく行うことで、チーム内のリソースが無駄にならないようにしている。なるべく優秀な人を第一線に残すという点において、アジャイル開発モデルは良く考えられている気がする。

人が増えてきたら管理職が必要という考え方は、古い会社組織構造だと思う。例えば漫画家は、節税対策のために会社を設立するケースが多いのだが、一番偉いのは漫画を描く漫画家で、社長でありながら漫画を書いている。当然社長（漫画家）が死んだらそこでコンテンツの生産は止まるが、今までのコンテンツを維持管理して社員が食いつなぐ事は可能だろうと思う。

ソフトウェア業界では、社長がプログラムを書いているうちはだめだというような意見も見かけるが、上記漫画家モデルを真似て、社長がプログラムを書きまくる会社があってもいいのではないかと思う。あとの社員は全員アシスタントだ。それでもソフトウェアが開発できるならなんの問題も無い気がするが。

２０世紀の組織論を無視して、一番能力を引き出せるような組織構造は何か、ということをもう一度模索した方がよいと思う。せっかくのスキルを埋もれさせることなく、世の中に貢献するために。

いい無駄わるい無駄、いい失敗わるい失敗

ソフトウェア開発、特に受託して開発するような場合は、無駄の連続である。無駄を排除して効率よくしようとすると、なぜか無駄が多くなるという矛盾がある。なぜだろうか。

机上でソフトウェア開発を考える人（要するにあまり実経験のない人）は、顧客のニーズを最初に「ちゃんと」引き出して、「ちゃんと」確定できれば、作る際に無駄はないし、非常に効率的だと考えるのである。まさに理想論なのだが、根本的な問題として、顧客は見たこともないものを「ちゃんと」決めるのは無理なのである。

ハードウェアはまずモックアップを作って、ぱっと見を検証する。原寸大の大きさが無理な場合は、ミニチュアモデルを作る。これを無駄という人はあまりいないと思う。実物を作る事が確立されているからという理由もあるが、実際に作り始めてからイメージと違った場合のコストを考えるとよっぽど安いのである。いい無駄と言えるだろう。

それに引き換えソフトウェア開発では、試行錯誤のプロセスを無駄と考えて、とにかく早く後の工程に進みたがる傾向にあるように思う。仕様が確定しようがしまいが、顧客に不満があれば最後にどんでん返しが待っている。無駄を排除して効率よく進んだ先には、最大の無駄があるかもしれない。

たしかに一度動かしてから直すというのは、ある意味コストが２倍、３倍とかかるようにも思えるが、落ち着いて考えると、コスト＝時間なのであり、仕様を決めるのにぐだぐだ長い時間をかけるのであれば、その分さくっと仕様を決めて２回、３回やり直した方が、同じ実時間で完成度は数倍高くなることは間違いない。

最初に無駄な過程を踏んで、顧客と開発側がお互いに仕様確定のやり取りの中で失敗を繰り返すことにより、両者が今回のプロジェクトについて精通し、最終的な成功へ繋がるのが本当の理想系の開発モデルかなという気がする。XPを始めアジャイル開発も、無駄と失敗を積み上げながら進める開発モデルのようである。

失敗を繰り返すことについて、設計者の発言－「As-is先行」か「To-be先行」か のコメント欄から引用
---
最終的に相手に気に入ってもらった「描かれた目」と相手の「目に関する発言」の間にある「因果関係」は相手にしかわかりません。気に入ってもらうまで、山ほど失敗を繰り返さねばなりませんが、そのときに必要なのが「似てないならアカラサマに似てないとわかるような図法」で、ＤＦＤやＥＲＤやパネルイメージはそのために適しています。高速に、サルのように失敗を繰り返す。これがカギです。
---
とあるが、いい無駄、いい失敗をうまく表現されている。顧客が決めるまで動かないではなくて、顧客が反応するまで動きつづけることで、真のニーズを探るというような形容がピッタリ来る気がする。

まとめると、無駄や失敗を繰り返す事で、ソフトウェア開発が成功に導かれる確率が高まる。それはいい無駄でありいい失敗である。逆に、最初に無駄や失敗を極力避けようとすると、ソフトウェア開発が失敗する確率が高まる。それはプロジェクトそのものが悪い無駄になり悪い失敗になる。最初が順調なプロジェクトほど疑ってかかった方がいいのかもしれないですね。

いきなり見知らぬ開発プロジェクトに放り込まれた時の対処法

ソフトウェア開発業界のよくある話として、ひとつのプロジェクトが終わったら、すぐに次のプロジェクトという使われ方をする人が多い。しかも最初から入れるわけではなく、すでに始まっているプロジェクトに途中参加するということも結構ある。

ソフトウェア開発の現場というのは、ルーチンワークなり、定まった仕事があるわけではなく、猫の手でも借りたいんだけど、簡単な作業があるわけではなくて、新しい人がいきなり入ると構ってもらえないということが多い。そこで、いきなりプロジェクトに放り込まれた場合の対処法について考えたい。

最初に認識しておかないといけないのは、いきなり放り込まれる時点で、プロジェクトが切羽詰っていると思った方がよいということだ。余裕のあるプロジェクトは人に余裕があるので手伝う必要がないからだ。

また、実力がわからないうちは誰もかまってくれない。何を任せていいかわからないし、スキルレベルは話を聞いてもよくわからないからだ。といっても、いきなりさらりとプログラムを書いてみせるというのも難しい。目に留めてもらうためには、まずは会話からである。

例えば、会話の端々に出てくる専門用語をうまくコントロールできるかどうかで、理解度がわかるというものである。当然、わからない用語が出てくると思うが、「ソフトウェア開発業界内での共通用語」と「組織/業務における専門用語」の２種類を区別できていて、前者がうまく扱えていれば、後者は教えてくれるだろう。前者については質問すると素人と思われ、後者については質問しないと素人と思われるので注意が必要だ。

最初は、仕事が与えられなくて暇かもしれない。しかし、ここで仕事をくれくれとせがむのも考えものだ。タスク割り振りする人は忙しいので、新しく入ってきた人に仕事をくれと言われても仕事の説明をする時間がなかなかとれないからだ。手持ち無沙汰でも、じっと我慢して本を読むなりして相手が暇になるまで待つのも仕事だ。

暇なら、業務に関係ありそうで、かつ１人でできるものを勝手に作って、評価してもらうのもよい。手当たり次第に今まで書かれたドキュメントを読み込んで、誰に聞かれるまでもなく当初の目的と現在の内容との乖離（ギャップ）を把握してみよう。

他の人はみな忙しく仕事をしているので、ドキュメントを振り返ったり、仕様に立ち戻ったりということをあまりしていない。一番状況を把握できる立場にいるのである。このチャンスは有効に利用しないといけない。全体を把握して、適切な状況説明ができれば、もう勝ったようなもんである。

まずは信頼関係を作ること。実力あっても、信頼されていなければ仕事は任せてもらえない。待っているだけではなかなか信頼も獲得できないし、自分の実力も発揮できないということだ。まだスキルが足りなくても、信頼されていれば教えてくれることもあるだろう。

急にプロジェクトに放り込まれても、慌てず騒がず、落ち着いていれば、それだけで一目おかれるような気もするけれども。生き生きしたソフトウェア開発プロジェクトになるように心がけましょう。

プログラムは分岐と分岐以外の2種類で構成されている

プログラムを勉強する時に、まず最初に行うのが「Hello World」を画面に表示することである。そしてその次に、データの種類、演算子、制御について覚えることになる。あまりに最初に出てくるので無意識的に使っていることが多いと思うが、プログラムは次に進むか、分岐するかのどちらかしかない。例外処理も分岐の１つだ。

一般的に、分岐が多くなればなるほど複雑になるといえるだろう。逆に言うと、分岐以外の部分は経路が1本なので複雑になりようがないのである。スパゲティコードと呼ばれるものは、分岐に分岐が積み重なって、流れが判断できなくなるところに問題がある。分岐と分岐以外を明確に分離したら、プログラムの構造が作る人にも見る人にもわかりやすいのではないか。

初心者がプログラムを学ぶ時に難しいと思われることの1つに、複雑になった１つのメソッドを複数のメソッドに分割する方法があまり明確でないということがあげられる。

共通なメソッドを切り出すのはわかりやすいが、それ以外にもただ単純に長いから分割せよと言われてもどこで分割していいのかよくわからない。そこで明確な方針として、分岐と分岐以外に分離するというのはどうだろうか。分岐用のメソッドは分岐ロジックだけに思考を集中できるので、少々冗長になるかもしれないが、バグの温床となるのを防ぐ事ができるだろう。

また、分岐は全て管理すべきものである。ラクだからという理由でコーディングの段階で勝手に分岐を増やすということは本来ありえない話なのだが、同じメソッドでいろいろなことを処理させようとすると、勝手に分岐が増えていく。そうならないためにも、分岐と分岐以外を明確に分離したほうがよいと思われる。

APIだライブラリだという前に、プログラムの構造はどうすれば必要以上に複雑にならないか、ということを考えないといけない。分割統治も分割の仕方を間違えたら意味が無いということだ。どんな高度な言語でも、考え方次第で複雑にもなるし簡単にもなる。MDAだから簡単になるとかは脳みそ思考停止状態である。キーワード１つで複雑さが解消できるわけではないのだから。

※　以前に書いた「IF文を極力減らすと見晴らしのいいプログラムになる」も、この記事の内容と重複している部分がありますので、興味がある方はどうぞ。

検索技術はIT業界で仕事をする上で最初に学ぶべき技術の１つ

一昔前では考えられないくらい、インターネットが発達したため情報量が爆発的に増え、またそれに伴い検索サービスが高度で高速になった。という文句はすでに使い古されている感があるが、仕事の中身は旧時代のままである。

なんのことかというと、YahooやGoogleで検索キーワードを入れて欲しい情報を調べようとしているが、誰も検索の仕方についての知識を社内で共有しようとしないため、検索に無駄に時間を使っているのではないかということである。

特に新入社員や、新しく入った人に対しての教育では、ぜひ検索に関する技術についてもカリキュラムに含めて頂きたい。１日調査に費やすのと、３分で回答を取得するのとでは大きく異なる。また、インターネットは万能ではないので、当然欲しい情報がない可能性も考えなければならない。どこで見切るのかも１つのポイントである。

検索している時間は確かにコストであるが、調査せずに作り後で後悔する可能性もある。なので短い時間で情報が取得できるのであればそれにこしたことはない。そういう意味で昔と仕事の仕方も変わらざるを得ない。なのに、検索技術という大事な部分を各個人任せにしてしまっていては、効率があがるものもあがらない。

まぁ探すものが曖昧であれば、検索キーワードも曖昧になるのでなかなか見つからないし、探すものがはっきりしてれば、検索キーワードも絞り込めるので、見つかりやすいというだけのことなのかもしれない。知らないものは探せないし、言葉に出来ないものも探せない。検索の限界を知って、検索する時は目的をもって、すばやく探せるようになれば、仕事もきっと素早く処理できることだろう。