プロジェクトマネージャーの生成AI活用術
目次[非表示]
はじめに
こんにちは、divxの阪村です。
今回はシステムの受託開発プロジェクトのプロジェクトマネージャー（以下PM）として、実際に現場で私が使っている生成AI活用術を厳選してご紹介します。
リスクの洗い出しと対策の叩き立案
プロジェクト管理においては、いかにリスクを潰していくかが大切です。
とはいえ、先行きが不透明なプロジェクトや、あまり経験がない技術や領域のプロジェクトの場合リスクは何か、リスクとわかっていてもどう対処するべきか判断難しい場面もあります。身近にすぐに相談ができる熟練PMがいればその人を頼ってみてもいいでしょう。ただ、常に相談ができるとも限りません。
よく言われることですが、生成AIは経験豊富な頼れるCopilot（副操縦士）です。プロジェクトを成功に導くために不安なことは遠慮せず聞いてみましょう。
私の場合、プロジェクトが始まる前段階では以下のようにざっくりと聞いてみます。今回はChatGPT（GPT-4o）を使用しました。※プロンプト内のプロジェクト内容は架空のものとなります。
プロンプト
私はシステム開発会社のプロジェクトマネージャーです。次に始まる予定のプロジェクトを成功に導くために、障害となりうるリスクを洗い出してください。
以下がプロジェクトの概要です。
●プロジェクト概要
クライアント社内の総合連絡システムに対する追加機能の開発
●契約種別：請負契約
●ステークホルダー：
・クライアント側の窓口となる方：事業企画課の課長。エンジニア経験はないものの、システム開発に関する知識を有する。
・アプリケーションを実際に利用する人：クライアント社内の従業員。ITに詳しくない方も多数おり、サポートや分かりやすいUI設計が求められる
●プロジェクトメンバー：PM1名、エンジニア3名
・シニア層エンジニア：チーム内で唯一インフラ構築が可能
・ミドル層エンジニア：開発速度は中程度だが、細かい仕様まで考慮した設計が得意である
・ジュニア層エンジニア：開発速度は中程度だが、設計が苦手。Rubyについては習熟しているが、Goはチームのサポートが必要な状態である
●技術スタック：
フロントエンド: Vue.js バックエンド: Go データベース: MySQL クラウド: AWS
●スケジュール：開発期間4週間、テスト期間2週間
●現状思いつく課題：
・要件定義の曖昧さ：要件定義書は存在するものの、複数の不明確な点が残っている。
以下回答
プロジェクトを成功に導くためには、さまざまなリスクを事前に洗い出して対策を講じることが重要です。以下に、このプロジェクトに関連する可能性があるリスクをいくつか挙げます。
要件の不確実性
リスク: 要件が不明確なまま開発が進むと、結果としてクライアントの期待に応えられないものになる可能性が高まります。対策: 早期にクライアントと詳細な打ち合わせを行い、要件を明確化する。また、不明確な部分については、仮説を立てて確認し、可能であればプロトタイプを用意する。
クライアントとのコミュニケーション不足
リスク: クライアント側の窓口担当が技術者でないため、技術的なコミュニケーションが上手く取れない可能性があります。
対策: 非技術的な用語を使い、実例を交えて説明する。また、定期的なミーティングを設定し、進捗状況を報告する。技術スタックの未熟さ
リスク: 特にジュニア層エンジニアがGoを未経験です。このため、開発効率が低下する可能性があります。
対策: チーム内での技術共有セッションやメンター制度を導入し、ジュニア層のサポートを行う。
スケジュールの厳しさ
リスク: 実質開発期間が短く、追加機能の開発が間に合わない可能性があります。
対策: 開発の優先順位を明確にし、リソースを最も重要なタスクに集中させる。進捗を細かく管理し、必要であればスコープを調整する。
ITリテラシーの低い利用者
リスク: 開発した機能が正しく使われない可能性があります。
対策: ユーザー視点に立ったUI/UXデザインを心掛け、必要であればトレーニングやガイドを提供する。
インフラ構築の依存
リスク: インフラ構築についてはシニア層エンジニアが唯一の担当のため、リソースの偏りによる遅延が発生する可能性があります。
対策: インフラ構築の標準化と自動化を推進し、他のエンジニアも基本的な作業をサポートできるようにする。また、外部リソースを検討する。
リスク管理計画の策定
事前に考えられるリスクとその対応策を文書化し、チームで確認
これらのリスクを理解し、適切な対策を講じることで、プロジェクトの成功率を高めることができます。
ざっくりと聞いている段階なので、少し考えたら当たり前と思えるような記述も多いものの、この段階で気づきを得られることがあります。
例えば私の場合、仮のプロジェクトとはいえ、上記回答から納品＝プロジェクト成功という視野が狭い考えになっていることに気づきました。
開発会社としては納品は重要ですが、その後のクライアント社内での展開や運用を見据えなければいけません。そういった計画・設計の欠如は今後さらなるリスクを生み出す懸念があります。
また、上記の最初の回答内容から気になることを更に深ぼっていくことも効果的です。
私の場合は追加で以下の様な質問を毎回おこないます。
- 上記の内容を踏まえて、プロジェクトマネージャーとしてプロジェクトのキックオフまでに行うべきことをリストアップしてください。
- 上記の内容を踏まえて、初回のクライアントミーティングまでにおこなうべきことと、ミーティングにて議題に上げるべきことをリストアップしてください。
早期のプロトタイプ作成による合意
要件定義のフェーズやアジャイル開発においては、どのようなアプリケーションや機能を作るかの認識がクライアントと統一することが重要です。
またクライアント側のステークホルダーが複数存在する場合は、口頭や文章だけでは認識を合わせることが難しいため、figmaなどデザインツールにて画面イメージ作成をすること一般的です。
ここでも生成AIの出番です。粗くても良いためで動くものを早期に実装イメージとして、クライアントと共有して実装前に合意を取ることで手戻りのリスク軽減できます。
v0（ https://v0.dev/ ）などのUI生成に特化したサービスもあります。しかし、今回はそこまでクオリティは求めないので、先程と同じくChatGPT（GPT-4o）でプロトタイプを作成してみましょう。
システムの管理者がユーザーの権限を変更できる機能を開発中です。 htmlとbootstrapを用いて、画面を作成してください。
選択できる権限の種類は以下の3つです。 ・プレミアム会員 ・一般会員 ・フリー会員
ラジオボタンで選択が可能でユーザーに対して複数の権限をもたせることはできません。 変更ボタンを押下後は変更内容の確認モーダルが表示されます。
確認モーダル内で変更ボタンを押下して、処理に成功した場合は「権限を変更しました」というフラッシュメッセージが表示されます。
回答を元に表示させたhtmlファイル
一回のプロンプトで中々それっぽい画面を作成してくれました。
質素な画面ではありますが、クライアントにどのような機能を実装するかの認識を合わせるには十分でしょう。
確認モーダル内でどの権限に変更したまで表示してほしいところですが、そのへんの微調整はコーディングのできる人であれば自身でおこなう方が早いでしょう。コーディングが苦手な人でも修正要望を投げればおこなってくれるでしょう。
もっとリッチな画面にしたい場合は、javascriptやcssのフレームワークを指定してやると良いかと思います。
資料作成によるステークホルダーとの共通認識の形成
クライアントとのミーティングにおいて、提案や説明をする際は簡単にでもいいので資料を用意しておきたいことがあります。
私の場合は簡単な資料の場合は、Napkin AI（https://www.napkin.ai/）を使って、資料作成をおこなっています。文章からイラスト案をいくつか提示してくれて、そのイラストをそのままパワーポイントにペーストでき便利です。2024年12月時点では無料で使えます。
また、少しエンジニア寄りなケースにはなりますが、簡単なAWSのシステム全体構成図などを作成する際に活用しているツールも紹介します。
ChatGPTなどのAIチャットツールでPythonのdiagrams（https://diagrams.mingrammer.com/）というライブラリを使用し、構成図を出力するコードを書いてもらいます。
プロンプト
diagramsライブラリを用いてpythonで以下のAWSの構成図を出力してください。
クライアントからのリクエストをまずRoute53で名前解決する。その後、Network FirewallとWAF、ALBを経由してプライベートサブネット内にあるEC2に送信する。EC2の背後にはRDSがある。
生成されたコードをPythonとdiagramがインストールされているPCで実行すると、以下のようなAWSアーキテクチャアイコンを利用した構成図の画像ファイルが生成されました。
ちなみに、この方法は細かいところで融通が効かない部分があるので、今のところ私は納品物等の正式文書に使用せずにあくまで一時的な資料として活用しているのみです。
さいごに
今回は、私がプロジェクトマネージャーとして働く中で、日々の業務で多用している生成AIの活用法をご紹介いたしました。
プロジェクトマネジメントの領域では、人を対象とした業務も多く、AIに完全に置き換わることはまだ時間がかかると感じています。ただ、AIが代替できる部分については積極的に活用し、プロジェクトマネージャー自身はAIで代替の難しい、より価値のある業務に専念できる環境が整いつつあると考えています。
エンジニアだけでなく、プロジェクトマネージャーも今後のさらなる技術革新を積極的に取り入れながら、プロジェクトマネジメントスキルを磨いていく必要がありますね。
最後まで読んでいただき、ありがとうございました。
