メテオフォール型開発と2025年の崖

メテオフォール型開発(※1)とは、2018年に日本で提唱されたシステムは開発手法。

当時、日本でもPIMBOK6版が出版され、従来のウォーターフォール型開発に加えアジャイル型開発が体系に追加された。これにより、システム開発の現場では実務の状況に合わせたシステムの開発手法の選択が推奨されるようになりました。

そんな中、当時の日本で最も広く活用されていたとシステム手法の特徴を叙情的に体系化したものがメテオフォール型開発です。

メテオフォール型開発はトップダウン的にリリース内容とリリース日のみを黙示録と言う形で決定し、あとは現場のエンジニアが死ぬ気でなんとかすると言う開発手法です。

現在の日本のレガシーシステムは、メテオフォール型開発によって開発され維持されているものが少なからず存在するとか、しないとか考えられるが、最近の労働環境の変化の影響を受けてメテオフォール型開発の継続が困難になってきている。これが2025年の崖の問題のひとつの要因(リスク)と考えられる。

元々、メテオフォール型開発を成功させていたのは、スーパーSEと呼ばれる人達の貢献によるものが大きい。スーパーSEはシステムの稼働を全てに優先させることを美徳とし、生活の全てを仕事に捧げる人たちです。また飽くなきテクノロジーへの探求心により幅広い知識を得ていて、さらにその知識をより拡張性し続ける人たちです。一説によると週90時間程度を目安に働いていたとか。業界では神に近い存在で、目に見えないデータの流れが見えたり、複雑怪奇なシステムの全体像を把握していたり、言ってみたら預言者です。これらの人達は日本の大規模ITシステムの黎明期から第一線で走り続けている人が多く、常にIT業界を第一人者として走り続けてきた人達と言えます。

しかし、これらの世代が加齢により、徐々に第一線を退く年代となってきました。それに加え、近年の労働時間管理の厳格化、ライフワークバランスを重視する価値観への変化、転職市場の活性化によるスーパーSE候補のコンサル化(※2)が進んでいます。これにより新たなスーパーSEは生まれにくい環境となってしまいました。結果としてシステム開発の現場にいたスーパーSE達が急激減っていくことでしょう。

このような背景から2025年の崖の問題を考察すると、メテオフォール型開発が破綻するリスクが、スーパーSEの消失により顕在化する可能性ある時期が来た問題と捉えることができます。

そこで、2025年の崖を乗り切るための対策案を考えてみました。

1.ズバ抜けた報酬の募集によるスーパーSE候補者の獲得(コンサル化の防止)により、無理やりメテオフォール型開発を推し進める。

2.雇用延長による現在のスーパーSEの延命により、無理やりメテオフォール型開発を推し進める。

3.スーパーSEに依存しない開発手法の実現のため、メテオフォール型開発を取り止め、アジャイル型開発の応用した、無理の無いショートゴール設定と、進捗阻害発生時の目標(ショートゴール)の見直しを可能とする。

レガシーシステムに悩みを抱える日本企業は、まずは自らのシステム開発手法の現状を調査し、必要に応じてこれらの対策案を検討するべきだと言うのはきっと過言でしょう。

残念ながら、多分この話はフィクションです。

(※1)参考url

https://eiki.hatenablog.jp/entry/meteo_fall

(※2)スーパーSE候補のコンサル化の問題は、コンサルがシステムの稼働の責任を追わない職種であること。多くのコンサルはシステム開発の上流工程のみを担当する。一方、スーパーSEは下流工程まで責任を持ってやりとげるため、メテオフォール型開発の実行力がある。

データセンターって寒い

マシン室退館 酷暑心地よく

奴隷SEを育てる魔法の言葉

とある日経の記事にて、SIerの奴隷根性を何とかせよとアブラギッシュな顔で語られている。あまり好きじゃないつもりであったが、いつもついつい目に止まり、読んでしまう。結局のところファンになってしまっているのかもしれない。

さて、その方の好きな単語である奴隷根性について思うところがある。

それはIT産業の格子にSEの奴隷化を求める仕組みが作り込まれているのではないかと言うこと。ここでは分かりやすく、ユーザー、SIer、メーカー(ベンダー)の３階層で整理する。IT業界の場合メーカーはほとんどアメリカ企業と考えて良い。メーカーは圧倒的な開発力と、コンセプト力でIT市場の動向をコントロールし、自社の製品を導入しないと、時代遅れのITシステムのになると言う不安をあおる。日本のユーザーやSIerにはことコンセプトを覆すだけの青写真を描く力はないため、この流れにただ身を預けるしかない。確かに新しい製品をコンセプト通りに使い、今まで新しい使い方へと変化することによって、効率や価値が産み出せると言うことはあるだろう。しかし、日本の多くのユーザーは業界に遅れないように新しい製品を導入したい。にもかかわらず、今までの使い方はなるべく変えたくない。そんな流れから、自身の現行システムを分析し、期待するメーカーの製品を示唆する形でRFPを作り、複数のSIerからの提案をもらう。提案と言っても、RFPにはざっくり言うと現行踏襲と書かれているだけなので、おなじ使い勝手で最も安いSIerを採用することになる。さて、SIerは過酷の入札を勝ち抜くために限界までダイエットした見積で契約が成立する。契約した時点ですでに赤字と隣り合わせのギリギリの見積となる。そうなるとあとは生き残る術はやる内容をいかに最小限におさえるか。つまり書いていないこと、言われていないことにいかに手をつけないかが生き残る術となる。当然ながら、SE工数の赤字はSIerにとって死を意味する。こうして無事にひとつの奴隷根性のSIerができあが上がった。

他にも

「見積の妥当性を確認するために工数の明細を出せ」→当然ながら、言われた作業だけすれば良いと言う意識付けの効果がある。

「製品不良な相性問に対して当初の計画から変更を許さない」→次からリスクのある目新しいことに消極的になる。かなり具体的に要件をまとめないと着手しないようになる。

「障害発生時に再発防止策を共用する」→言われたルール・対策のみ守れば良いと言う思考になる。

こんな環境で、こんな言葉を浴びなが仕事の経験を積み重ねることで一人前の奴隷SEが成長することになる。

これは死を意味する赤字を回避する為の生存本能とも言える。

結局は相手の見え方と言うのは写し鏡。奴隷のようなSEに不満がもしあるのならば、それは奴隷であることを求めているからなのではないかと感じたと言う話。

プロジェクトマネージメントに真面目に取り組むと組織が疲弊する件

プロジェクト推進の費用の公平性と透明性を確保するためには入札が必要だ。

入札のためにはシステムがほしいか明確にし、RFPをまとめあげる必用がある。RFPに対しての回答は、対応項目に×のある提案は論外。RFP記載のとおりに提案したベンダーの中で最も安いベンダーを、採用べきだ。

さて、RFPを参照して入札するベンダー側はと言うと、お得意様のRFPには、必ず回答しなければならない。記載の内容はすべて○にしなければならない。費用は最大限切り詰めなけらばならない。さもなければ、あそこはやる気がないと思われ、今後の声がかからなくなってしまうかもしれない。そして、見積の不確定要素のリスクを低減するため、できる限りの手弁当である程度の設計を進める。

そんな努力のかいがあって、ユーザ企業は特注のシステムを割安で手に入れることができるベンダーを決定。

そうして、システムの完成に向けてユーザ企業とベンダーでタッグ組んで走り出す準備ができた。しかし、システム開発の契約ができた途端にユーザ企業とベンダーの敵対的関係が始まる。

ユーザ企業は、契約した金額の中で設計が具体化するにつれて明確になってきた課題の取り込みを要求する。コスト増やスケジュール遅延を防止しなければならない。

一方、ベンダーは契約時に確定した限られたリソースで利益を確保しなければならない。そのため、実施内容は極力最小限にしたい。RFPに記載の項目のみにスコープを絞って、プロジェクトの損益悪化を防止しなければ会社がつぶれてしまう。

こんなそれぞれの思いからプロジェクトの完了までユーザ企業とベンダーの言った言わないの敵対関係が続くことになる。

真面目な取り組めば取り組むほど対立は明確になる。

結果として出来上がるのは何でも押し込もうとするユーザとユーザが予め言ったことしかやらない奴隷のようなベンダーの関係性だ。

真面目に仕事に取り組んでいるのに不幸なものだと思う。

そして、奴隷のようなベンダーが作り上げたシステムは必要最小限にしぼった気の効かないシステムとなる。

ユーザ企業は、気の効かないベンダーに動いてもらうのと、気の効かないシステムを扱うのにヘトヘトだ。

ベンダーは、わがままなユーザ企業の要求を実現するために、手弁当の入札対応の設計と、ほとんどの利益の出せない特注品のシステム開発でヘトヘトだ。

結局、ユーザ企業もベンダーも余力はほとんどなく、疲弊する日々を毎日ただ過ごすのみとなる。

では、疲弊しないためにはどうするか。

ユーザ企業は入札結果×の部分を認め、自身で○とする為の体制の確保してまで対応が必用か考える。そして値段のみではく、担当者自身が一緒にシステムを作っていきたいと思えるベンダーを採用するべきだ。こうすることで、担当者自身のシステムに対する思いが強くなり、自発的にシステムの改善を検討できるようになると思う。

一方、ベンダーはRFPのやりたくない項目を×のまま回答する勇気をもつこと。自身のソリューションパッケージやSaaSの長所を全面的に押し出した提案とし、×となる項目への対応は顧客自身で考えてもらう。REP通りの特注品の開発をやめることで、ユーザ企業と体力の削りあいをやめることだ。特注品は一見売り上げは大きいように見えるかもしれないが、案件を通して組織内部に残る価値はあまりなく、ただ主担当のメンバーが疲弊するだけだ。特注品作るリソースで、しっかり得意なものを強化し、実績を増やすことに、注力するべきだ。そうすることで自身のサービスをしっかり成長させられると思う。自身のサービスの強化と思えば、少しは気の効いたシステムを作る気になるのではないかと思う。

では、自身のサービスな強みはなく、特注品を作るしか無い場合はどうするか。それは、RFPの回答(請け負いの案件)ではなく、単に技術者の派遣の提案なのではないかと思う。名ばかり請け負いが行き着く先は結局は双方の疲弊だと思う。

UU2000

昨日までのトータルUUが2000らしい。

キリがよかったのでつい投稿です。

昔、キリ番ゲトーが流行っていたのを思い出します。

さて、このブログの初投稿を見てみると8月16日。ちょうど去年の夏休みに始めたので、ほぼ一年です。

そして、この投稿はちょうど40回目

かなりスローペースでやっているわけですが、こんなインターネットの片隅に一年間でのべ2000人も訪問いただけたことに感謝です。

それと、同時に、何かを伝えようと思って文を書くのはなかなか難しいなと痛感してます。

写真を撮って感嘆な投稿も、たまにはしたくなるものです。