はじめに
システム開発において最も重要と言われる「要件定義」。 教科書通りの理想的な要件定義とは、次のような流れです。
- 利用部門（現場）から「今の業務のここが大変で困っている」と課題をヒアリングする。
- 利用部門から「だから、システムでこういう機能を作ってほしい」と要望をもらう。
- 情シスの開発者は、ITのプロとして助言を行いながら仕様をまとめる。
しかし、情シス配属の初心者や、他部署からDX推進部門へ異動してきた方は、すぐに「理想と現実の巨大なギャップ」に直面することになります。
実際の現場では、利用者が具体的に「システムをこうしてください」と提示してくれることは、驚くほど珍しいのです。 今回は、そんなリアルな現場でプロジェクトを前に進めるための最強の武器、「たたき台」を作る力について解説します。
なぜ現場は要件を出してくれないのか？（SIerとの決定的な違い）
そもそも、なぜ現場のユーザーは具体的な要望を出してくれないのでしょうか。 これには、システム開発を専門に請け負う「SIer（ITベンダー）」と、事業会社内の「情シス・DX部門」という立場の決定的な違いが隠されています。
SIerがシステムを作る場合、利用者（客）は安くないお金を払って発注しています。「自分たちの望むものを作ってもらわなければ損をする」ため、当然ヒアリングにも真剣ですし、やる気があります（生々しい表現をすると、ちゃんと言わないと怒られます）。
一方、社内の情シスがシステムを作る場合、利用者の部門に「自分たちがお金を払って作らせている」という感覚はあまりありません。そのため、要件定義の段階で、まだ目の前に動くものが何もないのに「さあ、やる気を持ってどんどん意見を出してください！」という状況を作ること自体が、非常に難しいのです。
なんなら、「よくわからないから、とりあえず一旦作ってみてよ。できたら意見するから」という、開発者にとって最も恐ろしい言葉が飛び出すことも日常茶飯事です。
現場は「ITの魔法」を知らない
さらに、現場が要望を出せないもう一つの理由は「想像力の限界」です。 毎日Excelと紙の業務と格闘している現場の担当者は、「システムを使えばどこまで業務が自動化できるのか（ITで何ができるのか）」という引き出しを持っていません。知らない機能は、そもそも要望の出しようがないのです。
プロジェクトを救うのは「たたき台」を作れる人
要望が出てこないまま打ち合わせの時間が過ぎていく。そんなお通夜のような要件定義の場を救うのが、情シス側から「こういうのはどうですか？」と【たたき台】を提示できる能力です。
ここで私は声を大にして言いたいことがあります。 結局、システム開発のプロジェクトは「たたき台を作れる人」が一番偉い！
既に誰かが作った案に対して「ここは使いにくい」「こう直した方がいい」と問題点を指摘したり、ブラッシュアップしたりする作業は大事ですが、それをできる人は会社の中にたくさんいます。
しかし、自分から率先して「たたき台」を作れる人は本当に稀です。なぜなら、何もない真っ白なキャンバスから形を作る「0→1（ゼロイチ）」の作業は極めて難易度が高いからです。
批判を恐れない「黄金の魂」を持て
そして何より、たたき台というのはその名の通り「叩かれる（批判される）ためにあるもの」です。頑張って作って提示しても、「これじゃない」「ウチの業務を分かってない」と言われるのがオチです。
そのため、会社組織において「たたき台を作る人」は、労力がかかる割に表立って評価されにくいという理不尽な側面があります。 それでも、プロジェクトを成功に導くために、批判されるストレスを覚悟して自ら泥をかぶり、たたき台を提示できる強い精神力。弊社では、この尊い精神を「黄金の魂」と呼んでいます。
【マインドセット】たたき台への「批判」は成功の証
「せっかく作ったたたき台を批判されたら凹む…」と思うかもしれません。 しかし、ここでマインドセットを大きく変えてください。
ユーザーから批判が出た時点で、そのたたき台の役割は100点満点で全うされています。大成功です。
ユーザーは「自分たちが何を欲しいか」を言葉にするのは苦手ですが、「目の前に出されたものが、自分たちの業務とどう違うか（何が嫌か）」を指摘するのは大得意です。 つまり、「これじゃない」という批判は、隠れていた本当の要件（真のニーズ）が引き出された証拠なのです。批判されることを恐れず、むしろ「よし、隠れた要件を引き出したぞ！」と心の中でガッツポーズをしましょう。
実践！効果的な「たたき台」の作り方
では、実際にどのようにたたき台を作ればよいのでしょうか。 例えば、システムの「検索画面」を作るとします。最初はExcelの図形を使って「ここに検索条件を入れて、ここに結果が出ます」と見た目（ワイヤーフレーム）を作るだけでも十分効果はあります。
しかし、利用者に実際の業務をリアルにイメージしてもらうためには、「実際に動くもの」を作れると最高です。 Excelのマクロ（VBA）などを使って、実際に条件を入力するとダミーのデータが絞り込まれて表示されるような、簡易的なツールを作ってしまうのです。
「動くたたき台」は究極のリスクヘッジ
ここで、こんな疑問が湧くかもしれません。 「要件定義の段階で、わざわざマクロで動くものを作るなんて、やりすぎ（無駄な労力）では？」
決してやりすぎではありません。むしろ、これこそが事業会社の情シスが提供できる最高の価値です。 ここで数時間かけてマクロを作る労力を惜しみ、よくわからないままいきなり本番のコーディングに入ったとします。そして数週間後、苦労して作ったシステムをユーザーに見せた時に「やっぱり違う、やり直し」と言われたらどうなるでしょうか？
要件定義の初期段階で「動くたたき台」に手間をかけることは、後工程での大炎上と手戻り（数週間のロス）を防ぐための、最もコストパフォーマンスの高い保険なのです。
まとめ
情シスやDX推進の真の価値は、現場から言われたものをただ作る「御用聞き」になることではありません。現場自身も気づいていない潜在的な課題を、ITの力を使って「目に見える形（たたき台）」にして提示してあげることです。
0から1を生み出すのは苦しい作業です。批判されることもあるでしょう。 しかし、あなたが勇気を出して提示したその「たたき台」が、止まっていたプロジェクトを確実に前へ進める原動力になります。
ぜひ、「黄金の魂」を持って、プロジェクトを動かしてみてください！
コメント