もし企業の情シスがGoogleだったら

もし企業の情シスがGoogleだったらどうなるのだろうということを考えている。

業務システムは突然ローンチされる
業務システムが常にBeta版
システムの利用状況が低いと、突然、システムは廃止される
システムの利用状況が高くても、将来性が無いなどの理由で突然、システムは廃止される
メールの内容は全てモニタリングされる
IMEの入力内容も全てセンターに送信されてモニタリングされる
オフィスの入退室も当然モニタリングされる
監視カメラの画像もモニタリングされる
定期的に移動カメラでオフィス内が撮影されモニタリングされる
業務システムはユーザの要求にもとづいて作られるのではなく、モニタリング等で発見された事実によって作られる。
ユーザに意見は聞かない。
業務ロジックはA/Bテストで決める。

「テストから見えてくるグーグルのソフトウェア開発」を読んで感じたのだけれども、Googleの開発プロセスでは「要求を出す人」というのが兎に角登場してこない（あたりまえか）。抽象的な意味での『ユーザー』は出てくるのだけれども、単なる役割の名前程度の扱いである。データさえ取れれば、例えば異星人に対してだってシステムが作れそうな印象。

「要求の国」と「予想の国」

何が言いたいのかというと、googleは「要求の国」ではなくて「予想の国」でソフトウェア開発を行っているように見えるということだ(本当かどうかは知らない)。

要求に基づいてソフトウェアを開発するのではなく、予想されるニーズに対してソフトウェアをつくり、検証する。
ニーズの予想は、利用者の行動の観察などに基づいて行われる。
予測して作っているので最初から「正しいもの」は得られない前提。早い段階で見直し、作り直す(最適化する)。

こういったことが可能になったのは「やりなおし」「くりかえし」のコストが劇的に下がったからである。逆に言えば以前は「やりなおし」「くりかえし」のコストが高かったので、上流工程で仕様を明確化し、ウォーターフォールで開発するという「要求の国」のやり方があったのだと思う。

「要求の国」の致命的な弱点

どちらのアプローチもメリデメがあるので、個人的にはそれぞれの事業環境や状況に応じて使い分け、選べば良いと思っていた。しかし、「要求の国」には致命的な問題点がある。それは「ユーザー」である。

要求を定義して段階的に仕様化・詳細化するステップは、「ユーザー」と実施する必要がある。
業務の自動化や電子化といった、わりと分かりやすい領域ではこのアプローチでうまくいってた。
しかし、より高度なシステムの構築を目指すと、とたんに「ユーザー」が高い精度の「要求」を出せなくなってしまう。
- 努力して「要求」を出したとしても明確な理由付けなどできるわけないので、レビューや利害関係者調整に苦労する。

f:id:kent4989:20140125110943p:plain
昔から「ユーザーがボトルネック」という話はよくあったのだけれども、問題は決定力やITリテラシーやプロジェクトの参画度合いなどであった。これからは、これに加えて「ユーザーに聞く事自体がリスク」ということも考えていかなければならないのだろうか。