"ムダ"が極力省かれた構成体であるプロジェクトでは、一見"周辺的"問題でも致命傷を！

　ソフトウェア開発プロジェクトを蝕むさらに10の過ち／CNET Japan／2012.07.02

　最近わたしは、ソフトウェア開発プロジェクトを蝕む10の典型的な過ちについての 記事 を書いたが、その後、読者から数多くの貴重なコメントを受け取った。今回は、TechRepublic読者からのフィードバックを集めて、さらに10個の典型的な過ちをまとめた。

　１．「ノー」と言えない

　ある読者は、「プロジェクトマネージャーやチームマネージャーがノーと言えないと、要件変更があまりにも頻繁に発生してしまう。『イエス』と言うべき時と、『ノー、次のバージョンまたはアップデートの時まで待って下さい』と言うべき時をわきまえていなければならない」とコメントしてくれた。彼は正しい。要件変更は、プロジェクトにとって想像以上に大きな問題になる場合がある。......

　２．プロジェクトが大きすぎる

　要件変更と似た問題に、プロジェクトの仕様が大きすぎるというものがある。次の通り指摘をくれた読者がいる。

　「多くのプロジェクトは単に規模が大きすぎ、カバーする範囲が広すぎる。多くの場合、仕事の範囲が大きくても、一歩ずつ進めていった方がよい。明確に定義された、管理しやすい作業群を実行することに集中し、先に進む前に土台を固めていくべきだ。......　」

　３．関係者を議論から閉め出している

　また別の読者は「わたしは、あるソフトウェア開発プロジェクトを離れたところだが、そのプロジェクトでは、わたしはプログラマーではないと言われ、議論の輪の中から閉め出されていた。......」と述べている。

　あまりにもひどい。確かに、プロジェクトメンバーを打ち合わせに呼ばないのには、それなりの理由があることも多い。......「船頭が多すぎる」という問題が起こりがちだという理由もあり得る。しかし結局は、プロジェクトの全員が、少なくともどのような議論が行われているかを知っている必要がある。......　隠された要件を満たすこと　......

　４．機能よりも形を重んじる

　長年の読者であるTony Hopkinson氏は、関係のないことにのめり込んでしまうプロジェクトが多いと指摘しているが、彼は正しい。例えば、プロジェクトそのものが「ダッシュボードを作る」というものでない限り、ダッシュボードに取り組み始めるのは、アプリケーションの実際の機能が整ってからにすべきだ。準備が済む前に、プロジェクトの細部に手を取られてしまってはならない。

　５．何が問題かを知っている人間を無視する

　この教訓を指摘してくれた読者は「前線にいる人間の話を聞かないという失敗がある。これは、......　開発者が突き当たっている問題を助けようとして情報を知らせに来た人間を、マネージャーが罰するというものだ。これによって、マネージャーから悪いニュースを隠すという土壌が形成される」と述べている。
　......残念ながら、これはソフトウェア開発プロジェクトに限った話ではないが、間違いが非常に高くつくということを考えると、ソフトウェア開発プロジェクトでは特に問題が大きい。

　６．知らぬ間に責任を負わされる

　......　ある読者は、わたしがまったく考えていなかったものを指摘してくれた。それは、知らない間に責任を負わされるという問題だ。彼は次のように説明している。「わたしは『いつのまにか責任を負わされる』という問題も目にしている。例えば、特定の作業のために新人が配属され、その後なんらかの理由で、まったく関連のないプロジェクトに異動になったとする。言うまでもなく、これはもともとのプロジェクトとスケジュールにとって破滅的な影響を及ぼす」。まったくその通りだ。

　７．計画を立てる前に約束する

　また、ある読者は、電子メールでわたしの最悪の悪夢の1つを思い出させてくれた。それは、開発者と話をする前に、顧客に「イエス」と言ってしまう営業担当だ。これは多くの場合、ベンダーと顧客の双方を、悲惨さ、苦痛、欲求不満、失望に導く道だ。プロジェクトはすぐに遅れはじめ、開発者は非現実的な期限を守ろうと苦労することになる。

　８．最先端の技術に頼る

　開発者のMichael Graziano氏もまた、電子メールで多くの提案を送ってくれた。その中の1つに、まだ新しく実績のない技術をプロジェクトで使おうとする開発者の習性があるが、......　これをやると、プログラミングは綱渡りになる。その新技術には圧倒的な利点があるのか。今後使われない技術を使おうとはしていないか。正しい技術の選択はひとつの芸術　......

　９．自前の技術を使う

　上述の開発者が指摘したもう1つのポイントは、多くの開発者はフレームワークやライブラリを購入するのではなく、自分で設計して書きたがる習性を持っているということだ。自前のライブラリやフレームワークには利点があることも多いが、欠点もまた多い。自前のフレームワークとライブラリの設計、開発、テストの作業に取りかかる前に、そうすることの重要性をしっかり評価すべきだ。

　１０．間違ったプロトタイプを作る

　同開発者からの最後の項目は、プロトタイプに関するものだ。......勘違いしないで欲しいのだが、プロトタイプを作るのはよいことだ。......危険なのは、プロトタイプに多くの時間をかけたが、実際の製品を作る際には役に立たない教訓しか学べないということが起こり得るということだ。......　（ ソフトウェア開発プロジェクトを蝕むさらに10の過ち／CNET Japan／2012.07.02 ）

（ ※引用者注 ―― 文意を損なわないよう留意して割愛しています。）

　リソースに "ムダや遊び" が許された環境では、物事の達成効率が緩慢となる分、"些細なミス" が決定的な影響力を持つことにはなりにくい。しかし、高度な達成効率が目指される "プロジェクト" では、"ムダや遊び" が排除されている分、"些細なミス" や周辺的な問題が "プロジェクト" の進行を大きく撹乱することに繋がってしまうわけだ。
　こうした "当たり前の道理" が意外と意識されていないのかもしれない......　(2012.07.04）