デラックス過ぎる要求仕様は、いわゆる「ぼくの考えたさいきょうの○○」に通じるものがあって、あらゆるものを超越した理想は夢想でしかないということを良く表しています
要求仕様には、納品物の定義・規定も含みます。こちらも事細かに規定されていると、後々どえらい目に遭います
【閑話】
とある次期システム提案にてー
「今のお話を総合させて頂きますと、システム基盤には“ヴェーダ”の導入が必要と思われます。ええ、2200年代終盤に月の裏側に建設される量子コンピューターシステムです。ちなみに、端末には人間タイプのイノベイドと、ガンダムタイプがご利用頂けます。
…冗談も休み休言えですって?
それはお客さまの要求仕様のことでございましょう。私どもは至って大真面目でございます。宜しいですかお客さま、お客さまが望むものを実現しようとすると、これだけの内容になるということをお忘れなきように」
【閑話休題】
混沌とした要求仕様に反論もせず、驚きの安さでホイホイ請けてしまうシステム建設ベンダーの姿勢もどうかと思います。お客への提案において、無から有を生み出せるかのような言いぐさは、まるで自分たちが造物主にでもなった気でいるのでしょうか。
それとも、一部のIT関係の記事で囁かれているように、単なる無能が要求仕様に答えているからでしょうか。
分限をわきまえて度を越すなと言いましょうか、どこで線を引いて納得するかで業務システム建設の成否は決まります。
妥協のない姿勢は、本来ならば稼動時の品質に向けられ、性能や信頼性をも包含した堅牢なシステムを作あげるのですが、誤った“拘り”はときにシステム建設プロジェクトを圧迫し、あまりに現実離れした要求仕様は、じわりじわりと建設中の業務システムを蝕んでゆき、やがてシステム建設プロジェクトに大ダメージを与えます。行き過ぎた要求仕様を機能として忠実に実装しようと時間を浪費し、人は疲弊して、それでもシステムは動かない、仮に動いたとしても満足のゆく性能が出なかったり、予定範囲内の大量データを取り込んだら異常終了したり、いつの間にか必要な機能がオミットされた代わりに、どうでもいい機能がたくさんの工数を消費して贅沢に実装されていたり、迷走は止まるところを知りません。
それでもいつか、プロジェクトは終焉を迎えます。
そしてシステムが稼働を始めます。
プロジェクトだった“何か”は、死屍累々たるありさまです。後にはシステムだけが眈々と動いています。
システムが稼働した直後、僅かに生き残ったシステム建設ベンダーは、その後細々と、平和に維持保守を続けられると夢想します。
しかし、そうは問屋が卸しません。
システム開発期間中に稟議の下りなかった案件が溜まりに溜まり、システム建設ベンダーを待っています。
毎日毎日、予想通りに“予期せぬ障害”が起こります。
そのような状況下でも、お客のシステム部門の担当者は“もっと充実させよう”とシステム変更を行う気満々です。たとえユーザー部門が満足しても、システム部門が満足しないのです。(その逆の状況もあります)
さらに繰り返し案件を取り込んでゆくと、機能仕様が膨らみ、それだけ手間暇が掛かるようになります。(古から続く老舗の鰻屋の秘伝のタレのように、継ぎ足し継ぎ足し守り継がれてゆくシステムです。このシステムは、何年も後で次期システム化の際に、また膨大な資金と時間を消費することでしょう)
案件の内容如何によっては、膨大な機能を追加することもあります。
にも拘らず、お客は「みなさん熟練したでしょうから、次の案件では工数を減らしていいですよね」と言うのです。
設計者も開発者も減ってしまったというのに、一体誰が維持保守するのかと。
ところで、あるシステムにシステム更改の必要性が生まれた原初の時点まで遡って見てゆくと、その原初の時点ですでにシステム建設プロジェクトの成否とシステムの未来が決定付けられてるのが分かります。
たとえば、「その業務は何から構成されているのか」、「プロジェクトに関与する人たちの“妥協を許さない姿勢”のその矛先はどこに向いているか」という要素は、システム建設プロジェクトの最終目的である次期システム稼動に大きく影響します。これらの目標が正しく定まっていないと、システム建設プロジェクトは本来の目的を外れて、“厨二病”をさらに拗らせて、時間もお金も物理法則さえも、次元の彼方に吹き飛ばします。
事業と事情をを知らない財布を握っている経営層を誑かして「きっと使わない“贅を凝らした”システム」を建設しようとしたり、「せっかくシステムを変えるなら、(要件も定まっていないけれど)あれもこれも詰め込んでしまえ」という貧乏性かつ突っ散らかった思考も、システム建設プロジェクトに多大な悪影響を及ぼします。
このようにシステム化計画の段階ですでに歪んでしまった場合、そうした考えを反映した要求仕様は最早仕様の体をとってはいません。もはやファンタジィ小説(あるいはラノベとも)の領域です。
このリンクに、インターネットでよく見かける、システム建設プロジェクトにおける「仕様の解釈」を示すパロディ画像があります。
この画像は、システム建設の状況を非常によく風刺しており、「必要にして充分という状態の“姿”を誰も理解していない」という実態をよく表しています。プロジェクトでは、そこに関与するすべての人たちが、それぞれに勝手な解釈で「自分に一番都合の良い状態を思い浮かべる」という実態です。
目的を見失い、“抜け殻”の理想だけを追い求めると、このようになるのかもしれません。退廃的というか、ブルジョアというか、うなるほどのお金を持っているのに未来の目的(ヴィジョン)を描けないでいる弊害なのでしょうか。
ちなみに、システムの企画書や要件定義書から、次のような疑問(あるいは謎)が読み取れてしまったときは、非常に危険なプロジェクトになります。
- やってやれないことはないけれど、やるとしたら膨大な時間とお金が掛かる
- それでも実装するのか
- そもそも実装するに足る意味があるのか
要件に納得できないなら、お客によく確認して、真意を問いただすのが肝要です。どれほどお金に困っていても、何も考えずに応札したり提案書を持ち込むべきではありません。
一旦受注が確定し、プロジェクトが始まってしまうと「いつの間にか、要件にあった“期間内にやれるなら”が“やらねばなるまい”にすり変わってしまった」というコメディのような展開に遭遇することが多々ありますが、これはお客へ確認も諭すこともしなかったために起きる予定調和に過ぎません。
この他にも、プロジェクトの前段階やプロジェクトの中で、次のような意味のわからない奇怪な目的に縛られて、苦行を強いられることもあります。
- 流行りの実装仕様を頑なに踏襲する(これにより現実世界の運用に致命的な支障が出る)
- 誰も商用で試してもいない高尚な理論が先行する(本番稼動直後から運用を危機にさらすことになる)
- 物理的限界を度外視したシステム構成が決定事項となる
- システム部門の威信(笑 )を社内に知らしめるためのシステム建設プロジェクト
システムへの要求を出すお客に対して「“100てんまんてん”を目指す理由があるのか?」と問う前に、どのような状態を“100てんまんてん”とするのか、鑑を定めるべきです。(100点を目指すのは当たり前です。そうではなく、何を以て100点とするかのほうが重要です)
多少の時間が掛かっても、じっくりと腰を据えてお客と一緒にお客のの事業と向き合い、本当の理想の未来を具体的に描いたうえで、システム化構想に取り掛かれば良いものを、システムありきで事業を捉えているから、本当に必要なものが見えてこないのではないでしょうか。
これまで沢山のプロジェクトを見てきましたが、お客の(政治的な)内情(と人間関係)と自社の実力をよく知れば「君子危に近寄らず」と「虎穴に入らずんば虎子を得ず」との境目は、誰でも簡単に見分けられると思います。(ほとんどの場合は、止むに止まれぬ事情でお金を優先してしまいますが…)
Written by Interlude.
Interlude. 
