要件定義で炎上するSE、成功するSEの決定的な違い
〜JUAS調査が示す「システム導入の成功要因」とコンサルティング技術を活用する新しいSE像〜
目次
はじめに
私は長年、業務改革系コンサルタントとして、数々のプロジェクトマネージャを担当してきました。その後続のSIプロジェクトに関与もしてきています。その際、ユーザーサイドの立ち位置でしたが、優秀なSE（システムエンジニア）の方々とも接する機会が多くあり、色々なシーンにも遭遇しています。当コラム掲載にあたりまして、コンサルタントの客観的な目線にはなりますが、ユーザーが期待する「価値あるSE像」を考察した内容を寄稿いたしました。
SEの方々、特に、コンサルタント的な役割も期待されるシニアSEの方々に一読いただき、今後のSEの在り方を考察されるとき、何か一石を投じることができるコラムになることを目的としています。
1．JUAS調査が語る「システム導入の成功要因」
図表3-3 パッケージ導入によって業務プロセスの改革や改善、投資対効果の実現を図るために重要
なこと (複数回答：最大３つまで)
出典：JUAS（日本情報システム・ユーザー協会） ソフトウェアメトリクス調査2026
これは、JUASがまとめたパッケージ導入における成功要因です。「ユーザーの巻き込み」と「業務プロセス要件の明確な定義」が６０％を超える得票数を得ています。第三位に４６％得票の「パッケージ標準機能の十分な理解と評価」となっていますが、一位二位の成功要因があって成り立つ要因と解釈すれば、「ユーザー巻き込み」と「業務プロセス要件の明確な定義」の2点が外せない非常に重要な成功要因であると言えます。
2．成功要因である「ユーザーの巻き込み」の受け止め方
ここで使われている「ユーザーの巻き込み」という表現は抽象度が高く、色々な解釈があります。ただ、巻き込んだ結果、何を目指しているかという問いに変えれば、その意味するところは非常に明白になります。それは、「ユーザーが納得する結果になること」です。ここで“納得”という言葉を使っていますが、ユーザーの要望をすべて満たすということとは必ずしも一致しません。
多くの優秀なSEは、ユーザー要望を吟味し、できるだけ要件として受け入れ、それを実現するシステムとなるように設計を進めていきます。その際、いろいろな事情で、要望の一部が対応できない結果となることもありえます。その時、ユーザーがその結果に納得したかどうか、それが重要であると言っています。言葉で表すと微妙な違いにしかみえませんが、取り組む姿勢を大きく変える非常に異質な姿勢の違いを言っています。すなわち、ＧＯＡＬを、システム的な正解でよしとするか、ユーザーの納得があってこその正解であるとするか、この違いです
3．成功要因である「業務プロセス要件の明確な定義」の難しさ
次の重要なポイントとして、業務プロセス要件の定義があります。DXという言葉が誕生する前、BPR（ビジネス・リエンジニアリング）の時代でも同じことが指摘されていますし、“動かないコンピュータ”というと、必ず登場してきた常連課題です。この問題がなくならないのはなぜか、以下に、整理をしてみます。
SEはシステム設計を担うため、「業務の話はユーザーの責任範囲である」、これが大前提で考えられている方が非常に多いと思います。実際、それが責任を伴う範囲を指すこととすれば当然の帰結です。
しかし、一歩、ユーザー側の世界に足を踏み入れてみますと、カオス状態で悪戦苦闘している状態を頻繁に目にします。プロジェクト組閣においては現場をリードできる人を選任することとなっていますが、現実問題として、そういう人がそう簡単にいるわけはありません。人間的に関係者をリードすることには長けているが、ロジカルにまとめることは不得意という方もいます。その逆もあります。特に、最近は“ヌシ”と言われる誰もが一目を置く業務を熟知したヒトたちが退職され、人間関係と業務知識の両面で、求心力をもったユーザーが不在という企業が多くなっています。
ユーザーに現状の業務を確認する際、よくみられる象徴的な会話を紹介しましょう。
「今の業務のやり方ですが、なぜ、そうしているのでしょうか。」
「私が配属されて以来、そうすることになっています。なぜかと聞かれても、これまでそうしてきたからとしか言いようがありません。」
「では、今回、掲げられた要望は、どういう理由から要望としてリストアップされたのですか。」
「今のシステムは操作が面倒だからです。」
業務の決め事の根拠も曖昧で、システム要望は個人的な目的という側面が強く、ここから高邁なシステム導入目的にそって、システム要件を決める話を始めなければならないと思うと、ため息さえでてきそうな例です。
この例示は、表現こそストレートに表現していますが、決して例外ケースの会話ではありません。よくある普通の会話です。こういう状態の中で、ユーザーは、“業務プロセス要件の定義をしなさい”と言われているわけです。ましてや、得意でもないシステム要望をまとめるとなると相当のスキルが必要となります。こういう状態で検討を進めているユーザーに対して、SIチームが、「いつシステム機能の要望（もしくは要件）が固まりますか」とクールに問うわけですから、出てきた結果に対する品質や、現場の合意度は、バラつきが激しくなります。とにかく期限を守るために進めていきますので、後から、色々、矛盾や取り違いがでてくることは必然ともいえます。
4．なぜSEは「業務の世界」を目指さざるを得ないのか
これらの課題は、ユーザーの言うことを正しいとしてシステム要望をまとめ、システムとしての対応可能性を評価しシステム要件とするという従来の考え方の限界を示しています。現在のユーザー側の事情を考えますと、この限界をこえることは非常に難しくなっています。ましてや、IoTおよびデジタルツイン、識別・予測・生成AI、ビッグデータなど、新技術の進展も目覚ましく、ユーザー企業におけるITリテラシーはどんどん弱くなっているのが実情です。
この状態を打破するための示唆はいくつかあります。そのひとつが、SEがユーザーの業務の世界に入り込み、業務プロセス要件の定義にかかわることです。それはすなわち、業務課題をともに考える立ち位置にシフトすることになります。ICT技術を理解しているSEが業務の世界に入る難しさと、業務を知るユーザーがICT技術についていく難しさを相対的に考えてみれば、まだSEが業務に入っていくほうが障壁は低いと言えるからです。
参考に掲げたJUASのアンケート結果は、パッケージ導入に関するものですが、アジャイル開発に至っては、SEはさらにユーザーへ入り込み、業務課題への関わりは当然のこととなります。基幹系パッケージが成熟化し、生成AIがシステム設計およびプログラミングの肩代わりを始めている現在の状況を合わせて考えれば、むしろ、この役割の変化に乗ることこそ新しいSEの姿であり、SEとして生き残る有力な道であるといっても過言ではないと思います。
5．合意形成の壁
もうひとつ、SEとして乗り越えなければならない壁があります。それは、GOALのとらえ方です。「正しいシステム提案」をしたはずなのに、なぜ顧客は納得しないのか。優秀なSEの方々が失敗するシーンで、よく出てくる「嘆きの自問」です。顧客の要望をすべてシステム機能で解決しようとする姿勢には技術者としての意気込みやプロとしての信念を感じます。そして、適切な検討を行ってシステム要件に落としていこうとされた結果であれば間違った対応とは思えません。
しかしながら、“ヒトが納得する”ということは、ロジカルな説明だけで得られるものではありません。相手はヒトであるがゆえに、組織力学、利害関係、個人の価値観も大きく影響します。時には、個人的な好みで納得に至らないことすらあります。そういういわゆる「システム以外の要素を配慮したうえでの案なのか」、「ロジカルさを説明しようとするあまり、ユーザーには理解不能な説明になっていないか」という点に関しても検討を行ったのか。その視点を重要ではないと割り切ってしまっては納得などとても得られるものではありません。「私は技術者だからそういうことは重要と考えなくてもよい」と自分の弱みをカバーするために、言い聞かせているように見えることすらあります。納得が得られず、理屈で押せなくなった暁には、「その機能を入れると予算オーバーになります」という脅しとも受け取れる警告発言をされるシーンもみてきました。ここまでくると、もうユーザーの巻き込みどころか、対立関係を自ら作っているようなものです。発言と同時に、大炎上です。
前述しましたが、納得とは要望をすべて聞き入れることではありません。対応できなかった要望があることにも納得してもらうことです。この納得を得るためには、合意形成という行為が重要なアクションとなります。
6．実装というリアル
もうひとつ、落とし穴があります。システム的には、正しい提案であっても、それはシステムの世界の解決であって、実装における正しい提案かという問いに応えられるかです。
実装する際には、組織の責任範囲および権限からの制約があり、要員のスキル問題もあります。就業条件も絡んできます。その点を考慮して、実装可能なシステム提案に仕立てなければいけません。すなわち、実装するうえで、ユーザーの置かれている会社内での立ち位置からの調整は、必須事項とも言えます。すなわち、システム構築の見地からの考えとユーザーの立ち位置からの考えを融合させて、業務とシステムを考える必要があるということです。
この検討を効率よく効果的に行うためには、ユーザーとSEとの関係を変えることが必要です。これまで、起案者と制作者という従属関係や、システム要件にいれる、いれないという対立的な関係になることが多かった両者の関係を、業務を共通の世界として位置づけ、ユーザーとＳＥが共創の関係で検討を行う進め方に切り替えることが重要となります。
7．コンサルタントはどのように「合意」を創り出すのか
この関係の中で、ユーザーの検討、意思決定を助け、システム要件の合意をとっていくことが、SEができる新しい役割になります。そして、この姿を実現するためには、相応のやり方、技術が必要になります。それが、コンサルタントが身につけている技術です。
検討にあたっては、現状、どうなっているのか、今後、どうしたいのか、この問いから入っていくケースが多いのですが、この問いへの回答は簡単そうにみえて実は難しいものです。めざすものを論理的にしっかり持っているユーザーには簡単な質問ですが、そういうユーザーは多くはありません。いまひとつ改善後の業務イメージが固まっていないユーザーにとっては、非常に答えづらい質問です。そこで、コンサルタントがよく活用するテクニック、“仮説”を使います。一般論をベースにした内容でもかまわないので、仮説をたたき台として検討のテーブルに乗せます。人は何かを見れば、発言しやすくなります。この習性を活用します。この仮説の提示には、さまざまな効果があります。議論が早くなる、答えに早く行きつくなど、論理的な効果もさることながら、ユーザー目線から見ますと、業務を知らないヒトから、業務を話せるヒトに代わる点がすこぶる大きな効果です。仲間へのシフトです。
これに続いて、結論を決めていく際には、合意形成テクニックで仕上げます。これはケースバイケースですが、もっとも大切なポイントは、まずは合意部分と不合意部分を明確に区分すること、そして、その区分した結果そのものに対しても合意を取っていくことです。地味なテクニックですが、これを丁寧に進め、積み上げていくことが、最終的に全体の合意に結びついていきます。採用されなかった要望にも納得してもらう大切な活動です。
システム要望を聞き、その実現方法の説明を行った際、ユーザーが不備の点を突くことがよくあります。この際、この突かれた点に、討議を集中させるあまり、これだけの議論、やり取りに終始し、結局、物別れにおわるというシーンをよくみかけます。結果として、今回の説明対象のすべてが、合意を得られなかったことになるわけです。これは技術者として本能の部分もあるとは思います。自分が作ったものへの誇りがあり、プライドがあるからです。システムの正しさをわかってほしいという心理からの行動でもあります。
しかしながら、もし、合意することが今回の目的と認識していれば、不備の点を突かれた瞬間、まずは、指摘されなかった部分は合意なのかどうか、説明内容を分解して確かめることになります。その了解を得た後、合意された部分と合意されなかった部分を明確にし、この区分けそのものの合意を取ります。それからです。指摘された部分の話をするのは。こうして繰り返していくことで、どんどん合意範囲が増えていきます。
これは合意形成の一例ですが、コンサルタントは、他にも、いろいろな技術を使っています。ケースバイケースではありますが、合意形成を取りながら検討会を効率よくすすめるセッションテクニック、重要な合意をえるためのプレゼンテーションの構成や仕掛けづくりなど、合意のための技術を駆使しています。その根底には、「合意のない解決策は、無きに等しい」という冷徹な考えがあります。
8．SEの経験に「コンサル思考」を掛け合わせる
こうして、少し大局的に視野を広げてみますと、SEが持つ「確かな技術的裏付け」に、コンサルタントのもつ「仮説をベースにした課題解決・合意形成力」が加われば最強の人材になります。
特に、パラダイムシフトに近い大きな違いは、思考の違いです。SEは技術者です。したがって、仕様にこだわることは当然のことです。この仕事を長年してきていますので、脳の中の思考は、「仕様確定回路」を最優先で動かします。一方、コンサルタントは、実は「仕様確定回路」は最初からは動きません。まず動くのが、「再定義回路」です。「なぜそうするのか？」「どうしてそうなるのか？」という質問が動き出します。これが、「コンサルタントはすぐに“なぜか”と問う」と言われる所以です。この「再定義回路」が、要望の背景にある本来の課題をより明確にし、時には、ユーザーが最初に希望していた要望までも変えてしまいます。
ユーザーの要望をそのまま受け取り、仕様化する「仕様確定回路」と、ユーザーの要望を深掘りする「再定義回路」ふたつをシーンに応じて切り替えることができれば、これからの時代を生き抜く最強のSEとなるベースができあがります。これからの時代は、そういうハイブリッドなSEが求められると私は思います。
おわりに
このコラムで取り上げた考えや取り組みは、机上の話ではありません。実際に、「IT技術だけでは超えられない壁」に気づき、新しい取り組みをされているSEの層も相応に実在しています。私が元々は新人・若手コンサルタント向けに開発し、現在講師を務める「コンサルタント能力養成研修」において、最近では、受講者の80％以上をSEの方々が占めているという事実が、それを物語っています。
受講者は、コンサルタントの技術を自身の専門性に掛け合わせ、「最強のSE」へと越境しようと模索しているのです。当コラムで触れた要件定義活動以外にも、ＳＩの前段階で行われる業務整備＆システム要望整備支援、システム保守活動における業務にまで踏み込んだ改善提案などを適応範囲として視野にいれています。
なお、このコラムで紹介したコンサルタントの考え方および技術は、コンサルタントが日常的に活用している技術の一部です。その他にも、課題解決の基本形、合意形成に関するその他のテクニック、仮説の本格的な活用方法などがあります。
こういった技術の習得は、記憶すればよいだけの知識と違い、書籍での学習だけでは限界もあります。ケースバイケースの部分も多く、実際に取り組んでみて、初めてわかる落とし穴や、“わかったつもり”で終えている部分をみつけて、理解の定着化を図ることが大切です。「ぶっつけ本番」で試行錯誤することは、大きなリスクを伴います。技術としてしっかり身につける場が必要と感じた際は、研修という選択肢も活用してみてください。
