makotan _at_ gmail dot com

BurixとSIと・・・

何故Burixを作ったのか、それと何故伝票モデルすらまったく公開しなかったのか・・・
まこたんが考えていた事。


Burixの開発では当たり前の様にOSSの恩恵を受けまくってる訳だし、BuriOSSだし・・・なのにBurixは門外不出だったのにはそれなりに計算があったんだよ〜編


OSSを使うと生産性は上がるし、ソースが見れるから何をやってる変わるし(ソースがあるから設計とか品質面もチェックできたりするし)ってな感じでOSS(特にSeasarのプロダクト群)の恩恵を受けまくってたんだけど、使っていくうちにもう一つ問題が判ってきた。
というのは・・・OSSに依存する限り他社でも同じレベルの生産性はたたき出せる様になる。これはSIサービスとして考えると、単価の安いエリア(国内でもね)の会社が絶対的に有利になる。


そんなこんなで悩んだ結果、他社に無い特徴を作り出す必要がある。
というかSIで他社に対して生産性で負けるのはNGなわけです。っていうのは品質面が良かったり、出来上がったアプリが使い易かったりしてもそれは契約時には見えない品質であって単純な○×をやると価格が高すぎるとその時点でダメ。
上流に特化するとなんだかんだで実績のある大手に負けるし、実装だけに特化は確実にコスト競争に巻き込まれる


しかもスタロジって会社は(半端無く優秀だけど)少人数っていう大変なハンデがあるので大規模なSIをやるとそれだけやっても四苦八苦する(経営面からもね)。なので、なるべく楽に実装というか徹底的にコストダウンに向けて変化せざるを得ないと。結局コストをいかに下げるのかを考えるのが自然な流れになってたと。


そんな流れでBuriをつくってBurixを作ってた時、SIとしてのイメージが何となく出来上がってきた。
要件定義〜リリースまでを担当するチームA(最少一人)と実装の細かいところを担当するチームB(最大はチームAと同じ位の人数)だけで上手く回るんじゃないかな〜って思った。そうすると、実装担当メンバー自体は普通のSIに比べて少人数で良くて要件定義〜リリースを担当できるメンバーを増やしていけば良いと、あとはツール類を開発してどんどん供給していけば、生産性は上がり続け、コストダウンでも他社に勝てる!!
そしてそのロールモデルはそのときのスタロジに全員揃ってた!ってことで実際にそんな感じになったんだけどね。設計〜実装〜テストで大幅に増員するより品質面でも良いんじゃないかな


なんてことを考える傍ら、もう一つの悩みが解決する事にも気がついた。
会社の特徴に成り得るキーコンポーネントは別のところで作られて普通に持って来れる物は、他の会社がそれを採用した時点で同じレベルの生産性をたたき出せるからダメで、必ず自社で開発すべきだし、外に出すなんてもってのほか
んで、どこに特徴を出すのかとどんなキーコンポーネントが必要かを考えるのがとっても重要。
#そこを考えつつ実現できてたからあの頃は面白かったなぁ〜
なので、OSSにするつもりも無かったしスタロジメンバー以外が触る事自体拒否してたんだけどね〜〜〜〜〜


まぁそんなこんなで伝票モデルが公開される事も無く数年たっちゃいましたとさ。
それにしても・・・このシリーズ続くのか!?