要件定義の歩き方（機能拡張編）

はじめに

要件定義は本来Serviceを提供する企業が行うものだが必ずしも彼らの全てが情報処理技術に対して知見がある訳ではない。従って多くの企業は企画書を作成しVendorを選定後Vendorと共同して要件定義を行う。Vendor選定では企画書に対して安価な業者になる事がしばしばであるが安価になる要因は要件定義書や設計文書の一部省略にあったりする。それでも要点がまとまっていれば開発を進められるのだがそういう開発案件は大抵暗礁に乗り上げてしまう。暗礁は単体試験から結合試験にかけてしばしば発生する。挫傷した船が沈没しないように人海戦術で船内の水を外に掻き出す造作が所謂Deth Marchである。その間納期に間に合わせるため開発者は休日返上及び徹夜作業を強いられ心身ともに困窮してしまう事になる。開発者をこの様な状況に追い込むのは開発運用責任者の知見が低い事が要因となるのだが彼ら幼稚な管理者は納期を理由に開発者に過酷な労働を強いる事になるのだがこれは明らかにPower Harassmentであろう。特にOffshoreに対する仕打ちは目を覆いたくなるほど酷いものだ。日本人でさえもまともに理解できない設計書とSource Codeの切れっ端を仕様などと平気で依頼するPMも存在する。それでいて納期までに些細なBugが多いと怒るのだから始末に負えない。Agile開発になるとまともにDocumentすら作らない開発企業もある。Agile開発だからDocumentは要らないと勘違いしているからだ。そもそも人が人に仕事を依頼する際に解りやすくするのはBusinessの基本中の基本なのだがそれが出来ないいやしようとしない開発Vendorが多すぎる。過酷な労働環境では落伍者も多くその都度人員が入れ替わる事になるのだが引き継ぎをするためのDocumentもまともに揃っていないのでそう容易に引き継ぎが完了する道理もない。ところが世間一般ではこの現象を開発者不足と言って問題視しているのだから問題の根本を見据えていない。実際は開発者を不足させている要因は開発体制にそのものに問題があるのだから。

こういった現状に対して改善を求める有識者の中には要件定義の手引書の出版もしくはBlogやYoutubeなどSNSを利用して情報公開もされる方も増えては来ている。然し乍らこれらの内容は新規案件に対しての手引書が多く機能拡張や修正に関する手引書はあまり見かけない。企業において最も重要なのは機能提供を如何に効率よく拡張し継続する事にあるのだが多くの経営者は目先のスピード感（普段筆者は片仮名の使用は音節が崩れるため控えているが日本語特有の誤った概念を植え付ける片仮名については読者に問題意識を持たせる為あえて強調文字を使用している）という本来全く重要でないものを重要視する傾向が強い。実際この不毛な言葉を使った者が短期間に手がけたServiceの検証をした事がある。精神が多少不安定で喜怒哀楽が激しい方々の育成のための教育学習Siteと言えば体はいいのだがLogin画面が開くまで1分以上待つなどとてもSpeedyではない代物だった。おまけに彼らの環境を気遣った配慮すらなくとても親切なServiceとは言い難いものだった。設計書も何もないただのCodeが羅列されているだけの我楽多のため不具合が多発しReleaseすらまともに出来ないありさまだった。Codeが書けるだけで文章や図解説明力の欠如した開発者は普通にPGをしていれば良いのだ。最初に実装だけ進めて後で要件定義書から設計書までを作成すれば良いという開発者もいるがCodeから設計書や要件定義書など作れるものではない。

このような浅はかな開発思想はさて置き新規開発において要件定義からRelease過程をしっかり行ったとしてもその後始末もしっかりしておかないと次回以降の機能拡張や運用時に発生する不具合に十分な対応が徐々に出来なくなってしまう事がある。十分な機能拡張や不具合対応が出来なくなれば移行するか機能提供を諦め撤退する事になる。どちらにしても企業にとっては大きな損失と言える。しかし移行にしても現行要件がまとまっていなければ現在提供しているServiceと同等以上のものの開発は難しくなるのだ。

初めにお断りしておくが本書は要件定義の技巧や書式をまとめたものではない。目的を明確化するための推測力を養うためのものであるためその概念を掴んでおけば反復して読む文書でもない。然し日本の誤った記憶教育に慣れた方々には理解が難しい記述にもしている。殆どの技術者が会議で使う言葉に「・・・のはず」がある。つまり彼らは記録で仕事をせずに記憶で仕事をしている。この記憶のKeywordは単に一個人の思い込みに過ぎない。人の記憶ほど当てにしてはならないものはない。だからこそ概念を掴んだ上で実践で何度も試し失敗して身に付ける心がけ必要なのだ。技術や経験は一朝一夕に身につくものでもないし要領だけを望むなら技術者として向かないので他の道を進むのも良かろう。