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

GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

「SIerでのキャリアパスを考える」というイベントに登壇しました

403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。

あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした&ありがとうございましたー!

15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。

何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問題提起した内容のまとめ的位置づけの資料になります。

僕が常々問題にしているのは「上流工程と下流工程が分断されていること」です。それが引き起こす弊害は大きく2つありまして、1つはスキルがつかないという弊害、もう1つは工程の狭間で振り回されてデスマが生み出されやすいという弊害です。前者に関して一言で言えば、この業界に限ったことじゃなく、言われた作業を決定権を与えられず行い続けて仕事が楽しくなるワケがないだろってことです。不確定なものに対してリスクを取るから成長に繋がります。ノーリスク、ノーリターン。当然の帰結。

後者については、要件定義で全てのシステム像を洗い出してから開発をすること自体は間違いではないけれど、工程が分断されてしまうと互いのフィードバックを得る術を無くしてしまうことを問題にしています。フィードバックが無いということは、後工程にしわ寄せがくることになります。しわ寄せが意味していることは、「要件定義や設計工程がずるずる引き延ばされたけれども、納期は変わらずに開発期間が圧縮される状態」のことです。この段階になると「要件を決めながら実装をし続ける」という自転車操業状態になります。そして、人海戦術を繰り出して複数ラインを同時並行で走らせようとします。2ヶ月で2人体制の工程を、6人で半月で行う体制でカバーしようとします。後者のやり方はチームワークがよほど確立されていないと破綻しますので、余計混迷を極めます。で、エンジニアが疲弊します。

ウォーターフォールがダメでアジャイルが良いという方法論の是非を問うのではなく、「プロジェクトの工程間のつじつまを合わせることが出来ないやり方で仕事してんじゃねーよ、それこそ最大最悪のリスクだろ」ということですね。複数の関心事を同時並行で足並みを揃えて1つの不定形な成果物を作るのは、工程間の縦と横のコミュニケーションが取れなかったら終わりです。

で、そもそも工程の分断が始まったかと言えばですね、正直僕もよくわからないんです。僕が社会に出る前から始まってたことなので。推測するには、システム屋が仕事があるけど人がいないシステム屋にエンジニアを派遣して稼ぐようになったから、ではないかなと思います。所謂オープン化に伴い技術の共通言語を得ることが出来たことで、皮肉にも技術者を派遣してもビジネスになるようになったのでは、と。昔のIT技術はハードウエア制御がメインでしたから、その技術はメーカーによってまちまちで他社にエンジニアを派遣することは意味の無い行いでしたから。この仮説違ってたらごめんなさい。

                • -

さてさて、工程の分断が悪なのならばそれをやめて設計から実装まで優秀なエンジニアが取り組めばいいじゃない、という主張が当然出てきます。SIerオワコン節に対するアンチテーゼとして必ずテーブルの上にのってきます。端的に言えばアジャイルでありプログラミングファーストです。しかし、それらの開発手法を現実のものにするのは大変難しい。その理由が人月見積もりにあります。

人月を見積もりに使う場合、システムの価格はこのような方程式で表現できます。「人月単価」×「期間」×「人数」=「価格」です。これらが全てかけ算になっていることが肝でして、生産性があがると価格が安くなってしまうんですね。期間の減少は最もリスクに繋がります。また、このモデルで利益を最大化する為には「高い単価で顧客から受注して、単価の低いシステム会社へ仕事を依頼する」ことですので、生産性を向上して少数精鋭で数をこなしていくモデルとの相性は最悪です。外注に出せないモデルを是とする一般的なSIerの経営陣は皆無なのではないでしょうか。

いいじゃんいいじゃん。要件固めてこれ以外やりませんって言えばいいじゃん。なんでそんな苦労して値段下げてやるのよ。期間と人数圧縮したらめっちゃリスクでしょ?おまえがやれるかわかんねぇだろ?どうすんの?

ま、こういう壁に僕もぶち当たりました。

この問題を真剣に考えておられる会社さんは、「一括で人月で見積もってシステム価格を決めるのはお互い不幸」という共通認識の元、成果報酬型のモデルであったり月額定額でお客様が納得いくまでシステムを作ります、というモデルに切り替えられています。そういう動きが際立つようになりました。しかし、そうは言っても「人月」という単位は成果物が不透明なサービスビジネスとの相性は最高なので、人月は正しく使われながら生き残っていくでしょう。

で、「いいじゃんいいじゃん」と言ってられない状況になりはじめました。それが、クラウドビジネスの台頭です。僕は当初クラウドに対して懐疑的でしたが、SalesForceのビジネスモデルがどんどん受け入れられているのを目の当たりにして、これは大きな変化がやってきていると感じるようになりました。御用聞き的人月見積もりでは、どう頑張っても「サインアップしたら使えますよ、カスタマイズも月々の料金の中で行えますよ」というビジネスに、同じ分野のシステム構築で勝つのは難しいです。2年ほど前、大手SIerが軒並み利益率を悪化させました。軒並みというのがポイントで、同業他社に仕事を取られているのならUP/DOWNが同業間であって然るべき。みんなが一律に下がっているのは、同業ではなく別の第三者に仕事が流れていると解釈するのが自然ではないでしょうか。

SaaS/PaaSのビジネスモデルとパッケージビジネスの何が一番違うのかと言えば、システムオーナーがユーザーにあるかそうでないか、ということではないでしょうか。もちろん何かを変更するごとにおカネを頂くのは正しい行いですし儲かりますが、何かを行うたびにコストが発生するのは精神衛生上あまりよろしくない。中小はそこで怖がってしまう。

ビジネスのルールが変わろうとしているなかで、その過渡期をどうやって乗り越えていくのか、と。

僕が差別化要因を出そうとするならば、工数見積もりという概念を超える為に、今までのソリューションを再度デザイン設計からやり直しOSSベースで焼き直してWebで複数のビジネス課題を解決できる運用を含めた自社完結型の新サービスを作るという方向に向かい、クラウドのうまみをうまく融合させてサービスとオーダーメイドの垣根を融合させていけたら、と考えます。色んなユーザ企業とアライアンスを組みながら。

        • -

・・・・というのを15分に圧縮して話すのは難しいですねw

僕は受託開発が好きですし、受託開発なくしてIT産業は成り立ちません。Web系でも受託開発は活発に行われています。サービスやってる会社に移ったけど現状維持が強くなりSIの頃のダイナミックさを求めてSIerに戻る人もいます。Webに行ってみたけど24H/365dayのB to Cビジネスの難しさや厳しさについていけなくなり、SIに戻ってきた人もいます。SI/Webの二元論で解決できることは、ほとんどないってことですね。

一番大切なことは「自分が使っていて楽しい、自分が作っていて楽しい」そういうサービスなりシステムなりに触れて、どのような問題解決をITで行うことが自己実現に繋がるのかを見いだすことだと思います。それがサービスという形で提供されるのか、オーダーメイドのシステムで提供されるのかは、あまり問題になりません。

では、またどこかのイベントでお会いしましょう。