連休が間に入ったので自分でも何を書きたかったのか曖昧になってきた感がありますが、なんとか締めまでは持っていきたいです。
OSSビジネスがもたらす経済合理性が事前の想像よりも大きかった、ということと、楽しい仕事をしたいですよね、という話をしかかって中断していたような記憶があります。ただ、読んでくれた人から個別に質問をもらったりもしたので、まずはそのフォローから。
マージンってなに？
それこそ新人のころに、ベンチャーなどの勢いがある若い組織と、歴史のある組織の違いとして、個々のメンバーの仕事の守備範囲にフォーカスした記事を読みました。歴史の長い組織にいる人の方が「自分の仕事」を狭く評価する傾向があり、人と人の間にスキが生まれてしまう。そうした如何にも縦割りな、柔軟性のなさが組織の老朽化の典型的な弊害である、とかなんとか。「明確に自分に責任があると定められていること以外のこと」を実行に移して、もし失敗したらペナルティだけは間違いなく自分に降りかかる、という環境では人は保守的に振る舞わざるを得なくなります。
自分の仕事はこれだけ、そこに含まれないものは他の人の仕事、という線引きができれば、対象に含まれる仕事の効率はもしかするとあがるかもしれませんし、働く人としてのストレスも少ないかもしれませんが、多くの場合より広い視座から見れば効率が悪いセクショナリズムに見えます。どこの部門の仕事の定義にも含まれないものが発生した場合に、非常に効率の悪い例外対応をすることになるとか、あるいは大した件数がない事象なのに専用の要員を要求されるとか、ってことですね。そういうものを前の記事ではざっくりとマージンと呼んでいました。
なので、マージンを取り除く、というのは、ある意味では当事者にリスクを取ってもらうということでもありそうです。
OSSで取り除けるマージン
前の記事では、開発元、SIサービス提供者、お客さんなどの特定の技術を顧客に届けるまでの直線的な取引／サービスの流れの中でのマージンの説明をしました。これについては、OSSコンサルティング事業を始める時点でも意識していた点です。「ソースが見せて貰えるなら（パートナーとして）もっと良い仕事ができる」ということですね。
ただ、現実にこのジャンルの仕事をしてみると、例えばAlfrescoやLiferayなどの特定の製品だけでなく、直接パートナーシップを持っていない他のオープンソース技術との間の垣根の低さにも意味があるということに気がつきました。プロプライエタリの製品とのシステム連携を考えるとSDK評価版の入手であるとかNDAの締結であるとかっていうステップが間に入ります。とりあえず試してみる、ということがやりづらい。性格的なところも多分にあると思いますが、トライアルの申込みをしてしまうと相手先の営業さんにもプロスペクトとして認識されることになってしまう、というのもなんとなく心理的なハードルをあげます。どのくらい簡単にできるのかを実験したいのに、ちゃんとできないと申し訳ないような気がしてしまう、という。
ことマージンという考え方からすれば、相手側の会社やコミュニティから連携部分の実装をしてもらって、そちらでメンテナンスまでしてもらえれば色々と楽にメリットだけ享受できる、という下心をお互いに持っていてもおかしくない状況でもあるわけです。それも含めてこっそり自由にやらせて欲しい。そういう仕事のしやすさ、というのは、後で成果にも跳ね返ってくるんじゃないかと思っています。
楽しい仕事をしたい
自分達の技能を効率良く使って、できれば人から喜ばれる仕事をしたい。そう考えると、衛生要因扱いという、かSLAが高いところにあるビジネスはたとえ売上が上げやすかったとしても、今ひとつ気持ちがもりあがりません。例えばインフラのお仕事であればお客様からは使えて当然に見えているので、あまり喜んで貰える機会がないと予想されます。その場合は、効率を上げるツールを作るとか、っていう方向で誰かが喜ぶようにするところから考える必要があります。
そう考えると、エンタープライズ系の製品での利益の源泉として「ミッションクリティカル」というキーワードがありますが、それはちょっと面白くない。ミッションクリティカルな用途にも使えるような設計のソフトウェアを産み出すことには関心が持てますが、システム全体としての可用性を高めるためにはハードウェアから運用チームの体制まで多岐にわたって気を配りリソースを配置する必要があるので、そのこと自体で付加価値を生むのは小さいチーム向きの仕事ではありません。
マージンを取り除いて付加価値を生むことがリスクを取ることと表裏一体なのであれば、他の人達が自分達よりも怖がっているようなリスクであるのが一番です。多岐にわたるサービス領域のどこかでミスが発生しても全体で取り戻せる！というのは大きな組織のビジネスです。機動的にあちこちのまだ実績や日本語資料がない技術・製品を評価してみたり、通常のSIサービスの域を少しだけ踏み越えて製品の改善を行ったり、ということで既存のプレイヤよりも大きな風呂敷を広げて、コミットメントの部分で差をつけることなら小さいチームでもできます。OSSにしても昨今の技術Blogなどでの情報公開の文化も、小さいチームであってもスキルが蓄積しているということを示すための武器を与えてくれます。なので、なるべくそういう方面で付加価値を出していきたいと考えて、今の事業ドメインに落ち着いてきたわけです。
OSSで、サポートサービスをサブスクリプション（購読）型で売ります、というビジネスをしているということもありますが、元々やっていたコンサルティングサービスの領域でも、度々「日本人はサービスに対価を払う文化を持っていない」という壁（？）にぶつかります。これは多くの場合はただの愚痴として語られる言葉です。商品としてのサービスを上手く説明したりパッケージ化したりすることに失敗しているとか、（海外でも恐らくは同程度の困難を伴っていると思われる）市場の育成がまだ十分行えていない、とかってのが実態に近いことがほとんどだと思います。（いや、それがやりにくいからこういう文言がでてくるんだよ、っていう気持ちは非常によくわかるんですが）
生意気なことを言えば、こういう愚痴がある程度の説得力を持つ環境というのは、それだけ既存のプレイヤに力がないということです。実質的な参入障壁が低い。うちのような小さい会社でも実績を積むだけのチャンスを与えられてきましたし、小さい会社としては（9年目という）それなりのボリュームを持つ実績も示せるようになったので、今のところ、「仕事は楽しい」と言って嘘ではない感じです。
何がままならなかったかというと
このシリーズの最初に引用した弊社杉本の記事で、Railsベースでプロダクトを作ったらWindowsユーザ向けのインストーラの構成がやたら大変だった、という話です。エンジニアが扱う限りにおいては、細かい環境の違いとか例外ケースに応じたマニュアルとかっていう部分にかかる工数を省略をして、ソフトウェアそのものの強化や品質改善に力を注げるはずです。しかし、我々が取り扱ってる領域は企業ユースですし、その情報システム部門の人達にこちら側へ歩み寄ってもらうことでより効率的な分業を実現したいわけなので、今回のようにハードルを下げるための工数も取らないわけにはいかない。ビジネスドメインの選定についてはある程度自覚的だったつもりですが、実際に工数の割り振りをしていく中ではもっと攻める領域にメンバーのリソースを割り振ることができればな、、、とついつい思ってしまいますよね、という身も蓋もない話を簡単にするつもりでした。
結局まとまらなかったな・・・
（文責 Ishii Akinori IT-Coordinator）
