DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

先日、ユーザ系システム子会社の役員の方と「仕事のやりがい」について議論をしました。その方は温厚で控えめですが、目標の達成に向け周りの人を巻き込みながら真摯かつ愚直に即行動する方です。また物事を判断する場合は、必ず現地現物を心がけられているため、言われていることに説得力があります。その方は、Ｍ＆Ａにより会社の風土が一変したことから、やりたい仕事が極めてやり難い環境になったとのこと。その時、たまたまオファーがあった現在の会社に転職されたとのことでした。一変したのは、その方が一番大切にされていた「現地現物で物事を捉えること」を潔しとしない風土となったためだったそうです。

このお話しを伺いながら「ＰＭやＢＡも同じだ」と思いました。例えばＰＭは、プロジェクトマネジメントを理論だけで押し通そうとしても、そのメンバーである人は付いてきません。人は、机上の論理だけでは納得しないからです。現地現物に基づく的確な論理的な判断、そして熱意・価値観・共感・情け・励まし・叱責など、感情が理論に勝る『人の気持ち』も大切であるからです。

さて今回のテーマは「ＢＡはユーザとＰＭを繋ぐ触媒」です。

私が過去に携わったプロジェクトですが、ＰＭはユーザ系企業のシステム部門の方が担当し、ＰＭ配下のプロジェクトメンバーも同社のシステム部員でした。プロジェクトの計画はシステム部門主導で策定し、ユーザ部門は合議する形でプロジェクトはスタート。システムの構想・企画と要件定義（以降“要件定義”とする）は、同様な工程と位置づけられ、プロジェクトは進んでいました。
ユーザ部門は、ＰＭ配下のプロジェクト体制には入っていないため、ＰＭがユーザ部門に対し、権限を行使することは出来ない体制でした。よって要件定義は、システム部門のプロジェクトメンバーが、ユーザ部門の担当者と調整を進めながら行なうことになりました。

そのシステム部門では、開発に携わる際の考え方として
「必要以上の開発を行なうと、保守フェーズになってから改修費用が増大すると共に、不必要なプログラムを維持することによる思わぬ本番障害を引き起こす。シンプルな機能のみリリースし、ユーザが使ってゆくうちに真に必要な機能を追加してゆくことが望ましい。」
を共有していました。そのためユーザ部門から提示された要件も、そのまま鵜呑みにすることは無く、次のような観点で、その要件に対するシステム部門からの確認事項（もしくは提案）をしていました。
“なぜその要件が必要なのか？”
“業務のやり方を工夫することで、そもそもその要件が不要と言うことは無いのか？”
“また仮に必要な要件であったとしても、システム化する必要は本当にあるのか？”
“ユーザ部門の方は、その要件を真剣に考え、真に必要だと思っているのか？
（現行踏襲という安易な要件ではないのか？）”
“そもそも要件定義をしているユーザは、当事者意識を持ちえているのか？”

　要件定義でとかく陥りがちなのが「現行踏襲」です。しかし現行踏襲には、長年培ってきた業務の蓄積をシステムに反映しているため、実際には不必要な機能も多く含まれています。システムを利用している現場の方は、現行踏襲となる機能の中にも、見直ししたい機能が多く含まれていると認識しているのが実情です。しかし見直ししたいと言う要望は、個人的な見解なのか、それとも組織として最適な内容なのかに戸惑い、なかなか抜本的な改善を含む要件を出すことが出来ません。また業務の改善を行うことで、自分自身の仕事が無くなってしまうと思われると、見直しそのものに反対します。さらに直属の上司がかつて要件を決めて実現した機能であった場合は、部下であるユーザ担当者は、なかなか変更を言い出せなかったりします。このように現場の当事者が、自らの業務を見直しする場合は、様々なしがらみがあるため、結局現行踏襲＋ちょっと毛が生えた程度の改善しか出来ないことが多いと感じています。
　そのような状況に陥らないように、ユーザ部門の方々に比べ、その組織における利害関係が弱いシステム部門の要員が、積極的にユーザ要件を精査するような考え方が根付いたのだと思います。

このシステム部門の取り組みは、今から思えば、まさにＢＡの活動そのものであったと思います。また今から思えば、この活動をＰＭが自ら行なわなかったことも良かったと思います。ＰＭはプロジェクトの責任者です。その責任者が発する言葉は、どのような場面においても重たいものです。もしＰＭが、自らユーザ担当から出てきた要件に対し、あれこれ質問や提案をしたとします。するとユーザ部門の方々は、その質問や提案が「プロジェクトの制約」や「指示」であるかのごとく感じると思われます。するとユーザ部門は、自分たちが主張している事柄を変更されないよう、ＰＭに対し対抗意識を燃やす可能性が高まります。しかしＰＭ配下で、プロジェクトにおける決定権限の無いシステム部員がその取り組みを行なえば、ユーザ部門の方々がシステム部門に抱く対抗意識は、ＰＭ自身が行なった場合よりも弱くなると想定されます。

　当然プロジェクトの運営状況によっては、ＰＭが自らユーザ部門と交渉することも大切です。また小規模なプロジェクトでは、ＰＭがＢＡを兼ねるケースも多いかと思います。しかし上記のような事例を振り返ってみると、ＰＭとＢＡは、別の人が担った方が、プロジェクトの運営は円滑に進み易いと思われます。

次回も、事例を交えた具体的な話題を中心にお伝えいたします。

＜　前回　｜　目次　｜　次回　＞