2018年にこんな記事を書いた。
ビッグバンマージではなく、少しずつ書いたコードをマージしていき、本番環境を壊さずにリリースする、という話。
チーム内では浸透していて、コードベースにはフィーチャーフラグ機能やデバッグ機能が充実している。
今、コーディングAIを使うと、どのような進め方ができるか、どのような進め方が望ましいと考えているかも書いておく。
blog.sushi.money
2018年版フローのイマイチな点
まず、機能の全貌や設計が分かっていればいいけど、Pull Requestが小分けになって出てくることで、全容がわからないというイマイチさがある。
オフィスに集まって開発していた時代では、ホワイトボードにお絵かきして、これをつくるぞ、みたいな儀式があったけど、リモートワークが進んでからは、お絵描きして認識を揃えるというのが難しくなってしまった。
ということもあって、完成形のイメージ共有が難しくなってきている。
また、GitHubのレビュー機能でランダムにレビュワーをアサインしていると、シリーズものの前編と後編で別人がレビューしていて、それぞれ自分のレビューしていない範囲のことは知らない、ということが起きる。それによって、全体を通じてみると変な作りになっていても見逃してしまう。
私たちのチームではレビュワーをプロジェクトごとに固定して、最初の設計相談からコードレビュー、実装者と別人がQAしてバイアスの混入を防ぐ、といったことをしている。
イマイチな点ふたつめは、レビューのサイクルと実装のサイクルが一致している点。コーディングAIがあれば大量のコードを生成できるが、レビューの速度はなかなか上がらない。
数分で仕上げたコードについて、レビュー待ちで1日待っていると、時間の使い方としてもったいないと感じる。
レビューを待っている間に、続編のPull Requestを次々と作っていくこともできるものの、前半のPull Requestのレビューで方針転換があると、後続まで変更が波及していき、直すのが大変、だからレビューする頃には変更が難しいコードになっている、という、誰も嬉しくない出来事が起きることがある。
動くプロトタイプを作る
2026年6月のテクノロジーでは、「こういう物を作りたい」という話が出てきたとして、コーディングAIに依頼したら、数分か、長くても1時間もあれば動くものが手に入る。
実際に作ってもらうことで、「こういう物を作りたい」という企画情報だけで足りているのか、曖昧で検討が必要な仕様が残っているかを、明らかにできる。
あるいは、当初考えていた仕組みは破綻していて、そのままでは構築できない、矛盾したシステムが要求されている、ということがあるかもしれない。
動きはする、ということが確認できて、コードの良し悪しはともかく、一度構築済みのものが手に入る、という価値は大きい。
そして、作って終わりではなくて、関係者と話すと良い。
ディレクターには、動くものを見てもらい、動きに関する希望をもらっても良いし、仕様上の未決事項を話題として持ちかけて、どちらがいいか相談するのにも使える。どちらがいいか、というときには、両方作っても良い。
また、エンジニアにもこの時点でコードを見ながら会話すると良い。超絶雑に作ったらこうなるとして、一方、完成時点ではどうするか？を打ち合わせしておく。設計に関する議論が机上ではなく、実物の上で議論できる。
レビュワーにあわせたPull Request分割
動くプロトタイプは本当に速度重視で、エッジケースやエラーハンドリングのことは何も考えず作ってもらう。テストも書かずに動けば良しで、デバッグもAIに任せて、動くまで試行錯誤させて、放置していれば完成するであろう。
ただ、そのままリリースはできないので、その後、本番相当のコードとして作り直していく必要がある。
このコードは本番環境でエラーなく動き、セキュリティや動作速度といった特性も満たしたいので、最初のプロトタイプとは異なる特性が求められる。
AIへの依頼者がレビューしたら十分とするか、AIへの依頼者と別にレビュワーをアサインするかはチームによるだろうけど、人間が関わる場合はレビュー可能なコードの量の限界があると思われるので、レビューできる形で分割してPull Requestにしていくのが良いと思う。
全何個のPull Requestで、それらのタイトルはこうなります、までレビュワーと最初に打合せしておくと良いかもしれない。
あるいは、まとまったレビューの時間をおさえて、コードの前でディスカッションしながらペアプロして完成させていく、という形でも良いと思う。
こうして作り直すときには、旧来は、実装者の速度に律速してレビューに出していたのが、現代ではレビュワーの速度に律速して進めていくことになる。
工程の標準化が重要
巨大なコードベースに素手で立ち向かっていき、無から有を生み出す、という2018年の環境では、なんとなく上から下から、とか、下から上とか、レイヤごとにじわじわ物が増えていく、とか、素朴なスケートボードがじわじわ車になる、というような、イテレーティブでスパイラルなものだった。
現代の工程では、ビッグバンなプロトタイピングを終えてから、もう一度、人間が解釈できる単位に再構築する、という工程になっている。
すでに本番稼働しているコードベースに加えて、前にやったプロトタイプをふまえて、さらにプロトタイプに対する人間の感想やフィードバックもふまえて作る、という形で、一度に見るべき情報が増えている。
こうした情報の海のなかで、人間の認知がボトルネックにならず、前工程が次工程に期待通りに反映されることは担保しておきたい。
そのために、コーディングAI向けにスキルや手順として、各工程の定義や、手順をまとめておけると良い。
「プロトタイピングとは、こういった企画情報を動くコードに変換することである」とか、「実装計画とは、プロトタイプされたコードと、その後のディスカッションから、Pull Requestを作る単位をレビュワーに合わせて切り出していくことである」とか、各工程での入力と出力を、スキルや手順として標準化しておくのが有効と考えている。
これは、誰がやっても同じ、ということを期待しているのではなくて、誰がやっても同じ前提情報を手にできる、ということを期待している。煩雑な情報集めは定型化して、その後、どれを選ぶか、という、取捨選択する工程を、人間の仕事として残しておく。
工程化のなかでも、タスクチケットの本文を着手可能な形に整形し、チームで共有するスキルへの案内を埋め込んでおく、というのが役に立つのではないかと考えている。
たとえば「〇〇プロジェクトの見積もり」というチケットの本文に、「以下の要件を、/our-project-estimateスキルを使って見積もる。プロトタイピングしたコードは以下…それをふまえた議論以下…」などと書いておくようなイメージ。
こうすれば、このタスクをAIに渡すと、作業者の手元では/our-project-estimateが実行されて、チームで用意している標準的な見積もり手順で進めてもらえるのではないか。
焼き物は、ろくろが作るか人が作るか
工程を書き下してしまったら、人間はもう何もすることがないんじゃないかと思われると思う。
これは、ろくろで器を作った、と考えるか、ろくろが器を作った、と考えるか、という話に近い。
回転運動を加えるのはろくろのモーターであるとか、回転運動のみなもとはろくろの軸だ、と考えることはできる。
見方を変えると、ろくろと土は最終的に糸で切り離されるのであるし、土を触るのは人間の手であり、手の加減でさまざまな器を作っているのだと考えることもできる。
陶芸家は座ってるだけで、ろくろが頑張っている、と言われないよう、AIが出してくる前情報や、プロトタイプのコードを、どう整理、解釈し、取捨選択するか、ということが、これからの開発者に求められるスキルになると思う。
追記、忙しい人向け
スライドになったバージョンもあります。
blog.sushi.money
