Yusuke｜AI時代のプロジェクトデザイン

AIで仕事や開発が変わる中で、プロジェクト・組織・業務のあり方を考えています｜NRI→BayCurrent→Freelance PM・PMO｜PMP

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

AIで開発や仕事が変わっていく中で、プロジェクトや組織の動き方も変わっていくんだろうなと思っています。

大規模開発やCRMの現場で感じた違和感をもとに、
・意思決定
・業務設計
・データ活用
・PM/PMOやSIerの役割
・AI時代の働き方

あたりについて、少しずつ考えたことを書いていきます。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

https://t.co/Px7SEuVrDV

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

完全同意。品質における当たり前の基準が違っていることがフリーランスで色々なプロジェクトや会社を見てきて実感。（その分愕然とすることもあるのだが😅）

[志村裕司 / Hiroshi Shimura @hiro_shimu]

NRIで3年ほど働いた後、SalesforceやBoxなどのSaaSベンダーで働いてきましたが、今でも強く思うのは、NRIの仕事のクオリティ���本当に高かったということです。

少なくとも私がいた��時のNRIは、新卒文化が非常に強く、優秀な若手を採用し、何年もかけて徹底的に育てる会社でした。

そこで身につくのは、単なるスキルだけではありません。

お客様に約束したことは、最後まで品質を担保してやり切るというプロ意識です。

当時は、品質に責任を持つために深夜まで働き、タクシーで帰ることも珍しくありませんでした。もちろん今の時代にそれを美化するつもりはありません。

ただ、あの環境で叩き込まれた「お客様に対して中途半端なものは出さない」という基準は、外資SaaSで働く今でも自分の土台になっていると感じます。

スキルや知識は後から増やせますが、若いうちに身についた仕事の基準は、その後のキャリアにも長く残りますね。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

「FDE で開発は変わる」という話、最近よく見る。

あるべき姿としては素晴らしい。でも、それを一人で全部やれる人がどれだけいるんだろう、と思う。

FDE に期待されていること、よく見ると守備範囲が広すぎる気がしている。

・業務理解
・アーキ判断
・実装ハンズオン
・フィードバックループ設計
・意思決定背景の組織知化
・運用定着

これを一人で背負わせて、しかも「何をもってフィードバック完了とするか」まで設計させるのは、スーパーマン以外には難しい気がする。

現実的に作業分担した場合

成果物を「本番プロダクトに置く人」と、「プロジェクトが前に進む運営」に分担。

・課題の正本がどこにあって
・意思決定の背景がどう残って
・AI を使う範囲と人間が判断する範囲をどう分けるか
・何をもってフィードバック完了とするか

ここを設計しながら、必要なところだけ自分で手を動かす。

その立場の呼び方は FDE でも Delivery Architect でも何でもいいけれどFDE に「作って→定着まで」を一人で背負わせる前に、意思決定の背景と完了条件を残すための設計者というポジションは必要なのかなと。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

保守を「作ったものを維持するだけ」と見ているのに、
問い合わせも、小規模改修も、改善対応も、全部そこに回しているのはかなりちぐはぐだと思う。

問い合わせ調査には現行機能の理解がいる。
小規模改修には設計判断がいる。
改善提案には業務理解がいる。
保守の中には、かなり開発に近い仕事が含まれている。

それなのに、開発は作って終わり。
運用は引き継がれてから回す。
この前提で組織��切るから、無理が出る。

保守ではなく、エンハンス。
作ったものを使われる形に改善し続ける活動。

AIで作るコストが下がるほど、
価値は「作ること」から「改善し続けること」に移る。
AI時代は、保守の定義を見直すタイミン��だと思う。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

モヤモヤとか違和感など自分の中で感情が動くところに何か自己理解や強みの発見がありそう

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

業務やってて感じるモヤモヤとか違和感、前はただ溜まるだけだった。

最近それを発信テーマにしてみたら、「じゃあどうする？」って自然と考えるようになって、自分の中で整理が進むようになった。

ただ出すだけじゃなくて、ちょっと構造化してみる。それだけで結構変わる。

こういう場があるのは、地味にありがたいなと。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

ローコードの強みは、業務側が小さく改善できること。
なのに文言修正まで画面定義書の修正対象にすると、 結局、開発側が変更を握る構造に戻る。

プロトタイプを正にできるものはプロトタイプへ。 仕様として残すべきものは設計メタ情報へ。

この分離で、ローコードはようやく「現場が小さく改善できる仕組み」として機能しやすくなる気がしている。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

AIでプロトタイプを高速に作れるなら、 要件定義の合意対象はExcelの画面定義書ではなく、 触れるプロトタイプURLでいいのではないか。

画面、文言、導線、表示順。 紙に書き写すより、動くものを見た方が業務側は圧倒的に理解しやすい。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

この分離ができると、 軽微な文言修正まで毎回「設計書修正」にする必要がなくなる。

判断軸は
「文言を変えたか」ではなく、
「文言変更で業務仕様が変わったか」。
仕様が変わらない修正は、業務側が直せばいい。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

これから大事なのは、既存SaaSを捨てることではなく、その上にAIをどう乗せて、人に意識させないぐらい自然に業務を回すか。

「AIでSaaSが終わる」より、
「AIを既存基盤の上にどう乗せるか」の方が、現場では論点になる気がしています。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

「AIがSaaSを殺す」という話を見るたびに、少し前提が違う気がしている。

たしかに、UIは変わると思う。
業務画面も、入力フォームも、検索も、レポートも、AIによってかなり変わる。

SalesforceのようなSaaSでも、ユーザーが直接画面を操作する部分は、もっと自然なUIに置き換わっていくはず。

でも、それは「SaaSが消える」とは少し違う。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

現場を見ていて一番感じるのは、本当のボトルネックはツールではなく、人と運用定着だということ。

トレーニングをしても、
マニュアルを作っても、
UATをしても、
現場がすぐに使いこなせるわけではない。

使いやすいと言われた機能でも、慣れたやり方に戻る。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

プロジェクトで判断しない��いけないことがあって、頭がぐちゃぐちゃだったのをAIで壁打ちして整理した。これがすごく良かった。

いろんな人からいろんな要素はもらってるのに、自分の中でうまく整理できてなくて判断がつかない、って状態だったんだけど、対話してるうちに思考が勝手にほどけて次のアクションが見えた。

情報がないんじゃなくて整理できてなかっただけ、ってことに気づけたのが一番大きい。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

結局、法人でAIを本気で活用するには、セキュリティや出力結果の安定性だけでなく、「ITリテラシー格差」までも吸収できるハーネス設計が求められる。

セキュリティやAIの性能の話はするけど、��外とこのリテラシー格差への対応が、AIを組織に根付かせるための鍵なんじゃないかと思っている。が、本当に難しいところ。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

法人がAIを使うには「ハーネス」��必要。

ただ、セキュリティとAI出力結果の安定性だけを考えればいいわけではない。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

組織内にはITリテラシーの差がかなり大きい。

積極的にAIを使いこなそうとする人と、使い方すらよくわからない人が混在している。開発メンバーってITリテラシー高いと思っていた割に。

この格差を放置したままでは、AIは結局「一部の人だけが使えるツール」になってしまう。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

ただし、これは開発側でできること、できないことの限界がある。���れだけ自分たちの会議設計やプロジェクト分割を最適化しても、クライアント側の組織構造・意思決定のあり方が変わらない限り、本当の速度は変わらないので。そんなことわかっているけど難しいよね。

まずは自分のコントロールできる世界から。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

AIやFDEのようなポジションで、1人でプロダクトが作れる時代になってきた。じゃあ組織で開発する意味って、どこに残るんだろう。

最近、開発を縮小したプロジェクトにいて、いくつか気づいたことがある。

[Yusuke｜AI時代のプロジェクトデザイン @Asahi_YN]

解決③ プロジェクトを分割し権限を閉じる

1本の巨大プロジェクトとして管理するのではなく、意思決定できる範囲で分割した方がいい。それぞれに権限を閉じて、稟議・決裁のスコープを小さくすれば、承認の階層も減る。組織的な開発のあり方として、この方向の方が健全なんじゃないかと思う。