筆者は現在、ユーザ企業のＰＭＯとしてシステム開発導入に参画しております。当プロジェクトは、ユーザ企業と開発ベンダ（大手SIer）による基幹システム刷新プロジェクトです。
そのプロジェクトで開発ベンダ（大手SIer）に対するユーザ企業の評価として、ＳＥの評価が非常に低く、逆にPMの評価が高いという状況になっているのですが、そこに筆者としては疑問を感じております。
筆者の視点で見ると、ＳＥの方はプログラムに落とす際のロジックや例外パターンを網羅的に考慮して確認してくれるので安心できます。逆にＰＭはいつも適当な事を言っていて信用できません。
ですがユーザ企業の業務部門の方々から見ると評価が真逆なのです。
システム開発の途中経過においては、真っ当にシステム開発に向き合うほどユーザの評価が低く、適当なほど評価が高くなるという矛盾した現象が生じます。（あくまでプロジェクト途中での話です。最終的には適当な人は評価されません。プロジェクトが失敗するので。）
そしてユーザ企業はＳＥを疎かにして、適当なＰＭを信じた結果、プロジェクトは失敗します。
本記事では、このようなユーザ企業の評価が真逆になる理由と、ＳＥに欠けている視点、および解決策を記載したいと思います。
真っ当なＳＥの顧客評価が低い理由
ユーザ企業からするとＳＥが何を言っているのかわからない
結論から申し上げますとユーザ企業のＳＥへの印象は「何を言っているのかわからない」です。
システム開発というのは、最終的にはプログラムに落とし込まれますので、完全にデジタルな世界です。その世界は０と１で全てを表現できるので、プログラムで実装できることは、言語でも網羅的に表現できます。
開発（プログラミング）経験があるＳＥはプログラミングで必要となる確認事項を言語化して、網羅的にユーザに確認しようとします。
ですがユーザ側からするとＩＴの知見が無い人がほとんどですから、プログラミングのロジックに沿って説明されても全く理解できません。
結果、この人は何を言っているかわからない。普通にコミュニケーションが取れない。イライラする。信用できない。となるのです。
ＰＭが信頼できるように感じるのはコミュニケーションが通じるから
一方、ＰＭが信頼できるように感じるのは、（ＳＥとの対比で）普通にコミュニケーションが取れるから、ただそれだけです。
なぜコミュニケーションが取れる（ように感じる）かというとＰＭが適当だからです。
上記のＳＥのようにプログラミング経験がある人は、適当な受け答えはできません。これはどうやって実装したらよいのか（どのようにプログラムに落とし込むか？技術的に実現可能か？）という疑問が真っ先に沸くからです。
そういった疑問を感じるからこそ、ＳＥは細々としたことを確認してしまい、ユーザの信頼を失うのです。
ですがＰＭはそのような疑問は沸きません。なぜならプログラミングをそもそも理解できていないので。
そして、ユーザとのコミュニケーションも取り合えず適当に相槌を打って、その場を穏便に終わせることしか考えていないのです。
ユーザ企業も最初はＰＭのことを信頼しているかもしれませんが、徐々に怪しさを感じてきます。そして気づいたときには既にもう遅く、プロジェクトは取り返しのつかない状態に陥っています。
ＳＥに欠けている視点とは
このＳＥは実装するために必要な事項を網羅的に把握できており、これはシステム開発を行うためには絶対に必要なことです。適当なＰＭに比べると断然マシです。
ですがそれだけでは足りないのです。足りないのは顧客の視点を想像する力です。
顧客の視点が想像できていない
ＳＥに欠けているのは、顧客の視点を想像する力です。
顧客が理解できる文脈、顧客の知りたい事、顧客の合意を得るべきこと、が整理できていないのです。
顧客が理解できる文脈に落とし込む
顧客が理解できる文脈とは、顧客の普段の業務手順に沿った説明です。
業務手順を無視していきなり、画面やロジックの説明をされても顧客は理解できません。
普段のどの業務で使っている画面や帳票ですよ、というのをイメージさせながらでないと顧客はついてこれません。そうして初めてＳＥの確認事項にも適切に回答することが可能になります。
顧客が知りたいことを意識する
顧客が知りたい事とは、新たなシステムを導入することにより、今までの業務がどう変わるかです。
業務手順は今までと変わるのか？業務量は増えるのか減るのか？増えるのであればなぜ増えるのか？その分のメリットはあるのか？などです。
画面やロジックだけ説明されても、今までとどう変わるかわかりませんのでユーザは質問されても答えようがありません。
顧客の合意を得るべき事項を整理する
顧客の合意を得るべき事は、画面や帳票イメージや業務手順の変更など、顧客に直接的に見える範囲です。裏のロジックを細々と説明されても意味が分かりません。
どういったインプットに対してどういったアウトプットがでるのか、その合意を得るべきです。
裏のロジックについては、システム開発のプロとしてSIerが責任を持つべき領域です。
例えば家を建てる場合、間取りやキッチンの機能など顧客の目に見える部分の合意は取りますが、家の骨組みなど、裏の部分はプロとして建築業者が責任を持つと思いますが、それと同じです。
もし、後から仕様変更としてひっくり返されないようにするためというのが理由であれば、酷すぎるきがします。欠陥住宅に対して、設計図を見せたじゃないですか？というのと同じでもはや悪徳業者です。
解決策について
解決策は「ユーザ業務とシステム開発を繋ぐ人」を置くこと
解決策としては、ＳＥという役割を分割することです。
「ユーザ業務とシステム開発を繋ぐＳＥ」と基本設計や詳細設計を担当する「実装よりのＳＥ」を分けて明確化することです。
ですので、ＳＥを分割することが望ましいと考えます。ウォーターフォールで考えると以下のようなイメージです。
- 要件定義：ユーザ業務とシステム開発を繋ぐＳＥ
- 基本設計：実装よりのＳＥ＋ユーザ業務とシステム開発を繋ぐＳＥ
- 詳細設計：実装よりのＳＥ
- プログラミング：プログラマ
- 単体テスト：プログラマ
- 結合テスト：実装よりのＳＥ
- 総合テスト：ユーザ業務とシステム開発を繋ぐＳＥ
この「ユーザ業務とシステム開発を繋ぐＳＥ」の主な役割は、ユーザ企業と「実装よりＳＥ」の通訳です。
ユーザ企業の要件をシステム開発が可能な形に落とし込み、かつ、システム開発に必要な確認事項をユーザが理解可能な形に置き換えて合意形成する仕事です。
この「ユーザ業務とシステム開発を繋ぐＳＥ」が不在なプロジェクト、もしくは、この人がスキル不足な場合に、多くのプロジェクトは失敗します。
「ユーザ業務とシステム開発を繋ぐ人」が不在だと失敗する
この「ユーザ業務とシステム開発を繋ぐＳＥ」が不在なプロジェクトの多くは失敗します。
なぜならユーザとのコミュニケーションが十分でなく、合意形成が取れていないので、仕様面での品質が担保できていないからです。開発が終わった受入テストの段階で仕様不備が多々発生すると思います。
その結果、システム導入の当初の目的を達成できない、仕様変更に係る追加改修の費用負担の問題、仕様不備を回避するための新たな運用業務の追加など、なんのためにシステムを入れ替えたのかわからない、という事態に陥ります。
筆者が現在参画しているプロジェクトにおいても「ユーザ業務とシステム開発を繋ぐＳＥ」が不在なため、要件定義や設計段階でのコミュニケーションに苦労しています。
SIerだけだと回らないのは明らかですので、ユーザ企業の情シスがこの役割を一部肩代わりしています。
具体的にはSIerの「実装よりＳＥ」からでてきた確認事項をユーザが分かる形に翻訳して合意形成を図るというタスクです。
「ユーザ業務とシステム開発を繋ぐ人」がスキル不足で失敗する。よくあるＩＴコンサルの形
また「ユーザ業務とシステム開発を繋ぐＳＥ」がスキル不足なプロジェクトもよく見かけます。
一部のＩＴコンサル会社においてはこの役割の人を、ＩＴコンサルと呼んでいる場合もありますが、よくあるのはこのＩＴコンサルなる人がシステム開発の知見に乏しいケースです。
具体的には、仕様の詰めが甘く考慮不足、そもそも技術的に実装できない、工数の見積もりが甘く全然足りない、などのケースです。
そのため、後続の実装フェーズで問題事項が多々発覚し、仕様調整からまたやり直し、無駄な工数が発生し、長時間労働に陥り、コスト超過という事例をよく見かけます。
後続のＳＥやプログラマからしたら、何回もやり直しさせられるし、残業も多いし、たまったものではないです。
でもなぜかシステム開発の知見が無いＩＴコンサルが要件定義を行うというこの悪しき風潮は無くならないのです。
その理由は、システム開発の知見とユーザと合意形成できるスキルの両方を持つ人材がそもそもいない、システム開発の知見だけの人だとユーザとコミュニケーションがとれないという事に起因するのかと思います。
