システムイニシアティブ協会での発表 - ユーザーとベンダーの新しいパートナーシップを考える

さった1月16日に催されたシステムイニシアティブ協会の第34回研究会(例会)は「2014年のシステムイニシアティブ ~新しいパートナーシップの構築に向けて~」というテーマでした。今回は超高速開発コミュニティとのコラボレーションとなり、コミュニティを代表して私も発表させていただきました。
http://system-initiative.com/HTML/workshop.34.html

f:id:ynie:20140123082146j:plain
(写真提供:片貝さん。)

当日は年初の会ということもあったのでしょうが、60名を超える出席となり会場は満席でした。

これまでのパートナーシップの限界と、ユーザー、ベンダーの立ち位置

このテーマの主旨について、昨年末にシステムイニシアティブ協会の木内理事長から次のようなお話をいただきました。

活動4年目に入る2014年は、ユーザーもシステムイニシアティブであるなら、ベンダーもシステムイニシアティブであって欲しいという考えから、双方が役割をしっかり果たす本来のパートナーシップを求めていきたいと思います。ユーザーの主体性の表れとして内製も一つの手段ですが、内製だけで片付くものではありません。良きパートナーとの協働も必要です。優れたユーザーが優れたベンダーと協働する姿を求めていきたいと思います。

「新しいパートナーシップ」を超高速開発コミュニティの視点でどうまとめるか。思案の末に、4つの切り口で整理してみました。

  • 当事者意識の欠如
  • 開発のアプローチ
  • ビジネスモデルの違い
  • 予算

表形式でまとめると次のようになります。

ユーザー ベンダー
当事者意識の欠如 業務改革に踏み込めない。 業務改革に踏み込めない。
開発のアプローチ 仕様は固まらない。 はじめに仕様ありき。
ビジネスモデルの違い IT活用で利益確保、経費削減を目指す。 開発工期が伸びるほど儲かる。
予算 予算は年々、削減の一途。 人月単価競争で勝負。工数を減らすことは難色。

実は双方とも業務改革に踏み込んでいないのではないか、とお話しました。ユーザーにとって業務改革は痛みを伴いますし、ベンダーも下手に首を突っ込むとかえって煙たがられます。しかしその結果として IT は導入しても活用しているとは言い難い状態になってしまいました。

システムイニシアティブをユーザーの手に!

システムの主導権(イニシアティブ)をユーザーの手に取り戻そうというのが、この協会の立ち位置です。それは過度のベンダー依存 - 丸投げ - から脱却することを目指しています。先の4つの視点について整理すると次のようになるでしょうか。

ユーザーのイニシアティブ ベンダーに期待すること
当事者意識の欠如 ユーザーが主体的に業務改革を先導する。 ユーザーが主体的に業務改革を先導することを支援してほしい。
開発のアプローチ 仕様は固まらないことを前提に開発する。 仕様は固まらないことを前提に開発を進めることを受け入れてほしい。
ビジネスモデルの違い 丸投げを脱して、優先度をつけた開発に変える。 丸投げを脱して、優先度をつけた開発に変えたとき、工数で売上を立てないでも付き合ってほしい。
予算 予算削減の中、ユーザーができることはユーザー自身で取り組む。 ユーザーができることはユーザー自身で取り組むことを支援してほしい。

ベンダーの役割が変わる

システムイニシアティブをユーザーがもつ、という流れにおいて、ベンダーに期待することは様変わりします。

  • 業務改革には現場の抵抗が伴うことはわかっている。ユーザーの経営陣・情報システム部門と一緒になって汗を流すことができるSEを育成し、ユーザーと恊働するようにする。
  • 手戻りを受け入れる、とは、できるだけプログラムを書かない開発を意識すること。書けば書くほど、手戻りは受け入れ難くなる。
  • 「プロジェクト予算 = 人月単価 x 工数」という式において工数を減らす、代わりに人月単価を上げることを認めていただける付加価値を提案する。
  • ユーザーの内製を成功させるノウハウを提供することもビジネスとして捉える。

私はユーザーが本気でそれを望むなら、応えようとするベンダーは必ず登場するはずだ、と発言しました。市場のあるところに技術は育ちます。ユーザーの意識が変わることで、ベンダーも変わる(変わらざるをえない)のです。

超高速開発コミュニティとの関連性

このような流れの中で、超高速開発コミュニティは何を目指すのかを明らかにします。コミュニティ内にはさまざまなツールベンダーやメソドロジー提唱者がいらっしゃいます。どれがベストか、というのはコミュニティが決めることではありません。しかしコミュニティ内でほぼ共通の土台となっているのが、労働集約型産業からの脱却です。

f:id:ynie:20140123082227g:plain

超高速開発の捉え方は人によってさまざまですが、労働集約型でないアプローチを目指す、というのがコミュニティの方向性と考えています。関わる人が少なくなればユーザーとベンダーの距離は近づき、余分な管理コストやコミュニケーションロスも減り、恊働という本質的な枠組みを実現しやすくなります。

f:id:ynie:20140123082232g:plain

ユーザーにとっての超高速開発のリスク

超高速開発とは、ユーザーニーズを実現する手段の一つですが、これがすべてではありません。そして万能でもありません。
超高速開発によるリスクはどういうものかもお話しました。

生産性が高い、とはどういうことか

プログラムを書かないほど生産性が高くなります。これは業務仕様をツールやメソドロジが提供する「パターン(部品)」に合わせるということです。過去から何度も議論されていますが、適度な粒度の、使いやすいパターン(部品)とはどうあるべきか、はまだ発展途上です。

現場との調整が必要なことは変わらない

画面の操作性に関する要望がもっとも多く、かつ、もっとも工数が費やされるテーマです。ツールの限界を超えた要望の受け入れは、実現コストが跳ね上がります。どこかで線引きをすることが求められます。

リスクヘッジの考え方

ユーザーにとって、丸投げがリスクヘッジにつながるという思想が残るかぎり、ベンダーとの関係を変えることは難しいです。簡単な仕様書だけを渡して、これをつくってくれる最も安いベンダーと契約し、契約後の仕様変更でも予算追加はないことを飲んでもらうのがリスクヘッジだ、という考え方は誰も幸せにならないと考えています。超高速開発ツールは、その関係性を維持するものではありません。

理想の関係(案)

最後に私がイメージする理想の関係をまとめました。

  • ユーザーがリスクもメリットも享受する。イニシアティブをとることでリスクも発生するがメリットも大きい。
  • ベンダーは頭数ではなくノウハウを提供するようにする。平均的スキルをもった大量生産型の開発者1,000名より、開発生産性10倍のスキルをもった開発者100名を提供することを目指す。
  • 開発と運用を一体で捉える。納期までにつくって、あとは運用という発想から、業務の成長や変化にあわせて常に開発を継続する体制を目指す。

実際の適用事例

ここまでが私の発表でした。その後、ブックオフコーポレーション様と市進ホールディングス様の事例(実際のユーザー視点での発表)があり、ツールを使った自社開発の体験談が語られました。両社とも満足度が高く、これからの開発計画も自信に裏打ちされたものでした。予算規模も驚くほど削減されています。またツールへの過度の依存ということもなく、使えるものを徹底して使う、という冷静な視点で活用されていました。

まとめ - 超高速開発コミュニティの状況

年が明けて、超高速開発コミュニティへの入会申込ペースが急激に伸びています。特にユーザー企業からの申込や問合せが多いです。これは私たちにとって朗報です。ユーザーが動けば、業界が変わります。超高速開発という視点を取り入れることで閉塞状況に陥っている感のあったエンタープライズ開発分野に新しい可能性が語られるのであれば、コミュニティの存在意義があります。

今回はシステムイニシアティブ協会様に大変お世話になりました。今後も、さまざまな外部コミュニティに出かけていってお話ができればと思っています。是非ともお声掛けください。もとい、こちらから提案に伺いますので、どうぞよろしくお願いします。

おまけ - 今後の予定

2月10日(月)は、超高速開発コミュニティ主催「GeneXus, Wagby, Web Performer 徹底比較 – 自動生成ツールの効果的な使い方」セミナーがあります。仕様書からアプリケーション自動生成といっても、この3つのツールはいずれもアプローチが異なります。Wagbyについては当日、私が語ります!

2月15日(土)は、名古屋でジェネレーティブ・プログラミングの勉強会があります。日本でこのテーマの勉強会が催されるのは珍しいです。(私が知らないだけ?)当日は大先輩の知見が披露される中、私もWagbyの話をしてきます。興味のある方、是非ともご参加ください!