読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

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

Project Management

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

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

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

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

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

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

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

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

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

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

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

関連記事

グーグル社員、ひいてはA/Bテストの信奉者は、データ中心でない意思決定システムを「HiPPO」と呼んで軽蔑する。HiPPO―highest-paid person's opinion(トップの意見)と。
WIRED VOL.5 GQ JAPAN.2012年10月号増刊 特集「A/Bテスト」

WIRED VOL.5 GQ JAPAN.2012年10月号増刊

WIRED VOL.5 GQ JAPAN.2012年10月号増刊

テストから見えてくる グーグルのソフトウェア開発

テストから見えてくる グーグルのソフトウェア開発