2013年4月26日金曜日

求める人物像など

前回の記事が、結局ハードルを上げてしまっている、というもっともなご指摘してきをいくつか頂いてしまいましたので、さっそく続編を。頑張ってハードルを下げていきたいと思います。あ、下げ始める前に、ハードルの高さという意味でのネガティヴ要素を吐き出してしまうとすると、今現在の技術要員のほとんどが東大か京大の出身です。例外はありますが、個人始めたAndroidアプリのダウンロードが50万を超えた、とかっていうフランス人です。でも、学歴は別に条件ではないので、例外っていう言い方は不適切かもしれませんね。



よし、ハードルを下げる時がきました。(繰り返しますが、別に学歴やコミュニティ活動の実績は初めから求人の条件に入っていないので、それをもってハードルというのは本来おかしいんですけどね)



求める人物像



例によって、スキルや実績の話と性格や姿勢の話があると思うんですが、まずはより具体的な直近で求めているスキルの話から。



期待するスキル



今弊社で開発中の2つの製品CMISSnycとNemakiWareのうち、すぐにも人員を増強したいのはNemakiWareの方です。これはいわゆるNoSQL系の中でもドキュメントDBといわれるCouchDBを利用する文書管理のためのソフトウェアで、本体部分はJavaで作っています。検索はSolrを使っています。UI部分はRailsで作っています。CouchDBの都合なども考えると、言語としてはJavaかJavaScriptかRubyができれば良いということになるわけですね。(ハードル下げてますよアピールが鼻につく文体になりがちで、注意が必要な気がしてきました)



ただ、この製品はOASIS標準規格であるCMISに準拠するというコンセプトがあるため、この規格についての理解が求められます。おそらく日本国内にこの規格に明るい人材なんて数える程しかいないはずなので、これは参画の時点で求めるべきスキル・知識だとは考えていません。ただ、英語でこの規格についての文書を読み、理解を深め、場合によっては規格策定の当事者たちに質問して疑問を解消する、というようなことが求められる可能性はあります。(また、上がってきてしまいました)



ということで、新メンバーの方には、実際にはCMISについての理解度の要求水準が比較的に低いRails製のUIのところから着手してもらうことになるのではないかと思います。パッケージ製品として長期にわたって展開していくので、メンテナンス性や拡張性を考えた設計や実装をしていきたいですし、オープンソース製品なのでその成果物のほとんどは衆目にさらされることになります。このあたりを引き受けられるかどうかがポイントになるのではないかと思います。その点で信頼できる人であれば、たとえば仕事でRailsを使ったことがなくても問題ないくらいだと考えています。



スキルや経験以外の話



この場では副社長権限で私の好みについてだけ書かせて頂きます。実際にはチームワークなので、他のメンバーの好みはここに書かれているものとは異なりますし、採用の条件にはなりづらいと思いますが、少なくとも候補者の方の視点から私の好みを観察できることに意味はあると思うので。



色々考えたのですが、「自分のことを頭が良いと思っている」ということに尽きる気がしています。より正確に表現すると、「文脈・分野・問題によっては他の人より自分が考えた方が良い結果に繋がる(こともある)、というステートメントを引き受けることができる」ということなんですが、言葉が増えた割には明確にはなっていないかもしれませんね。要するに考えることをすべて他人任せにされてしまうととても困る、ということです。そして、自分で考えるという選択肢を主体的にとれるのは、そういう自負がある人だけだというのが私の考えです。



念のために書いておきますが、うちのメンバーが全員自分が一番賢いと思っている鼻持ちならない秀才タイプということではないです。むしろ逆と言っても良いくらいです。あえて当てはまりそうなのは私くらいじゃないかと思います。そういう思い上がりを表に出しても良いことはないわけですからね。



くどくなりますが、うちのメンバーは見るからに優秀です。特に技術部門のリーダーは(本人はありとあらゆる隙間を見つけて否定してきますが)相対する側が圧力を感じるくらいに優秀です。そのため新しく参画する人は、自分よりも他のメンバーに判断を委ねた方が組織全体のためになる、と考えてしまう可能性が高いわけです。特に自分がまだ不慣れな状況である、ということを勘案すれば、その選択はなかなか責められるものではありません。しかし、我々の業界では、考える部分を他人に依存し続けることで楽しく仕事ができることはほとんどないと思います。個別に正しい割り切りを積み上げていくと、結果みんなが不幸になってしまう。



弊社のような環境では、優秀な仕事仲間を仮想的な競合(敵)とみなすことなく、あくまで助言者として利用し、自分で考えて仕事を進めていく必要があります。そのためには、現場感覚としてはリスキーに思えても、自分から担当範囲を広げていくしかないわけです。その時の支えになるのが、これまでに積み上げた成功体験です。自分が考えたことで良い結果を生んだという体験がない人には、なかなかそのリスクを引き受けることができないのではないかと思います。だからこそ、私は「自分のことを頭がよいと思っている」人を求めているわけです。(東大卒の人達などは立場上普段から「自分はバカですから」という発言を封じられているという意味で、この基準をクリアしやすいという構造があると思います)



なかなかうまく表現できませんでしたが、個人の好みを書き連ねるのはここまでにします。もし、今後ここを読んだ候補者の方とお話をする機会が持てたとしたら、その時個別にフォローしたいと思います。



会社の特徴



今、イノベーションの主戦場がWeb系のサービス運営会社に移ってしまい、企業向けソフトウェアの業界はその魅力を失っていると言われています。我々は、その陰りが見え始めたと言われる業界において、もっとも活気があると思われる領域(の一つ)をホームとしています。



情報システム分野、特にソフトウェアについては初期投資があまり必要ではないため、新規事業者が戦い易い領域です。つまり、混沌とした競争環境が続く戦場です。その中で長期的に生き残る為には、何らかの競争優位な性質を見極め、そこに注力するのが良い選択だと考えられます。そこで我々が選んだのが「オープンソース」です。



これまでの仕事



今「オープンソース」はある特定の文脈においては、「ソーシャル・モバイル・クラウド」などに比べて新規性(輝き?)が失われたキーワードだと見なすことができるかもしれません。しかし、それを言うのであれば我々が戦略としてここに注力することを選んだ8年前でも、別に新しさのある言葉ではありませんでした。我々は新しい分野で目立ちたくて選んだのではなく、長期的な優位性を持ち得る考えたからこの道を選んだのです。



なぜ、オープンソースが長期的な優位を生むのか。それは、このモデルが一次生産者である個々の技術者と消費者の双方にとって有利なものだからです。IT技術はインターネットによって一般のビジネスにおける情報格差を消滅させ、多くの卸売業を窮地に追い込みましたが、IT技術そのものの供給は相変わらずIT技術の知識の有無という情報格差に依存したSIビジネスによってなり立っています。特に、ユーザ企業側の技術に対するコミットが弱いとされる日本企業においてその傾向は顕著であると言えるでしょう。それでも、一次生産者と消費者がオープンソースを選好していけば徐々に企業向けのITプロジェクトがオープンソース製品ベースのものになっていくと考えられるわけです。



なぜ、一次生産者と消費者にとって有利なのか。これにはいくつか理由があります。まず、ここでいう一次生産者はITベンダではなく、そこで働く技術者を想定しています。プロプラエタリな技術は徹頭徹尾勤務先であるベンダに帰属します。その知識や経験が適用可能なプロジェクトはそのベンダの製品を取り扱ったものに限られます。そして、その製品自体の寿命はその企業の経営状態にも依存してしまいます。ビッグベンダによって買収され、親会社の製品ラインナップのなかに無理矢理押し込められる、というのは恐らく最良に近い将来像であると言えるでしょう。つまり、仕事をつまらなくする要素に事欠かない、ということです。オープンソースの場合は、もう少し状況は改善されます。貢献の事実は個人の資産ですし、部分的にであれ良いものができているなら好きなだけ他のプロジェクトへ持っていくこともできます(持っていく先も多くの場合はオープンソースであることが期待されますが)



ソースコードを公開する、という前提があるので、ある程度以上の自信があるエンジニアでなければ精神的に辛い面もあるかもしれません。しかし、それはつまり、オープンソースのものとそうでない2つの技術なり製品があった時、前者側に参加しているエンジニアの方が相対的にスキルが高いと期待できるということでもあります。私の知る限り、優秀なエンジニアと一緒に働きたいと考えない「優秀なエンジニア」は存在しません。以上の帰結として、オープンソース製品には(相対的に)優秀なエンジニアが集まる傾向にあると予想できます。少なくとも自由に選択肢が提示されれば、そうなっていくはずです。その意味で、長期的な優位、です。



消費者にとって有利、というのも、価格のことだけではありません。特定のベンダにロックインされにくく、技術自体の存続性の期待が高い、そして優秀なエンジニアに担当してもらえる可能性も高い、ということです。こちらも、IT投資のリスクをどう評価するのか、という点にかかっているので、すぐにオープンソース陣営が大勝ちするということは期待していませんでしたし、実際に移行は緩やかなものだったと思います。「感度の高い」お客様から先にオープンソースの製品を採用していくという傾向がありました。これは、8年前の時点で明確に狙っていたことではありませんが、結果としてこれまでのお客様のほぼすべてが、皆一緒に働く甲斐のある人達でした。



これからの挑戦



そして今、私たちはさらに新しいことに挑戦しはじめています。自社製品の開発です。当然、オープンソースモデルを採用しています。



今までの経験がどこまで通用するか、まだはっきりとはわかっていません。しかし、海外で成功しているオープンソースの企業向けソフトウェアの実態や、それを日本で展開することのビジネス面と技術面双方での難しさ、などについての理解・経験においてすでに我々は国内でもトップの水準にあると思われます。それは確かに一つの経営資源であり、活かさない手はありません。その一つの方法が、自社製品の開発であると考えています。



ベンチャーなので、小さい会社なので、個人の裁量が大きいという言い方はあまりしたくないのですが、そういう実態があるのもまた事実です。そのことは、単なる丸投げ体質と言われかねないものでもあるでしょう。だからこそ、どういう見込みに基づいてこれまで仕事してきたのか、これからどんなレベルで試行錯誤をしていかなければならない状況にあるのか、ということについて可能な限り明らかにしておきたいと考えました。十分な整理なく、勢いで書いてしまっているので、冗長なわりに表現しきれなかったことばかりである気もしますが、以上が今回の人材募集の背景として考えていることになります。



まとめると、「なんだか面倒くさそうな人達と一緒に、RailsやNoSQLとJavaを織り交ぜて、企業相手のソフトウェアを書く仕事」に興味がある人いませんか? って感じです。



皆様是非よろしくお願い致します。



(文責 Ishii Akinori IT-Coordinater)