AI-NATIVE DEVELOPMENT FRAMEWORK.
人が回していた仕事を、AIが正確に回せる型にしました。
私たちは、開発会社として積み重ねてきたマーケティングとプロダクト開発の仕事を、AIのワークフローとスキルに落とし込んでいます。
AIが動き、人が判断する。この仕組みで、私たちはAI開発を組織として回しています。
MARKETING WORKFLOW.
メディア運営のPDCAを、まるごとAIのスキルにしています。
私たちは、目標の設定から、毎日のレポーティング、タスク化、制作、公開後の評価までを、一つのサイクルとして回しています。
このサイクルの工程をAIのスキルに落とし込み、スキルを動かす基盤として、CMS「Autorial」を自社で開発・運用しています。
レポートからチケットを起こして対応するのはAIです。人は、変更点のレポートを受け取って確認します。
ただし記事など特に重要なものは、人にアサインし、人が注力して仕上げます。
FIG. 01-A
メディア運営のサイクル
7つの工程を、AIのスキルとCMS「Autorial」で回します。水色の工程は人が判断します。
FIG. 01-B
レポートからチケット、対応まで
AIがレポートからチケットを起こして対応し、人は変更レポートを確認します。記事など重要なものは人にアサインします。
ステップ・バイ・ステップ
01 — GOAL
目標を決める
事業の目標から、追いかける指標とレポートの形を決めます。
人が判断
02 — REPORT
毎日レポートする
SEOの調査や数値の変動を、毎日レポートにまとめます。
03 — TICKET
AIがチケットにする
レポートの変動から、AIが打ち手をチケットに起こします。
04 — CREATE
対応・制作する
AIがチケットに対応し、クリエイティブや記事の制作・レビューを進めます。記事など重要なものは、人にアサインします。
05 — CHECK
ルールを確かめる
医療広告ガイドラインなどのレギュレーションを、公開前にチェックします。
06 — PUBLISH
公開して反応を見る
公開したあと、ユーザーの反応をチェックします。
07 — CONFIRM
確認・評価する
人が変更点のレポートを受け取って確認し、目標と照らして評価します。
人が判断
01 目標に戻り、サイクルを回し続けます
TICKET DRIVEN DEVELOPMENT.
プロジェクトマネージャーの仕事を、ワークフローに組み込みました。
チケッティング、要件定義、実装時のユーザーストーリーの整理。私たちは、これまでプロジェクトマネージャーが担ってきた領域を、ほぼすべてAIのワークフローで回しています。
受託開発の会社が最も人手をかけてきたのは、要望や設計をチケットとドキュメントに起こす仕事です。私たちはこれをワークフローに組み込み、チケットを更新したのにドキュメントが古いまま、ということをなくしました。
タスクボードは、Notionや自社のボードなど、プロダクトに合わせて拡張して使います。
なかでも一番難しかったのが、QAの実機テストです。私たちは、サービスをどう操作するかをまとめたナレッジWikiを裏側に持ち、サイトの仕様や操作方法を定義しています。だからAIが、実際にサービスを操作してテストできます。
もう一つの壁は、AIに任せたQCは何をどう確かめたのかが残りにくいことでした。そこで、ブラウザQCの証跡を管理する社内ツール「koma（コマ）」を開発しました。AIがブラウザで行った操作を、1操作ごとのスクリーンショットと確認項目として記録し、あとから再生して共有できます。QCの操作はテストケースとして残り、次のQCにそのまま引き継がれます。
受託開発でいちばんのボトルネックになるのが、このブラウザでのQCです。チケットとドキュメント、実装、そしてQCの証跡までが一続きに残るから、レビューする人は、何がどう確かめられたのかを一コマずつ追って判断できます。これが、私たちがAIによる受託開発の型として持っている仕組みです。
AIの性能だけで回っているのではありません。型をつくり、日々の業務で定量的に回し続けてきたノウハウと経験、実績が、このワークフローを支えています。
FIG. 02-A
チケットの進み方
一つのチケットが、起票からQA、完了まで、ボードの上を進みます。
FIG. 02-B
ブランチ戦略
チケットごとに作業ブランチを切り、PRで開発ブランチに戻してQAし、本番ブランチへのマージでデプロイします。
FIG. 02-C
チケットとドキュメントの同期
チケットを更新するとドキュメントも更新され、コードはドキュメントに沿って書かれます。
FIG. 02-D
実機テストを支えるナレッジWiki
サイトの仕様と操作方法をWikiに定義しているから、AIがサービスを実際に操作してテストできます。
FIG. 02-E
komaで残す、QCの証跡
AIの操作を1操作ごとのスクリーンショットと確認項目で記録し、再生して共有します。QCの操作はテストケースとして次のQCに引き継がれます。
ステップ・バイ・ステップ
PLAN — 計画
01ICEBOX起票要望を、チケットに起こします
お客様の要望や、気づいた課題は、まずすべてチケットにします。口頭やチャットのままにせず、記録に残すところから始めます。
この工程でやること
要望をチケットにする
打ち合わせやチャットで出た要望を、AIがチケットに起こします。言った・言わないが起きません。
要件を決める
何ができたら完了なのか、要件と完了の条件をはっきりさせます。
ユーザーストーリーを整理する
誰が、何のために使う機能なのかを整理し、作る理由をチケットに残します。
- 02TODO着手待ち
着手できる状態に整えます
大きな要望は、作業できる大きさまで分けてから、次に何をやるかを決めます。
この工程でやること
タスクに分ける
1つのチケットが大きすぎれば、実装しやすい単位に分けます。
作業量を見積もる
作業量を見積もり、スケジュールとのずれを早めに見つけます。
順番を決める
事業への影響と緊急度から、着手する順番を決めます。
BUILD — 開発
03IN PROGRESS作業中ドキュメントを直してから、作ります
着手したらステータスを作業中に変えます。先にドキュメントを更新し、それに沿って実装します。
この工程でやること
作業ブランチを切る
チケットごとに作業ブランチを切り、ほかの変更と混ざらないようにします。
ドキュメントを更新する
仕様や設計のドキュメントを先に更新し、チケットとドキュメントのずれをなくします。
実装する
更新したドキュメントに沿って、ソースコードを書きます。
- 04DONE実装完了
機械で確かめられることは、全部確かめます
実装が終わったら、自動で確かめられることをすべて通してから、レビューに出します。
この工程でやること
コードのチェック
型チェックやLintで、書き間違いや型の食い違いをなくします。
ビルドテスト
本番と同じ手順でビルドが通ることを確かめます。
プルリクエストを作る
何を、なぜ変えたのかをまとめたプルリクエストを作ります。
- 05MERGEDマージ
触って確かめられる環境に出します
レビューを通った変更を開発ブランチにマージし、実際に画面を触れる環境に反映します。
この工程でやること
レビュー
変更の内容が、チケットの要件と合っているかを確かめます。
開発環境に反映する
開発ブランチにマージすると、開発環境が更新されます。
確認用の画面を用意する
本番と同じように動く画面を、確認用のURLで見られるようにします。
TEST — 検証
06QC品質検証実際に操作して、確かめます
いちばん手間がかかり、ノウハウが要る工程です。ナレッジWikiをもとに、AIがブラウザと実機で、実際にサービスを操作してテストします。
この工程でやること
ナレッジWikiを読む
サイトの仕様、画面と導線、操作手順、テストの観点をまとめたWikiを読み、何をどう操作するかを決めます。
ブラウザでテストする
実際のブラウザで画面を開き、表示と操作を一つずつ確かめます。操作のたびに、スクリーンショットと確認項目をkomaに記録します。
実機でテストする
スマートフォンなどの実機でも、同じように操作して確かめます。
- 07QC OK検証済み
結果を、証拠と一緒に残します
テストの結果はQAレポートにまとめます。問題が見つかったら、作業中に戻して直します。
この工程でやること
QAレポートにまとめる
何を確かめ、結果がどうだったかを一覧にします。QCの操作はテストケースとして残し、次のQCでも使います。
komaで証跡を残す
操作ごとのスクリーンショットと確認項目をkomaに残し、あとから誰でも再生して確かめられるようにします。
NGは差し戻す
不具合は再現手順をつけて作業中に戻し、直してからもう一度テストします。
RELEASE — リリース
08PM REVIEWPMレビュー人が見て、出すかを決めます
最後の判断は人がします。AIが上げたレポートを見て、リリースしてよいかを決めます。
人が判断
この工程でやること
要望と照らし合わせる
出来上がったものが、最初の要望と要件に合っているかを確かめます。
レポートを確認する
QAレポートとkomaの証跡を再生して確認し、気になる点があれば差し戻します。
リリースを決める
公開のタイミングも含めて、リリースしてよいかを決めます。
- 09DEPLOYデプロイ
本番に出して、見守ります
本番ブランチにマージしてデプロイし、本番でも動くことを確かめます。ここから運用と監視が始まります。
この工程でやること
本番にデプロイする
本番ブランチへのマージで、決まった手順どおりにデプロイします。
本番でテストする
本番環境でも、主な操作が正しく動くかを確かめます。
監視を始める
死活監視・内部監視・外形監視を入れて、運用に引き継ぎます。
03 運用・監視へ引き継ぎます
OPERATE FROM DAY ONE.
デプロイした時点から、監視と運用が始まります。
私たちは、デプロイして本番に投入した時点で、死活監視・内部監視・外形監視をすべてのプロダクトに一律で導入しています。
アラートが上がったら対応し、軽微な不具合やサーバーエラーのレベルであれば、自動で修復する仕組みを取っています。
保守・運用・監視・開発といった定常の業務も、開発会社が持っている仕事はすべて、ワークフローとスキルに落とし込んでいます。
FIG. 03-A
監視と自動修復
3種類の監視で本番を見続け、軽微な不具合は自動で修復します。
ステップ・バイ・ステップ
01 — LAUNCH
本番に投入する
デプロイと同時に、監視の設定を一律で入れます。
02 — MONITOR
監視する
死活監視・内部監視・外形監視で、止まっていないか、遅くなっていないかを見続けます。
03 — ALERT
アラートを上げる
異常を検知したら、アラートを上げて対応に入ります。
人が判断
04 — AUTO-FIX
自動で修復する
軽微な不具合やサーバーエラーのレベルなら、自動で修復します。
監視を続け、次の開発にもつなげます
WHAT CHANGED
LESS DRIFT. FASTER PAYBACK.
予定どおりに進み、コストが見合い、早く回収できる。
私たちは、もともと開発会社です。
人が回していて業務コストが高かった仕事を、ワークフローで正確に回せるようにしました。
その結果、私たちはスケジュールと予算の見通しが立てやすいプロダクト開発を提案できるようになりました。
- 01 — ON SCHEDULE
予定とのずれが小さい
想定外の手戻りによるスケジュールの遅れやずれを、最小限に抑えられるようになりました。
予定していた開発内容とのずれも少なくなりました。 - 02 — RIGHT COST
コストがプロダクトに見合う
信頼できるディレクター1人が、1つの案件の全体を回せる形になりました。
大人数で回すよりも開発コストを大きく抑えられるので、収益とコストのバランスが良い提案ができます。 - 03 — FASTER PAYBACK
投資の回収が早い
意思決定から次のアウトプットが出るまでのサイクルが短く、市場に早く出せます。
市場に早く出せるほど初期投資の回収も早くなり、予算を割きやすくなります。
BUILD IT WITH THIS WORKFLOW.
このワークフローで、次のプロダクトをつくります。
私たちは、新しいプロダクトの立ち上げも、動いているプロダクトの運用開発も、このワークフローで進めます。要件がまだ固まっていなくても構いません。