10年後も世界で通じるエンジニアであるために Developers Summit 2012
http://codezine.jp/devsumi/2012
デブサミに２日連続で行ってきたので、とりあえず感想を書こうと思う。
まー今回は１０周年ということでこの１０年間のまとめみたいなテーマが多かったように思われ、
特に印象に残ったのは「3・11から見えた社会基盤としてのIT」と「ライターズ・フィロソフィー IT業界で書いて食っていくひとたちの哲学をきこう（仮）」という、ちょっとテクノロジー寄りではないセッションであった。
資料がアップされたら各セッションの詳細を振り返ることにする。
で、内容を詳しく覚えているわけじゃないんだけど今回は何故か開発プロセスのセッションを３つも受けてしまった。
全部面白かったけれども、スクラムだとか（アジャイルの一種）をどう日頃の開発業務に取り入れていくべきかっていう話は少なくともうちの会社には時期尚早なので、セッションの内容とは直接関係ないことばっかり考えることになったのだ。
うちの会社は就職・転職情報サイトなどリクルート的なウェブサイトをいくつか運営していて各サイトごとに社内SEみたいのがついているが、例えばソーシャルゲーム開発ができるほどの部隊がいないためエンジニアは基本的に売上を生まず人件費だけかかる存在としか（事実上）考えられておらず、上層部がITに疎いことも相まってエンジニアの数を増やす経営判断は後手に回りがちなのである。
別に自社批判をしているつもりはなく、彼らは彼らにとって確信的なビジョンのない博打をしないだけであろうと思っている。面白いソーシャルゲームに自然とユーザが集まる、つまり営業・販促の費用が抑えられエンジニアの人件費だけで莫大なPVを得られることが分かっているならエンジニアを増やす判断は難しくない。しかしノウハウもない会社が突然ソーシャルゲーム市場に参入できるわけもないので、別の例を用いてそういった「判断が難しくない状況」に持っていくことが重要になってくる。
最近DVDで「無法地帯」を見ていて、その中で元帝国陸軍大本営参謀の壹岐正がシベリア抑留を経て近畿商事（伊藤忠がモデルとされている）に入社し商社の大本営たる業務本部創設を社長に提言するが、壹岐がそれをしなければ近畿商事はしばらく重要な組織を欠いた状態のままであったと思われる。壱岐の提言が受け入れられたのは、彼の大本営参謀としての頭脳に社長が信頼を寄せていたこともあるかもしれないが、業務本部を作ることのメリットがデメリットを上回る、しかも割と短期的にそうであることをうまく説明することによって社長を「判断が難しくない状況」に持っていったのだろう。
ある分野に対する上層部の理解がないという状況でありがちだと思うのは、提言がとても中途半端なために単なる愚痴や文句になってしまい聞き入れてもらえずそれ以降あきらめるというパターンである。エンジニアの話でいえば、要は１人雇うと１人分以上の利益が出るようなエンジニアの使い方（体制）を予め用意できていればいいわけで、その用意ができるのはITに疎い上層部ではない。しかしその用意をするためには時間と方法論が必要であり、方法論のほうはエンジニアが習得すべきことであるが時間を与えるのは上層部の役目である。しかしその時間を与える理由が前述のような体制を作るためであって、時間があるとこれこれこのように体制が実現する見込みであると説明するのはエンジニアの役目である。
簡単に考えれば、既存のサイトが例えば１PVあたり１円の儲けになるとすると、１００万ほど月平均PVをアップさせればいい（厳密に言うと、その原因をエンジニアに帰着させなければいけない）のだが、新しくＡ人のエンジニアを採用して同じサイトをＡ☓１００万PV増やすのはＡが大きくなるほど難しくなる。よって、そのサイトの総PVが１００万に対して非常に大きいか（例えば月１億PVのサイトであれば、わずかな直帰率の改善で大きくPVが増える）、少なくとも同規模のサイトが複数存在する必要がある。
つまり、まず増やしやすいのは既存サイトの改善部隊であろう。PVアップの施策を行い、うまくいったらその原因を自分たちの施策に帰着させるためのレポートを行う。反対に、新規サイトの自社構築部隊は後回しになるだろう。新規サイトが増えていけばそれぞれに改善部隊を設けることができ、エンジニアの絶対数が増えるとGoogleの20％ルールのようなプロジェクトによって自前でβサービスを立ち上げられるようになる可能性が高い。
他社構築が前提となっている状態の問題点は、コーディングスキルの高い人がつまらないこと（ひいては、そういう人の需要も供給もなくなる）、また他社構築を要するほど大きい案件ばかりでは新規サイトが増えるスピードが遅いためエンジニアの絶対数が増えるスピードも遅く、２０％ルールを適用するのに必要な余剰時間が作れないこと、つまりコンテンツエンジニア※が生まれないことである。
※コンテンツエンジニア
例えばソーシャルゲームのコンテンツをエンジニアが提供しているとすれば、その人はコンテンツエンジニアである。MovableTypeで記事を作るのがライターなのであれば、そのMTを用意した人はコンテンツエンジニアではない。
PVを生む当の人がエンジニアである場合を含めれば、前述の改善部隊も広義のコンテンツエンジニアと呼べるかもしれない。
まーしかし、ここに矛盾が１つあって、自社にコンテンツエンジニア部隊を持ちたいと考える人は自分がその部隊に入りたいのであって、体制を作っていく当事者になりたいとは限らないしその手の才能なり元気なり覚悟なりがあるとも限らない。うちのエンジニアに聞いてもそのように言っている人はいる。他社構築から自社構築へと転換した話としては昨年のデブサミでDeNAの南場さんが自社の例を紹介していたが、ぼんやり覚えている限りでは、自社で開発しないのにコンサルなんてできねぇよみたいな思いから端を発していた。ふむ、そりゃそうだ。だからDeNAでは上層部のレベルでハードランディング路線を決める判断に確信が持てたんだろう。
うちの場合はコンサルなんてやってないし、他社構築でも直近では問題ない。だから少なくとも論理レベルでは、自社構築路線に転換するにはソフトランディング路線が求められる。デブサミは新しい技術、開発プロセス、クラウドなどの新製品、エンジニアのキャリアに関するセッションはあるが、非IT企業がIT企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
