要件定義にモックを持ち込んだら、200個の決定事項が発生した話【AI駆動開発イベントレポ】

先日Algomaticオフィスにて、Ubieさん、KDDIアジャイル開発センターさんと3社合同イベント＋懇親会を実施しました。

テーマは「現場で効いたAI駆動開発の実践知: 越境を支える体制と仕組みづくり」。

登壇したAlgomaticのVPoE 坂本は「AI駆動開発における決定負荷」をテーマに、AI駆動開発を実践するなかでぶつかった課題とその乗り越え方について語りました。今回は、そのセッションの内容をお届けします。

AlgomaticのAI駆動開発では、なぜ仕様書よりも前にモックを作るのか

Algomaticでは、AI駆動開発の一環として「要件定義段階でモックを作る」という開発手法に取り組んでいます。

これは、仕様書より先にフロントエンドのモックを作り、クライアントに触ってもらったあとで合意を取る。開発に着手するのはそれから、といったアプローチです。本セッションでは、なぜこの手法に至ったのか、そこでぶつかった課題などについて語られました。

この開発手法の背景にあるものとして坂本は、「システム開発の根本的な問題は『認識のズレ』にある。エンジニアの方であれば、開発したあとに『なんかこれ違うんだよね』と言われた経験は、一度や二度ではないと思う」と切り出しました。

セッション中、引き合いに出されたのは「Tree Swing Cartoons」。顧客が本当に必要だったものと、プロジェクトの各関係者が理解したものがまるで違ってしまうという有名な図です。

それを受け、さまざまな開発手法が生まれてきた背景を、次のように話します。

「ウォーターフォール開発は大量のドキュメントでズレを防ごうとしていたのに対し、アジャイル開発では『ズレは不可避なものであり、提供できる価値も出してみるまでわからない』という前提になり、小さくリリースして検証する方向に進みました。つまり、価値を提供するために『細かく定義する』から『早く触る』へ変化したのだと思っています」

その先にあったAlgomaticの発想は「じゃあ、もっと早く作ればいいじゃん」というシンプルなものでした。

「仕様書よりも先に、フロントのソースコード自体をモックとして作ってしまいます。それをお客様やPdMに触ってもらい、"なんか違う"となれば、その"なんか"を言語化し、何度もモックをループさせる。実際のモノを触りながら、作りたいものの価値を言語化していく形です。

仕様書を作るのは、お客様と合意が取れたあと。このタイミングではフロントエンドである程度モノが出来上がっているので、あとはバックエンドを作り込めばよい、という進めかたです」

以前はソースコードが高級品で、要件定義段階でコードを書いているととても時間がかかり、工数が間延びしてしまっていました。しかし現在は、AIを使えばソースコードを高速に生成できる。今だからこそ取れるアプローチです。

「勝ったな」と思ったら、課題管理に200個超の決定事項が発生した

「チームのメンバーと話してこの方法で進めることを決めたとき、正直『勝ったな』と思いました」

しかし、実際にやってみると、課題管理表に200個以上の決定すべき事項が積み上がってしまったと言います。

「これまで、決定事項は自然と各フェーズに分散されていました。要件定義が完璧に終わって次の開発段階に進んでも『ここどうなってましたっけ？』と後ろに戻ることもよくありますし、テストのフェーズで実際に動かしてみて不具合に気づいたり、リリースしたあとに『やっぱりなんか違うかも』という点が出てきたりします」

しかしお客さまに「いじってもらう」を最初のフェーズに持ってくると、「作ってわかる」「触ってわかる」「たくさん触ってわかる」といった、今まで意図せず分散されていたすべての気づきが、要件定義のフェーズにのみ集中してしまったのです。

クライアントが積極的にフィードバックしてくれたことは手法が機能している証拠ではありますが、その反面、PdMへの意思決定負荷が跳ね上がりました。

解決策①：決定負荷をチームで分散する

この問題が発生したとき、2つの解決策を講じました。

1つ目は、決定負荷をチームで分散することです。

従来の開発では、デザイナーやエンジニアが各々決めだすと、PdMとしてはそれらの整合性を担保しきれないため、越境した意思決定が難しかった。しかしモックがあることで、各自が意思決定しても、実際の動きをみたうえで最終確認ができるようになりました。

「もし、『このデザイナーのアイディアがすごく良さそうに見えるけど、それってほかの画面や仕様とちゃんと整合が取れてるんだっけ？』という懸念があったとしても、その場でやってみることで『これでいこう』『やっぱり別の案を検討したほうがよさそう』といった会話ができる。これにより、筋の通った判断がしやすくなるのです」

坂本は、この副次的効果にも触れました。

「さらに、こういうやりかたで進めることで全員が意思決定者になるため、自分ごと化することもできる。そうすると、プロダクトやソリューションに愛着が湧くんですよね。『自分で要件を決める』というのは、モノをつくる一つの醍醐味。実際に、エンジニアの方との採用面談でも、『要件定義に関われるかどうか』はよく聞かれる質問です。自分が要件から決めて作ったものが、世に出て、それを使ってもらえることがモチベーションになるエンジニアも多いと思います」

解決策②：決めないことはAIに任せる

2つ目の解決策は、決めなくていいことはAIに任せるです。

決定負荷を分散しても、決めるべきことの全量は減りません。ボタンの配置、スキーマの定義、ほかの画面との整合性など、細かい決定事項は山のようにあります。坂本は「乱用は厳禁ですが」と前置きしたうえで、それらを解決するための“魔法の呪文”を紹介しました。

「僕は、開発手法のすべてが先進的である必要はないと思っています。人間が死ぬほど考えても『やっぱりこれはほかと同じにすべきである』という結論になることもある。とくにBtoBのシステムで言えば、管理画面が今まで見たことのない斬新なデザインに変わると、逆に使いにくかったりしますよね。そういう意味でも、ほかと同じデザインにするということが、大事な場面もあるはずです」

既存機能や以前作った別のシステム、世の中のベストプラクティス、過去の判断記録、デザインパターンなど、過去の資産を分析し落とし込んでいくのは、AIが得意とする領域です。そのため、人間がしっかり考え、ほかと同じほうが良いと判断したならそれらはAIに任せてしまえばいい。大事なのはその線引きだと話しました。

「毎日同じシャツを着よう」の意味

最後に坂本が語ったのは、このセッションタイトルの主題を「毎日同じシャツを着よう」にした理由です。

アップルの創業者であるスティーブ・ジョブズは毎日同じ服を着ていましたが、それは、決定疲れを防ぎ、本当に重要な意思決定にエネルギーを集中させるためだと言われています。（ただ坂本いわく「今回調べたら、本人が明言したわけではなさそう」とのこと）

「決めるべきことは、やっぱり主体性を持って、何が価値につながるのかをきちんと考えてやらなきゃいけない。一方、決めないことをスパッと決めることも大事です。決めなくていいものはAIに任せて、決めないことを決める。これが非常に大事な決断だと思っています」

Q&A：モック開発で仕様漏れは防げるのか

セッション後には質疑応答の時間もあり、こんな質問が寄せられました。

A.後戻りがゼロになったわけではありません。ただ、10年前にしっかり要件定義書を書いていた時代でも、やっぱり仕様漏れはなくなっていなかった。実際に作ってみた感想としては、圧倒的に減ったと感じました。

A.これは作りました。まさにAI時代だからこそ、できたことですね。パターンが10個や20個ある場合でも、1個作ってしまえば、それを型として量産してくれるのはAIの強みです。

一方、パターン自体はモックで作れるんですが、それを試してくださるクライアントがいるという点もポイントです。お客様には毎週のように触る時間を作ってもらったり、使っていただいたりしました。お客様の協力あっての手法かもしれません。

Algomaticのエンジニアは、今回のセッションで紹介したような方法で日々開発を行っています。

こういった開発スタイルに興味のある方、実務の場でAI駆動開発の経験を積んでいきたいという方は、ぜひ下記ページをご覧ください！

▼Algomatic エンジニアの求人一覧

▼登壇した坂本とのカジュアル面談

▼Algomatic 採用ページ