このページについて

SIの新人さん向けに要件定義など上流工程を過ごす上での考え方をまとめた資料になります。

１．要件定義のスタートラインとゴールを意識しよう

あるITシステムの企画が始まりたての頃は、お客さんが抱える真の課題やそれに刺さるソリューションはぼやけていることが多いです。まずこのスタートラインを意識しましょう。
SIerさんは、お客さんと一緒に問題設定と仮説設定および評価まで導くことが要件定義のゴールとなります。

要求というのはたいてい混沌としており、スライムのようなものだ。デザインはそこに有理なフレームを与え、新たな要求の形 = 仕事をつくる。混沌とした要求をそのまま反映しただけのデザインは、混沌とした仕事を生むだけ、つまりデザインしていないのと同じである。 pic.twitter.com/F1Q1W3NS5z
— Manabu Ueno (@manabuueno) November 11, 2020

そもそも問題がわかっていない、ソリューションが適切かどうかわかっていないうちに、大量のお金と時間突っ込んで開発したらヤバいよねと（もちろん企業の体力によるところはある）。 pic.twitter.com/wbv7LOs7UO
— Ryutaro YOSHIBA (@ryuzee) March 31, 2021

２．問題や仮説の紐解き方

２．１．デザイン思考や要件定義のプロセスを活用しよう

問題や仮説の設定・評価を行うための道具として、デザイン思考プロセスや要件定義プロセス（業務フロー、非機能要件定義の作成など）を利用します。
よくこの道具の完成が目的になりがちなので気を付けましょう。

２．２．大局から細部、細部から大局の両面から考えよう

お客さんの抱える問題は大小様々あり、SIerさんは沢山の情報を得ることになります。
これらを大局的に観て1つのシステムコンセプトを捉えること、局所的に観て行って全体コンセプトと整合していること、この様な思考を繰り返して問題と仮説を整理していきましょう。

たとえば、ひとつの全体性としてコンセプトがあり、それを実現するために必要な要素がある。その際、各要素を個別に評価して採用したりしなかったりするのは愚行だ。どれを選ぶかに関係なく、ゲシュタルトを見ていない態度そのものがデザインをスポイルしてしまう。 pic.twitter.com/V5zVGMJgpK
— Manabu Ueno (@manabuueno) December 8, 2020

デザインは How → What → Why の順序で行う。表現する行為の中から論理をリバースエンジニアリングする。我々は形を通じてしかそれが何であるかを言い当てられないから。一方それをプレゼンする時には Why → What → How の順序で行う。そうすることでデザインがそう在るべくして在るように見える。 pic.twitter.com/e8rsactPup
— Manabu Ueno (@manabuueno) November 25, 2020

３．設定した問題と仮説を評価しよう

ここまでの検討で出来上がった問題と仮説を評価しましょう。
有識者やユーザー、ステークホルダーとのウォークスルーなど、他者への説明を通してフィードバックを得る方法が有効です。
自分の説明は「いちごを主役としたイチゴヨーグルトパフェ」「果物を少しずつ集めたフルーツパフェ」になっているでしょうか。「すしラーメン、キウイにバナナジュースを添えて…」になっていないでしょうか。

４．まとめ：価値にフォーカスしよう

昨今のシステム開発では、この様にお客さんの価値にフォーカスすることがより重要視されています。
価値に根差した進め方を心掛けること、それが変わっていないか定期的に検査すること、問題が判った段階で次の手が打てること。こんなことを考えながら日々の業務を進めて貰えれば、もう立派なSIerさんだと思います！

数ヶ月前に私が社内向けにプレゼンした中に「ゴミはいくら納期と予算が守られていてもゴミ」という文があって、その時社内はザワついた。

構想段階でも作り始めてからでも、いつそれがゴミだと気付けるかがポイントなのに未だに全てのものに大きな価値があると信じる勢力が強いのはどうにかしたい。 https://t.co/4Oo1DWZaZo
— Aki (@AkiDebukatsu) April 28, 2021

OutputよりOutcomeなので、生産性という言葉は注意が必要だと思う今日このごろです pic.twitter.com/pFBfXHLiDK
— Ryutaro YOSHIBA (@ryuzee) May 14, 2021