プロジェクト管理の仕組み (その41) サブシステムの開発目標

2017-07-05

　前回までで、化粧品の自販機についてシステムの内部構造を決めました。システム内部構造は、システムを独立したサブシステムにブレークダウンしたもので、ブロックやモジュールなどチームや技術者が扱える単位まで繰り返します。そして、このブレークダウンは本質的に試行錯誤からなる作業であり、ブレークダウンした結果を評価することができる仕組みを持っていることが重要だとお伝えしました。FURPS+ を使って作成したシステム要件はサブシステムへのブレークダウン結果を評価するために必要だったわけです。

　システム設計というのは、このブレークダウンを繰り返し実行して適切な開発単位にすることです。では、システム設計ではいったいどこまでブレークダウンするのでしょうか。それは、その開発プロジェクトのメンバーあるいはサブチームが自分たちで開発を進めることができると思えるところまでです。

残り70%　続きを読むには・・・

新規会員登録

この記事の著者

石橋良造

株式会社ＲＤＰｉ

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

この記事の著者

石橋良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

　システム設計の後はほとんどの場合、ボードや機構やソフトに分かれて、あるいは、機能ブロックごとに分かれて、それぞれの担当者やサブチームで同時並行に開発作業が進められます。このとき、どのようなサブチームで分かれるのか、どのようなスキルのメンバーがいるのかなど様々で、だからこそ、システム設計者は、サブチームやメンバーの実力・能力に合ったアウトプットにするところまでを自分の仕事とする必要があります。

　したがって、システム設計は、エンジニアリングの責任者、つまり、プロジェクトの中で技術的な中心人物が担当することが大切です。一人ではなく数人ということもあるでしょうが、開発プロジェクトメンバーの中でトップレベルのシステム設計スキルを持ち、製品全体の設計に責任を持つことができる人たちが、一元的にシステム設計を行う体制になっていることが要求されます。

　サブシステムと呼ぶのか、ブロックと呼ぶのか、モジュールと呼ぶのかはいろいろでしょうが、システム設計によりサブチームあるいは技術者が開発作業を行うことができる単位にブレークダウンしたものを、ここではサブシステムと呼ぶことにします。また、開発を進めるのはサブチームとしましょう。サブチームは、サブシステムが何を作ればよいのかが明確に把握できる状態になっていないと開発作業を進めることができません。作るもののゴールを明確にするということことです。それでは、自販機の例を使って実際にやってみましょう。

　図77はサブシステムにブレークダウンしたシステムの内部構造です。システム要件一つひとつについて動作を検証したもので、サブシステム間にその一部を記載しています。細かなところまで見ると気になる点もありますが、説明用サンプルだと考えてください。

図77. サブシステム構成

　図の中心に位置している「操作管理サブシステム」について考えたいと思います。図を見ると、状態管理サブシステム、金銭授受サブシステム、金銭管理サブシステム、商品管理サブシステムのそれぞれとどのような関係でつながっているのかがわかります。次回は、操作管理サブシステムだけを抽出したもので、解説を続けます。