Vol.5 No.1 2012

17/84

研究論文:高品質なプロジェクトマネジメントを実現するトレーサビリティ・マトリックスの構築(榮谷ほか)−14−Synthesiology Vol.5 No.1(2012)ものかを定量的に評価できることを示しています。ソフトウエアを早く確実に構成するためには、複雑性を排除したプロジェクトを設計することが大事で、その意味において構成学に関係する論文です。しかし、情報の伝達効率を評価するためのトレーサビリティ・マトリックスの手法の説明が中心になっています。複雑性の比較ツールとしては活用できることは示されていますが、構成そのものの指針を得ることには直接的には活用できる例が示されていませんので、その点の加筆をお願いします。コメント(中島 秀之:はこだて未来大学)ここで提案されている手法が具体的に構成に役立つことを示してください。回答(榮谷 昭宏)「5.1.3 個々のマトリックスの相互依存性・難易度の低減と複雑性の評価」として記述しました。行列計算の特性から、トレーサビリティ・マトリックスの個々の行列はどのようにあるべきか説明し、具体的な事例を用いて相互依存性・難易度をどのように利用して最善の構成を作り上げていくか記述を追加しました。議論2 この手法のマネージメントへの活用コメント(赤松 幹之)組織の複雑性が高いとマネージメントが困難になることは直感的には理解できますが、それはあくまで仮説であり、この手法によって、どのようにマネージメントが容易になるのかについて記載していただきたいと思います。具体的なマネージメントの仕方は構成学において重要なポイントであることから、この手法を使うことによってマネージメントがどのように容易になるのか、この手法で得られた指標を元にどのようにマネージメントをすれば良いのか等、具体的に示していただきたいと思います。回答(榮谷 昭宏)「5.トレーサビリティ・マトリックスを活用したプロジェクトマネージメントのPDCAサイクル」としてトレーサビリティ・マトリックスを用いたマネージメントのPDCAサイクルをシナリオとして記述しました。複雑性を指標としたプロジェクトの状況を評価する観点、また難易度や相互依存性に着目することによる個々の要素の状況を評価する観点について説明を追記しました。議論3 PDCAサイクル質問(赤松 幹之)トレーサビリティ・マトリックスを使ってPDCAサイクルを回すという利用方法が書かれていますが、サイクルを回しながらシステムマトリックス上の関係性や難易度を書き換えて複雑性を計算するのは、かなり面倒な作業のように想像します。ある領域の要素が別の領域のどの要素に使われるのかを把握したり、難易度の値の大きさをどのように決めるのか等、簡単ではないと思われます。現実的にPDCAを回すためには、その部分の工夫が必要ではないかと思いますので、その点についてのお考えを示していただきたいと思います。回答(榮谷 昭宏)ご指摘の点を追記しました。マネージメントの単位を検討し、適切な要素の粒度を選定すること、そしてその粒度にあったPDCAの周期を設定すること等を追記説明しました。また以下にシステムマトリックスの成分値の設定について、もう少し踏み込んだ見解を述べさせていただきます。・難易度の設定について難易度設定には、二つの難しさが考えられます。一つ目は定性的に要素の難易度を把握すること、二つ目はその定性的理解を定量化することとなります。まず、定性的に難易度を把握することについて述べます。定性的に難易度を把握するにあたっては、プロジェクトの進捗状況やリスク事項等の情報を入力することになると考えております。既存のプロジェクトマネージメント技術としても進捗管理やリスク管理は実施されていることですので、難易度設定にあたっての入力情報としては問題なく整っていると考えております。実際、プロジェクトマネージャー、アーキテクト、または各担当のリーダークラスであるならば、感覚的には各要素の難易度の変化を把握していると考えております。例えば、多くのプロジェクトでは、誰がキーマンであるとか、どのツールに問題があるとか、どの作業がキーポイントになる等、プロジェクト内で交わされる会話の節々でプロジェクト構成要素の難易度に関する議論は多くなされています。したがって、定性的に難易度を把握することに特に大きな障害はないと考えております。しかし、そのリスク事項を難易度に定量化することには課題があると考えております。この論文で提示した指針で、誰もが同じような評価をできるかまだ検証が不十分であり、その改善は今後の課題と認識しております。・相互依存性の設定について作業標準のようなものが存在しないプロジェクトにおいては、相互依存性を整理することもとても困難な作業となると予想されます。そのように作業標準が存在しないプロジェクトでは、そもそも既存のプロセスを中心としたマネージメントも困難なはずです。そのような意味で、今回提案させていただいたモデルを用いることは、当初不慣れさから生じる面倒さを感じるかもしれませんが、プロジェクトの状況を把握するツールとして有効に機能すると考えます。また作業標準をすでにもっているプロジェクトでは、一般的に作業標準では作業と成果物、また各担当の役割を定義しているものであるので、その段階から相互依存性を整理することは可能であり、その整理が一度できてしまえば、それをテンプレートとして、個々のプロジェクトでカスタマイズし、使い回すことに大きな障害はないと考えております。・全体をとおしてご指摘のように少なくとも当初はとても難しいマネージメント技術に感じられることもあるかもしれません。今までのプロジェクトマネージメントでは、プロセスを中心とした進捗状況の管理、およびそれに則した予算の管理が主体であったため、その観点から生じている問題を分析的に調べ、原因の対処を行ってきました。しかし、この手法では、モデルをもとにして個々の要素の難易度と相互依存性によってプロジェクトで生じている問題を構成的に理解し、全体を俯瞰した視点から対処を行っていくという考え方となります。つまり、今までのプロジェクトマネージメントは、分析的であるが故に個々の要素を中心とした個別最適なソリューションに傾倒してしまいがちであるのに対して、ここで提案しているものはプロジェクトの全体最適となるソリューションを思考するツールになると考えております。そういった面で、思考方法の違いが障害となってしまうケースは有り得るかもしれませんが、思考の切り替えさえできれば、大きな問題はないように考えます。難易度のところで申し上げたとおりプロジェクトマネージャー等は感覚的に把握していることですので、例えばEVM(Earned Value Management)の実行よりも容易ではないかと考えております。議論4 終了したプロジェクト質問(中島 秀之)「完全に情報移転が終わった要素間ではその相互依存性が無くなっていく」とありますが、終了したプロジェクト同士には情報依存性が無いと考えるべきなのでしょうか?たとえばある新しい技術が発見されて、プロジェクト1の成果を改良した場合に同じ

※このページを正しく表示するにはFlashPlayer9以上が必要です