トイレで学ぶ、システム開発の難しさ　その４　まとめ

第四回は、まとめです。

まとめ

やはり、「ITの開発は難しい」という言葉に尽きます。

例えば飲食や建築のように長い歴史もありませんし、そもそもシステムやITの在り方といった根源的な議論が充分に尽くされていません。

かといって、これらは物凄いスピードで進化しているため、語っている最中に前提が変わってしまったり陳腐化してしまうなんてこともありますが、この「難しさ」にはポイントがあります。

一つ目はユーザ側が自身の要件を正しく漏れなくベンダ側に伝えることができず、ベンダ側もユーザ側の要件を引き出すことができていないことです。

その結果、要件や仕様に足りない部分や齟齬が出てしまい、それを当初想定のスケジュールの中でやりきるために何らかの要素を犠牲にしていることで、犠牲になるものは、品質・追加料金・劣悪な労働環境などが代表的でしょうか。

二つ目は、システムには上記の要件の抜け漏れの以外にも、ビジネスニーズの変化などによる仕様変更がつきものですが、デザイン自体や重要な前提条件が覆ったとき、システムはそれを吸収しきれないことです。

建築でいえば、基礎を作った後にできる変更には制限がつきますし、柱を立てた後に間取りを変えるなんてことはできません。壁紙を貼った後なら、何も変更できないに等しいでしょう。
しかし、システムの開発では、こういったことが「何故できない！？」というスタンスで語られてしまいます。

さて、このシリーズ最終回では、これまでの回でもあったユーザ側とITベンダ側それぞれの問題点について触れたいと思います。
正直、「どっちもどっち」だったりしますが、どうかお怒りにならず最後までお付き合い頂けますようお願い致します。

ITベンダ側の問題点

まず、ベンダはサービスする側です。
お客様はそれに対する対価を支払って頂く存在であり、お客様がいなければ、我々はメシを食っていけません。それは当然の話です。

しかし、だからといってユーザ側に「キツイこと」が言えないというのは問題です。
不当な要求を突っぱねたり、契約から外れた条項を押し付けられた場合に調整しなければなりません。

もちろんお客様の方が立場が強いことは間違いなく、受け入れなければならないことはよくありますが、サービス可能なラインを越えてしまったら、納期の延長や追加費用などの対価がなければ、営業的な収支もそうですが従業員や労働環境を守ることも果たせません。
簡単でないことは承知の上ですが、これは殆どの会社や案件で、できていません。

次は、ベンダがいわゆる「システム屋」でありすぎることです。
そもそもユーザはシステムにお金を出すのではなく、システムを導入した後の業務運用に対してお金を出すのですが、機能としてのシステムのみを提供して「あとは好きに使って」的なスタンスをとるITベンダは多いように思います。

そういう姿勢だからこそ、不用意にユーザを怒らせてしまったり、結果として関係が悪くなってしまったり、そのお詫びの体で無償の追加要件などの不利な条件を呑まされてしまったりします。
結果、デスマーチと呼ばれる日々が始まってしまうのではないでしょうか。

最後に、プロ意識の問題です。
要件の抜け漏れをユーザの後出しジャンケン的なものだと断ずるエンジニアが多いように感じます。確かにそういった例も数多くあるかと思いますが、「お客さんが○○と言ったから」「××とは言っていなかった」というスタンスで仕事をしている人は山ほどいます。

自らの要件を言葉にすることができるユーザなどまず存在しないのですから、「要件は喋ってもらうものではなく、引き出すものだ」という意識での取り組みが求められると考えています。

ユーザ側の問題点

最初に思い浮かべるのは、「具体的なイメージが湧かない」という表現がよく使われることで、端的にどういうことかというと、いくら説明しても、システムがある程度カタチになるまで興味を示さないことです。

この悪癖のせいで、後続の作業の方針や大枠を決める、最も重要な要件定義フェーズをおざなりにし、形になった統合テスト～本稼働前くらいに山程の仕様変更を入れることとなり、システムの品質を下げるだけの無残な日々が始まるのです。

さて、システムの変更というものは、簡単なものもあればヘビーなものもあり、傾向こそあれケースバイケースとしか言えません。

なのにユーザは、建築でいえば壁紙を貼り終わった後で「そういえば、もう一部屋欲しいんだけど」的な変更を持ちかけてきたりします。
もちろん、ITの専門家でないユーザが変更のインパクトを知る由もありません。しかし、どうか「犬小屋くらいタダでサービスしろ」とでも言わんばかりのスタンスは勘弁してください。

これは甘えと言われてしまうかもしれませんが、作る方のベンダだって人間です。
作り上げてテストをしたその場で変更を言い渡されては、ちょっと落ち込みます。
この頻度やインパクトの大きさが積もって、プロジェクトの士気は大きく左右されます。

骨組みができてからのインパクトの大きい変更は、見た目が悪くなるだけでなく、耐震や雨漏りなど建物自体の強度も悪くなり、建物の寿命を縮めることに繋がるはずで、システムだって一緒です。

仕様変更は絶対ダメ！！というわけではありませんが、デザインやコンセプトに関わる部分は変更のインパクトが非常に大きいので、ご注意ください。

どこがデザインやコンセプトなのかわからないよ！！と思われるかもしれませんが、もの凄く乱暴に言えば、大抵、設計書の最初の5ページ以内にあります。どうかそこだけでもご注目ください。

長くなってしまいましたので、この辺りで。