目次
AI駆動開発でビジネス側と開発側の境界が溶けてきた
打合せ前のメモから、15ページの画面を作る
要件定義の前に、まず“モノ”を作る
それでも最後は開発知識がものを言う
NoCodeとは違う、エンジニアがビジネス側に溶け込むイメージ
AI駆動開発に興味を持った方へ
AI駆動開発でビジネス側と開発側の境界が溶けてきた
ここ1〜2年で、ビジネス側と開発側の境界が溶けてきた感覚があります。原因はシンプルで、AIツールの進化です。
v0のように、自然言語で「こういう画面が欲しい」と伝えるだけで、モックが立ち上がる。以前ならデザイナーやエンジニアの手を借りて数日かかっていたことが、すぐに出来上がり、会話の延長で進むようになりました。
この変化は、単に既存のプロセスが早くなったという話ではありません。仕事の進め方そのものが、変わり始めています。
打合せ前のメモから、15ページの画面を作る
最近、顧客との打合せ前にいただく事前情報が「箇条書き数行」だけ、ということも珍しくありません。
以前なら、その情報でできるのは限られて、詳細は打合せで確認するという流れでした。ところが今は、そのメモを起点に、打合せ前にモックを作成して臨めます。先日も数行のメモから約15ページ分の画面遷移をもつモックを組み、打合せの場に持っていきました。
「この入力の次に、こういう確認画面が出て、ここで分岐して…」
実物があるだけで、議論の質が変わります。言葉だけでは顧客も思い描けていなかった前提が、画面として固まっていく。顧客側の“頭の中のイメージ”が可視化され、こちらの理解も一段深くなります。
要件定義の前に、まず“モノ”を作る
私は、前職の経験から要件定義はとても重要な工程だと実感しています。
ただ、新規事業で大規模な金融システムのウォーターフォール開発のように最初から完璧に固めようとすると、現実から離れたまま議論が進むことがあります。だからそのようなケースの場合は、弊社では要件定義をバッチリ固める前にまずはモノを見る、という順番を大切にしています。
モックはあくまでもスピード感をもって作れる“たたき台”です。
触れて、違和感を言語化して、修正していく。その過程で、顧客の意思決定も早くなるし、私たちの設計も現実線に落ちていきます。結果として、手戻りが減り、品質が上がる。V時モデルとは逆の順番でプロトタイプ開発を爆速にしたイメージです。違いはやはり自然言語で従来よりも爆速で高い品質のモックが出来上がることです。
それでも最後は開発知識がものを言う
一方で、ここは誤解してほしくないのですが、モックが作れるだけでは“ビジネスで使えるシステム”にはなりません。
データベースへの接続、細かいロジックなど、最後に責任を持って形にするには、開発知識が必要です。
だからLifedgeでは、「プロダクトの価値を会話で要件を掘り出しながら、技術で成立させる」人が、これからますます重要になると考えています。
NoCodeとは違う、エンジニアがビジネス側に溶け込むイメージ
私が今感じているのは、エンジニアがビジネス側により深く溶け込んでいくイメージです。
会議で要望を翻訳し、モックで合意を取り、設計で地盤を固め、実装で最後まで責任を持つ。ビジネス担当と開発担当の間を行き来するのではなく、境界そのものを薄くしていく。
NoCodeというツールもありますが、あれはビジネス側が主に使うツールで、本格的にスケールさせる場合はコードに起こす必要があります。
ただ、AI駆動開発はエンジニアがモックを作り、そのまま開発するのでビジネス側とシームレスにつながります。
それはただモックを作るという点でのメリットではなく、その後のプロセスも含んだ線でのメリットになります。
AI駆動開発に興味を持った方へ
LifedgeではAI駆動開発に本気で取り組んでいます。日々技術の最前線で出来ることをブラッシュアップする日々はとても刺激的で、エンジニアにとっていい環境だと思います。
もし興味をもっていただけたら以下から応募をお願いします。