皆さん初めまして、QAコンサルタントのノブです。
私はこれまで、大手IT企業等の品質管理部門を長年担当し、様々なプロジェクトの商談判定・監査/監視・レスキュー対応・PMO支援・社内研修等を実施してきました。
その経験の中で、多くの問題プロジェクトで共通することは、”引継ぎ”に関する取組みが不十分、又は全く考慮されていないという点でした。
”引継ぎ”の対策が不十分であれば、何が問題になるのか、どのように対応すべきかを紹介させて頂きます。
ブラックボックス化による弊害
システムを開発･運用するためには、様々なITスキルと業務知識が要求されますが、簡単に身につくものではありません。現実的には、要員や予算･納期等の事情により、特定の人物に業務固定化･ノウハウ集約が進んで、ブラックボックス化するケースが多く発生しています。このような状況になると、下記のような弊害が発生します。
- ドキュメント化がされていない、又は最新化漏れのため、実際の仕様が把握出来ない。
- 改善･最適化を実施するうえで、客観的な判断や効果的な施策が出来ない。
- 設計時の仕様決定や課題の切り分け時に特定人物に負荷が集中する。(ボトルネック化)
- ナレッジ化が出来ていないため、スキルトランスファーに時間が掛かる。
→ 新規プロジェクト/トラブル発生時に、増員メンバーの生産性/品質が低下する。 - キーマンの病欠･所属変更･休職･離職に伴うリスクが非常に高い。
ウォーターフォール開発(WF)における分業化と問題
私がシステム開発に携わり始めた1990年代は、要件定義→設計→開発→テスト→保守が、同一のサプライヤーで開発･運用されることが一般的でした。
そのため、システム企画段階から関与した会社･メンバーが一貫して従事することで、品質を担保することが出来ていました。
しかしながら現在は、企画はコンサルティング会社、設計はA社、開発はB社×複数(オフショア開発含む)、テストはC社、運用はD社と、工程の分業化が進んでいます。
ここで問題となるのが、工程間の業務引継ぎです。
引継ぎの際には設計書の品質が一番重要であり、後工程のサプライヤーは、設計書に記載されていないことは、開発もテストも実施することが出来ないのが実態です。
私が関与したQCDが問題化したプロジェクトでは、設計書のレベル(資料構成･記載項目･記載内容等)が、全て不十分な状況となっていて、後工程で多くの問題が発生していました。
開発担当者及びテスト担当者にとって、仕様の行間を読み取ることは困難であり、要件定義等で確認した背景･検討事項も把握していないため、記載不備=不具合となってしまいます。
またサプライヤー間の壁(利害関係)に加え、昨今はリモート開発によるコミュニケーション密度の低下により、業務･工程引継ぎや仕様調整の難易度は上昇しています。
このため、引継ぎ時及び後工程では様々なコンフリクトが発生し、QCD悪化のみならず、プロジェクト全体の雰囲気(コミュニケーション)が悪化するという事象が発生しています。
引継ぎの円滑化によるメリット
ブラックボックス化(属人化)が防止できて、円滑に仕様継承とスキルトランスファーが出来れば、下記のようなメリットがシステム開発に出てくると考察します。
- 後工程での仕様漏れ･仕様誤認が大幅に減り、システムの品質が向上する。
- 新メンバーの仕様理解が進み、QA数が大幅に削減できる。
- 担当者の理解度が向上し、生産性･品質が向上する。
- キーマンへの負担が減り、本来の重要な作業･課題に集中できる。
- 要員補充が効果的となり、特定キーマンへの依存度が低下し、リスクが分散される。
引継ぎに対する対策
複数のサプライヤーや担当者が入れ替わるプロジェクトにおいて、引継ぎ作業を円滑に行うことは誰もが望むことです。しかしながら引継ぎ作業は軽視されるケースが多いのが実態です。なぜならば、引継ぎ作業には非常に多くの手間と時間を要するため、コスト面の制約があること、具体的なタスクにブレイクダウンすることが難しいことが主な理由です。
そのため実際のプロジェクト推進では、QCDの制約がある中で全体最適化を意識し、該当プロジェクトに適した施策を実施することが重要となってきます。
規模･システム特性･要員構成･業務特性･継続性等を考慮して、下記のような施策をテーラリングして効果的に取り込むことがPM/PMO/QMには要求されることになります。
- プロセス関連
- 1-1.プロジェクト計画書での引継ぎ関連事項の明記(OUTPUT一覧、役割分担、レビュー等)
- 1-2.工程毎の計画と詳細体制図/役割分担(企画～運用保守)
- 1-3.引継ぎ作業のWBS化と見積り
- 1-4.メンバー管理台帳の作成と管理(役割、期間、スキル、ナレッジ教育状況等)
- 1-5.新メンバー受入作業(誰が、いつ、何を教えるか)
- 1-6.工程完了判定
- 1-7.業務説明/引継ぎ会の開催(マイルストーン化)
- 1-8.運用設計書/マニュアル等の整備
- 引継ぎ資料/設計書関連
- 2-1.要件定義書/概要設計書/詳細設計書の詳細化と最新化
※システム全体を俯瞰出来る概要図･一覧系の拡充が効果的 - 2-2.開発規約書/プロジェクトルール等の策定(標準化資料)
- 2-3.新メンバー向けの説明資料の集約
- 2-4.業務概要/詳細説明書(用語集の作成含む)
- 2-5.プロジェクト概要説明書
- 2-6.ひな型アプリ
- 2-7.テスト/本番環境/パラメタ定義等の一覧化
- 2-1.要件定義書/概要設計書/詳細設計書の詳細化と最新化
- その他
- 3-1.リスク管理台帳での対策(要員関連)
- 3-2.新メンバーのトレーナー設定(ペアプロ等)
- 3-3.工程/プロジェクト完了時の振返り会の開催(KPT等を活用)
- 3-4.人員育成計画の立案と実行(短期と中長期)
- 3-5.習熟度の管理と評価
対策事例と効果
私が実際に推進、又は関与したプロジェクトでは下記のような対策を実施し、ブラックボックス化の弊害を減らし、効果を上げることが出来た事例があります。いくつかを簡単にご紹介させて頂きます。
事例１.レビューの徹底
スキルトランスファーを意識したレビューを確実に推進。
→ 仕様理解が進み、追加メンバーの業務スキルが向上。(＋不具合の早期発見)
事例２.要件定義書の体系化
運用保守及びシステム改版までを意識して、要件定義書を充実･詳細化･最新化。
→ 引継ぎ･説明工数の短縮と理解度UPに加え、改定時の影響範囲の検討に活用。
設計･開発工程以降は追加メンバー主体で対応し、コアメンバーの負荷は大幅減。
事例３.要員育成と管理の徹底
要員管理台帳を作成し、受入手続きを体系化。スキルを把握し、役割に応じた育成を実施。
→ 全メンバーに対する「プロジェクト計画書」をはじめとするルール･業務要件の周知徹底を実施することで目的意識/役割が明確化。早期習得とチームの一体感の醸成にも寄与。
まとめ
私の現役時代は、一貫してお客様のシステムを請け負っているという自負と責任感を持ち、プライドを持って対応していました。そのため、部外者がシステム開発/運用に加わる際は、非常に警戒し、受け入れた場合はルールを徹底させたものでした。(逆の立場もあり)
現在のプロジェクトは、役割が専門家･細分化され、責任範囲が曖昧になってきています。もちろん工程の分業化や専門化は時代の流れであり、適用するメリットは大きいです。
しかしながら、工程の分業に対するデメリットを意識し、対策を練らなければ、個別組織や個人の役割最小化が進んだり、責任の押し付け合いになり、結果としてプロジェクトが破綻する可能性が高くなります。
また顧客はLCM(Life Cycle Management)全体での品質を求め、Devopsといった開発手法が注目されているなど、運用保守が重視される流れとなってきています。
最適解はプロジェクト毎に異なりますが、当記事をきっかけに、引継ぎを重視した計画･対策を事前に立案することで、少しでも円滑にプロジェクトを推進して頂ければ幸いです。
機会があれば、引継ぎ･標準化に関連する組織的な対策(人材育成･情報共有･プロセス)について投稿させて頂きます。
