不確実な時代を生き抜くエンジニアリング組織論｜SEカレッジ ウェビナーレポート

この本では、「エンジニアリングとは不確実性を減らすことである」ということを説明しています。

これは不確実性コーンの図ですが、プロジェクトを始めた最初の見積もりは実際と 4 倍くらいの幅があり、後半になると徐々に見積もりの確度が上がることを示しています。組織でも、社長の言った曖昧なことから最終的には具体的な行動になり、不確実性を減らしています。

こういった不確実性を上手に扱うには、どうエンジニアリングするべきなのか、それを本では様々なトピックを紐解きながら解説しています。

では、その不確実性とはなにか、それは人間が本質的にわからない「未来」と「他人」の 2 つです。

まず “未来” に対する不確実性を取り除く方法は、 実験して仮説検証 することです。不確実でわからないからこそ、実際にマーケットに聞いてみましょう、回数を増やしましょうというアプローチです。

もう一つ、 “他人” がわからない場合は、身も蓋もない話ですが、実際に コミュニケーション するしかありません。

ただ、人間は不確実なものには本能的に恐れを抱き、攻撃的行動を取ったり、回避的行動をして ( Fight or Flight ) 、向き合おうとしません。コロナ禍でこの 2 つの行動が至るところで起こっていましたね。

こういった恐れがあるので、不確実なものに向き合う心理状態を作るのは難しく、そこで必要になるのが 心理的安全性 です。

不確実性に向き合うためには責任感をもって様々なことを言い合って仮説検証して、失敗やうまく行かなかったことは “暴露” しないと進められません。この心理的安全性が低いと、プロジェクト後半のギリギリになって「間に合わない」「失敗してました」といったことが “暴露” されたりします。

一方で “コミュニケーション” は、ソフトウェア開発の生産性にも影響します。

実証的なソフトウェアエンジニアリングの研究では、たとえば、ペアプログラミングやモブプログラミングによる品質改善は 10 % ～ 15 % の効果がありますが、前工程の要求段階で、顧客などとインスペクション^注をすると 30 % ～ 45 % 品質改善に繋がることがわかっています。

本ではこの “コミュニケーション” を「楽しくみんなで話しましょう」といった意味ではなく、 情報の非対称性を削減すること と定義しています。情報の非対称性とは、自分が知っていて相手は知らないこと、相手は知っていて自分は知らないことを意味しています。

この情報の非対称性によって、例えば、稼働しているシステムを見ても、営業のようなポジションからは「ちゃんと動いている」と見えても、 IT エンジニアには中身が見えるので「良くない」とわかり、それにより対立が生まれたり、判断を誤ることもあります。

この情報の非対称性が大きい状態でも認識の齟齬を解消できることが “コミュニケーション能力” です。

さらに進めると、実は組織構造はコミュニケーションの構造そのものなのです。

コンウェイの法則で「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」とあるように、悪い組織構造だと悪いシステムを生み出してしまいます。

こういった組織構造などをリファクタリングしながら、不確実性に強い新しいエンジニアリングを作りたいと思って書いたのが、この本です。

昔の「作れば売れる」といった硬直した構造から変わったので、今を “不確実” と捉えるようになったと思うのですが、それによって起こった変化はあるのでしょうか？

昔は “業務の効率化” が主な目的でしたが、今は “マーケットの不確実性に対応する” システムが求められるように変化しています。

なるほど。その “不確実性” に対応するため “内製化” にシフトする会社が増えています。そこでベンダー側の SIer はどのようにポジションすればよいのでしょうか？

まず前提として、これは大変よろしくないと思っているのですが、インターネットでは「 SIer に所属している IT エンジニアはレベルが低い。 SI のビジネスは良くない」と分断を生み出すような記事がよく出ます。

所属場所が違うだけで IT エンジニアのスキルセットは変わりません。

SIer であれ、内部の所属であれ、優秀な IT エンジニアにいてもらうことで生産性は上がります。その IT エンジニアが SIer に所属しているのであれば “共創” できるように、いろいろな会社が新しい方式を考えています。

例えば、ゲーム業界ではレベニューシェアを最初から契約の中に盛り込むことがあります。

具体例を挙げると、モンスターストライクの開発では人月単価ではなく、レベニューを分け合っています。これであれば、利害関係の衝突が起きませんし、 IT エンジニアのパフォーマンスを監視するようなコストも下がりますよね。

このように SIer もビジネス構造の問題を共創できるようにリファクタリングすればよいと思っています。

開発チーム内にアジャイルで積極的に進めたい人と、そうではない人が一緒になることが起こりがちです。この場合、どのようにアジャイルを進めればよいのか、アドバイスを伺えますか？

私はアジャイルをよく「自転車に乗る」ことに例えて話すのですが、「定期的に右足と左足を交互に動かして、車輪のバランスを取って … 」といった理屈では自転車は乗れるようになりません。「乗ってみて、何回か転びながらやってるうちに、乗れるようになる」のが自転車です。

この「乗ってみる」と「転ぶこと」 = 「どう上手に転ばせるか」が大事で、転んだところをみて「それ見たことか！」となじっても上手く乗れるようになりませんよね。

もともとアジャイルは日本発でアメリカから再輸入されて、なぜか “クールな方法” と捉えられてしまったのですが、根底にあるのは、この「自転車に乗る」と同じなんです。

つまり、アジャイルは決して “クールな方法” ではなくて、めちゃくちゃ泥臭くて、泥にまみれるという話でしかないんですね。

なので、「アジャイル開発をやりたい」という言葉は「泥にまみれたい」と理解すればよくて、なら「一緒に泥にまみれようぜ」と返せば、前に進むものだと思っています。