不良システムを作らないプロジェクトの枠組み：ユーザーサイド・プロジェクト推進ガイド（4）（2/2 ページ）

[山村秀樹，＠IT]

業務部門からベンダへ流れる“チェーン”を意識する

　良いシステムを開発するためには、実際にシステムを開発するベンダが余裕を持って作業できること、モチベーションの高い状態で能力をフルに発揮できる環境であることが理想です。この実現には、ユーザーサイドの気配りと努力が必要です。

「後工程はお客さま」の精神とは

　製造業の製造ラインにおける品質スローガンの中には「後工程はお客さま」というものがあります。これはポピュラーな文句であり、多くの人が知っています。

　システム開発プロセスも、機能要求仕様の検討などの最上流から、開発などの下流工程へと流れていくものですが、ユーザー側において実施する最上流とベンダが作業するその下流の境界においては、そのスローガンは適用されていません。まったく逆の「上流工程がお客さま」になってしまっています。

　ユーザー側が、「システム開発とはまったくベンダの作業である」との認識でいるとすれば論外としかいいようがありませんが、そうでなくてもシステム開発の“サプライチェーン”が意識されていない、あるいはユーザーとベンダがあたかも1つの組織として作業するといったバーチャル・ファクトリー的な見方がないことは往々にしてあります。

　これは、サプライチェーンやバーチャル・ファクトリーといった概念が製品を生産する主力業務を対象に喧伝されており、プロジェクトチームにとってはソリューションとして導入を検討する対象だという固定観念を持ってしまっているからでしょう。自らのプロジェクトに応用するものだと考えていないのです。サプライチェーンを主眼としたパッケージ導入プロジェクトにおいても、プロジェクト自体をサプライチェーン的に考えることは多くはないように思えます。

　しかし、プロジェクトはユーザーとベンダが協働するものであって、そこに指示と成果物の流れがあることは間違いありません。作業の流れが存在するのに「後工程はお客さま」というよく知られた良識がおざなりにされてしまうのはもったいないことです。プロジェクトをサプライチェーン的に考え、後工程を大事と考えることは非常に価値があり、Win-Win関係の構築にもつながります（ベンダ側工程における元請けと下請けの作業もそうですね）。

プロジェクトチームの任務を自覚し、周りにも理解してもらう

　不親切な機能要求仕様の検討が、いかに下流工程に悪影響を及ぼすかは、ベンダの立場になって考えれば分かります。

　あなたがベンダだとしてユーザーのいうことが思い付きのようにコロコロと変われば、リスクの高い危険な仕事だと判断するでしょうし、作業が進んだ時点で仕様変更が続発し何回もやり直すことになれば、やる気がなくなるでしょう。時間がどんどんなくなってきて余裕がないのに、まだ機能要求仕様が決まっていなければ、まともな設計などできるわけがありません。このような状態で良いシステムを作るのは不可能です。

　十分認識されていると思いますが、品質の良い機能要求仕様をベンダに伝えることは、ユーザーサイドのプロジェクトチームの重要な任務の1つです。これをきちんとこなすには時間とエネルギーが必要なのですが、上司にこのことをなかなか理解してもらえずに苦慮しておられる方も結構見受けられます。いま一度、上司の方に、目前のことよりも、もっと広範な見地からプロジェクトを見てもらえるように説明を工夫してみてください。

プロジェクトの枠組み チェックポイント

• 「不良プロジェクトは不良システムを生み、それを使っている限り業務効率の向上は望めない」ということを上司や業務部門に繰り返し伝える
• システムは事後の改修にはコストが掛かり、早い時期の機能要求仕様決定が大切であることを、上司や業務部門によく理解してもらう
• システム開発ベンダに能力をフルに発揮してもらうために、「後工程はお客さま」というマインドで接する

　さて、システムの概要やスケジュールにめどが付くと、プロジェクトに必要なマンパワーが見えてきます。各業務部門長から人を出してもよいとの協力を得、トップマネジメントからプロジェクトの続行が承認されたならば、チームの編成に取り掛かります。次回からはチーム編成について考えていきます。

profile

山村 秀樹（やまむら ひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、なかでもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

• 業務の可視化で、多くの関係者を巻き込め！
• 工夫と規律で「システム用語辞書」を実現せよ
• 社内用語を統一する「用語辞典」作成のポイント
• 言葉の不統一がもたらす業務とシステムへの悪影響
• ドキュメントを作成しないユーザーは、失敗する
• プロジェクトメンバーがそろう前に行っておく事前準備
• システム開発プロジェクトの魅力を伝えよう
• プロジェクトチームのマインドとルールを方向づけるには
• プロジェクトキックオフ！ オリエンテーションで話すこと
• プロジェクトリーダーは十二分な準備で自信を生み出せ
• プロジェクトチームのリーダーに向く人、向かない人
• プロジェクトチームにおける“システム担当者”の役割
• プロジェクトチーム結成──業務部門との関係を考える
• プロジェクトチームに付きまとう制約を打破するために
• タイプ別プロジェクトチームの問題点
• 不良システムを作らないプロジェクトの枠組み
• スケジュールとコストは、ユーザー側が始めからつかめ
• 最初が大切──構築システムの“概要”を作る
• ユーザー企業側プロジェクトチームの使命と役割