June 12, 2007
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。
しかし結構、難しいですよね、と、ついつい言ってしまう。
理由のコアは、下記エントリーに書いてあった。
「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む
１．受託開発では「技術」が蓄積しない
２．受託開発では「人材」が蓄積しない
３．受託開発では「資金」が蓄積しない
技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。
（受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。）
一番重要なのは、キャッシュフローが安定しないところではないだろうか。
サービスと受託の大きな違いは、
「受託は技術を売る仕事」
「サービスは、文字通りサービスを売る仕事」
である。
サービスは、お客様がつくと継続的に収入が入ってくるため、受託では得られない収入の安定が得られる。ましてWebサーバーがお金を稼いでくれるので、うまく回ると非常においしい。
しかし同時に、サービスは作ったからと言って売れるわけではないし、収入が入ってくることが確約されているわけではない。何より、自分たちがいくら頑張っても、儲からないものは儲からない。
ここに対する我慢やチャレンジができるかどうか？が重要ではないだろうか。
何せ比較対象である受託は、うまくこなせば100%の見積額が入金されることが決まっているわけだから、会社継続に対しては、受託の収入も重要だと思う。（って、簡単そうに書いてるけど営業の人が頑張ってるんだけどね）
売り上げに対するリスクはサービスの方が大きい。これはリスクとリターンのトレードオフと言えよう。
特に会社が大きくなってしまったり、出資されてしまって売り上げ達成がmustになっている会社では、十分に儲かっていないと、この部分でチャレンジするのはなかなか難しいのではないだろうか。
このチャレンジが難しいとどうなるか？
ありがちなパターン
１．決算時期に、来月の売り上げをなんとかして今月あげられないか？をしてしまう（工数の前売り）
２．受託とサービス開発を平行して行おうとする。
来月の工数の前売りは致命的である、その売り上げ要求ペースで回さなきゃいけない会社にサービスの開発はまず無理だと思う。
当然、前売りしてしまって、本来当月に稼ぐはずの工数は、次回の決算の前に不足分として露呈する。それなんて自転車操業？
後者の受託とサービスの同時開発の問題は、短距離のタスクと長距離のタスクが並行したときに、そのプライオリティ付けは非常に難しいという問題にあらわれる。
長距離のタスクを行っているところに、短距離のタスクが入ってきたときに、「今は忙しいからできない」と言ったとする。
当然、営業からすると、「では、いつなら、この作業はできますか？」という質問をするだろう。
この質問への適切な回答は難しい。
短距離タスク vs 長距離のタスクであるならば、「いつでもできますよ」か、もしくは「まったくやらない」かのどちらかしか選択肢がない。少々スケジュールを遅らせたところで長距離タスクのどこかの時間を奪うだけであれば、今やっても１週間後でも全然、関係ないからだ。
しかし問題なのは、こういうシチュエーションが、当然一回で終わるわけはなく、割り込み仕事が多数入ってくる。求めるお客様がいれば、それを無視することはできない。
なので、これをやらざるを得ない職場においては、長距離の仕事はどんどん遅れる。
大事なのは、長距離の仕事をさせたい人に、短距離仕事のアサインを絶対に行わないことだと僕は思う。
お客様の仕事を断れという話ではない。受託絡みであれば、他社では簡単に代替が効かない仕事だから、現実的に断るという選択はない。
矛盾。だから難しい。
2007-06-08 コムスンとグーグルに見る理念のウソ・ホント
経営理念の浸透度、実践度を考える際に、最もシンプルなものは、「経営理念の為に、どれだけの利益（もっと分かりやすく言うならば現金）を犠牲にする覚悟」が実行できているかという視点ではなかろうか？この「利益よりも重要な何か」の実践が、その「何か」に対する社長の本気度を社員は感じ取り、それを実行しようとするのではないのだろうか？
社員が本気度をどこまで感じられるか？はともかく、
受託にどっぷり使っている会社が、サービスを開発にするには、如何にその開発体制を整えられるか？において、覚悟が絶対に必要だと思う。
それこそサービス開発のための会社を一つ作った方が良いんじゃないかと思うぐらいだ。
「タスクを完全に分けろ」とは逆のケースで、もし同じオフィスで、ちょっと前まで同じチームだった受託チームがデスマーチに陥ってしまったとしたら、のうのうと長距離走のサービス開発仕事なんてやってられない。できれば、サービス開発チームみんなで火を消しに行きたいと思うハズだ。
しかしそれだと開発が遅れてしまうので本来はやってはいけないこと。でも、もし受託チームを見殺しにしたとしたら、それはマネジメント陣に対して、サービス開発チームは大きな不満に思うことであろう。（少なくとも僕は嫌だ。）
それはそれで難しい話だ。
ここで問題になるのは、受託とサービスが同じ技術でできているから、簡単にビジネスモデルを拡張できるのではないか？という甘い考えではないかと思う。
現場は、それぞれに求められる時間幅が違うことによる混乱に陥り、顧客優先の元、本当に実現せねばならないことがどんどん後回しになっていく。
おそらくサービスと受託を両立できる会社は、会社が小さいうちに、最初からサービスの実現のために受託をやっているような企業と、新規事業のために子会社を作ってリソースを切り離してもやっていけるぐらい余裕がある企業のどちらかではないだろうか。
受託が板についてしまった余力無き中小ベンチャーには、かなり厳しい戦いを強いられることになるだろう。
（そう考えると、最初にいた会社では、２年目３年目で新規製品開発をやらせてもらったんだけど、それ自体がとてもリスキーかつ幸せなことだったのかもしれないな、と、今更思ったり。その割には、開発したら速効辞めてしまってすいません。あの頃は若かった・・・。ただ、新製品開発終了後の先が見えなかったのは事実なので、そこんところの対話が出来てたら辞めなくても良かったかもなぁ。ただ、マネジメントとして良かったのは、僕らを抜擢してくれた上の上の方にいた専務であって、直属の上司ではなかったということなのかな。直属の上司も尊敬してたけど、その辺は同じサラリーマン。だから「直属の上司」へのマネジメントもまた重要。というか直属の上司層は、僕らが新製品の開発をするのには反対していたそうだし(w ）