開発のやり方
（毎度、言いますが、サラリーマン風情の個人的意見ですので、あまり目くじらをたてないでくださいｗ）
システム開発のプロジェクトマネージメントでは「アジャイル」開発がまるで、魔法の道具のように扱われているので、やってみて、当然だけど、大失敗して、炎上。「ウォーターフォール」の方が同じ炎上するならましやったわ！「アジャイル、クソじゃん！」と言うお話をよく聞くので、「開発のやり方」について、ちょっと考えてみることにする。
そもそも、「炎上」した原因って分かってます？
某銀行のシステム開発のプロジェクトが約4000億円をドブに捨てるほどの「大炎上」を起こしているという。この某銀行のシステム開発は前にも大破綻して、本にもなっていた記憶がある。
僕はよく火消し人員（ファイアーマン、消防士さん）として投入されることが昔よくあった。当然、炎上した後に。（「ITざっくばらん会」の1回目でもその辺の話はしましたが）その経験（といってもたいしたことはない）から言うと、新入社員がやって、真っ先に怒られるようなことをベテランの開発者が平気でやって、さらにそれで発生した問題を放置しているパターンがびっくりするほどたくさんあって、てんやわんやに。
具体的に言うと、「アクションアイテム」の管理ができていなくて、「誰が、いつ、どこで、どのように、優先度は」などがさっぱり分からず、開発を続けて、「あの人がやってくれるんじゃなかったん？」と平気で責任の擦り付け合い。挙句、「やるしかないんだ！」と気合論。これが何十年もシステム開発に携わってきた人たちが何時間も会議で議論した後で言うわけで･･･もう･･･ね･･･。
さて、この手の話はどこにでもあると思うのだが、これは「開発手法」の問題ではないと思う。きちんと炎上した「原因」がどこにあるのか。
それは、マネージメントなのか、それとも個々のスキル不足なのか、そもそも工程に無理がなかったか、モチベーションなのか、メールでの「ホウレンソウ」はできてたのか･･･そんな細かいところまで落としこんだ振り返りもせずに、開発をまた続けていき、にっちもさっちも行かなくなって、「誰か助けて」状態。周りからすれば、「またかよ。」ということで、また繰り返し。
こんなことじゃ、「開発手法」という「器」を変えたところで、何にも解決しないわけで。
「開発手法」の選定の前に、「体制」を見直すべき
「開発手法」の云々の前に、開発体制を見直すところから始めた方がいいと思う。これは決してリソースを増やせ！というわけではなくて、リソースがないなら、それなりの工夫をして、それにマッチしたまず「体制」をつくっていくことが大事なんじゃないかなと。その出来上がった「体制」にマッチした「開発手法」を選定していけばいいのではないかなと思う。別にウォーターフォールならそれでもいいし。アジャイルでもいいと思う。
それで「開発期間」が短縮できれば、浮いたリソースで新開発やら保守に工数をまわせて、「経済的効果」にもつながるんじゃないかな、なので、費用対効果としては、炎上するよりもすごくよくなるはず。
ちなみにアジャイルは悪い手法ではないと思う。いかに体制にマッチするようにアレンジできるかだと。ということで、以下を参考資料に。
（ソフトウェア開発期間短縮の取組み）
ということで、この辺で。
【了】
記事を読んでいただきありがとうございます！ いただいた投げ銭はプログラミングスクールの運営費（修理や機材購入）に使いますので、よろしくお願いします。