SESに特化したERPって聞いたことないなぁ。

そう思い立って、相当に軽い気持ちで作り始めました。

営業部隊とエンジニア部隊でシームレスに情報連携ができるようになったらビジネスも加速するはず！

そんな「ぼくがかんがえたさいきょうのSES」的な、問題分析や要件定義も置き去りにしたまま作りたい時だって、エンジニアにはありますよね。

次々と新たな生成AIサービスが跋扈し、日進月歩で進化する今日び

生成AIで作ってみた！なんてネタ、この記事を出す頃には色々と既に周回遅れになっているかもしれませんが、、、

大事なのは何を使うかではないのです。

何故作りたいのか、なのです。

開発コンセプトとしてはシンプルに

なるべくコードを書かない

です。

プロジェクト名はプロジェクトを最適な方向にナビゲートするぞって期待を込めて

【PRONAVI】

それではいってみましょう。

まずはGoogle AI Studioに相談を仕掛けてみました。

いいですね、AIは。

「それ今いるの？」「誰が喜ぶの？」「予算はどこから出るの？」

なんて野暮なことは訊いてきません。「素晴らしいアイデアですね！」という前のめり傾聴スタイルがAIの利点です。

さて、早速提案してきてくれました。

素晴らしいアイデアですね！SES事業におけるエンジニアの状況把握とフィードバックの標準化は、エンゲージメント向上や問題の早期発見・解決に繋がり、非常に重要です。

社内ERPの一部として、エンジニア向けのプロジェクト状況報告サイトを構築する際の主要な機能や考慮点を整理してみましょう。

---

**1. 目指すこと・解決したい課題の再確認**

*   **標準化:** 誰がヒアリングしても同じ情報が得られ、フィードバックの質にばらつきが出ないようにする。
*   **効率化:** 1on1の時間をより本質的な対話（キャリア相談、深い悩みなど）に使えるように、定型的な状況報告はシステム化する。
*   **情報集約:** エンジニアの状況、プロジェクトの課題、顧客からの要望などを一元管理し、営業担当や管理職が必要な情報にアクセスしやすくする。
*   **早期発見:** プロジェクトの炎上リスク、エンジニアのメンタルヘルス問題などを早期に察知する。
*   **記録・分析:** 過去の状況やフィードバック内容を記録し、傾向分析や改善活動に活かす。

**2. 必要な機能案**

**【エンジニア向け機能】**

*   **マイページ:**
    *   自身の基本情報（氏名、所属、連絡先など）
    *   現在参画中のプロジェクト情報表示
    *   過去の報告履歴閲覧
*   **プロジェクト状況報告フォーム:**
    *   **報告対象プロジェクト選択:** (複数掛け持ちの場合)
    *   **報告日:** (自動入力)
    *   **報告種別:** 定期報告（週次、月次など）、臨時報告（問題発生時など）
    *   **プロジェクト進捗:**
        *   今週/今月の主な業務内容（選択式＋自由記述）
        *   進捗度（計画比：順調、やや遅れ、大幅遅れなど選択式）
        *   達成したこと、成果物
    *   **課題・問題点:**
        *   技術的な課題
        *   コミュニケーション上の課題（顧客、チーム内）
        *   環境・設備に関する問題
        *   その他（自由記述）
        *   課題の深刻度（高・中・低など）
    *   **顧客からのフィードバック・要望:**
        *   顧客から直接受けた評価、要望など
    *   **自身の状況:**
        *   業務負荷（高い、適切、低い）
        *   残業時間（目安）
        *   体調・メンタルヘルス（選択式：良い、普通、少し悪い、悪いなど）
        *   困っていること、相談したいこと（会社に対して、上長に対してなど）
        *   スキルアップ・キャリアに関する要望（こんなスキルを身につけたい、次の案件の希望など）
    *   **その他特記事項:** (自由記述)
    *   **添付ファイル:** (参考資料などがあれば)
*   **フィードバック確認機能:**
    *   提出した報告に対して、上長や営業担当からのコメントや指示を確認できる。

**【管理者（上長・営業担当など）向け機能】**

*   **ダッシュボード:**
    *   担当エンジニアの報告状況一覧（未提出者のアラートなど）
    *   要注意エンジニアのハイライト（例：メンタルヘルス「悪い」、課題の深刻度「高」など）
    *   プロジェクトごとの状況サマリー
*   **報告閲覧・検索機能:**
    *   エンジニア名、プロジェクト名、期間などで報告を検索・フィルタリング
    *   個別の報告内容詳細表示
*   **フィードバック入力機能:**
    *   エンジニアの報告に対してコメント、アドバイス、指示を入力
    *   対応状況管理（例：未対応、対応中、対応済）
*   **アラート機能:**
    *   特定のキーワード（例：「退職」「つらい」）や、特定の項目でネガティブな回答があった場合に通知
*   **レポート出力機能:** (CSV, Excelなど)
    *   エンジニア別、プロジェクト別、期間別などで集計レポートを出力
    *   勤怠状況のサマリー（残業時間傾向など）

**3. 考慮すべき点**

*   **入力負荷の軽減:**
    *   エンジニアにとって負担にならないよう、選択式の項目を多くする。
    *   前回報告内容をコピーして編集できる機能など。
    *   スマートフォンからも入力しやすいレスポンシブデザイン。
*   **報告頻度:**
    *   週次、隔週、月次など、適切な頻度を設定する。プロジェクトの状況やエンジニアの経験によって変えることも検討。
*   **誰がフィードバックするか:**
    *   直属の上長か、営業担当か、あるいは両方か。役割分担を明確にする。
*   **セキュリティ:**
    *   個人情報や機密情報を含むため、アクセス権限管理を徹底する。
*   **既存システムとの連携:**
    *   もし勤怠管理システムやプロジェクト管理ツールがあれば、それらとの連携も視野に入れる（将来的に）。
*   **運用ルール:**
    *   報告期限、フィードバック期限、エスカレーションルールなどを定める。
    *   システム導入の目的と使い方をエンジニアに丁寧に説明し、協力を得る。
*   **「報告のための報告」にならないように:**
    *   入力された情報がきちんと活用され、エンジニアにメリット（問題解決、適切なフィードバック、キャリア支援など）があることを示す。
    *   システムはあくまでツール。1on1での血の通ったコミュニケーションを補完するものと位置づける。重要な課題は別途面談を設定する。

**4. 開発アプローチ**

*   **スモールスタート:** まずは最小限の機能（エンジニアの報告フォームと管理者の閲覧・コメント機能）から始め、利用状況を見ながら改善していくアジャイル的なアプローチがおすすめです。
*   **プロトタイプ作成:** 実際の画面イメージをプロトタイプで作成し、エンジニアや管理者に意見を聞きながらブラッシュアップする。
*   **技術選定:**
    *   **Webフレームワーク:** Ruby on Rails, Django (Python), Laravel (PHP), Node.js + Express/NestJS など。
    *   **フロントエンド:** React, Vue.js, Angular など、またはサーバーサイドレンダリング主体でも。
    *   **データベース:** PostgreSQL, MySQL など。
    *   **インフラ:** AWS, GCP, Azure などのクラウドサービスを利用するとスケーラビリティやメンテナンス性が向上します。社内サーバーでも可能ですが、管理コストを考慮。
    *   **ローコード/ノーコードツール:** FileMaker, kintone, Microsoft Power Apps などのツールでプロトタイプ～実運用まで持っていくことも可能です。開発速度は速いですが、カスタマイズ性や拡張性に制約が出る場合があります。

**5. 導入後の期待効果**

*   エンジニアの定着率向上
*   プロジェクトトラブルの未然防止・早期解決
*   管理職・営業担当の業務効率化
*   データに基づいた客観的な状況把握と意思決定
*   組織全体のコミュニケーション活性化

---

この構想は、SES事業の運営において非常に価値のあるものになると思います。
まずは、どの情報が最も重要で、どの機能から着手するかを具体的に検討していくと良いでしょう。
もしよろしければ、さらに具体的な質問項目案や、画面イメージのラフスケッチなども一緒に考えられますよ。

素晴らしい。もう君がディレクターした方がいいんじゃないかな。
「エンジニアにとって負担にならないよう、選択式の項目を多くする」って気遣いもいいね。

ここからちょっと味付けをしていきます。同じくGoogle AI Studio上でインプット。

まずプロジェクト状況を報告できること。そして報告の質を標準化することが優先だね。
エンジニアへの質問項目はpmbokに沿ったプロジェクト管理に大事な指標をベースにするってのは難解すぎるかな？

返す刀の返答。

PMBOKのプロジェクト管理指標をベースにするという着眼点は素晴らしいですね。プロジェクトの健全性を測る上で非常に有効な視点ですし、報告の質を標準化するという目的にも合致します。

ただ、おっしゃる通り、エンジニアの方々にとってPMBOKの用語や概念が **そのままでは難解に感じられる可能性** は確かにあります。
「報告のための報告」になってしまい、現場のリアルな声が吸い上げにくくなったり、入力負荷が高すぎて報告が滞ったりする事態は避けたいですよね。

そこで、以下のようなアプローチはいかがでしょうか。

**PMBOKの「考え方」を参考にしつつ、エンジニアが直感的に理解・回答しやすい言葉に置き換える**

PMBOKには10の知識エリア（統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー）がありますが、これら全てを網羅的にエンジニアに質問するのは現実的ではありません。

SES事業のエンジニアが現場で直面しやすい状況や、会社として把握したい情報を中心に、これらの知識エリアの**エッセンスを抽出**し、具体的な質問に落とし込みます。

**具体的な質問項目案の方向性（例）：**

PMBOKの知識エリアを意識しつつ、平易な言葉で表現します。

1.  **業務内容・進捗について (スコープ、スケジュール)**
    *   「今週（今月）の主な作業内容と進捗状況を教えてください。」（例：〇〇機能の設計 50%完了、〇〇バグの修正 3件完了など）
    *   「当初の計画と比較して、進捗はどうですか？」（選択式：計画通り、やや遅れている、大幅に遅れている、計画より進んでいる）
    *   「遅れている場合、主な理由は何ですか？」（自由記述または選択式：仕様変更、技術的課題、人員不足、連携部署の遅れ、その他）
    *   「作業を進める上で、何か困っていることや不明点はありますか？」（技術的なこと、仕様に関することなど）

2.  **課題・リスクについて (リスク、品質)**
    *   「プロジェクトで何か問題や課題は発生していますか？」（はい／いいえ）
        *   「はい」の場合：「具体的にどのような問題・課題ですか？」（例：特定の技術での実装に苦戦、テスト環境の不備、顧客からの急な仕様変更など）
        *   「その問題・課題の状況は？」（選択式：解決済み、対応中、未対応・要相談）
        *   「その問題・課題について、会社（営業や上長）にサポートしてほしいことはありますか？」
    *   「今後、問題になりそうなことや懸念点はありますか？」

3.  **コミュニケーション・人間関係について (コミュニケーション、ステークホルダー、資源)**
    *   「お客様やチームメンバーとのコミュニケーションは円滑ですか？」（選択式：非常に円滑、概ね円滑、少し課題あり、課題が多い）
    *   「お客様から何か要望やフィードバックはありましたか？（褒められたこと、改善要望など）」
    *   「チーム内で何か困っていることや、改善してほしいことはありますか？」

4.  **自身の状況・要望について (資源、ステークホルダー)**
    *   「現在の業務量についてどう感じますか？」（選択式：多い、適切、少ない）
    *   「残業時間は平均してどのくらいですか？」（目安でOK）
    *   「体調やメンタル面で気になることはありますか？」（選択式：特にない、少し気になる、かなり気になる）
        *   「気になる」場合：「差し支えなければ、どのようなことか教えてください。」（会社としてフォローが必要かどうかの判断材料）
    *   「今後、挑戦してみたい業務や習得したいスキルはありますか？」
    *   「その他、会社に伝えたいことや相談したいことはありますか？」

**標準化のための工夫**

*   **選択式回答の活用:** 自由記述だけでなく、選択式の回答を多く取り入れることで、回答のブレを減らし、集計・分析しやすくします。
*   **具体的な記入例の提示:** 各質問項目に対して、どのようなことを書いてほしいのか、具体的な記入例を示すことで、エンジニアが迷わず入力できるようにします。
*   **必須項目と任意項目の区別:** 必ず把握したい情報は必須項目とし、それ以外は任意項目とすることで、入力負荷を調整します。
*   **用語の統一:** 社内で使われている言葉に合わせるか、平易な言葉を選びます。
*   **定期的な見直し:** 運用を開始した後も、エンジニアからのフィードバックを元に質問項目が適切か、分かりにくい点はないかなどを定期的に見直し、改善していくことが重要です。

**PMBOKの指標を直接使う場合の注意点**

もし、PMBOKの指標（例：SPI、CPI、EVMなど）を直接使いたい場合は、
*   その指標の意味や計算方法をエンジニアが理解しているか、あるいはシステム側で自動計算できるか。
*   エンジニアがその指標を報告するために必要な情報を持っているか。
といった点を考慮する必要があります。一般的には、これらの指標はプロジェクトマネージャーやリーダーが管理する情報であり、個々のエンジニアが日常的に報告するのは難しいかもしれません。

**まとめ**

PMBOKの考え方はプロジェクト管理のベストプラクティスであり、報告内容の質を高める上で非常に参考になります。重要なのは、そのエッセンスをいかに現場のエンジニアが「自分ごと」として捉え、負担なく、かつ正確に報告できる形に落とし込めるか、という点です。

まずは、いくつかの主要な観点（進捗、課題、コミュニケーション、自己状態など）から質問項目を絞り込み、シンプルな形でスタートし、徐々にブラッシュアップしていくのが良いかもしれませんね。

この方向性で、さらに具体的な質問項目を一緒に検討していくことも可能です！

（^^;）（^^;）（^^;）やっぱつえぇわ。

さぁガンガンいこうぜ！

選択式回答の活用はその通りで、なるべく入力の負荷を減らしたい。それと、全て必須入力ではなくて、情報が分かり次第都度入力して報告できるようにしたいね。だから必須項目と任意項目の区別も提案してくれた通り。
まずは質問項目を進捗、課題、コミュニケーション、自己状態に絞って作ろうか。

承知しました！「進捗」「課題」「コミュニケーション」「自己状態」の4つのカテゴリに絞り、入力負荷を軽減しつつ、都度更新できるような質問項目案を作成してみましょう。

**基本方針**

*   **選択式中心＋補足の自由記述:** 迅速な入力と詳細把握のバランスを取ります。
*   **「状況変化があったら更新」を促す:** 全てを一度に埋めるのではなく、変化があったタイミングで該当箇所を更新する運用を想定します。
*   **必須項目は最小限:** エンジニアが最初にプロジェクトにアサインされた時や、大きな変更があった時に更新してもらうコアな情報に絞ります。
*   **「前回報告からの変更点」を意識させる:** 定期的なチェックだけでなく、変化点を捉えやすくします。

---

**【プロジェクト状況報告】質問項目案**

**凡例:**
*   **（必須）**: 初回登録時や大きな変更時に必ず入力してほしい項目
*   **（任意）**: 状況に応じて入力。または定期的な自己チェックとして入力。
*   **[選択式]**: プルダウンやラジオボタンなどで選択
*   **[自由記述]**: テキスト入力
*   **[日付]**: 日付入力
*   **[数値]**: 数値入力

---

**A. プロジェクト基本情報**
   （ここは主に初回登録時や変更時にエンジニア自身が確認・修正する情報。システム側でマスター管理されていれば、エンジニアは選択するだけで済む場合も）

1.  **報告対象プロジェクト名:** [選択式] （複数アサインされている場合）**（必須）**
2.  **現在の役割・担当業務:** [自由記述] （例：基本設計、詳細設計、開発（フロントエンド）、テスト）**（必須）**
3.  **プロジェクト開始日（自身のアサイン日）:** [日付] **（必須）**
4.  **プロジェクト終了予定日（自身の離任予定日）:** [日付] （任意）
5.  **主な使用技術・ツール:** [自由記述] （例：Java, Spring Boot, React, AWS, Git, Slack） （任意）

---

**B. 進捗状況**
   （日々の業務で変化があれば更新。週に一度など定期的に見直すことを推奨）

1.  **現在の主な作業フェーズ/タスク:** [自由記述] （例：〇〇機能の画面設計、△△APIの開発、□□バグ修正対応）**（必須）**
2.  **作業の進捗度:** [選択式] **（必須）**
    *   予定通り
    *   やや遅れている
    *   大幅に遅れている
    *   予定より進んでいる
    *   （その他：[自由記述]）
3.  **進捗に関する補足・理由:** [自由記述] （任意。遅延理由、前倒しの要因、現在取り組んでいる具体的な内容など）
4.  **直近で完了した主なタスク/成果物:** [自由記述] （任意。報告の区切りやアピールポイントとして）
5.  **次のマイルストーン/目標:** [自由記述] （任意。短期的な目標を意識するため）

---

**C. 課題・リスク**
   （問題が発生したり、懸念事項が出てきた場合に都度更新）

1.  **現在、プロジェクトで困っていることや課題はありますか？:** [選択式] **（必須）**
    *   特になし
    *   あり（詳細は以下に記入）
2.  **課題の種類:** [選択式・複数選択可] （任意。「あり」の場合）
    *   技術的な問題（スキル不足、不明点、実現困難など）
    *   仕様の問題（仕様変更、仕様の曖昧さ、矛盾など）
    *   環境の問題（開発環境、テスト環境、ツールなど）
    *   リソースの問題（人員不足、時間不足など）
    *   コミュニケーションの問題（詳細はDセクションへ）
    *   品質の問題（バグ多発、性能問題など）
    *   その他：[自由記述]
3.  **課題の詳細と現在の状況:** [自由記述] （任意。「あり」の場合。具体的に何がどうなっているか、どう対応しているかなど）
4.  **課題の深刻度:** [選択式] （任意。「あり」の場合）
    *   軽微（自身で対応可能）
    *   中程度（相談・サポートが必要）
    *   深刻（プロジェクト進行に大きな影響あり、至急対応が必要）
5.  **課題解決のために会社（営業・上長）に期待するサポート:** [自由記述] （任意。「あり」の場合。具体的な要望を記入）
6.  **今後、問題になりそうな懸念点やリスク:** [自由記述] （任意。早期に情報を共有するため）

---

**D. コミュニケーション**
   （顧客やチームメンバーとの関係性に変化があった場合や、定期的な振り返りで更新）

1.  **顧客担当者との関係性:** [選択式] （任意）
    *   非常に良好
    *   良好
    *   普通
    *   やや課題あり
    *   課題が多い
    *   （補足：[自由記述]）
2.  **チームメンバー（社内・社外含む）との連携:** [選択式] （任意）
    *   非常にスムーズ
    *   スムーズ
    *   普通
    *   やや課題あり
    *   課題が多い
    *   （補足：[自由記述]）
3.  **顧客からのフィードバックや要望:** [自由記述] （任意。直接受けた評価、感謝の言葉、改善要望、追加要望など）
4.  **コミュニケーションにおける課題や困っていること:** [自由記述] （任意。報告しづらい、情報共有が不足している、会議が多いなど）
5.  **社内（営業・上長）への報告・連絡・相談のしやすさ:** [選択式] （任意）
    *   非常にしやすい
    *   しやすい
    *   普通
    *   ややしにくい
    *   しにくい
    *   （改善してほしい点など：[自由記述]）

---

**E. 自己状態**
   （自身のコンディションやキャリアについて、変化を感じた時や定期的な振り返りで更新）

1.  **現在の業務負荷:** [選択式] **（必須）**
    *   非常に高い（キャパオーバー気味）
    *   高い（やや忙しい）
    *   適切
    *   低い（手持ち無沙汰感あり）
    *   非常に低い
2.  **直近1週間の平均残業時間（目安）:** [選択式] （任意）
    *   0時間
    *   1～5時間程度
    *   5～10時間程度
    *   10～20時間程度
    *   20時間以上
    *   （具体的な時間：[数値] 時間）
3.  **体調面で気になること:** [選択式] （任意）
    *   特になし
    *   少し気になる（例：睡眠不足、肩こりなど）
    *   かなり気になる（医師の診断が必要なレベルなど）
    *   （詳細：[自由記述]）
4.  **メンタル面で気になること:** [選択式] （任意）
    *   特になし
    *   少し気になる（例：ストレス、モチベーション低下など）
    *   かなり気になる（専門家のサポートが必要なレベルなど）
    *   （詳細：[自由記述]）
5.  **現在の業務内容に対する満足度:** [選択式] （任意）
    *   非常に満足
    *   満足
    *   普通
    *   やや不満
    *   不満
    *   （理由や改善希望など：[自由記述]）
6.  **スキルアップやキャリアに関する希望・相談:** [自由記述] （任意。挑戦したい技術、次の案件の希望、研修要望など）
7.  **その他、会社や上長に伝えたいこと（個人的な相談も含む）:** [自由記述] （任意。この報告フォームで伝えられる範囲で）

---

**運用イメージの補足**

*   **初回登録:** プロジェクトアサイン時に、エンジニアは「A. プロジェクト基本情報」と、その時点での「B～E」の必須項目を中心に登録。
*   **随時更新:** 何か変化（進捗、課題発生、体調変化など）があったら、該当する項目をエンジニアが更新。
*   **定期的な確認・棚卸し:** 例えば週に一度、月末などにエンジニア自身が全項目を見直し、現状とズレがないか確認・更新する時間を設けることを推奨。管理側もそのタイミングでチェック。
*   **通知機能:** 特定の項目（例：課題の深刻度が「深刻」、メンタル面で「かなり気になる」など）が入力された場合、管理者にアラート通知が飛ぶようにすると早期対応に繋がります。
*   **入力促進のためのリマインダー:** 一定期間更新がないエンジニアに対して、システムからリマインダーを送る機能も有効かもしれません。

この質問項目案はいかがでしょうか？
エンジニアの方々が実際に使うことを想定して、さらにブラッシュアップしていきましょう。
例えば、「この質問は答えにくいかも」「こういう聞き方の方が良いのでは」といったご意見があれば、ぜひお聞かせください。

ちゃんといかがでしょうか？って確認してくれるのもいいNE。
でもNA、アウトプットのスピードが早すぎてこっちの思考と検討が追いつかないZE。

ひとまずこの方針で進めていこう。
AIエージェントに開発を任せようと思っているので、要件定義としてまとめてくれるかな。

承知いたしました。AIエージェントへの開発指示を想定した要件定義としてまとめます。
これは初期の要件定義であり、開発を進める中でAIエージェントと対話しながら、より詳細化していくことを前提としています。

---

**プロジェクト状況報告システム 要件定義書**

**1. システム名称（仮称）**
   SESエンジニア プロジェクト状況報告システム

**2. 開発目的**
   *   SES事業に従事する社内エンジニアのプロジェクト状況報告プロセスを標準化する。
   *   エンジニアからの報告内容（進捗、課題、コミュニケーション状況、自己状態など）を一元的に集約・可視化する。
   *   プロジェクトにおける潜在的なリスクやエンジニアのメンタルヘルス問題を早期に発見し、適切な対応を可能にする。
   *   1on1ミーティングの質を向上させるため、定型的な状況報告は本システムで行い、対話の時間をより本質的な内容に充てる。
   *   収集したデータを分析し、組織的な改善活動やエンジニアのキャリア支援に活用する。

**3. 利用者**
   *   **エンジニア:** プロジェクト状況を報告する主体。自身の報告履歴の確認も行う。
   *   **管理者（営業担当、上長、人事担当など）:** エンジニアからの報告を閲覧し、必要に応じてフィードバックや対応を行う。全体の状況を把握する。

**4. 主要機能**

   **4.1. エンジニア向け機能**
      *   **ログイン機能:**
          *   社内アカウント（例: メールアドレスとパスワード、SSOなど）による認証。
      *   **マイページ機能:**
          *   自身がアサインされているプロジェクト情報の一覧表示（複数アサイン対応）。
          *   各プロジェクトの最終報告日、報告ステータス（例: 報告済、下書き中）の表示。
          *   過去の報告履歴の閲覧。
      *   **プロジェクト状況報告機能:**
          *   報告対象プロジェクトの選択。
          *   以下のカテゴリに関する情報を入力・更新できるフォーム。
              *   A. プロジェクト基本情報
              *   B. 進捗状況
              *   C. 課題・リスク
              *   D. コミュニケーション
              *   E. 自己状態
          *   各質問項目は、前回の「質問項目案」で定義された通り、選択式、自由記述、日付、数値入力などを組み合わせる。
          *   必須項目と任意項目を区別し、エンジニアは情報が分かり次第、都度入力・更新できる。
          *   入力内容は一時保存（下書き保存）できる。
          *   「報告する」ボタンで正式に報告を提出する。
      *   **フィードバック確認機能:**
          *   提出した報告に対して、管理者からのコメントや指示を確認できる。
          *   未読/既読管理。

   **4.2. 管理者向け機能**
      *   **ログイン機能:**
          *   社内アカウントによる認証（エンジニアとは権限を分離）。
      *   **ダッシュボード機能:**
          *   担当エンジニアの報告状況サマリー（未報告者、特定のアラートが出ているエンジニアなど）。
          *   主要な課題やリスクの傾向表示（簡易的なグラフやリスト）。
      *   **報告一覧・検索機能:**
          *   全エンジニアまたは担当エンジニアの報告を一覧表示。
          *   エンジニア名、プロジェクト名、報告日、キーワード、特定の項目（例: 課題の深刻度が高いもの）などで検索・フィルタリングできる。
          *   報告内容のソート機能（報告日順、エンジニア名順など）。
      *   **報告詳細閲覧機能:**
          *   個別の報告内容を詳細に閲覧できる。
      *   **フィードバック入力機能:**
          *   エンジニアの報告に対して、コメントやアドバイス、指示などを入力できる。
          *   フィードバック内容をエンジニアに通知する。
          *   対応状況（例: 未対応、対応中、対応済）を管理できる。
      *   **アラート機能:**
          *   特定の条件（例: 「自己状態」のメンタル面で「かなり気になる」が選択された場合、課題の深刻度が「深刻」と報告された場合など）に合致する報告があった際に、管理者に通知（メール、システム内通知など）する。
      *   **ユーザー管理機能（システム管理者向け）:**
          *   ユーザーアカウントの登録・編集・削除。
          *   ロール（権限）管理。
      *   **（将来的に検討）レポート出力機能:**
          *   指定した条件で報告データをCSVやExcel形式でエクスポートできる。

**5. データ項目**
   前回の「【プロジェクト状況報告】質問項目案」で定義した項目群をデータベースに格納する。
   *   **A. プロジェクト基本情報:** プロジェクト名、役割、アサイン日、終了予定日、使用技術など。
   *   **B. 進捗状況:** 作業フェーズ/タスク、進捗度、補足理由、完了タスク、次期目標など。
   *   **C. 課題・リスク:** 課題有無、種類、詳細、深刻度、期待サポート、懸念点など。
   *   **D. コミュニケーション:** 顧客関係性、チーム連携、顧客フィードバック、コミュニケーション課題、社内報告のしやすさなど。
   *   **E. 自己状態:** 業務負荷、残業時間、体調、メンタル、業務満足度、キャリア希望、その他伝達事項など。
   *   上記に加え、報告ID、報告者ID、報告日時、最終更新日時、管理者フィードバック内容、対応ステータスなどの管理項目も必要。

**6. 非機能要件**
   *   **ユーザビリティ:**
      *   エンジニアが直感的かつ簡単に入力できるインターフェース。
      *   入力負荷を軽減するため、選択式の項目を多用し、スマートフォンからの入力も考慮したレスポンシブデザインであること。
      *   前回報告内容を参照・コピーして編集できる機能（検討）。
   *   **セキュリティ:**
      *   適切なアクセス権限管理（エンジニアは自身の情報のみ、管理者は担当範囲の情報のみ閲覧可能など）。
      *   個人情報を含むため、データの暗号化や不正アクセス対策を講じること。
      *   ログイン認証のセキュリティ強化（例: パスワードポリシー、二要素認証の検討）。
   *   **パフォーマンス:**
      *   システムの応答速度が快適であること（目安として主要画面の表示3秒以内）。
      *   多数のエンジニアが同時期に報告しても性能が劣化しないこと。
   *   **可用性:**
      *   業務時間中は安定して稼働すること。計画メンテナンス時を除き、高い稼働率を目指す。
   *   **拡張性・保守性:**
      *   将来的な機能追加や変更に対応しやすい設計であること。
      *   コードの可読性、保守性が高いこと。
      *   利用する技術スタックは、メンテナンス性や開発コミュニティの活発さを考慮すること。

**7. その他考慮事項**
   *   **運用ルール:**
      *   報告の頻度（週次、月次、随時など）や期限。
      *   フィードバックのルール（誰が、いつまでに、どのように行うか）。
      *   アラート発生時のエスカレーションフロー。
      *   これらの運用ルールはシステム外で定義するが、システムがそれを支援できることが望ましい。
   *   **導入・教育:**
      *   システム導入の目的と使い方について、エンジニアおよび管理者への説明会やマニュアル提供が必要。
   *   **既存システムとの連携:**
      *   現時点では必須ではないが、将来的には勤怠管理システムや社員マスタなど、他の社内システムとの連携も視野に入れる（API連携など）。
   *   **開発アプローチ:**
      *   アジャイル開発を推奨。まずはコア機能（報告入力、閲覧、フィードバック）からスモールスタートし、利用者からのフィードバックを元に改善を重ねる。

---

この要件定義が、AIエージェントによる開発の第一歩として役立つことを願っています。
開発を進める中で、AIエージェントから具体的な質問や確認が出てくると思いますので、その都度詳細を詰めていく形になるでしょう。

「AIエージェントによる開発の第一歩として役立つことを願っています。」だって

気が利くのよ。この一言なのよ。

「あなたの幸せを、いつも願っています」的な一言が、あるのとないのとではね。

全然関係無い（こともない）ですけど、漫画のテラフォーマーズ外伝アシモフで登場する、タチヤナって女性キャラのセリフがとてもよくってですね、ずっと覚えているんです。

タチヤナはアシモフに恋心を抱いとりまして

「ついて来るな」「なんで平凡に生きようとしない」「俺についてきても不幸になるだけだ」

そう言って距離を置こうとするアシモフに対して

「隊長、あなたが手術を受ける時、傍にいさせてください。火星に行く直前まで補佐をさせてください。

「私は....」

「あなたの激動の人生で　私だけは何も変わらず傍にいます」

「だから...安心して欲しいんです」

どんな時でも信頼してくれる人、帰る場所、変わらない場所があるということ

それがどれだけ心の支えになるか

閑話休題！

これ以降もやりとりはあったんですが、記事が長くなりすぎちゃうのでかいつまんで。

ログイン機能はGoogleWorkSpaceのアカウントと連携させたいので、Googleアカウントでのログインを可能としたいな。

→Google OAuth 2.0を利用したシングルサインオン、SSOの提案をしてくれました。

初回ログイン時のユーザープロビジョニング」の方針は、メールアドレスを元にした自動作成にしたいな。

→要件定義に反映してくれました。またセキュリティと管理の観点から、許可するGoogleアカウントのドメインを制限する という点を加えることを強く提案してくれた。意図しない外部のGoogleアカウントでのユーザー作成を防止することができる。抜け漏れを多角的な視点で指摘してくれるのが素敵。

ここからは別のAIエージェントを組み合わせてみます。
Devin.aiっていう、AIエージェントサービスを活用しました。

Google AI Studioで整理してもらった要件定義をインプット。
リポジトリ設定してないぞエラーが出てますが、一旦スルー。

要件定義インプット後、ここでpush先のリポジトリ情報をインプット。

おおスマンスマン、ってことで権限付与後に約16分で叩き台実装完了(　ﾟдﾟ)

ローカルアプリの公開までやってくれてるもよう。
過程を覗いていると、仮想サーバー上でclone〜実装〜DBコンテナ上で単体テスト的なところまでやってくれてるっぽい。

Google OAuthの設定内容まで指導してくれるのよ。
もう先生やん。

動作確認をしたいのでデプロイ環境を相談しつつ模索。

laradock環境まで構築してくれんのかい。
しかも「やっといて」レベルの一言指示で。
意図を汲んでくれすぎるだろ。

その後、MySQLコンテナ起動失敗やらDocker周りのエラーが発生するも、全てdevin先生に訊いて解決。

そしてようやく、一切コードを書かずに、ローカル環境でこれを表示する所まで辿り着きました。

果たして動くのか.....！！

続きは次号をお待ちください(*^ω^*)