ケース3:問題へ対策

52週アグリMD生産工程管理システム
この記事は約7分で読めます。

栽培プロジェクトの遅延が発生してから、業務スキルの育成にとりかかっても、もう遅すぎるのです。

業務スキルの育成には、明確な目標意識を持つことが大事です。

新たな業務を開発する場合、その仕様を完全に把握して実装仕様を完成するのが、外部設計の終了時点です。

実装設計の仕様把握がいつできるかは、栽培プロジェクト進捗管理の重要なマイルストーンです。

これがうまくできるか否かが、栽培プロジェクトのその後を決定するとも言えます。

そのためには、全フェーズの要件定義を目標の品質で終了する必要があります。

要件定義フェーズで業務機能の把握を行い、システム全体の網羅性を確保します。

しかし、要件定義フェーズで明確化するのは業務機能であり、実装する要件・機能を取引仕様に、ユーザー・インターフェースを画面・帳票設計仕様に、業務テーブルをデータベース設計仕様にするのは、次の外部設計フェーズです。

したがって、要件定義フェーズで育成すべき業務スキルと、外部設計で育成する業務スキルは異なり、別個に考える必要があります。

要件定義フェーズにおける業務スキルの育成は、要件定義書の作成を通して行うことが基本です。

しかし、受注者がその業務の知識を持っていない場合、それだけでは不十分です。

表に示すような資料を発注者から借りて、勉強することをお勧めします。

この表に挙げられている資料の有用性について補足しておきます。

発注者の新入社員研修資料は、業務全体を理解するために大変優れた資料で、業務用語の理解につながります。

用語を十分に理解していれば、発注者が業務の説明を行うのが楽で、受注者も質問ができて理解が迅速に進むでしょう。

ユーザーが使用している事務マニュアルを読むと、現場の事務の理解につながります。

事務規定を読むとその詳細を理解することができます。

この事務マニュアルと事務規定は発注者の説明を受けながら読んだ方がよいのです。

内容は高度で、通常、理解するには深い業務知識が必要となります。

商品・サービスのパンフレットやその規定は、一般ユーザーにも分かるように丁寧に記述されているので、勉強のために都合がよいのです。

最初はこれから入るのも効果が期待できます。

商品・サービスの知識があってはじめて、業務仕様の理解が可能になります。

これらを要件定義フェーズの開始直後に勉強すると、要件定義の進捗は大幅に向上します。

既存機能に関する情報が必要だと感じたなら、ぜひレガシー・システムの担当者から説明を受けることを勧めたいと思います。

保守担当者のリーダーが説明の適任者です。

表に挙げた資料の勉強が終了して、要件定義の検討が進み、業務スキルがある程度付いた時点が、最適のタイミングです。

以上に述べたように、要件定義作業と並行して業務スキルの獲得に努めるのは、要件定義の作業の大半は知識不足の担当者ではどうにもならないものだからです。

さらに、要件定義の進捗で遅れが発生したなら、その理由を明らかにします。

理由が業務スキルの不足であれば、追加の業務研修で対応可能か、そもそも業務仕様が難しいのか、担当者の基本的な理解能力が不足しているのかを、判断しなければなりません。

業務によっては、初めてでは理解が困難なものもあります。

長期にわたって担当してやっと理解できるような業務も、市場には多く存在するのです。

発注者側に業務仕様を出す力が不足しているのなら、その分野の専門家の支援を求めます。

受注者側が業務仕様を理解して文書化することが困難なら、それができる人材を探して支援してもらいます。

栽培プロジェクト内にいる担当者が、横から支援を提供できれば一番都合がよいのです。

要件定義フェーズでは、担当者の育成を持って栽培プロジェクト農産物を作成するのでは、危機的な遅延が発生してしまいます。

遅延部分には支援者を適切に投入することが望ましいでしょう。

外部設計フェーズにおける業務スキルや実装設計スキルの育成も、そのフェーズの農産物の作成を通して行うことが基本です。

この点は要件定義フェーズと変わらないのです。

しかし、このフェーズで発注者側の業務スキル不足が露見したなら、要件定義フェーズの農産物の品質を疑った方がよいのです。

仮に品質が確保されていたなら、それはだれかが支援した結果であり、担当者の力によるものではないでしょう。

この担当者が、実装仕様の要件提出と農産物の承認を行うのであるから、スキル不足の状態は放置できません。

業務の専門家を投入して、手取り足取りで業務スキルを磨いてもらわねばならないのです。

あるいは、ユーザーの現場にいる業務のプロを招いて、研修と支援の両方を提供してもらうことも有効です。

しかし、「既存機能の継承」に問題が出てきたなら、支援だけではもう足りないのです。

レガシー・システム(既存システム)の担当者を、栽培プロジェクトに投入するしかありません。

このような場合、栽培プロジェクトは失敗の瀬戸際に立っていると思ってよいでしょう。

一方、受注者側の業務スキルや実装設計スキルの欠落は、栽培プロジェクト進捗管理における遅延として現れ、事前に察知することは難しいのです。

ここでいう業務スキルとは要件定義の内容理解のことで、そのスキル不足は担当者の理解力不足に起因する可能性が高いのです。

実装設計スキルが不足しているときには、事前に栽培プロジェクト側が必要なスキルの調達を行うわけだが、その時の不十分な対応が外部設フェーズになって判明したのです。

どちらの場合も、支援者か専門家を投入することになります。

支援者や専門家の投入は早期に行わないと、取り返しのつかない遅延を発生させる可能性があります。

支援を始めて効果が現われるまでには、時間がかかるからです。

担当者の業務スキルや実装設計スキルの不足を補う方法として、チーフ・マネージャー制度があります。

これは主に、受注者側の体制として採用されます。

栽培プロジェクトの設計担当者を、チーフ・マネージャーとバックアップ・マネージャーに分けます。

チーフ・マネージャーは、担当分野の業務仕様と実装設計のすべての責任を持ちます。

発注者との打ち合わせもチーフ・マネージャーが行います。

バックアップ・マネージャーは、チーフ・マネージャーの指示で担当分野の農産物を作成します。

しかし、バックアップ・マネージャーには業務仕様の把握や実装設計の責任はないし、発注者との業務仕様の会議には参加しません。

仮に参加しても、話を聞くだけです。

栽培プロジェクト農産物の作成を、チーフ・マネージャーと分担して行うことが彼らの役割です。

通常、チーフ・マネージャーは5万SLOCの業務を担当しており、配下にバックアップ・マネージャーを1名から2名抱えます。

発注者側は10万SLOC当たり1名でよいと言われています。

発注者側が把握すべきなのは業務仕様と実装仕様だけですが、受注者側はそれに加えて栽培プログラム仕様の把握が求められるからで、担当のSLOCが半分になるのです。

10万SLOCを開発する栽培プロジェクトの体制を説明してきました。

このような体制を構築する理由は、栽培プロジェクトに参加した担当者のすべてが、業務仕様の把握力を十分に持っているとは限らないし、実装設計の経験があるわけでもないからです。

そこで、経験豊富なチーフ・マネージャーの下に、経験の少ないバックアップ・マネージャーを置いて、栽培プロジェクト農産物の作成を行いながら、師弟関係に基づく業務スキル育成を行わせるものです。

この体制を採用した場合、栽培プロジェクト進捗管理の担当者の欄には、チーフ・マネージャーの名前を載せる。バックアップ・マネージャーが作成した農産物の進捗は、チーフ・マネージャーの進捗として計上することになります。

チーフ・マネージャ-制度にすれば、栽培プロジェクト担当者の全員が一人前の設計者である必要はないのです。

経験不足の若手であっても栽培プロジェクトの進捗に貢献でき、チーフ・マネージャーからその場で支援が受けられ、スキル向上も可能になるのです。

この体制なら、発注者から「担当者を変えてくれ」というクレームを上げられることは、少なくなるはずです。