書類ファーストから、プロダクトファーストな情シスへ

人は見えるモノしか信じない。

人は本当に不思議な生き物です。まったく見えもしない、漠然とした不安に怯えて夜も寝られない一方で、素敵な新しいシステムの企画書を書いたところで、それを見るまでは全く信用してくれません。

自己の望むものがそこにある、と現場の方に共感してもらうことが情報システムの企画フェーズにおいて重要ですが、面白みのない企画書の文章からそれを読み取る事は困難です。PoCで行われるプロトタイプづくりで重要なことは、物語の筋立てをドラマとして見せることで自己の望むものがそこにある、と共感してもらうことにあります。

最近はパブリッククラウドサービスの充実のおかげで、初期のプロトタイプそのものが、あっという間にクラウド上で実装出来るようになりました。概念設計から実装までのリードタイムを大幅に短縮できるのがパブリッククラウドの良さです。デザイン思考でいうところの「犠牲になるコンセプト」がクラウド上で簡単に実装でき、しかも捨てられる。この捨てられることがクラウドの最大の利点です。

あえてパブリッククラウドと述べているのは、プライベートクラウド、マネージドクラウドなど同じクラウドの名前がついていますが、性格が全く異なるからです。経理部門出身のCIOの方とクラウドの話しをすると、話が噛み合わないことが多いのですが、資産を持たず費用化することが会計から見たクラウドの姿だとされて、自社保有のサーバーをベンダー資産とした事をもって「フルクラウド化に成功」と言われても、私としては「ちょっと違うよね」と思ってしまいます。資産の費用化はクラウドの一つの特徴ですが、それだけがクラウドの良さではありません。ちょっとやってみた、試してみた、でもダメだった、というときに「やめます！」と言ってサービスをやめられることが、クラウドの良さであり、クラウドの本来の姿だと思います。こうしたことが自由に出来ないプライベートクラウドやマネージドクラウドは本来的な意味でクラウドではない、と私は思います。

また、こうしたクラウドの良さを生かす情シス部門の体制は、自社で内製することが理想です。発注書を書いて、見積を取って、予算承認をもらって～とやっているような外部依存体質ではスピード感が出ないのです。自社にある情シス子会社にしても状況は同じです。情シス子会社を動かすための依頼書作成とその承認のリードタイムがあれば、内製で簡単なプロトタイプは出来上がってしまいます。システムを高速でリリースした上で、早めにフィードバックをもらい、改善サイクルを回す。ダメならいったん撤収する。たくさん失敗する中で成功が生まれていくような、プロダクトファーストが実践できる体制づくりが求められます。

何をやるにも書類で依頼しないと動かない「書類ファースト」な情シスを改めて、思いついたアイデアをすぐに実装してみる「プロダクトファースト」な情シスに改革することが、クラウド時代の今日のCIOの重要な役割だと思います。

見えるモノしか信じない人を信じさせる「魔法のつえ」のようなクラウドを使って、現場の人に驚きと興奮を与える事が出来るのです。エンジニアを書類から解放し、魔法使いに変身させましょう。