はじめに
生成AIをコアエンジンに据えるサービスが世間を賑わせている。それと同時に「もっとはやくリリースできないのか」という経営からの強い期待や、現場レベルでは同業他社を含む熾烈な競争が始まっているところもあるだろう。
よりはやくリリースするためには、無駄を省く、効率化する必要があるということで、「エンジニアリングのコストと時間」に着目されることが多い。
しかしながら、エンジニアリングとは本来は必要経費であり、仮に効率化されるとしても 対象が絞られているが故に最適化できる に過ぎない。この前提が「高速化」のために重要であることを本稿では述べていくこととする。
＊エンジニアリング＝ソフトウェア開発を通じたモノ造りの意
エンジニアリングを構成する要素
エンジニアリングを構成する要素とは何だろうか？
異論は認めるがｗ、ここでは大きくは「プロセス」と「テクノロジー」に分けて考えていく。
テクノロジー
モノ造りをするうえで、再現可能な形で計算機に委ねられる部分、あるいはその構成を支える領域をテクノロジーと総称している。
速くせよに答えるために、デプロイの自動化、ローコードツールの活用はよくある話だ。いずれも 対象が定まっている 、自動化の範囲が決められているからこそ、効率化され速くすることに貢献できる。
次に、「テスト」はどうだろうか。 対象が定まっている テスト、それこそバージョンアップ時には必ずこのデグレードテストを実施する、といった内容であれば効率化に寄与する。では、新機能の開発に関わるテストについてはどうだろうか。テストコードを実装する工数は、新規開発の予算が少ない中で重くのしかかってくるだろう。その新機能が今後どれだけ使われるのか、価値を提供する存在になるのか、といったビジネスに根ざした問いに答えることができれば、テストを自動化することで「モトが取れる（今後数年でROIが向上する）」という判断もできるだろう。
このように、仮にテクロノジーの領域であったとしても、テクノロジー視点だけでは効率化の判断はできず、 テクノロジーが表現するビジネスとしての出力を顧みる必要がある のだ。
プロセス
テクノロジーとそれを扱う人の間に存在するモノをプロセスと総称している。
「アジャイル開発ならウォータフォールより速く開発できるのでは？」と聞かれたことのあるエンジニアは多いのではないだろうか。エンジニアならば「速くなるわけないだろうｗ」と思いつつも「目的地に速く到達する可能性はあります」と遠回しな回答をした経験もあるだろう。
やるべきこと（作り込む機能）が変わらない場合、アジャイルの方が小さく造っていくために、細かな手戻りや総量としてのテストの最適化ができずに、ウォーターフォールよりも工期がかかるというのは容易に想像がつく。では、なぜアジャイルがこんなにも注目されるのかというと「そもそもやるべきことなんて開発している間に変化してしまうので、滝が流れ落ちるまでの間に目的地が移動してしまう」という、変化の激しい時代の意思決定に適したプロセスとされるからである。
また、開発プロセスとは別に発展してきた品質管理の手法にも速さの観点で課題がある。
顧客に提供するようなシステムやその部品となるプロダクトをウォーターフォールで開発する場合、開発規模や造る対象の複雑さから摘出すべきバグ数、テスト件数を事前計画し、計画に沿ってバグ数が収束することにより品質を確保できたものと判断する。（IPAでバグ密度などして紹介されている）
Webサービスに関わったエンジニアならば、事前に予見した開発規模から目標とするバグ数が定められたり、必要な工数が決まることに違和感を感じるのではないだろうか。
このような品質管理の方法では、開発規模という形で、その中に含まれる各機能について優先度や重み付けをしていないこと、また、摘出されたバグについても等しく扱っている点において、ビジネスとして意思決定に関与していないところに違和感を覚えるのである。
ここでアジャイル開発に話を戻すと、アジャイルではイテレーションという一定の作業期間を刻みながら、都度、ビジネスの状況に応じて、開発や実行すべきタスクを優先度判定のもとで選びとっていく。このプロセスの中では、各機能、運用中に起こった事象、それぞれについてビジネスに根ざした形で影響を見積もり（例. 流通総額への被害額がいくらか）、意思決定をしている。つまり、現在の目的地に向かうために都度判断、最適化することで、エンジニアリングがビジネスを支えている状態を保ち、それ故に速いと言えるのである。
まとめ
ここで話を冒頭に戻そう。 ビジネスとテクロノジーが一体となって意思決定できるプロセスを保ち、それによって、いまやるべきことを絞り込むことで「対象が絞られているが故に最適化できる」状態に至ることができる。逆に言えば、これまでのようにテクロノジー視点から来るプロセスや管理基準によって、総量を満たすことや、すべてを等しく扱うことを求める方法論では、全体として速さを生み出せないということである。
CI/CD、オブザーバビリティ、インフラの自動化、テストの自動化、コードレビューとペアプログラミング、継続的な学習と改善など、手段としてのベストプラクティスに注目されがちであるが、「それがなぜ必要とされたのか」というビジネスの背景、求められるスピード、切迫した事業環境、こうしたことを深く理解し、その上でアジャイルなりDevOpsなりの必要性を議論して欲しいと切に願う。
すべてはビジネスの成功のために。