発表から一部で非常に強い拒否反応と共に盛り上がっているのがこちらの「超高速開発コミュニティ爆誕」のお知らせです。
- 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 － Publickey
- プロフェッショナルたちの熱い想い：「超高速開発コミュニティ」を設立――日本が19位で黙っているわけにはいかない - ＠IT
超高速開発のコンセプト自体は僕もOSSのフレームワークを活用して自動生成の恩恵に授かっているので否定しません。開発自体が高速になることは歓迎すべきことです。
今回の件はポジショニングが「いつまでも手組みでコードを書いているから生産性が低く作業も多く品質も問題が出てしまう」への解決策という立ち位置のため、「そのツールがカバーできないことが多くて結局コードを書いているのですが」という生理的拒否反応が大きいようです。その辺は情報提供を増やすことで地道に解決していくしか無いでしょう。
僕のTwitterのタイムライン上では下記のような指摘が多く見られました。
- 銀の弾丸を探したい人にツールを売り込みたいだけじゃないのか。
- 非エンジニアがそのツールを作ったものを誰もメンテ出来ないのでは。
- 超高速開発で短納期になったら価格破壊が起きて誰得じゃないのか。
- ツールの都合に合わせてくれるクライアントがどれだけいるのか。
今回の発表で最も不明瞭だなぁと感じたのは、このツールを誰に売ってどんなメリットを享受してもらいIT業界自体の市場を活性化させるのか、ということでした。ターゲット設定がぼんやりしていて、それも違和感を増幅させてしまった一因のように思います。
例えば、こんなお悩みの会社さんがあるとします。
エンジニアを抱え込む余裕はないけれど、見積の管理がしたいしそれを全員で共有できる状態にしたい。でも業界特有の慣習や社内でのチェックフローを入れこみたいので既存のツールではうまくいかないしExcel配布も限界が・・・的な。やりたいことはそんな多くないけど非エンジニアでも使い方を覚えれば社内で使うシステムを作れるという売り方ならWin-Winが見込めそうです。それ、kintone - 今日からはじめる業務改善クラウド・サイボウズのクラウド型データベースアプリ「kintone」- cybozu.comで出来るよみたいな話なんですけどね。
もしも超高速開発ツールを同業(SI・ベンダー)に売り込むとするとノンプログラミングによる生産性向上と品質の均一化、という題目になると思います。これを目的に掲げた時に、超高速開発ツールの導入がどこまで受けいられるのかは正直かなり厳しいと思っています。これから見えてくることだとしても。
受託開発の場合は環境が各々バラバラですから、自分たちが提供する開発環境・動作環境の中で動かせるケースがそんなに多くありません。更地に新しく木を植えましょうなら通るでしょうが、街が出来上がった中でよっしゃスクラップアンドビルドだっていう理屈はなかなか通らないでしょう。顧客にも予算があり、予算を明らかに下回る場合は逆に懸念されてしまうものです。また、このツールの教育機関やこれを使った時どんなアプリが作れるのか、ある程度の習熟期間が必要なように思います。
また、車輪の再発明やめようぜ的に売ろうとしても、受託開発はどうしてもプロジェクト間でノウハウが閉じてしまいます。車輪の再発明をするから属人性が高く一定の品質が確保できない問題は、僕がSIerに所属していた10年前(2003年頃)からありました。属人性によって成果物の品質が安定しないのはSI側としては死活問題なので、ある程度の規模のSIerでは開発標準推進的な部隊が立ち上がって車輪の再発明から卒業しようと努力しているのですが、卒業できましたという話を僕は知りません。
エンタープライズの世界はインフラが複雑で動作環境が多岐にわたり全体像が見えにくいでしょうから、例外例外アンド例外からの連携連携アンド連携みたいな世界にアプリ開発ツールを持ち込んでも・・・という気もします。ミドル連携ならまだ理解出来ます。
これらの超高速開発ツールが要求→仕様→設計→実装に直接落とし込むという永遠の課題を解決しようとされている感はありますが、どこまで行けるものなのか・・・。
というわけで、エンプラ開発の救世主的立ち位置は難しいんじゃないか問題を上げました。次なる問題は、これらのツールを担いでくれるSIerは現状ほとんどいないんじゃないか問題です。
なぜかといえば、SI側にビジネスモデルの転換が求められる可能性が高いからです。これを担ぐと工数を減らす必要があります。高速にできるって言って工数変わらないってなんだよって絶対突っ込まれるでしょう。案件単価が激減することは必至の中で、如何に作らない開発モデルに沿った利益モデルを構築できるのかが先になると考えます。
単価が下がっても利益が出るようにするためには、案件案件に技術者を貼り付けることは出来ないので少人数で回せるようにスケールようにするしかありません。その転換を行わないと難しいでしょう。むしろ、このようなツールをバックエンドで担いで事業会社がWebサービス展開を行うみたいモデルのほうが面白いなぁと。
そして最後の問題は、仮に導入して開発生産性を極限まで高めても、オーダーメイドの実装部分の効率がよくなるだけでオーダー自体の決定が遅ければスピードが出ない問題です。開発生産性の高いツールを使っていることがSIerの営業力UPに寄与するのか、悩ましいところです。
僕のまわりには雑貨のメーカー・卸・小売業の経営者がたくさんいます。弊社が雑貨メーカー兼卸ですので。彼らは誰も開発生産性の高さは求めていません。ある意味それ以前の段階で、的確に自分たちの曖昧とした要件ビシっとを引き出して落としこんでくれること、そして最終的には自力でそれを出来るように導いてくれることを求めていました。自分たちが何にお金を突っ込んで得られるものは何なのかというのがわかるようでわからないのがシステムの商売。マーケティングの古典話であるじゃないですか。ドリルを買いたい顧客はドリルが欲しいのではなく、穴が欲しいからドリルを買うのだと。そこですよね。
スクラッチじゃないから安くて早くて安心だねという価値観は、このドリルは穴をあけるのに最高っス！っていう話と同じように思います。それを超えたストーリーをどう作っていくのか。悩ましいことですが必須課題だと思いました。
色々厳しいことを書きましたが、案件単価の下落傾向がとどまることを知らない中で新しいIT業界を作っていく・生き残っていくための未来像を作っていくことは業界全体の問題として捉えるべきです。顧客のビジネスに寄与するという目的はブレないわけですから、それにどう沿っていけばお互いがWin-Winなのか。僕もユーザー企業側として、考えを深めていきたいと思います。
