大規模プロジェクトの失敗と変化の許容

大規模案件の炎上話は胸が痛みますね・・・ 自分も若いころ「連日終電、月に休みが１〜２日」を数ヶ月という経験をしましたが・・・ここに書いてあることが本当だとすると、想像を絶します。

blog.livedoor.jp

いやー・・・これは・・・

下請けの方々におかれましては、まだ未来もあることと思いますので脱出も視野にいれて良く考えて頂ければと思う次第です。 後ろ指さされたっていいじゃないですか。 心を病んでまでするべき仕事ではありませんからね。 経営者の方は大変でしょうけど・・・。

弊社では、さすがにこんな酷い状況はめったにありません。 普通に休めてますし、帰宅して夕飯食べて子供がネタ後に妻と海外ドラマを観る余裕だってあります。 今夜は、「２４　リブ・アナザー・デイ」の最終話みちゃいました。 いやー・・・しかし、あれは・・・

観終わってグッタリしたわー。 だってジャックが、ろ、、おっと。

そんなわけで、責任感とガッツあふれるのに不幸な事故に巻き込まれてしまったIT戦士の皆様。 大企業の失敗を押し付けられて溢れる才能や家族との時間を無駄にしているなんて、もったいないですよ！ 弊社では絶賛エンジニアの方を募集しております！普通のライフワークバランスを取り戻しましょう！ （謎の宣伝）

それにしても、なぜいい大人が大勢集まるプロジェクトが大失敗してしまうのでしょうか。

企業間の利権のせいでしょうか。 いまだにウォーターフォールだからでしょうか。 多重構造のせいで、１次請けはボンクラなのでしょうか。

いずれも要因としてあるかもしれませんが、最も致命的なのは「ソフトウェア開発は問題の細分化が難しいから」ではないかと思います。

大きな問題に直面した場合、解決のセオリーは「細分化」です。

一般的に、問題が大きくどこから着手していいかわからない場合、行動プランを立てられる程に問題を分割し、優先順位を決めて着手します。 これはソフトウェア開発に限りません。

２００人でなわとび１００回飛んでください！と言われて、大縄跳びで２００人同時に１００回飛べるでしょうか？ 誰かが縄に掛かっただけで失敗。 回す力が不十分で縄が弛んだら失敗。

こんな仕事、とても不可能でしょう。

でも５人ずつ個別に１００回飛ぶのを４０組やればOKならどうでしょう。 これなら達成できそうな気がしますね。

しかし、ソフトウェア開発ではこの分割をされることは、ほぼ無いです。

設計・開発は、機能単位に分割して実施しますが、最後に一つにまとめてゴールしようとするのですから一塊に扱っているのと同じです。

「上場企業の基幹システムのリプレース案件」と聞いて何を思うでしょうか。 この業界が長いほど、デスマーチの未来が脳裏をよぎると思います。

でも、こんなスケジュールだとしたらどうでしょう。 最初は「顧客管理」だけ作ってリリース。 その後、「受注」を作って結合してリリース。 一段落したら「在庫管理」を作って結合してリリース。 その後も、「発注」「請求」「経理」と、段階的にリリース。

一気に刷新となると大炎上を覚悟するところですが、上記のように機能単位で開発・リリース出来るなら、なんだか行けそうな気がするぅ〜。（古い）

しかし実際に、上記のように対応することはありません。

なぜなら、後半の開発で設計が変更になった場合、前半につくったアプリまで修正する必要が出てしまうからです。 特に「データ設計」は、後からの変更が非常に面倒くさい。

後で変更が発生したら、ドキュメントも大幅修正。プログラムも大幅修正。 データベースに至っては、テーブル構造から変わるかもしれない。 既存データへパッチを当てないとダメかもしれない。

などなど。 想像すればするほど、うんざりしてしまいます。

「だったら最初から全部考慮しとこうよ。」ということで、全部まとめて整合をとろうとしちゃう。 そして失敗してしまう。

悲惨な歴史の繰り返しなのであります。

しかし。

逆に考えると「単機能開発、後から結合」が実現出来るのであれば、もはや大規模プロジェクトなど恐れる必要はなくなります。 簡単に言えば、個別に作った後くっつけるときにくっつけ方を考えれば良いのですから。

「あー、受注と請求をくっつけるには、請求側に受注データのキー持たせないとですね〜。」 「なるほど、じゃぁ受注データのキー渡せるようにしますね。」 「OK。くっつけられるように次のリリースでカラム追加しておきまーす。」

なんて、気軽に会話出来ればいいわけです！

昨今流行りのアジャイルやスクラムも、人にフォーカスしつつ、その根底を支えているのはCIツールや、テスト自動化があってのことと思います。 つまり製品の品質担保を自動化し、大きな変更が発生することを許容することで、ソフトウェアにおける問題の細分化と向きあおうとしているのです。

ここです。ここ。

「変化を許容すること。」

特にデータ構造の変化の許容と品質の担保。 その手法の体系化とツールによる自動化。

これらが可能になれば、ウォーターフォールでも全く問題ありません。 日本のIT再生の鍵はここにありや！（大げさ）

変化を許容せよ！

ん？どこかで聞いたような・・・ ２００１年頃流行った、エクストリーム・プログラミングかな？

ケント・ベックは、もうずっと先に行ってたんやな・・・。

いずれにしても、今年後半は「変化を受け入れる」活動に注力していきたいと思います！ まずはテスト自動化の確立からっ！

なお、弊社は絶賛エンジニアの方をぼｓｙ（しつこい

アジャイルサムライ−達人開発者への道−