■

漫画を適当に積んでいたんだけど、なんか限界を感じたので、適当に並べなおし。
以前、一回、それなりに積む順番を整理したんだけど、気が付いたら限界に近付いていた次第。
垂直方向に積むのはよくない。いや、少し考えたらわかることだけど。

とにかく、並べなおし。っていうか、もう二度と読まないやつが多いんだから、なんとかすべきだよな

• 読まないのは読まない
• 最後の巻以外は読まない可能性が非常に高い
• 小説はどんなに面白くても二度と読まない

要求分析はそれなりに楽しいと思い込むようにしよう

最近、要求分析だけは、しっかりやったほうが良いのかもしれない。と、思うようになってきた。
実際の仕事では、「コーディングだけでは解決できないけど、客が何をしたいのか、という点さえ理解できればあっさり解決するような問題」というのは、それなりの量があるように感じる。分野によるかもしれんけど。

んで、要求分析をやるモチベーションを維持するには、「要求分析を行うのには、非常に高い能力を必要とする」というふうに思い込むようにすればよいのではないかと思う。実際そうだろうし。

というか、要求分析するのに必要な能力は、コード書く能力と近いものがあるような気がしなくもない。それは、「顧客とコミュニケーションをとるうえで、技術知識は欠かせない」とか、そういうレベルではなく、もっと本質的に。（本質的て何だよ）

要求をもとに仕様を作るのは、以下のような作業になるはずだ。

最初に客から、「なんたら仕様書」というものが出てくる。まず、ここから、「客がやりたいことは、なんなのか」を、抜き出さないといけない。
そのためには、書いてある動作を脳内でシミュレートしないといけない。文として記述されている断片化した仕様、それを、脳内で繋げて、断片化しないシーケンシャルな動作へと変換する作業が必要になってくる。

さらに、最初に客から出てくる「なんたら仕様書」は大かれ少なかれ問題を抱えている。どっかで矛盾してるとか、巨大な仕様が一言で表現されてるとか、実現無理だとか。
そういうのを発見するためには、要求を抜き出すために行ったシミュレート結果を分解して、各機能の詳細について考えないといけない。シーケンシャルな動作から、独立した機能へと分解する作業が必要になる。

この一連の作業は、コードを読んだり書いたりするときの作業と結構近い。シーケンシャルな動作と、断片化されて並列に記述された機能との間の相互変換。

ここで、無理矢理、「要求分析がうまくできる人はコーディング能力が高い」というような理解をしておく。実際はどうかは知らない。けど、そう考えておけば、それなりにモチベーション維持に繋がるはずだ。人によるだろうけど。
要求分析が欠かせないものである以上、嫌々やらないようにするのは悪いことではないはず。

■

まあ、そういう話なんだけど、実際のところ、その程度でモチベーションなんか上がらないくらい要求分析をやるモチベーションを下げる要因は非常に多い。

• 客とやりとりしないといけないのが面倒
• 金の話と絡んでくる
• 何も理解しない人が仲介として存在する可能性がある。自分の行動が著しく制限される
• うまくやっても誰も気付いてくれない

最後のは結構ダメージ大きいと思うのだけどどうだろうか。

要求分析をうまくやることで得られるメリットは、「最後にやってくる仕様変更が少なくなる」とか、「客がいつもより喜んでくれる」というようなことがあるはず。だけど、こういうのは、「今回はお客さんがよかった」の一言で片付けられてしまう。要求分析がうまくいったかどうかまで考える人間はいない。

コーディングをうまくやれば、それなりに名声を得ることができる。さらに、コード書くのをうまくやったのは証拠も残せる。給料は上がらなかったとしても、まだ救いはある。

けど、要求分析をうまくやったのは、誰かひとりに気付いてもらうことさえできない。それを主張するような証拠を残すこともできない。
要求分析をやるためのスキルというのは、何をどうやっても報われないのである。

だから、まあ。えーと、どうすればいいのかは知らんが。
とりあえず、仕様変更が少なかったときや、顧客満足度が高かったとき、要求分析を担当した人に感謝するようにしたほうがよいのかもしれない。というようなことを思う。最近。