アジャイル狂詩曲

スキル | ワークスタイル | 技術動向

» 2015/05/25

■死の行進曲

　そのプロジェクトは異様であった。
　プロマネとリーダー以外は社外からの寄せ集め。それも入れ替わりがはげしく3ヶ月前に入った人たちが、もう引き上げてゆく。リリースは分割リリースで、最初のリリース日がすぐそこに迫っている状況なのにプロジェクト内ミーティングの場ではプロマネとリーダが激しく言い争い、プロマネが「俺はこんな仕事、やりたくなかった」と言い放つ始末。

　当然の帰着としてリリースは2度程延期され、客先からは会社の体をなしてない、と言われてしまう。ようやく社長も本気になるものの、責任をリーダにすべて押し付けて辞めさせようとするが次のリリースが迫っている中で実行に移せず、代わりのリーダとして投入したプロパーも2ヶ月も経たずに心を病んで離脱。

　ようやく確保できた高スキルの技術者2名参画で、少しずつプロジェクトは回りはじめ、その後もいくつかのトラブルはあったものの空中分解は免れ、なんとかゴールにたどり着くことができた。

　最終納期は死守することはできたものの、大きな赤字プロジェクトで、加えて人的に被害も出たことも考慮すると、厳し評価は受けざるをえない。

■幻想曲

　このプロジェクトは何が問題だったのか。

　プロジェクト自体はBIツールの導入案件で、開発はデータマートの作成とツールを使った画面の作成。規模的には中規模で期間は1年と余裕がある。ただやり方はアジャイルを標榜し、客先の要望と仕様変更を積極的に受け入れ、仕上がった機能から何回もリリースを繰り返す方法。

　基幹システムのデータの評価・分析を目的としているため業務仕様が決まらないという点を考慮すると、アジャイルの方法論を取り入れることに間違いはないが、プロジェクトメンバーへのヒヤリング内容やトラブルの状況を見てみると、アジャイルに対する幻想がトラブルの原因になっているように思われる。

　例えば以下の様な状況だ。

• スケジュールは作成しない
• ドキュメントも作成しない
• リーダが勝手に客先と打合せ、仕様変更を受け入れてくる

　ひとつはアジャイルに対する勘違い。アジャイルソフトウェア開発宣言を見ても、スケジ　ュールやドキュメントを作らなくてよいとはどこにも書いておらず、計画やドキュメントの価値を認めつつもそれ以上に変化への対応や動くものに価値をおくとしている。

　もうひとつはアジャイルの徹底不足。プロジェクトはなんとなくアジャイルっぽく進んで　いるが、メンバーに話を聞くとアジャイルでやっているという認識がなかったり、アジャイルでやっているという事は知っていてもこれまでのやり方と何も変わっていなかったりと、アジャイルというやり方に対する意識は希薄だった。

　要は、プロジェクトがアジャイルという方法論に対して未熟だったという事だろう。

■交響曲

　プロジェクトはナマモノである。一つとして同じプロジェクトは存在しない。だから一般論としての手法を、そのプロジェクトに合わせてカスタマイズして取り入れないといけない。これまでのやり方（例えばウォータフォール）は、メンバーの身にしみついているので、そのことをあまり意識しなくてもプロジェクトは進んでいく。しかし新しいやり方はメンバーにとっても未文化なので、しっかり手法を設計してメンバーに徹底させないといけない。そうしないと、見た目は新しい手法だけど中身は古いままという歪なプロジェクトが出来上がる。時にその不整合は、混乱を招いてトラブルを増幅する。

　特にアジャイルは柔らかい。柔らかいが故、自由度がありすぎて難しい。だからしっかりとメンバーが思想を理解して、自律して動かないといけない。そこがアジャイルのハードルの高さだ。

　そして、特に難易度があがるのがプロマネの役割であろう。変化を受け入れるという事は、それだけコントロールが難しくなるという事だ。プロジェクトに入る前に定義をしっかりしないといけない。このプロジェクトでは何の管理帳票を作成し、どのように管理するか。そして、メンバーへの意識づけ。プロジェクトが進み始めると、時々刻々と変わっていく仕様に対して、ゴールを常に再定義し続けないといけない。

　ウォーターフォールであれば、多少プロマネのレベルが低くてもプロジェクトは進んでゆく。しかしアジャイルはプロマネの機能がきっちり果たせなければ、プロジェクトは発散してしまう。

　変化はコントロールできて初めて、受け入れられるものなのだ。

■鎮魂曲

　プロジェクトの失敗はプロマネに帰結されるというのは当たり前ではあるが、その事を踏まえても今回のプロジェクトの失敗はプロマネの機能不全にあったと思う。正確には、アジャイルではプロマネの役割が特に重要であるという認識が足りず、適当な人材をアサインできなかったことであろう。逆説的にいうと相応な人材がアサインできないのであればアジャイルという方法を採択してはいけなかったのかもしれない。もしくはPMOの役割がなく、この様なプロジェクトに対するチェック機能がなかった事も被害を大きくした原因ともいえる。

　しかし我々は、貴重な経験を積むことができた。「愚者は経験に学び、賢者は歴史に学ぶ」というが、失敗の経験をするという事は、愚者でも学ぶことができたという事だから。

　…しかし、そうなると世の中の失敗プロジェクトはもう少し少なくなっていそうなものだが、そうではないことを考えると、あまり当てにならない名言なのか、などと皮肉なことを考えつつ。