ID:74221さん

前職SIerにて、内製化を進めるエンジニア組織の人とチームをマネジメントしてきた。PM/PLと並行してEMを担当し、5名から最大15名のチームを4年間受け持った。グループ・部の目標策定、1on1・評価・育成、採用戦略（TMP設計）・面接を含む採用業務を担い、ニアショア開発拠点立ち上げに参画し、半年間現地チームのマネージャも兼務した。

私の責務は、内製化に伴い拡大するエンジニア組織において、メンバーが定着・成長し、組織として継続的にプロジェクトを遂行できる状態を維持することにある。本責務は、内製化を提案し、組織のあるべき姿を自ら描いて推進する立場から担ってきた。具体的には次の3つを並列で担う。 (1) メンバー: 辞めずに長く活躍でき、新卒・中途を問わず案件で活躍できるスキルを獲得できる状態にする。 (2) 組織: 採用・育成・評価が継続的に行われ、組織として安定して機能できる状態にする。 (3) ニアショア拠点: 本社と一体感を持って機能し、自走できる状態にする。

これらの状態を作るため、組織の健全性・定着、育成、採用、ニアショア開発拠点立ち上げの4領域に並行して取り組んだ。 ## 組織の健全性・定着 目的（目指した姿）: - メンバーが辞めずに長く活躍できる状態 - メンバー同士が打ち解け、活発にコミュニケーションが生まれる状態 考え方: - 良い雰囲気は自然には生まれない。継続的に場を作り、自分が起点となってメンバー同士の自発的な交流を促す - 1on1を本来の目的で運用し、相互理解を関係の土台にする 取り組んだ活動: - 週1のチーム会に雑談の時間を設け、自分から話題を振ってメンバー同士の対話を促した - 1on1で業務以外も含めた相互理解を深め、打ち解けやすい関係を作った - 育成の場(研修・勉強会)でも、中堅が和気あいあいと、かつ真剣に取り組む姿勢が若手に伝播し、交流の場として機能した 直面した問題と工夫: - リモート移行で発言が同時にしづらくなった → チャットを併用し、リモートでも雑談・交流の時間を維持した ## 育成 目的（目指した姿）: - 新卒・中途が案件で活躍できるスキルを獲得できる状態 - 中堅が教える経験を通じて専門性を深め、成長できる状態 - 若手と中堅がプロジェクト外でも結びつき、知見共有が起きる状態 考え方: - 自身が育成の仕組みのない環境で苦労した経験から、わからない人の視点に立って設計した - 即戦力の採用が難しい中で、ポテンシャルのある若手を採用して育てる方針を取った - 教わる側のスキル獲得だけでなく、教える側(中堅)も学びを深める双方向の仕組みとした - 顧客に専門技術を説明する力が求められるため、若手が調べて発表し、中堅が質問する形式を取り入れた 取り組んだ活動: - 新卒研修カリキュラムの策定と実施 - 中途入社研修の研修メニュー作成と実施 - 社内勉強会の主催 - LTの導入と主催 - グループ企業間での合同勉強会の主催 直面した問題と工夫: - 教育に使える稼働工数の制限 → 個人の目標で勉強会・LTの回数を決定し、最低回数分のスケジュールを事前確定。目標回数までは稼働時間を使用可、それ以上は自分の時間 → カリキュラムごとに教える担当を複数人設定(例: 設計研修はA・B・C担当)し、担当者間で調整 - 勉強会の質の確保 → 中堅以上が担当する勉強会・LTでは、初学者向けテーマではなく専門領域の知見共有に焦点を絞った。ただし最新技術の紹介は、領域の専門性の有無に関わらず誰もが初見となるため対象に含めた ## 採用 目的（目指した姿）: - 内製化を進めるために必要な人材を継続的に確保できる状態 - 役職・スキル・レベルが定義され、欲しい人材像が組織で共有された状態 - 入社したメンバーが受け入れ態勢の中で活躍できる状態 考え方: - 即戦力の採用が難しい中で、ポテンシャルのある若手を採用し、育成と連動させた - 採用を人事任せにせず、エンジニアリング視点で主体的に関与し、ミスマッチを防いだ 取り組んだ活動: - 役職・欲しいスキル・求めるレベルの定義 - 募集文の作成 - スカウト文のチェック - 採用計画 - レベル感に合わせた面接担当の検討 - 面接実施(PL/PMクラスを1次、新卒/ジュニアを2次) 直面した問題と工夫: - 給与水準で他社と競合しにくい → 給与以外の魅力で補完。育成で整備した教育制度・勉強会・LTに加え、「組織の健全性・定着」で築いた活発なコミュニケーションの雰囲気を訴求 → 自分自身とチームの雰囲気を見て入社を決めた応募者が複数いた - 求職者→エージェント→人事→自分と伝わる過程で、職種・スキルの解釈がぶれる(例: プロジェクトリーダの担当範囲、システムエンジニアにプログラマが含まれるか) → 用語を可能な限り揃え、揃えにくいところは説明・補足で認識を合わせた ## ニアショア開発拠点立ち上げ これまで取り組んできた育成・採用・組織づくりの実績から、会社方針で進めるニアショア拠点の立ち上げを任された。現地管理職が採用されるまでの半年間、以下に取り組んだ。 目的（目指した姿）: - 拠点が自走できる状態 - 本社チームと連携・一体感を維持できる状態 - 拠点間の文化・働き方ギャップを解消できる状態 - 拠点立ち上げ期の品質・進捗を確保できる状態 考え方: - 地理的に離れた拠点が孤立しないよう、人の往来と日常的な接点を重視した - 東京で確立した育成体制を移植し、自走できる土台を作った 取り組んだ活動: - 自分自身が月1で現地訪問(リーダ含めたメンバーの育成、孤立感の解消) - 育成してきた部下1名をリーダとして派遣(東京のやり方の波及、ブリッジ役を担う) - 週1で東京メンバーとニアショア拠点メンバーの雑談時間を設定(孤立感の解消) 直面した問題と工夫: - 急な立ち上げで、メンバーのスキルに見合う担当業務を十分に用意できなかった → 業務面: 周囲の協力を得て業務を調整・捻出 → スキル面: 育成で確立した新卒・中途研修カリキュラムと教える体制を活用して対処 ## 総括 育成で確立した研修・知見共有体制は採用やニアショア立ち上げでも活用し、組織運営で築いた雰囲気は採用の訴求にもつながった。個別の問題に対処するのではなく、組織の構造に働きかけることで、育てた人材がリーダーを担い、離職を抑えてメンバーが定着・成長する状態を作り、エンジニア組織が約30名規模まで拡大するのを支えてきた。

ソフトウェア開発における品質をマネジメントしてきた。前職SIerではPM/PL兼品質管理・PMOとして、案件単位の品質作り込みと組織のテスト体系の整備を担った。現職AzitではAI駆動開発推進として、SDD+TDDを基盤に自社プロダクトの品質を作り込んでいる。

私の責務は、ソフトウェア開発の品質を、見積段階で必要な費用・期間を読み込み、各工程で作り込み、運用に耐えるレベルにまで仕上げることにある。具体的には次の3つを並列で担う。 (1) 案件単位: 見積で読み込まれた費用・期間に基づき、要件定義以降の各工程で品質が作り込まれ、認識齟齬・仕様不確実性が上流で解消される状態にする。 (2) 組織: テスト計画から品質評価までのテスト体系が組織として導入され、テンプレートとルールに基づき、案件の状況やメンバーの経験に左右されずに同じ品質を目指せる状態にする。 (3) 自社プロダクト・AI駆動開発: SDD+TDDを基盤に、AIによる実装でも品質を作り込める状態にする。

品質を上げる仕組み化に長年取り組んできた。社内外の実態や国際標準・公的体系を取り込みながら、上流工程の体系化、テスト体系の組織導入、AI駆動開発の品質作り込みの3領域に取り組んだ。 ## 上流工程全体の体系化 目的: - 案件やメンバーの経験に左右されず、組織として同じ品質を作り込める状態にする - 各工程が組織として体系化された状態にする 直面した問題: 各工程が組織として体系化されておらず、案件やメンバーの経験次第で品質が変動し、手戻りや顧客との認識齟齬が生じる 体系化の方針: - 各工程の成果物を、後ろの工程のニーズから逆算して定義する - 成果物の定義には、IPAの分類やV字・W字、ウォーターフォール開発の基本、社内外の慣習を参考にする - テンプレートとガイドで網羅性を担保する(決めておかなければプロジェクトの致命的な問題に発展する項目を中心に、雛形やサンプルを盛り込む) - エンジニアの守備範囲で実績を積みながら、他職種の領域へ徐々に取り組みを広げる 整備した仕組み(工程順): - 提案書: アピールポイントを集約・統一し、フォーマットの統一と最新版管理の仕組みを整備。直近の大型案件の提案書を集めて精査・平準化し、組織として再利用可能な形に整理 - 見積: テンプレートの各項目を詳細化し、抽象的な塊での見積が成立しない構造に - 要件定義: 工程の作業範囲を網羅的に定義。終了条件は、要件を実施する・実施しない・保留の3区分に整理した状態。顧客との合意形成は、要件定義書をテキストで作成し、内容を確認してもらった上で明示的な了解を取る運用に - 設計: 設計書の種類(基本設計、詳細設計、共通設計書、各種一覧)を分類し、それぞれの役割と記載内容を定義。後ろの工程(開発・テスト)で必要なことから逆算して設計の対象を定める。マークダウンで作成しGitベースで管理する運用を整備 - 各工程で行うレビュー: コードレビューはレビューアとレビューイの責任分界点を明示し、観点(可読性・保守性・テスト容易性・障害許容性・脆弱性)を定義。設計書レビューは、設計書の役割分担(各設計書に何を書くか)に沿っているかを観点とする 途中の問題と工夫: - テンプレート詳細化への懸念(慣れた担当者からの手間増加や他社比較での見積額の高さへの懸念) → 詳細な見積根拠を組織の強みと位置付け、説明工数は品質を作り込むために必要なプロセスとして組織内で受容。業務未経験の担当者にとっては何を見積すべきかの指針として機能し、属人化の解消と若手の戦力化に寄与 - ガイド・テンプレートの浸透・教育 → 研修・勉強会で普及活動を同時並行で進め、徐々に理解度を上げる - 他職種領域(提案・見積・要件定義)への展開時の組織的抵抗 → エンジニアの守備範囲で実績を積み、その実績を背景に他職種領域へ徐々に手を伸ばす ## テスト体系の組織導入 目的: - 案件の状況やメンバーの経験に左右されず、組織として同じ品質を目指せる体系にする - 個別案件に閉じず、組織横断でテストが体系化された状態にする 直面した問題: 品質を測定・評価できないため、悪い品質のものがそのままリリースされ、リリース後に障害が多発する。背景として、テストで品質を測定する体系(テストプロセス、テストレベル、テスト技法、テストタイプ、テスト設計、テスト項目のあり方、成果物)が組織として確立していない 体系化の方針: - SQuBOKとISTQBをメインに、IPAやISO規格(ISO/IEC/IEEE 29119、ISO/IEC 9126)、JIS X 0014などの国際標準・公的体系を取り込む - テスト方針・テストプロセス・テスト戦略の組織標準と、各テストフェーズのドキュメントテンプレートを整備する - 個別案件のテスト計画・品質報告から始めて、テスト仕様書・テスト設計、テストレベル・テスト技法・テストタイプの取り込みへと徐々に範囲を広げ、最終的に組織全体に適用するテスト方針・テスト戦略まで拡大する 整備した仕組み: - テスト方針(組織の最上位ドキュメント): テストの定義・目的、テスト組織の役割と構造(品質管理グループ)、テスト技術者(マネージャ・設計者・テスタ)の定義 - テストプロセス: 7工程(見積・計画・分析・設計・実装・実施・品質評価)と各工程の作業・成果物、テスト分析〜設計、テストレベル分類(コンポーネント・統合・システム・受入) - テスト戦略: 部署役割、参画フロー、ドキュメント定義、品質特性(ISO/IEC 9126)、テスト技法、開始/終了/中断/再開基準、判定基準、障害管理、メトリクス - テンプレート: テスト計画書(全体・個別)、テスト設計書(統合・多端末・システム)、テスト仕様書(CAT・WEB・スマホ向け)、テスト品質報告書 途中の問題と工夫: - テスト体系の浸透と教育 → 研修や勉強会で普及活動を継続し、テストの定義・目的、テストプロセス・戦略の概念、テンプレートの正しい使い方を段階的に教育。個別案件のテスト計画・品質報告で実践と並走させ、組織に徐々に定着させた - 途中で立ち上がったQA組織との協調 → 立ち上げ当初からQA組織と緊密に連携し、テスト体系のルールを共同で策定。開発視点とテスト視点の双方が反映された体系を構築した ## AI駆動開発の品質 目的: - AIによる実装でも品質を作り込める状態にする - バイブコーディングの属人化を脱し、AI駆動開発を体系化する 直面した問題: AI駆動開発は業界でも体系・標準が未確立で、バイブコーディングでは設計が欠如し、品質を作り込めず、修正困難・属人化に陥る 体系化の方針: - 領域1・2で培った体系化の発想(後ろからの逆算、テンプレートでの網羅性確保、体系的な学び)をAI駆動開発に適用する - 人間がプロジェクトマネジメントに徹し、AIが実務(要件定義・設計・実装・テスト)を担う役割分担とする - SDD+TDDを基盤とする 整備した仕組み: - 4フェーズの計画的開発プロセス(分析・要求整理 → 要件定義・設計 → 実装 → リファクタリング) - TDD(AIが網羅的にテストケースを生成し、リファクタリング時の安全性を確保) - 段階別プロンプト集・ドキュメントテンプレート、構造化レビューフロー 途中の問題と工夫: - AIは文脈や判断の経緯を保持できず、開発の一貫性が損なわれる → 議事録・技術判断記録などの開発記録を体系化し、AIの記憶の不在を補う - AIによる実装は出力の品質にばらつきが出る → 多視点での並列レビューとAI出力の判定基準群で品質を担保する - 個別プロジェクトで確立した仕組みが属人化するリスク → 個別案件のテンプレート・標準を、他者が再利用できる形(スキル・標準ドキュメント群)に整理 ## 総括 個別案件から組織横断へ、SIerでの受託開発から事業会社でのAI駆動開発へと、環境や開発スタイルは変わってきたが、いずれの場面でも同じ体系化のアプローチで品質を作り込んできた。開発スタイルや案件・メンバーの経験に左右されず、同じ品質を作り出せる仕組みを構築できる。

前職SIerにて、PM/PLと並行してEMを担当しつつ、プロジェクトを軸に組織横断の業務プロセスと役割体系をマネジメントしてきた。提案からリリース・運用までの全工程をタスクとして体系化し、各タスクの担当役割（営業/PM/PL/SE/PG/QA/インフラ/デザイナー/保守運用）を組織標準として定義した。あわせて、案件単位の計画書テンプレートと本番環境作業申請のルール整備にも取り組んだ。

私の責務は、プロジェクトを支える業務プロセスと役割の体系を組織標準として確立し、その標準を案件運営と本番環境作業の組織ルールに展開することにある。具体的には次の3つを並列で担う。 (1) 業務プロセスと役割の組織標準: 提案からリリース・運用までの全工程のタスクと、各タスクを担う役割が、組織標準として確立される状態にする。 (2) 案件運営: 組織標準を案件ごとの計画書に落とし込み、顧客との合意形成が機能する状態にする。 (3) 本番環境作業申請: 組織横断の作業申請ルールが、申請者・承認者双方の負荷を適正化した形で機能する状態にする。

これらの状態を作るため、プロジェクトの進め方を実態に即して整理し、段階的に精緻化することで組織標準として体系化してきた。整備の結果は、業務フローと役割定義、案件単位の計画書、本番環境作業申請の組織ルールの3領域にわたる。 ## 業務フローと役割定義 目的: - プロジェクトの標準的な進め方と各タスクの担当役割が組織として可視化され、参照可能な状態にする - 役割の責任分界が組織標準として共有される状態にする - 可視化により、気付かれていない問題（職能間のグレーゾーン、所有者不明のタスク 等）が構造的に発見できる状態にする 直面した問題: プロジェクトの進め方と各タスクの担当役割が組織として整理されていないため、案件ごとに進め方がばらつき、タスク抜けや認識齟齬による手戻り、プロジェクト参画者(特に若手や入社直後のメンバー)の立ち上がり遅延、担当不明なタスクの所在や責任の曖昧化が生じる 方針: - 実態を可視化することから始め、見えてきた問題を段階的に精緻化していく - 既存案件の実情を最大公約数的に集約し、業界基本理論(ウォーターフォール、V字・W字、JSTQB、PMBoK 等)に立脚した形を保つ - 案件ごとの個別制約や新規・追加開発の差異は標準から除外する 整備した仕組み: - プロジェクト全工程(受注前・見積・契約・要件定義・設計・開発・テスト・リリース・運用)のタスクと、各タスクの担当役割(営業/PM/PL/SE/PG/QA/インフラ/デザイナー/保守運用)を定義 - 全体をマトリクス形式のタスク相関図として可視化 - 業務フロー図を若手向け研修資料として精緻化し、社内標準資料として組織に展開 - 展開後は、現場からの建設的議論(タスクの追加・分離 等)を通じて継続的に精緻化され、組織として参照可能な標準として定着した 途中の問題と工夫: - 社内標準として展開する際に、職能間で不要な対立構造が生まれる可能性 → 管掌役員の承認を得た上で、役員主導での組織展開とする - 標準への問い合わせや個別の主張への対応 → 業界基本理論への立脚を根拠として、論理的に説明できる状態を作る ## 案件単位の計画書 目的: - 案件ごとに同じ品質の計画書が作成され、顧客と合意の上で着手できる状態にする - フローと役割が案件単位に展開され、各案件の固有制約・リスクが事前に管理される状態にする - 計画書の作成自体が PM の標準業務として組織に定着する状態にする 直面した問題: プロジェクト計画書を作成する文化が組織に存在しないため、案件運営が属人化し、案件ごとに進め方や顧客との合意プロセスがバラバラで、計画外のリスクが後半でトラブル化する 方針: - 業界知見(PMBoK 等)をベースとしつつ、現場で発生している問題から逆算して「決めておかないと困るもの」をテンプレートに組み込む(複合的なアプローチ) - テンプレートを案件単位の計画書として作成し、顧客との合意の土台とする - 計画書の作成文化を組織に啓蒙し、PM の標準業務として定着させる 整備した仕組み: - プロジェクト計画書テンプレート(主要項目): 役割分担、推進体制、日程計画(マスタスケジュール・クリティカルパス)、プロジェクト制約事項、進行重要事項(品質特性・バグ管理・リリース判定基準・ソース管理・タスク管理 等)、各フェーズ定義、会議体・情報共有方法、リスク/課題管理、変更管理プロセス - 案件着手時にテンプレートから計画書を作成し、顧客と合意した上で進行する運用として組織に定着。第三者や後から参画したメンバーが過去・現在のプロジェクトを把握する参照資料としても機能している 途中の問題と工夫: - 計画書を作成する文化が組織に存在せず、計画書の意義が共有されていない → 計画書の意義を関係者に伝達し、文化として定着させる - 計画書の作成自体が現場で負担と捉えられる → テンプレート利用により作成工数を抑え、負担感を軽減する ## 本番環境作業申請の組織ルール 本ルールは別メンバーが先行整備したベースを継承し、私は運用後のブラッシュアップを担当した。 目的: - 本番環境への作業(リリース、ログ取得、データ取得 等)が、組織として承認されたプロセスで実施される状態にする - 無許可作業や事後承認による顧客への影響リスクが構造的に防がれる状態にする - 申請者・承認者双方の負荷が適正化され、ルールが形骸化せず機能する状態にする 直面した問題: テンプレートの記載が不十分でチェックが機能していなかった。すべての作業が一律マネージャ承認となっていたためマネージャの負荷が高かった。申請の作成期限が定められておらず、事後承認が常態化していた。 方針: - 申請の対象となる作業を網羅的に把握する - 作業の影響度に応じた承認フロー設計で、申請者・承認者の負荷を適正化する - 暗黙のルールを明文化し、ルールが形骸化せず機能する状態を作る - 正当な事後承認の必要性を認め、特例として正式化する 整備した仕組み(ブラッシュアップ後): - 本番環境作業の網羅: リリースに加え、ログ参照、DB 参照、データ取得 等を申請対象に明示 - 作業のグレード分けと承認フロー - プロジェクト内承認: ログ・DB の参照系(影響度低) - マネージャ承認: 通常の本番作業(影響度中) - GM 承認: 初期リリース等(影響度高) - 暗黙ルールの文章化(作業時のバディ制の原則化 等) - 申請の作成期限・担当の明記 - 事後承認の特例ルール: 緊急の障害対応に限定し、テキストでの連絡を必須化 - 上記の整備により、形骸化していたルールが明示的に機能する形となり、影響度別の承認フローで申請者・承認者双方の負荷が適正化された 途中の問題と工夫: - 申請・承認の負荷が高い状態は、現場がルールを迂回する動きにつながり、ルールが形骸化するリスクがあった → 作業の影響度でグレード分けし、グレードごとに承認フローを設定することで、低リスク作業は軽い承認、高リスク作業は重い承認に切り分け、申請者・承認者双方の負荷を適正化した - 事後承認を全面禁止すると、承認者不在時の緊急障害対応に支障が出る → 事後承認を全面禁止せず、緊急障害対応に限定した特例ルールとして正式化し(その場合もテキスト連絡を必須化)、現場の緊急対応能力と組織統制を両立させた ## 総括 業務フローと役割の組織標準を起点として、案件運営の計画書と本番環境作業の組織ルールに展開してきた。いずれの領域でも、実態に即した整理と段階的な精緻化、業界知見と現場で発生する問題からの逆算という共通の姿勢で組織標準を構築してきた。職能間の対立を生まない展開、形骸化を防ぐ負荷設計など、組織が標準を機能させ続けるための運用上の工夫も含めて、プロジェクトを軸に組織横断の業務プロセスを整備できる。