今更になって、ここの環境だとMarkdownの強調文字が反映されないことを知りました。見出しはちゃんとでるのに。
前回のまとまらない話の続きです。「自社のためにソフトウェアを書き、そのソフトウェアによって構築するシステムとそれが実現するサービスで付加価値を生む」、いわゆるWeb系のサービス企業が全盛とも言える中で、大雑把に言ってしまえば「顧客のためにシステムを構築、あるいはその支援をし対価を得る」従来型のビジネスにまだ魅力があると考える理由、の話でした。
基本的な「仕事」観
最初に務めた企業、その業種や業態によって、その人の「ビジネスの常識」がある程度規定されてしまうのは仕方のないところなのではないかと思います。私の場合は、21世紀に入ってすぐぐらいのタイミングで当時会計系と言われていた外資系コンサルティングファームに就職したので、以下の議論にはその影響が色濃く出ていると予想されます。（実家の天井クレーン工場の影響も多分にあるはずですけど）
当時、いわゆるITコンサルティングの業界ではSAPをはじめとするERPの導入が全盛を迎えていました。我々新人は、今がピークということは今後成長速度は鈍るし、そういうスキルを身につけることは本当に得なことなんだろうか、という悩みを広く共有していた気がします。私は実際のプロジェクトでは全然関係ない役割を負ったものの所属としてはSCM（サプライチェーンマネジメント）のチームだったので、そのコンセプトやツール・方法論などについても色々と教えてもらいました。
「基本的に技術を理解すればするほど単価も給料も低くなる」ということを実感し、結果的には3年に届かずに辞めてしまうかなり典型的な感じに駄目な若者だったので偉そうなことを言える立ち場ではないんですが、新人は新人なりに考えることもあります。当時の私は自分の職業とその環境について以下の様に考えていました。
- パッケージソフトウェアは社会的な分業である。多くの企業で共有できると規模の経済によりベンダに富が集中しやすくなる
- 業種、企業、部門、などのサイロや「壁」はどこにでもあるし、それを壊すことは基本的に善いこととされている。効率が上がる。抵抗の声は単なる既得権の主張に聞こえやすい
- 自分たちの仕事の仕方が「他社よりも優れている」と考えている人は非常に少ない。同程度に他社を知らないと言い出しづらい主張だから
- 自分達の従来の仕事の仕方が「低リスクである」と考えている人は非常に多い。精査されているかどうかは別として実績はあるし、今更否定されても困るところだから。でも通常、それが現状であること以上の根拠はない
- パッケージ化されている業務とシステムにもそのプロセスが「最善である」という根拠はない。すでに実装されていて他所でも動いている、というだけである
- 我々は宣教師である。客観的に最善である保証はないが、内部のロジックは整備されている。後は勢いで取り込めばお互いに幸せに近づく
これ以外にも、コンサルティングサービスの具体的な効能、などについても色々と考えていましたが、基本的な仕事観としてはこんな感じだったと思います。
要するに、皆がせっかく確保してきた「自分が快適に過ごすための他者との間のマージン」を取り上げて自分の手柄にするお仕事、というわけです。
ただ、どんなマージンを取り除くのか、どうやって取り除くのか、それ次第によっては、組織全体（あるいはエコシステム全体？）にとってはもちろんのこと、個々の部門や個人にとってもプラスになる。そこに職業としての価値があると考えていました。どうやって、のところはツールや手法だけでなく、理由、根拠付けも重要です。
どのマージンをどういう理由・手法で取り除くのか。例えば前述のSCMにしても、それまで注力してきた企業内の部門や業務プロセスの間のマージンではなく、企業間のマージンに手を入れる、それも国際的な競争の激化を背景に新しいツールによって実現される精度やスピードを活用する、という建て付けで盛り上がっていたように見えました。そして多くの方法論が、マージンを取り除くことの意味・価値をステークホルダー全員がしっかり理解し共有することが肝だと主張していました。そりゃ、ま、皆がそういう気持ちなら導入も楽ですよね。
OSSによって取り除かれたマージン
さて、ようやくオープンソースです。ソースコードの隠蔽や独占というのは、ベンダ・SIer・ユーザ企業という企業間の壁にもなるし、開発者と支援者との間の壁にもなる。オープンソースならその壁は始めからないし、皆がそのことを理解している（という期待が持ちやすい、くらいですか）。
話が前後してしまいましたが、あらゆる「壁」を取り除けばいいというものではない、というのはある種自明なことと考えています。組織の構成要素の1つとも言えますし、例えば壁がなさ過ぎると他部門からの膨大な作業依頼や割込的なコミュニケーションで担当者がパンクしてしまう、なんてこともよくある話です。壊すべき壁とそうでない壁がある、と。
これはあちこちでお話していますが、プロプライエタリのパッケージ製品のコンサルティングをやっていると、国内代理店（もしくは国内法人）のサポートスタッフ、技術スタッフ、海外にある本社のサポートスタッフ、開発エンジニア、と非常に層が厚いコミュニケーションパスをくぐり抜けないと「ソースコードレベルの問題解決」にまで到達できません。層の厚さはスピードの低さだけでなく信頼性の欠損に直結します。
もちろん、今では弊社でも製品サポートサービスをやっているので、サポートメンバーの所で以下にしっかりした防波堤を築くか、がビジネス的に重要であるということも十分理解しているつもりですが、プロジェクトという期限が切られた環境で直に顧客と接するコンサルタントの立ち場で、バックエンドとのこの距離感は辛いものがあります。OSSのビジネスではまずここが劇的に改善されています。従って、これは壊すべき壁であったと考えています。
言い換えると、ソフトウェアのソースコードを出発点として、それを実際のユーザ企業まで届けるまでに関与するITプロフェッショナル全員の間の壁は、少なくともソースコードの隠蔽や独占という意味では取り払うべきだという主張です。
この壁、マージンを壊して新しいやり方に移行していく過程には十分なビジネスがあると考えました。顧客サイドにとっても価格面やロックインフリーという意味で魅力があり、個々のエンジニアも雇用されている企業が独占できないレベルでキャリアが積めるというメリットがあり、他人の目を気にしたコードの品質の高さもなども含めて、根拠付けもばっちりです。何より、我々にはこの変化で失うプロプライエタリ型の収益もありませんでした。
以上が元々考えていた企業向けOSSビジネスを選んだ理由です。しかし、これだけだと（一時的に、かもしれないにせよ）他の選択肢を捨ててまで集中する理由としては乏しいかもしれません。もっと効率的に、もっとたくさんのマージンを取り上げる方法があるなら、そっちを選択すべきでは？ と。その問いかけに対しては、完全ではありませんが2つ回答があります。
- 実際にやってみるとOSSモデルが取り除いたマージンは上記の想定よりも大きかった
- スキル、経験、そして個性を活かせるポジションを求めた
また、長くなってしまったので、この辺で一旦終わります。続きは恐らく連休明けにでも
（文責 Ishii Akinori IT-Coordinator）
