AIによる生産性向上が前提になると、開発チームに求められる能力は変わっていくと思います。これまで価値が高かった「手を動かして実装する力」だけでなく、何を作るべきかを判断し、設計し、学び続ける力の重要性が増していくはずです。

このためチームメンバーの育成を考えた時に、AIではなく人間としてチームに在籍し続ける意味・価値を発揮する人材として育ってもらう必要があります。今後は、AIのトークン費用と人間の人件費が今よりも露骨に比較される場面が増えていくはずです。その現実を直視したうえで、人間がチームにいる意味をどこで発揮するのかを考えなければなりません。そのためにはメタ認知をいかに伸ばす育成の仕組みをチームに作っておけるかがチームリードとして求められる役割になるのではないでしょうか。AIに負けないことよりも、AIを含んだ開発システムを扱える人材を目指す方が生存率が高いのではないか、ということです。

ここではメタ認知を、タスクを実行する力そのものではなく、「そのタスクを実行する準備は整っているか」「そもそも取り組む価値があるのか」「どこにリスクがあるのか」を一段高い視点から捉える力として扱います。

この考えを掘り下げると、AI時代に生き残りやすい人材とは手が早い人ではなく以下ができる人になります。

  • 問題を正しく切り出せる
  • 要件の曖昧さに気づける
  • AIに任せる部分と人間が責任を持つ部分を分けられる
  • 出力を検証できる
  • リスクを先回りできる
  • 失敗を手順・自動化・知識に変換できる
  • 他者の学習速度を上げられる

##メタ認知を高める思考誘導の仕組みを作る

チームメンバーを望んだ方向に推進したい時、ただ求める姿を言っても基本的に人が変わるわけではないと思います。そのため制度を整えることで自ずとその形へと変化せざるを得ない仕組みづくりが大事だと考えています。開発チームのレベルで制度という会社にまたがる大掛かりな変更を加えることは出来ないため、開発フローに手を加えることで達成していく必要があります。

開発・保守運用を行うチームにおいて、案件フェーズを下記に分割してそれぞれに問いを置くことでメタ認知を高める思考誘導が出来ないか考えてみた結果が下記になります。

これらの問いの目的は、正解を埋めることではなく、担当者が自分の作業を案件全体の中に位置づけ直せるようにすることです。実装や作業の前に一段引いて考える時間を作ることで、AIに任せられる範囲、人間が判断すべき範囲、先に潰すべき不確実性が見えやすくなるはずです。

###案件受付フェーズ

観点問い
目的この案件は何の問題を解決するのか
背景なぜ今この案件が必要なのか
価値やることで誰にどんな価値があるのか
緊急度今やらないと何が困るのか
代替案開発せずに解決できる方法はないか
優先度他案件より優先する根拠はあるか
成功条件何が実現したら成功と言えるのか
依頼者最終的に誰が判断する案件なのか

###案件立ち上げフェーズ

観点問い
スコープ今回やること・やらないことは何か
関係者利用者、依頼者、承認者、運用担当は誰か
影響範囲どの業務、機能、データ、外部連携に影響するか
制約期限、予算、セキュリティ、可用性、性能などの制約は何か
前提成立していないと困る前提は何か
不明点現時点で分かっていないことは何か
リスク最初に潰すべき不確実性は何か
体制誰が何に責任を持つか

###方針・設計フェーズ

観点問い
解決方針実装、設定変更、運用変更、既存機能活用のどれで解くか
案の比較複数案を比較したか
分割方針小さく段階的に出せるか
技術選定新技術を使う必要はあるか
保守性半年後・1年後に保守できるか
セキュリティ権限、認証、個人情報、ログ出力に問題はないか
データ移行、整合性、削除、復旧の観点はあるか
運用リリース後の問い合わせ、監視、障害対応はどうなるか
AI利用AIに設計案を出させた場合、人間が何を検証したか

###実装・構築フェーズ

観点問い
一貫性既存の設計・命名・責務分担と合っているか
説明責任担当者は実装内容を自分の言葉で説明できるか
テスト正常系だけでなく異常系・境界値・権限差分を見ているか
AI出力AIが生成したコードを理解・検証したか
変更単位レビュー可能な単位に分けられているか
保守性将来の変更時に追いやすいか
ログ障害時に原因を追えるか
運用運用担当が確認できる状態になっているか

###テスト・受入フェーズ

観点問い
成功条件案件カルテに書いた成功条件を満たしているか
業務観点実際の利用シナリオで確認したか
権限利用者ごとの権限差分を確認したか
データ既存データ、新規データ、異常データで問題ないか
影響範囲周辺機能や連携への影響を確認したか
非機能性能、セキュリティ、監視、ログは確認したか
運用問い合わせ・障害時の対応手順はあるか
受入誰が何を見てOKを出すか明確か

###リリース・移行フェーズ

観点問い
リリース手順誰が、いつ、何を、どの順番で実施するか
切り戻し失敗した場合に戻せるか
判定基準リリース成功・失敗を何で判断するか
監視リリース後に見るべきログ・メトリクス・アラートは何か
周知利用者・問い合わせ窓口・運用担当へ伝わっているか
権限リリース作業に必要な権限は揃っているか
データ移行バックアップ、整合性確認、再実行可否は整理されているか
問い合わせリリース後に想定される問い合わせと回答はあるか

###運用定着・振り返りフェーズ

観点問い
成功条件当初の成功条件は満たしたか
予測差分見積もり、影響範囲、リスク予測は当たったか
手戻りどこで手戻りが発生したか
問いの不足最初に何を確認していれば防げたか
AI利用AIはどこで有効だったか。どこで危なかったか
運用影響リリース後に問い合わせや障害は起きたか
再利用次の案件でも使える知識は何か
仕組み化チェックリスト、テンプレート、自動化、監視に反映することは何か

##実際のチームへ適用する際のミニマムスタート

いきなり重い変更をチームへ導入すると反発が怖いです。特にチェックリストは、運用を間違えるとすぐに監査の道具として受け取られてしまいます。ここで目指したいのは不備を探して詰めることではなく、案件を見る目を育てるための補助輪として使うことです。

なのでまずは各フェーズで下記の問いかけを行う程度からの導入にすると良いのではないかと考えています。

# 案件チェックリスト
 
## 1. 案件開始前
 
- この案件の目的を一文で説明できる
- 成功条件が明確である
- やること／やらないことが分かれている
- 意思決定者・承認者が明確である
- 実装以外の解決策を検討した
- 優先度の根拠が説明できる
 
## 2. 案件計画時
 
- 影響するシステム・機能・データを洗い出した
- 関係者を洗い出した
- 未確定事項を管理している
- 主要リスクを洗い出した
- 最初に検証すべき不確実性を決めた
- 案件を段階的に進められる形に分割した
 
## 3. 設計時
 
- 複数の解決案を比較した
- 既存設計・既存運用と整合している
- 保守性・運用性を考慮している
- セキュリティ・権限・ログの観点を確認した
- テスト方針を決めた
- リリース・切り戻し方針を決めた
 
## 4. AI利用時
 
- AIに任せる範囲を明確にした
- 機密情報・個人情報を入力していない
- AI出力を採用した理由を説明できる
- AI出力を人間が検証した
- AIに作らせたテスト観点に、案件固有の観点を追加した
 
## 5. リリース前
 
- 受入条件を満たしている
- リリース手順がある
- 切り戻し手順がある
- リリース後の確認項目がある
- 監視・ログ確認方法がある
- 関係者への周知が完了している
- 運用手順に反映されている
 
## 6. 案件完了後
 
- 成功条件を満たしたか確認した
- 予測と実績の差分を確認した
- 手戻りの原因を確認した
- 次回に再利用できる知識を整理した
- チェックリスト・テンプレート・自動化へ反映した

このチェックリストは全て埋めきらないとNGを突き付けるのではなく、とりあえず考えるクセをつけてもらうために、確認しているかをヒアリングすることを繰り返すだけでもまずは効果的なのかなと考えています。メンバーには案件を見る目を育てるための補助輪として捉えてもらい、監査の道具としてはなるべく見られない方が良いのかなと思います。

とはいえ、結局のところこれらのスキルはAIが登場する以前からデリバリースキルとして当然求められてきた能力です。AIが登場したことで作業遂行力の価値が相対的に下がり、判断・設計・学習・振り返りの優先度がより高まっただけとも言えます。

つまりAI時代の育成とは、まったく新しい能力を教えることではなく、これまでも重要だったデリバリースキルを、より意識的に、より早い段階から育てることなのだと思います。その積み重ねが、AIと人間が比較される時代においても、人間がチームにいる意味を発揮するための土台になるはずです。