読者のお一人（SE）から，大変貴重なご意見を頂いた。
この読者は「毎回のように開発中のシステムの心臓部が割愛されたり，間引きされたりで，本当に作成したかったシステムにはできないでいる」という悩みをお持ちで，その解決のために「何かいいアイディア」はないだろうかとお考えになっているという。
そして，その後にご指摘が続く。筆者は以前のコラム「ユーザー要求は適当なところで切り捨てろ 」で，レイムダック化（弱体化）したシステムを甦生させるために，ユーザー要求を切り捨てなければならない状況があることを紹介した。
しかし，ただでさえシステムの心臓部が割愛・間引きされる状況下で，「ユーザー要求は適当なところで切り捨てろ」と主張することは，SEに誤解を与える。筆者が設定した「レイムダック化したシステムの甦生を図る」という前提が捨象されて，ユーザー要求の切り捨てがまかり通る危険があるというご指摘である。
その読者は非常に冷静，かつ的確に「システムの心臓部が割愛・間引きされる」状況を分析し，自ら賢明な問題提起をしておられる。「機能の割愛や間引きの理由」は工数・予算・納期・業務無知などであり，それらの原因はSEのアプリケーション力とマネジメント力にあるとしている。
さて，その読者が指摘される開発部隊の問題を，SE，あるいはチームの立場からどう解決すべきか。
あいにく筆者に明快な解決策を示す経験も知恵もない。しかし，せっかくのご提案なので，今回はこのテーマに関してせめて問題を提起し，活発な議論とアイディアが出ることを期待したい。
いずれにしろ，システムの心臓部が「割愛や間引き」されることは，大きな問題である。
納期と予算の優先で品質は後回し
提起されたテーマは，2つのケースに分けて考えられるだろう。
（1）これからプロジェクトが始まるという段階で，機能の心臓部の「割愛や間引き」をいかに防ぐか
（2）すでに進行中のプロジェクトで行なわれている「割愛や間引き」に，いかに歯止めをかけるか
プロジェクトの最大関心事は，納期と予算である。もちろん品質も重要だが，プロジェクトが進行し，時間や人材の不足などのトラブルで追い詰められるほど，品質は忘れられる。世の中に赤字プロジェクトがこれほど増えると，納期と予算はさらに優先されるようになる。特に（2）の状態で品質を強調すると，「納期と予算」をないがしろにする国賊扱いになりかねない。筆者も経験がある。
こうした状態の中で，いかに正論を通すか。
プロジェクト後方支援のためには「PMO（Project Management Office）」といった専門組織を設けて，相談に乗るべきだという意見もあるだろう。しかし，ここではそうした大仰な組織論や形式論は，議論の対象外としたい。
まず（1）の場合，正論を通すことは比較的容易である。これからプロジェクトが始まるというとき，たとえ過去いい加減なことをやってきた前科があるにしても，プロジェクト・リーダーを始めすべての関係者は初心に帰って，正論で物事を考えることができる。したがって，プロジェクト・マネジメントの基本を容易に実行できる状況にある。
PMBOK（注1）によればプロジェクト・マネジメントは，スコープ，スケジュール，コスト，品質，人材，コミュニケーション，リスク，調達，統合などのマネジメントで構成される。システムの「割愛や間引き」を避けるために最も重要なことは，スコープ・マネジメントを基本として，品質マネジメントを落ち度なく実行することである。しかし，これらを容易に実行できるはずのプロジェクトの開始時点でも，最初からスケジュールやコストに関心が行き，スコープや品質については形式的なマネジメントだけで済ませる場合が多い。ここで手を抜かないことが，（2）の段階で悩まなくて済むことに通ずる。
スコープ・マネジメントは，プロジェクトの目標である最終成果物を達成するための諸要件を定義し保障するもので，「開発の目的とその範囲」を示す。スコープ・マネジメントの成果物は，WBS（Work Breakdown Structure）に細分化される。そして，プロジェクトの最終成果物を，潜在的要求も含めたユーザー要求と一致させ使用に適うように維持することが，品質マネジメントである。
これらを実施する際の手法として，充分なコミュニケーション・機能要件の可視化・優先順位の明確化などが求められる。ここにこそ担当者が心臓部の「割愛や間引き」を避けるために自分の意見を反映させるチャンスがあり，その努力を怠ってはならない。これからプロジェクトが始まる段階ならば，プロジェクト・リーダーも耳を貸すだろう。不幸にしてプロジェクトの開始時点からリーダーが耳を貸さないという最悪の場合にどう対応するかは，最後に触れる。
先の読者は，システムの心臓部が「割愛や間引き」される理由の1つに，SEが担当「業務を知らない」ことも挙げておられる。それはシステム失敗の重大原因でありながら，しばしば見受けられることである。プロジェクト・リーダーはSEに担当業務の勉強を義務付けなければならない。該当業務に関する書物やマニュアルを読ませ，併せて該当業務に携わるユーザー担当者のそばで長期間，少なくとも1ヵ月間は付きっ切りで業務を「体験」させるのである。とてもそんな時間はない…と言うなかれ，プロジェクトが決定した時点から直ちに行動しなければならない。
進行中のプロジェクトでは主張は通りにくい
次に（2）の場合である。こちらはプロジェクトが進行するほど納期と予算が前面に押し出されて，基本的なことを主張しても，なかなか聞いてもらえない。本来ならレビューを行なうことで軌道を修正するべきだが，レビューが不充分だったり形式に流れたりして「割愛や間引き」が見逃されるのだろう。
こういう状況下でできることは限られる。まず疑問を持った場合，あらゆる機会に正しいと考えることを主張する，あるいはスコープ・マネジメントのレビューを執拗（しつよう）に要求する。しかし，（読者からのご意見にもあったが）主張は通りにくいだろう。
次にできることは，せめて自分の担当テリトリだけでも，正しいと考えることを実行する。もちろんシステムは全体との関係で進んでいるから，できることは限られる。しかし，何もかも押し流されるよりは救いがある。ただ，完ぺき主義はどこかでひずみが出るので戒めなければならない。「落としどころ」を探る知恵も必要である。
そしてプロジェクトの開始時点か進行中かを問わず，正しいと考える主張が通らなかったとき最後に担当者のできることは，そのプロジェクト・マネジメントやリーダーを反面教師とすることである。自分が将来その立場に立ったとき，そういう欠陥プロジェクト・マネジメントにはしない，欠陥リーダーには決してならないよう決心するのである。
（注1）Project Management Body of Knowledgeの略称。アメリカの非営利団体PMIが規定したプロジェクト・マネジメントのための知識体系。プロジェクト・マネジメントにおける事実上の国際標準。
|
→増岡 直二郎バックナンバー一覧へ |
■増岡 直二郎 (ますおか なおじろう)【略歴】 小樽商科大学卒業後，日立製作所・八木アンテナなどの幹部を歴任。事業企画から製造，情報システム，営業など幅広く経験。現在は，nao IT研究所代表として経営指導・執筆・大学非常勤講師・講演などで活躍中。 【主な著書】 『IT導入は企業を危うくする』，『迫りくる受難時代を勝ち抜くSEの条件』（いずれも洋泉社） 【連絡先】 nao-it@keh.biglobe.ne.jp |
