2006-08-18

低コストで中小ITを進化させる方法

利益率の低い「受託」と「人投げ(但しこれはリスクも少ない)」から脱却するには、自社商品・パッケージを!!…と思いたい。

が、そんなリスクを負えるようならみんなとっくに手を出している訳です。

いくら「Ruby on Railsで速攻ベータ版リリース出来るよ!」といってもそううまくいきはしない。RoRにしろPrototype等のJavaScriptフレームワークにしろ、それはあくまで手段なのだから。


ではアプローチを変えて、将来設計というか理想地を考えてみる。

コストが安く、生産性が高く、社員が生き生きしていて、営業が楽で、スキルの高い人材が来る!

おお!これは文句ない理想だわ。

では、理想を逆算で具体化してみるにはどうするか。

  • 開発コストを下げる
モダンフレームワークの導入
OpenSouce系のミドルウェア活用
営業の類似案件獲得努力による基礎の共通化
同じく独自機能のプラグイン化(モジュール化)

  • 共同作業への最適化
ノウレッジデータベース
ソースライブラリ
→コメントやドキュメント、組み込みTipsなどの記述ガイドライン
Ruby/RoRやPhytonのようなストリクトな言語へのシフト
→記述の個人差を少なくし、分散化を視野に置く

  • モチベーションを高める
モダンテクノロジを扱う会社・仕事である自負とプライド
繰り返し作業の排除(OpenSauce/社内ライブラリ)


うーむ、昨日のエントリじゃないが、我田引水の感が無くもないw


※営業と企業イメージ(人材確保)は、話が混乱するので後日また。ヒントだけあげるなら、
  • Webからの集客・問い合わせを増やす
  • OSSへのコミットメント


たとえばRoRを導入してそんなに劇的に作業負荷が下がるわけでもない。
どうせドキュメント共有や社内ガイドラインなんて守られも使われもしないし…。

そうなんだけど、ここは運用の意思統一と根気です。
便利なことを判るためには、数ヶ月まじめに運用しなきゃだめですよ。

そのコストは、まぁ、一見ゼロじゃないですか。ココが説得の肝。

◆営業さんには、最近東京ではいっぱい落ちてるRoRやAjax案件(例えばプロトタイプ品や仕様確認案件など多い)を拾ってもらい、小さい案件を数こなす。これはコストゼロ

◆要件定義は、しばらくその手の何件は自分が必ず顔を出して、我田引水しながらどこが共通でどこが拡張で、何が類似拡張かをまとめておく。これはコストは移動日と僕の人件費か

◆できれば、ここからの工程管理の過程でドキュメント整備だのソースライブラリだのをコントロールしたいところ。ここは各PMの意識次第だなぁ。コストは若干だがかかる

はい。
ここでこのいかさまに気づいた人は鋭いか、ちゃんとした仕事をしているSEです。




人(お客)の金で自社パッケージが9割がた出来上がります。
※ちゃんとしたSEさんへ---これで感心する会社が結構あるんですよ!まじで。

設計が巧ければ、拡張機能のカスタマイズと称して案件数をこなすほどにコピペの濡れ手に粟になります。

ところで
個人的意見ですが、独立サービスを想定しています。
僕はこういう案件は、まずASPサービスにはしません。

なぜか。

お客に合わせたカスタマイズが利かない。だから機能が汎用化する。使い勝手が悪い。などなど。
じゃあ、チェックボックスで機能が追加できる形プラグイン式にしたらどうか?
とんでもない。絶対にプログラムが大きくなりすぎてソースがスパゲッティ化する。断言するが、絶対にそうなる。

ここは少し手間でも、毎回、基礎+拡張+開発というスタイルで、いちいち独立したサービスを立てましょう。

  • 鈍重なシステムを抱えたら、保守コスト・カスタマイズコストが雪達磨式に増える。利益率のグラフは放物線型であって、どんどん上昇率が鈍化するモデルなんです。

  • 基礎+拡張+開発型なら、案件をこなすごとに枯れてきて、慣れてきて、コピペが通用するようになるので、利益率の曲線は指数関数型になるモデルです。
※あくまでこの例は一例だし、我田引水がMax巧くいった場合のはなし。


さて、駆け足だけど、目標値と行動指針がおぼろげに出来てきた。

まだまだ先は長い。
品質管理や検証システムの問題もあるし、社内系のライブラリDBは?運用マニュアルの工夫は?中小ITにとっての工程管理とは?などなど問題山積みですな。

しばらくはネタが付きませんw
喜ばしいんだか何なんだか。