「バグが出てこないのは品質が悪い！」と叱られ…
牛尾 今となっては笑い話ですが、昔ある企業でやっとの思いでアジャイル開発の導入が認められたんですね。「絶対失敗するからやめなさい」「品質保証できない」と管理職から猛反対されたのを押し切って。
で、チームが当時の新しいやり方でコードを書きました、テスト駆動開発というのですが、それをしたらものすごくバグが少なかったんです。そしたらなんて言われたか？
「バグが出てこないのは品質が悪い！」
上の人たちはコードが読めるわけではないので、当時このくらいのコード量を書いたらこのくらいのバグが出るばずだという統計資料があって、「お前らがちゃんとテストしていたら、統計上もっとバグが出るはずだろ！」とお叱りを受けた。
埒が明かないので、通常はバグに含めない微細なエラーもカウントに含めたデータを再提出して、「失敗しました。どうですか？」「おっ、よくやったな」と（笑）。
――本当にバカバカしい話ですね！
牛尾 実際、日本の開発現場はこんなのばっかりなんですよ。だから日本にいる時は、政治半分・技術半分の働き方を余儀なくされました。上の人の承認やら説得にものすごく労力をとられ、そりゃ優秀なエンジニアが活かされないし、チームとしての生産性が低迷するのは当たり前の気がします。
先ほど「不確実性」の話が出ましたが、上がガチガチに現場やスケジュールを管理してコントロールしようとするマインドを捨てたらいいのになと思います。詳しくは本書に譲りますが、現場のチームが主体的かつスピーディに判断できるよう権限委譲したらもっと結果が良くなりますし、とくにソフトウェアのような変化の激しい世界で、緻密な計画なんて要らないと思います。AIが超速で進化する時代に、1年後の未来なんて誰もわからないのだから、変化にすぐ対応できる力のほうが不可欠ではないでしょうか。
――もっと主体的に動いて生産性を高めたいと願いつつ、会社の管理システムや請負が多い事業構造などで思うように動けないと感じている人も多くいます。この点についてはどう思われますか？
ソフトウェア開発の内製化が世界的なトレンド
牛尾 日本にいる時によく聞いていた悩みが「うちは請負契約なので無理」でした。日本でウォーターフォール方式が根強く残っているのは、みな企業が必要なソフトウェアを外注していたり、大手SIerも自分たちで手を動かさず、実装を外に安く丸投げしているから、上が管理しやすい方式として都合が良いという事情があります。大量にドキュメント書かせて、チェックします、みたいなのが。
