ふりかえらない「プロジェクト」をふりかえさせる

この記事はふりかえり Advent Calendar 2022の12月20日の記事として書いています。ほかにもたくさんの良い記事が掲載されていますのでぜひみてくださいね。

ふりかえらない世界

いまでは「ふりかえり」という言葉は一般の世にも、すくなくともITの世界では浸透してきました。別にアジャイルやスクラムの文脈の話でなくとも自然に「ふりかえり」という言葉は出てきますし、それに対する「ふりかえりって何？おいしいの？」みたいな反応も今では見られません。

しかしながらみんながみんな「ふりかえり」を習慣づけているかというとそういうわけではありません。「知ってはいるもののスルー」みたいなのが非常に多く存在します。

特に伝統的な開発手法を重んじる（受託開発を主としてきたSIerとか、それにおんぶにだっこの情シスとかウォーターフォール中心の世界）世界では、「ふりかえり」が一般化しているかと言えば、そうでもないというのが現実かと思います。

「システム開発プロジェクト」のふりかえり

たいていのトラディッショナルな会社はITシステムの新規導入や入れ替えをするときには「システム開発プロジェクト」という携帯を取って運営されます。ここには開発を実施に行うパートナー企業や、そのシステムを使う（使わせる）ビジネス部門や間を取りもつ情シスや経営企画などの部門で構成されます。そしてそのトップはかなり偉い人、社長とか専務とか常務みたいな肩書の人が就くことになります。

まぁ投資予算を確保しなければならない都合があるからなのですが、プロジェクトはお金と期間がはじめから決められています。期間は何年にも渡ることもよくあります。

こういった場合、実際にふりかえりを行うのはパートナー企業に限られてしまいました。なぜならサラリーマン役員の人気は短く、業務部門の人たちには「システム開発」なんてものはめったに回ってこないからです。経理部の人が次の経理システム刷新に向けて「次はもっと工夫しよう」と思っても、それがやってくるのは１０年くらい後ですし、そのときにはリーダーだった役員もとっくに引退しているからです。ふりかえろうにもふりかえりようがありません。

その反面開発パートナーのほうはふりかえりが可能です。プロジェクトが失敗するとその損失を押し付けられて赤字になったりするので、彼らは次のプロジェクトに向けて改善を行います。ですから最近はプロジェクトと言えばマニュアルとか規定に沿って、きっちりと計画を立て、長年磨き上げられた手法やツールを使用してプロジェクト管理（コントロール）を行うようにしてきました。その結果PMBOKも猛スピードで更新され続け、いまは開発側の問題でシステム開発プロジェクトが失敗することはだんだん少なくなってきています。

そういった意味ではウォーターフォールの世界であってもふりかえりは行われてきたのです。そうでなければPMBOKはこんなに高速でバージョンアップされません。

しかしプロジェクトの失敗はなくならない

しかしいっこうにシステム開発プロジェクトが失敗した話は耐えることはありません。なぜかと言うと開発側以外の原因はぜんぜん減っていないからです。

最近のプロジェクトの失敗といえば、要件があいまいだったり、顧客側が途中で要求を変えてきたり、要件通りに業務改革が実施されなかったりと、システム単体ではない問題により頓挫する例がよく見かけられます。
SIerのプロジェクト管理のポイントも「いかに要件をきっちりまとめるか」「撤回できないほど顧客側の承認をきっちり取る」「とにかくドキュメントごとに顧客に承認させる」「要求変更は受け付けないようにして、やるなら別費用、別プロジェクトとして実施」みたいなものに集中しています。だから大手SIerのドキュメントはどんどんとぶ厚さを増しているのです。

でもSIerたちだって自分の生存権（利益）を守るためなので仕方がないですよね。

「プロジェクト」はふりかえらない

話をもとに戻すと、現代のシステム開発プロジェクトの失敗は開発側以外〜つまり「ふりかえり」を行わない人たちが関わる領域に集中しているのです。とはいえ相変わらずその人達にふりかえる要素はありません。やっぱり爺さんは次々に引退していくし、業務部門にはめったにシステム案件は巡ってくることはありません。

・・・・結果として「要件定義」「要件変更」が明日もシステム開発プロジェクトの失敗を生み続けることになります。

「プロジェクト」をふりかえるようにするには

このままでは「システム開発プロジェクト」は一生うだつが上がらないままです。でも犠牲者は繰り返し生み出されるのでなんとかしなければなりません。ほおっておくと誰もへーしゃのシステム開発プロジェクトを請け負ってくれなくなってしまいます。

そこで色々やっている策を挙げてみます

プロジェクトごとにふりかえりを実施する

正攻法なやり方ではあります。プロジェクトの終わりに「ふりかえり」を実施するように提案して挑んだ事はあります。
アジャイルとかスクラムを学んでいない人が多数はなので、ふりかえりを行うはずが「反省会」になってしまったり、ふりかえるところがプロセスの最期のところ（つまりはリリース後のバグ）に集中してしまったりと様々な失敗を繰り返しながらではありますが、続けてきました。

やらないよりは遥かにマシだと思うのですが、やっぱり根本的な部分・・・ふりかえりの結果を使う場所がない人が多数派・・・・二度とシステム開発プロジェクトに関わらない人の比率が多いという問題は解決されません。

情シスが主導権を取る

ユーザ企業において、業務部門や経営層がふりかえっても仕方がない状況というのは仕方がありません。なおしようがないのですがユーザー企業の中で唯一「ふりかえり」を行う勝ちがある人達が居ます。それは「情シス」〜会社のシステム部門の人たちです。少なくともこの人達は業務部門よりも繰り返しシステム開発には関わります。
いままで「調達部門」とか「橋渡し」、「システム屋の通訳」でしかなかった情シスがしっかりとプロジェクト〜を業務サイドからしっかりとホールドしてマネジメントすること（要求レベルからしっかりマネジメントする）をするようになれば「ふりかえり」は有効に機能して、過去の教訓が生かされるようになるはずです。

今、民法の改正とかがあってソフトウケアの完成委託開発は難しくなり、だんだんと準委任に移行してきています。業務要件が失敗の最大の原因である限りはリスク回避のために必然的にもっと準委任契約にシフトすることが考えられます。

準委任に置いてはシステム開発の結果の責任は「受託側」ではなく「発注側」となります。そういった流れからもユーザ企業側に責任が移るので、これを機に主導権を情シスに移管すべき・・・ということになります。

「プロジェクト」をやめてしまう

一番いいのが、プロジェクトの形式を辞めてしまうことです。不満とか不足をどんどん貯めに貯めて、数年おきにシステム開発プロジェクトで一気に放出する・・・・という「プロジェクト」という手段は、変化の激しい今のビジネスの世界には合致していません。

しかし世の中にはECサイトの強化ですら「プロジェクト化」して実施しているところがまだまだあると思います。結果として、つくってみたものの効果が薄かったり、リリースしたときには既に時代遅れ・・・という結果になってしまいます。

いっそのこと「プロジェクト」ではなく「ず〜〜〜〜〜〜〜っと改善し続ける」に変えてしまったほうがマシだと思います。大きな事はしずらくなりますが、顧客への提供スピードも増しますし、準委任で毎月話し合いながらリリースするものを決めていく方式ならば、完成委託みたいなプロジェクトリスクも無いので、結果リスク対応コストがほぼ無くなるのでコストも下がるはずです。（実際下がりました）

いまやインフラ部分がクラウドに移行し「インフラの入替」というタイミングがなくなってきたので、出来るところからでも「プロジェクト」をやめる方向にもっていくのはどうでしょうか？

まとめ

社内システムに大きく関わる「システム開発プロジェクト」というものにフォーカスを当てて掘り下げてみましたが、いがいなところに「ふりおかえり」が有る無しの影響があることがわかりました。
いろいろ考えると、「ふりかえり」って、アジャイルの一部ではなくて、むしろ「ふりかえり」を行うために必然的に発生したような気もしてきちゃいます。

とにかく「ふりかえり」ができる仕組みに向かって今後も頑張ろうと思うのでした。