共創――ユーザサイドにも求められるパラダイムシフト
みなさまこんにちは。
10月最終日はハロウィンということで、都内は結構な賑わいだったようです。
経済効果はバレンタイン・デーを凌駕したとか。各種ニュース番組でもずいぶんと大きく取り上げられていました。
このハロウィン、もともとはケルト民族の先祖の霊を迎える、いわばケルト版「お盆」だったそうです。
祖霊が現世に訪れる際に、一緒に流れ込んでくる悪霊に害を受けないよう、「悪霊の仲間のフリ」をするための仮装だったとか。
聖バレンタインの逸話同様、由来は知られずとも現象だけがムーブメントとして一人歩きするのは世の常なのかもしれません。
「クラウド」という言葉も、世間的にはその由来や実体は、言葉自体の認知度の半分も理解されていないのだろうなと、そんなことを思いました。
「共創」という考え方
さて前回は、「クラウドインテグレータ（CIer）」という存在のあるべき姿について考えました。
これから、そのCIerとしてのふるまい、ユーザの抱える課題をクラウドコンピューティングをもって解決する手法をご紹介していきたいと思っていますが、その前に、ユーザサイドにも意識していただきたい考え方についてお話したいと思います。
キーワードは「共創」です。
呼んで字のごとく、「ともにつくる」ということですが、ユーザサイドと開発サイドが、協力し合ってひとつの仕組みを作り上げること、これが共創です。
ここでいう仕組みとは、コンピュータシステムに留まりません。そのシステムを十全に生かしきるための組織や業務管掌、オペレーションフローなど、コンピュータシステムを包含した業務運営そのものを指します。
当たり前のことですが、コンピュータシステムはそれ単体では意味を成しません。
何らかの目的の元に設計され、その目的に貢献すべく構築されているものです。
その目的を抱いた「人」が使って、初めて目的に貢献できるのです。
つまり、システム開発の獲得目標はシステムそのものではなく、そのシステムを利用することによって起こる変化にあるはずです。
ところが、納期や予算に追われる実際のシステムの開発や導入の現場では、この極めて基本的なことが忘れ去られてしまうことが往々にして起こります。
「納期どおりに出来上がること」は言うまでもなく当然のことなのですが、それ自体をゴールにしてしまうと、開発者はリスク低減のために要件変更や追加をかたくなに拒み、発注者は「業務上必須」の錦の御旗をもって押し通す、対立構造になりがちです。
これでは良いプロジェクト運営は望むべくもなく、「共創」どころか「競争」になってしまいます。
プロジェクトの成否は、何よりもまず推進者がいかに意志を持って進めるかにかかっています。
この場合の意志とは、「今回のシステム導入によって、どんな変化を起こすのか」を明確に自覚し、それに向けてまい進する力、そのものです。
ユーザサイドは「来るべきシステムを利用した来るべき変化」、すなわち起こすべきイノベーションを明確にし、ステークホルダーに理解してもらう必要があります。
開発者サイドはそのイノベーションを十分に理解し、納期・予算を踏まえたうえで変化を起こすに最適な方法で貢献する責任があります。
この役割を双方が理解し、力を合わせることで初めて「共創」関係が生まれるのです。
共創を阻むシステム開発の構造的問題
ここまでの話は、何もクラウドコンピューティングに限ったものではありません。
これまでのオンプレミス型の開発でもまったく同様に起こりうる問題です。
しかし、機器調達や実装のリードタイムが長くなるこれまでの開発においては、ユーザーサイドの関与に限界がありました。
応答や処理の性能といったパフォーマンスや実際のアプリケーションの挙動は、初期段階では紙上でのシミュレーションで判断せざるを得ず、システムに対する経験値の差もあって、開発者との認識合意が容易ではなかったのです。
実装に関する、発注者と開発者の知識量の差は、いつでもシステム開発の大きな壁であり、お互いの不信感を生む土壌となってしまっています。
結果として、発注者サイドは「やりたいこと」をドキュメントに落とし込み、実現方法や表現方法を開発者サイドに（言葉は悪いですが）丸投げするという構図が少なからず生じていたはずです。
この方法論は「責任分解」という意味ではわかりやすくはありますが、発注者の前工程に対する開発者の後工程という分断構造になりがちです。
言ってみれば製品の製造工程の構造なので、どうしても達成目標が「納期どおりの完成」になりがちで、「製造者」である開発者は「要求仕様に対する品質の担保」のみに終始しがちです。
先に述べたシステム開発の獲得目標に照らし合わせれば、これは必要条件であって、十分条件にはなりえないはずなのですが。
また、発注者が必ずしも「そのシステムのユーザ」とは限らないという構造的な問題もあります。
開発者と対峙する発注者サイドの担当者は、情報システム部門であったり、企画部門であったりと、実運用部門の方ではないことが大半であると思います。
もちろん十二分にユーザ部門との検討を重ねて要求を出しているとは思いますが、開発者サイドから上がってきた機能仕様に対して、オペレーション的にどこまで許容できるかの評価を正確に判断することは難しい場合もあるでしょう。
そうなると、「現場の声」をある意味妄信せざるを得ず、結果として「起こすべきイノベーション」とは直接関係しない部分に、多くの時間と労力を費やすことになりかねません。
お互い歩み寄って「よりより仕組み」をともにつくりたいのはやまやまだけれど、このようにそれを難しくする構造的問題が存在していたことも確かなのです。
クラウド時代の共創関係
「クラウドコンピューティングは開発にイノベーションをもたらす」。
言葉は違えど意味的にはこういったことが、もういたるところで語られていると思います。
では、そのイノベーションとは何なのでしょうか。
コスト削減？
工期短縮？
改修への受容性？
どれも正しくはありますが、私が思う最大のイノベーションは、ユーザと開発者との距離を近づけ得るということです。
これまでのオンプレミスでの開発では、プロジェクトの最終盤、受け入れテストの段にならなければ見ることすらできなかった「実際に動くシステム」が、クラウドではごく初期段階からユーザにもアクセス可能になってきます。
IaaSや多くのPaaSでは、アプリケーションの構築工程は従前どおりになりますが、それでも処理性能や応答性能を「実見」することが可能になります。これは思うより大きな効果です。
ましてやSaaSにおいては、最初期段階からユーザが直接触れる画面そのものまで実見できるのです。
実際に触れて、想定しているオペレーションをシミュレートすることができるのですから、要件と仕様の乖離や不足の把握、どうアジャストするかを開発者と同じ目線で検討することが可能になってきます。
実際、SaaSとPaaSの中間とも言えるSalesforceの開発では、要件定義段階から実際の画面を構築し、メンバーのそろったミーティングの場でアジャストして行く方法がほとんどです。
成果物のイメージが共有できる環境が整うことで、極めて有益な「共創関係」が築けると実感しています。
ただ、この優れた環境を真の共創関係に導くためには、ユーザサイド、開発者サイド、双方の意識改革が必要です。
まずユーザサイドとしては、要求を「投げる」役割に終始することなく、自らもシステムを「つくっている」意識を持つこと。
実現の難易度や実装後のイメージはこれまでとは比較にならないくらい情報が得られるはずです。
その情報を得た上で、システム開発の獲得目標である「起こすべきイノベーション」を成し遂げるため、どこまでシステムに依拠し、どこまでオペレーションでカバーするか、それを常に考え、アジャストしながらプロジェクトに臨む必要があります。
開発者サイドとしては、品質担保に拘泥するのではなく、いかに「起こすべきイノベーション」に貢献しうるかという意識を持つこと。
クラウドプラットフォームが提供する機能については、既に品質担保が取られています。
これから求められるのは「バグを出さない」という意味の「品質」ではなく（もちろんコードが必要な部分では、これまでと変わらず重要であることは当然ですが）、実際に使われるシーンでの価値の高さです。
この意味での「品質」にこれまで以上にこだわる必要があり、かつ、それができる時間的余裕も確保できるはずなのです。
私が考えるクラウドの海の上を往く船上では、ユーザは乗客ではありません。
共に船を動かすパートナー、スポンサーでもありますから言ってみればオーナー船長でしょうか。
これまでよりも考えねばならぬこと、手を動かさねばならぬことは増えるかもしれません。
ただ、これまで、ビジネスの荒波の中、舵や船速を人手にゆだねて制御できないことに、フラストレーションを感じたことはなかったでしょうか。
窓のない船室から出て、自分で舵や船速を体感できる、それがクラウド時代の、ユーザにとっての開発なのです。
是非このパラダイムをご理解いただき、クラウドの海に乗り出していただきたいと思います。