そんなセンシティブなテーマからスタートします。
正直何かしらの開発経験がある方なら共感いただける話かもしれません。
今回の話はWEB開発現場の声としてお届けしていきます。
ここで絶対に区別しておきたい点がPDCAサイクルやアジャイルやウォーターフォールとの明確な区別です。これらは最低限のセット（要件定義→設計→開発→検証）がしっかりと機能しているということが前提と考えています。
今回はこの中で要件定義と設計が欠けている状態、または不足している状態と仮定しています。
その上で設計の甘い状態でこれらのサイクルを回転させていく事、ただの工数の無駄使いに陥っているものを愚か者であると定義しています。
【解決策はこれ】
プロジェクトを成功させていくのであれば要件定義は絶対に必要事項であるから
過剰に心配性なマインドを持ち、最終ゴールから逆算して必要な要素をかき集める。
何よりも日頃のインプットが本丸のプロジェクト進行時に重要となる。
準備（要件定義・設計）を怠る者との始まりの話
とあるプロジェクトの検証フェーズになってつぶやかれるフレーズ
「これ思っていたのと違う」「もっとこうしたいんだよね」「ここを変更したい」などこんなフレーズです。
これら全部、意味がわからないフレーズなのですよね、本当にPDCAサイクルやらアジャイル開発が
機能しているのであればここでつぶやかれるフレーズはこうですよね
「ここを〇〇にしたら使い勝手が良くなる」「もっとレスポンスを良くしたら気持ちいいよね」
「ここをさらに強化したい」
このような形でNOT（否定）ではなくADD（強化）になるはずです。
何故このような事態に陥るかは答えはこれしかありません、
「事前に入念な準備をしていない」これだけです。
しかし、こんな話をすると愚か者はこう言います「時間がない」「忙しい」「事前にわかるわけない」これは全部いいわけでしかないですよね。
なぜならお腹痛かったら胃薬を飲み、頭が痛かったら頭痛薬を飲む、骨が折れたら病院にいく
骨が折れてるのに時間がないから、忙しいからという理由でギブスをつけない人はいないですよね。
結局は優先順位の問題で、大抵は怠けて甘くみているだけのことが多いのです。
この記事での本題はこれです。「要件定義」「設計」この部分にフォーカスします。
そして冒頭のフレーズ「要件定義を怠るものは愚か者である」
準備が必要なことは誰にでも想像ができることなので、今回は著者が考える要件定義を考える上で
大事なコト3選をまとめていきます。
【要件定義で大事なコト】
その1：過剰に心配性になって考える
その2：最終アウトプットから逆算して必要な要素を考える
その3：日頃のインプットがすべてである。
その1：過剰に心配性になって考える
どんなタイプの人であれ心配性の仮面をつけて考える、すなわちリスクを感じ取るアンテナを持つことが大事だと考えます。
人は不安になると安心できる材料を探します。
直感的に損失回避が機能して、本能的に失敗したくないと強く思うようになります。
この心理を逆手にとって、ロジカルに安心できる材料を集めていける環境となります。
例えば50MBのデータを表示するという仕様。
大体のケースで普通に考えればこの程度のデータで落ちるわけがないです。
ここに不安要素を取り入れることで
「ピーク時にどれくらいのアクセスになれば落ちるのだろうか」と漠然とした不安が生まれます。
これを解消するためには具体的なデータを積み上げて、トラヒックなど数字を計算することが必要です。安心材料を用意することが具体的な仕様を定義することに直結していきます。
その2：最終アウトプットから逆算して必要な要素を考える
スタート地点から山頂を見上げるのではなく、頭の中で標高を描いておく
このようなゴールをはっきりと描きその情報を把握しておくことが重要と考えます。
これはゴールをしっかりと描いた上で、そこまでの道のりを埋めていくように、逆説的に考えるということです。
例えば家を建てようとして家の内装に気持ちがいってしまうのはわかります。
まずは土地から考えて、その土地にどれくらいまでの大きさの家が建てられるかを考えて最後に内装というような感じです。
もし、満足する内装にならないのであれば、もっと広い土地が必要だとすぐにわかります。
設計工程が進んだ先でやっぱり狭い、やり直したいということが防げます。
まさにこれが、検証工程で「思ったのと違う」ようなニュアンスの問題を回避することに繋がりります。
その3：日頃のインプットがすべてである。
ある日突然、最強のアウトプットを可能として、プロジェクトで力を発揮できるようになるものではありません。日頃から情報収集をしっかりしていることが要件定義のような場面で生きてきます。
最新のWEB開発の仕様を設計している人間だとして
それが日頃、まったく最新のOSやハードの情報に触れておらず、情報に疎いということであれば
この知識のズレ、感覚のズレが要件定義の際にはっきりと問題の輪郭を表します。
そんな人がいくら付け焼き刃で仕様を検討しても、知らないことだらけなのですから
準備をしっかりできるわけもなく、もちろん本質を知らないのですから
皆が納得できる良いものができあがるわけがありません。
常に幅広く情報を収集して、コネクティングドットを実現していく必要があります。
最後に
今回の記事を通して、一人でも多くの人が要件定義や設計が曖昧なことで苦しむ機会から解放されればいいなと思います。
要件定義はきっと優秀な人であれば経験がありノウハウがあり日頃から問題を解決しているはずです。
しかし、世の中は優秀な人ばかりではなく、普通の人が多くを締めているはずです。
そんな人がこの記事を通して気づきを得て、愚者から賢者にチェンジすることで
明日から一人でも多く救われるようにと願い、この記事を締めくくりたいと思います。
こんにちは♪
スタッフの友人です。
時々、気になった記事を投稿しています＼(^o^)
