ウェブシステム開発の話をしたので、その中で感じたことを追加で書いてみよう。
開発パートナー会社や他部署の関係者と新しいサイトに関する取り決めを話し合っていくとき、もれなく使うコミュニケーション補助ツールがある。Redmineというウェブシステムで、これは簡単に言うとインターネット掲示板の進化形である。
下記はデモ用のサイトであり、テーマごとにスレッド（掲示板の最小単位）が立てられている。掲示板の世界でスレッドと言っていたものが、Redmineではチケットと呼ばれる。
https://my.redmine.jp/demo/projects/demo/issues
（ちなみに掲示板スレッドとはこんな感じのものである）
http://ikura.2ch.net/expo/#1
並んでいるチケットのうち、「アップデート手順の改善」というものをクリックしてみよう。するとチケットの内容が表示される。
https://my.redmine.jp/demo/issues/2587
「説明」と書いてあるところがチケットのテーマである。決めるべきテーマを誰かがチケットとして提示し、提示された者が返信し、やりとりを繰り返すうちに決定事項がでてチケットのステータスが終了となる（※）。こういったやりとりはメールでも行うことができるが、時間がたってから一部を引用しやすいのがRedmineの特徴である。
例えば下記のURLをクリックすると、先ほどのテーマAに対する１つ目の返信がピックアップされる。これは「良いんじゃないでしょうか」と書いてある欄の右方にある「＃１」のリンク先URLである。
https://my.redmine.jp/demo/issues/2587#note-1
同様に、２つ目の返信は次のURLで示される。
https://my.redmine.jp/demo/issues/2587#note-2
時間がたってから一部を引用しやすいというのは、上記のようなURLにより文章をピンポイントで指示できるということである。例えば、先のチケットにおける決定事項とそこに至る経緯を忘れた頃に、開発パートナーとやりとり（チャットなど）をしていてテーマAに関する情報を相手に示す必要に迫られたとしよう。この場合、テーマ名などのキーワードによりRedmineの中を検索し、まず先ほどのチケットを見つける。次にチケット上のやりとりを見て、相手に示したい情報が含まれている箇所を見つける。その右方にある「＃数字」部分のリンク先URLを拾えば、あとはチャットにそれを打ち込むだけである。
もし初めにRedmineではなく電子メールでそのやりとりをしていたなら、引用部分をURLで指示することができない。何月何日のメールでやりとりをした件・・・と言うことはできるが、相手方にもそのメールが残っている保証はなく、残っていても相手がそれを検索する手間がかかる。チケットのケースでは、検索をしたのは一人だけである。またチャットの送信履歴にチケットのURLが残るため、よく引用する箇所は再検索しなくて済むようになっていく。
後で振り返るケースではなく、現在進行形のケースでも引用のしやすさは威力を発揮する。
開発パートナー会社との間で、結論が出ていないテーマが全てチケット上で議論されているとしよう。さっさと全ての結論を出すため、グループチャット（複数人で同時に行うチャット）によりバーチャル会議を行うことにする。そこへ、事前に準備したチケットのURLリストを打ち込む。「今日の議題はこれらです。まずチケット番号2587のNote２をご覧ください・・・」メールでやりとりをしていた場合、こんなことはできない。
「URLは偉大だ」ということをもう少し詳しく言えば、「指示できることと、指示先をすぐに参照できることは偉大だ」ということである。家族で一緒にみかんを食べていて、カゴの中の１つを指さして「これうまそうだね」と言うのと似ている。
「これ」の一言で特定のみかんを指示できるのは、状況（みんなが近くにいてみかんに注意を払える）と常識（指さした方向が厳密にはカゴを向いていたとしても、みかんを指しているのだろうと推測する）のおかげである。カッコ内の状況がなければ誰も返事できないし、カッコ内の常識がない場合の返事は「カゴがうまそうなわけないだろう」かもしれない。
「指示したつもり」だけだったら誰でもできるが、それが相手に伝わるには指示先をすぐに参照してもらう必要がある。また、指示対象を勘違いさせてはならない。そういう意味でURLは偉大であり、その価値を十分に引き出すRedmineに類するツール（一般的にはタスク管理システムという）はよく出来ている。コミュニケーションを重んじて仕事をするのであれば、指示にまつわる効率性をよく考えてみる必要がある。
※
チケットはそれ自体が属性を持つ。これが掲示板スレッドとの大きな違いである。
https://my.redmine.jp/demo/issues/2587
上記において、「ステータス」「優先度」「担当者」などと並んでいる項目がチケットの属性であり、Redmineでは任意の属性でチケット全体を検索することができる。メールでは基本的に全文検索を行うしかないので、関係ないメールもたくさん拾ってしまう。つまり検索効率単体で比べても、タスク管理システムはメールより優れている。
2012年12月7日金曜日
2012年4月30日月曜日
会社で寝ること
もはや今の時代、少しウトウトすると能率が上がることはほとんどの人が認めるところだと思うが、それでも完全に成果主義ではない会社の場合は特に「人目」の観点から会社で寝ることをよく思わない管理職もいるだろう。人目の観点とは簡単にいえば周囲の士気を下げるということである。しかしそれに対しては簡単な反論をすれば十分と考える。少し眠ることで能率よく仕事をしている様を見せることが士気を上げる効果があるだろう、という反論だ。もちろんその効果の大きさは測定できないが、寝姿を見せることが士気を下げる効果の大きさも測定できない。従ってこれらの主張は（ナイーブに考えれば）互角で、「士気を上げる論者」は単にその説得力を「士気を下げる」論者のそれから大きく離されないようにだけ気をつけていればよい。時代の追い風もある、ラクな闘いだと思うがどうだろう。
「眠くなった社員は寝てもよい」――さいたま市のリフォーム会社が昼寝制度を導入 （オルタナ） - Yahoo!ニュース
http://zasshi.news.yahoo.co.jp/article?a=20120410-00000301-alterna-bus_all
※もちろん、昼寝が良い効果を持つことをほとんどの人が認めているのであれば、反論など省略して上記リフォーム会社のように公式に制度化するのが建設的である。しかし現在なんとなく昼寝が人目をはばかる雰囲気の職場で、ほっといても制度化しそうにないならば、とりあえず寝てみて文句言われたら反論してみてはどうだろう。波風を立てなければ方向転換は起きない。ただし、理論武装なしに波風立てると勝てないし相手にも迷惑だ。
2012年4月27日金曜日
空気を利用してキャラクターを作る
「あるキャラクターになる」とは、周囲が「その人はそのキャラクターである」と認識することである。
例えば「お調子者」がいたとしたらその人は周囲からお調子者と見られており、その人に対してお調子者としての振る舞いを期待する。期待されたら、それに応えないのはマイナス評価であるから普通は応えようとする。そうしてキャラクターは固まっていき、その人にどのように働きかければ何をしてくれるか明確になり、コミュニケーション量を必要最小限で済ませられるようになる。いわゆるツーカーの仲に近づく。
さて、自分をどのようなキャラクターにするかは重要な問題だ。お調子者としての振る舞いを期待されるのがとても楽しければ自分をお調子者に育てるとよい。しかし、キャラクターの種類はお調子者を初めとする数種類に限定されるものではなく、周囲はその人を一般名詞的なレッテル（お調子者はその例）で見ていることはほとんどない。少なくとも、コミュニケーションをとる当人同士が近しい間柄なのであれば、周囲はその人の個人名をキャラクター名そのものとして受け取っているだろう。
その状態で自分のキャラクターを育てていく、あるいは変えていくとは、レッテルを張り替えることではなく「自分という振る舞い全体」の一部分を少しずつ変えることである。いわゆるデビューは、かなりの経験値と捨て身の勇気がなければ成功しない。中学生の自分が嫌いで、高校生になったから新しい自分に生まれ変わろうとしても、そもそも模範となるキャラクターを経験していないのだからそれを演じることは難しく、できることといえばゼロから再構築を試みるくらいである。しかしそれは、周囲から見ればとても変だろう。そういうギャンブルな人生もあるかもしれないが。
少しずつ自分を変えていくのでも何年も続ければ別人になることは、有名人の過去の写真など紹介するテレビ番組を見れば分かるだろう。あの頃の自分と今の自分では考え方も見た目も全然違うと、よく言っている。僕は思うのだが、例えば職場の環境が悪くてなかなか帰れないとか、言いたいことが言えないとかいうのは、単にキャラクター作りに失敗しているだけじゃないだろうか。社会人になって何年かは、さすがにそのことに確信が持てなかった、単に自分のバックグラウンドがたまたま恵まれているのかとも思ったが、３３にもなるとさすがにそうではないと感じる。正確に言うと、それだけではないと感じる。
あるキャラクターを演じるのに必要な資質は確かにある。例えば「言いたいことを言う」に必要な資質は、彼が「文脈に即しているとか面白いとか問題解決に役立つ」などのセリフを言えることである。「早く帰る」に必要な資質・バックグラウンドは「効率良く仕事をする、そもそも仕事が多すぎる職場に就かない」などである。しかし、その資質があるかどうかを試そうとしない人が多い。早く帰れるかどうかを「空気を読んで」判断するのは馬鹿げている。注意すべきは「明日の仕事が明日片付くか」それだけである。
早く帰ることが周囲に「あの人は早く帰る人なんだ」と思わせ、その期待が自分に伝わり「帰っていい空気」になる。失敗してもデビューほどのリスクはないし、成功したらその空気を利用してキャラクターを定着させよう。遅くまで仕事している人はみんな、部署異動しても遅くまで仕事しているよ。それは空気が自分の制御圏にある証拠だ。
2012年2月27日月曜日
Developers Summit 2012 の資料など
講演資料が揃ったようなので個人的に重要と思われるものをまとめておこう。上２つは実際に聞いたやつで下２つは聞きたかったけど他のセッションとかぶってて聞けなかったやつ。うーん、twitter（ http://twitter.com/#!/devsumi ）とかじゃなくてタイムテーブル（ http://seshop.com/se/timetable/21 ）に資料の欄を追加してほしいな・・・終わったら急に手抜きになるのはどうか。
【16-A-1】及川卓也氏「見る前に翔べ ～ギークの工夫で社会を変えよう～」
http://www.slideshare.net/takoratta/ss-11690864
【17-E-3】 オンライン機械学習で実現する大規模データ処理
http://www.slideshare.net/devsumi/17e3
【16-C-2】桑野章弘氏/並河祐貴氏「大規模化するピグライフを支えるインフラ ～MongoDBとChefについて～」
http://www.slideshare.net/akuwano/mongodbchef
http://www.slideshare.net/namikawa/devsumi2012-pigglife-chef
【16-A-7】市谷聡啓氏「あの人の自分戦略を聞きたい！」
http://www.slideshare.net/papanda/moon-and-strategy
あと、下の２つは資料がないね。せっかく良かったのに残念だ。特に16-E-7は建築の専門家が出てきて、津波のシミュレーションから防災設計の優先順位等を意思決定する話を紹介してくれて大変ためになった。17-C-6は進行役がのんびりしすぎていてスケジュールを捌ききれてなく、興味深いテーマが２つくらいかっとばされた。
【16-E-7】3・11から見えた社会基盤としてのIT
【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう
16-A-1の中で、マーク・ザッカーバーグの有名なセリフ「Done is better than Perfect」が出てきた。完璧を目指すよりまずは完了させること、という意味でアジャイル思想と強く関係する言葉だと思われるが、適切な分割設計なしには達成できない巨大なプロジェクト・作業・情報処理に広く応用できそうだ。
大きいことをしたい → 大人数を投入 → 各人に仕事を配るため、完成させたい巨大なものを分割しなければならない → 分割されたもの（部品）は、全て組み立てるまで動かないのでは困る → 部品がそれ単体で意味を持ち、正しく動作するような分割の仕方が要求される というプロジェクト一般の流れは、この矢印を逆に辿っていけば個人でも大きいことができることを意味している。「各人」を、今日・明日・明後日の自分と読みかえればいい。この流れに適合する部品だけがいい部品であり、それ以外は「Done」してもしなくても「Perfect」にやりたい内容とは無関係のことだ。
そこへいくと Done is better than Perfectの教訓というのは、やれることからコツコツ実現しようという当たり前のことではなく、全体と部分の関係についての直感を常に働かせよということではないか。部品を見て組み上がりが想像できるかどうか。何かの目標のために始めた習慣が、ただ惰性となって残り元来の目標が何だったか忘れてしまったとか。何か調べたいことがあって分厚い本を最初から丁寧に読み始めたが、つまらないので捗らずそのうち調べたいことを忘れ、なぜそれを調べたいと思ったのかも忘れてしまったとか。
目に見えるのは常に部品だけであり、全体は最後に現れるか下手をするとずっと抽象物のままである。周囲の人々の行動を見れば、やっていることは大して珍しくもないし高度でもない。にもかかわらず人によって蓄積に違いが出るのは、各人の持っている部品がそのように分割されている意味の濃さによるのだろう。
【16-A-1】及川卓也氏「見る前に翔べ ～ギークの工夫で社会を変えよう～」
http://www.slideshare.net/takoratta/ss-11690864
【17-E-3】 オンライン機械学習で実現する大規模データ処理
http://www.slideshare.net/devsumi/17e3
【16-C-2】桑野章弘氏/並河祐貴氏「大規模化するピグライフを支えるインフラ ～MongoDBとChefについて～」
http://www.slideshare.net/akuwano/mongodbchef
http://www.slideshare.net/namikawa/devsumi2012-pigglife-chef
【16-A-7】市谷聡啓氏「あの人の自分戦略を聞きたい！」
http://www.slideshare.net/papanda/moon-and-strategy
あと、下の２つは資料がないね。せっかく良かったのに残念だ。特に16-E-7は建築の専門家が出てきて、津波のシミュレーションから防災設計の優先順位等を意思決定する話を紹介してくれて大変ためになった。17-C-6は進行役がのんびりしすぎていてスケジュールを捌ききれてなく、興味深いテーマが２つくらいかっとばされた。
【16-E-7】3・11から見えた社会基盤としてのIT
【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう
16-A-1の中で、マーク・ザッカーバーグの有名なセリフ「Done is better than Perfect」が出てきた。完璧を目指すよりまずは完了させること、という意味でアジャイル思想と強く関係する言葉だと思われるが、適切な分割設計なしには達成できない巨大なプロジェクト・作業・情報処理に広く応用できそうだ。
大きいことをしたい → 大人数を投入 → 各人に仕事を配るため、完成させたい巨大なものを分割しなければならない → 分割されたもの（部品）は、全て組み立てるまで動かないのでは困る → 部品がそれ単体で意味を持ち、正しく動作するような分割の仕方が要求される というプロジェクト一般の流れは、この矢印を逆に辿っていけば個人でも大きいことができることを意味している。「各人」を、今日・明日・明後日の自分と読みかえればいい。この流れに適合する部品だけがいい部品であり、それ以外は「Done」してもしなくても「Perfect」にやりたい内容とは無関係のことだ。
そこへいくと Done is better than Perfectの教訓というのは、やれることからコツコツ実現しようという当たり前のことではなく、全体と部分の関係についての直感を常に働かせよということではないか。部品を見て組み上がりが想像できるかどうか。何かの目標のために始めた習慣が、ただ惰性となって残り元来の目標が何だったか忘れてしまったとか。何か調べたいことがあって分厚い本を最初から丁寧に読み始めたが、つまらないので捗らずそのうち調べたいことを忘れ、なぜそれを調べたいと思ったのかも忘れてしまったとか。
目に見えるのは常に部品だけであり、全体は最後に現れるか下手をするとずっと抽象物のままである。周囲の人々の行動を見れば、やっていることは大して珍しくもないし高度でもない。にもかかわらず人によって蓄積に違いが出るのは、各人の持っている部品がそのように分割されている意味の濃さによるのだろう。
2012年2月19日日曜日
Developers Summit 2012 の感想
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企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
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企業になる過程の話を聞くことはあまりない。ある程度組織の基盤が固まったらその先は開発プロセスの分野からヒントが見つかる気もするが、その前は・・・経営論でも参照すると何か書いてあるんだろうか。
2011年2月20日日曜日
Developers Summit 2011
2011/2/17,18 目黒雅叙園で行われたDevelopers Summit 2011のまとめ。
17日に見たもの。
【17-A-1】
Mobile Future Conference開会のご挨拶／ 世界へ挑むDeNAの「X－border」「X-device」戦略
南場智子 氏 / 守安功 氏
南場さんの、TO氏（怪盗ロワイヤルの作者）に関する話が面白かった。
話を聞く限りTO氏はあまりエンジニア然とした人ではなさそう（営業から転向した）だが、
南場さんが評価する３ポイントであるところの「能力」「意欲」「実績」のうち特に２番目と、何がなんでもやり遂げようとする根性が抜きん出ているという。
そういうタイプの人がどのように会社に影響を与え、また管理する側がどのようにそういう人を扱うかに関する興味深い例。
守安氏の話は、DeNAが比較的最近買収したngmocoという会社が開発したX-Platformゲームエンジン「ngcore」に関するもの。
【17-E-3】
Hadoop：黄色い象使いへの道 ～「Hadoop徹底入門」より～
下垣徹 氏
一番才気を感じさせるスピーチでしたで賞をあげるとしたらこの人。
短い時間に盛りだくさんの内容で、比喩をうまく使いながらHadoopの全体像と「Hadoop徹底入門」の構成、ページ数の関係で盛り込めなかったところなどを説明していく。
【17-A-4】
大規模Webサービスのためのデータベース技術の現在・未来
松信嘉範 氏
大規模Webサービスのボトルネックであるマルチスレーブへのレプリケーションを、PCI-ExpressのSSD採用によるIOPSアップにより解決すると今度はボトルネックがマスタやCPUやネットワークに移っていって・・・というようなお話。ザ・エンジニア！という感じでスピーチも上手。
【17-E-5】
Cassandraで見るNoSQL
小林隆 氏
NoSQLはNot only SQL。RDBMSよりNoSQLというんじゃなく住み分けが大事だと。
よく「重要」を「でかい」と表現していた。
【17-A-6】
Smartphone X-Platform 開発
近藤和弘 氏 / 上条晃宏 氏 / 増井雄一郎 氏
web+db press #61 2/24発売！titanium特集。
いくつかの描画エンジンによるフレームレートと描画オブジェクト数のグラフが印象的。
js+canvasは現段階では非常に遅い、objectiveCのようなnativeは非常に早いがdevice依存。
中間の策としてtitanium mobile。ある程度までなら十分なフレームレートでX-device、またjsで書ける。
18日に見たもの。
【18-A-1】
ハッカー中心の企業文化を日本に根付かせる
よしおかひろたか 氏
Linuxカーネル読書会などで有名な人（という話を聞いた）。
メモから引用：
統制の種類には功利的、強制的、規範的なものがある。
『超マシン誕生』『洗脳的マネジメント』
許可を求めるな、謝罪せよ。
ハッカーは「自ら行動する人」であり、行動はプログラミングだけとは限らないと。
シリコンバレー感たっぷりのスピーチ。
【18-A-2】
次世代ジオロケーションサービスの開発手法
佐藤伸介 氏
Yahoo! Open Local Platformの話。A-1が面白すぎたのであまり印象に残っていない。
【18-A-3】
スマートフォン向けソーシャルアプリケーション開発の現在
伊藤直也 氏
ほんとは「SilverlightとAzureで魅せる未来」を見る予定だったんだけど
rakuten_saitama（twitter）がこっち見る１手でしょと言うのでついていった。
なんかこのへんからメモが適当になっているが・・・
taglet NFC共有 OpenFeint unity（jsだけじゃなくC#も使えるとな）
【18-A-4】
ウェブアプリケーション関連技術5年間の変遷とこれからのはなし
藤本真樹 氏
５年前はGreeではこんなハード・スペックでこんなバージョンのミドルウェア・言語・フレームワークを使っていたよ・・・こうしてみると思ったより進歩してないね。という感じの話。
資料をみて復習しないと思い出せない。
【18-A-5】
前例のないソフトウェアを作る！ コミPo!開発秘話
小野知之 氏 / 田中圭一 氏
休憩時間から「コミポコミポ」という歌が無限リピートされていて、気分転換ぐらいのつもりでいたがかなり面白かった！田中圭一さんというのは漫画家で、ふだん絵を描かない人がカンタンにマンガを（ビジネス用途まで想定してるようだ）作れるようなソフトがほしいということで、ウェブテクノロジさんと一緒になって要件定義をしたりモックアップの作成をしたらしい。ウェブテクノロジさんといえば減色エンジンや携帯向け画像変換ツールを開発しているところ。これはちょっと、記憶に残ったよ。
【18-B-6】
Chrome、Chrome OSとChrome Web Store
北村英志 氏 / 及川卓也 氏
及川氏にベストスピーチ賞をあげたい。何回も話しているので早口になってしまう・・・と本人が言っていたので、慣れてるってことなんだろうけどね。さて、Chrome OSの思想は分かるんだけども、あれがほしいかと言われると躊躇してしまう。確かに今のwindows pcは、不要といって差し支えないくらいたくさんの機能がゴテゴテしているが、ではChrome OS搭載PCが進化していった先にはどんな便利なPCがあると、彼らは思い描いているんだろう？その説明があったほうがいいと思った。
17日に見たもの。
【17-A-1】
Mobile Future Conference開会のご挨拶／ 世界へ挑むDeNAの「X－border」「X-device」戦略
南場智子 氏 / 守安功 氏
南場さんの、TO氏（怪盗ロワイヤルの作者）に関する話が面白かった。
話を聞く限りTO氏はあまりエンジニア然とした人ではなさそう（営業から転向した）だが、
南場さんが評価する３ポイントであるところの「能力」「意欲」「実績」のうち特に２番目と、何がなんでもやり遂げようとする根性が抜きん出ているという。
そういうタイプの人がどのように会社に影響を与え、また管理する側がどのようにそういう人を扱うかに関する興味深い例。
守安氏の話は、DeNAが比較的最近買収したngmocoという会社が開発したX-Platformゲームエンジン「ngcore」に関するもの。
【17-E-3】
Hadoop：黄色い象使いへの道 ～「Hadoop徹底入門」より～
下垣徹 氏
一番才気を感じさせるスピーチでしたで賞をあげるとしたらこの人。
短い時間に盛りだくさんの内容で、比喩をうまく使いながらHadoopの全体像と「Hadoop徹底入門」の構成、ページ数の関係で盛り込めなかったところなどを説明していく。
【17-A-4】
大規模Webサービスのためのデータベース技術の現在・未来
松信嘉範 氏
大規模Webサービスのボトルネックであるマルチスレーブへのレプリケーションを、PCI-ExpressのSSD採用によるIOPSアップにより解決すると今度はボトルネックがマスタやCPUやネットワークに移っていって・・・というようなお話。ザ・エンジニア！という感じでスピーチも上手。
【17-E-5】
Cassandraで見るNoSQL
小林隆 氏
NoSQLはNot only SQL。RDBMSよりNoSQLというんじゃなく住み分けが大事だと。
よく「重要」を「でかい」と表現していた。
【17-A-6】
Smartphone X-Platform 開発
近藤和弘 氏 / 上条晃宏 氏 / 増井雄一郎 氏
web+db press #61 2/24発売！titanium特集。
いくつかの描画エンジンによるフレームレートと描画オブジェクト数のグラフが印象的。
js+canvasは現段階では非常に遅い、objectiveCのようなnativeは非常に早いがdevice依存。
中間の策としてtitanium mobile。ある程度までなら十分なフレームレートでX-device、またjsで書ける。
18日に見たもの。
【18-A-1】
ハッカー中心の企業文化を日本に根付かせる
よしおかひろたか 氏
Linuxカーネル読書会などで有名な人（という話を聞いた）。
メモから引用：
統制の種類には功利的、強制的、規範的なものがある。
『超マシン誕生』『洗脳的マネジメント』
許可を求めるな、謝罪せよ。
ハッカーは「自ら行動する人」であり、行動はプログラミングだけとは限らないと。
シリコンバレー感たっぷりのスピーチ。
【18-A-2】
次世代ジオロケーションサービスの開発手法
佐藤伸介 氏
Yahoo! Open Local Platformの話。A-1が面白すぎたのであまり印象に残っていない。
【18-A-3】
スマートフォン向けソーシャルアプリケーション開発の現在
伊藤直也 氏
ほんとは「SilverlightとAzureで魅せる未来」を見る予定だったんだけど
rakuten_saitama（twitter）がこっち見る１手でしょと言うのでついていった。
なんかこのへんからメモが適当になっているが・・・
taglet NFC共有 OpenFeint unity（jsだけじゃなくC#も使えるとな）
【18-A-4】
ウェブアプリケーション関連技術5年間の変遷とこれからのはなし
藤本真樹 氏
５年前はGreeではこんなハード・スペックでこんなバージョンのミドルウェア・言語・フレームワークを使っていたよ・・・こうしてみると思ったより進歩してないね。という感じの話。
資料をみて復習しないと思い出せない。
【18-A-5】
前例のないソフトウェアを作る！ コミPo!開発秘話
小野知之 氏 / 田中圭一 氏
休憩時間から「コミポコミポ」という歌が無限リピートされていて、気分転換ぐらいのつもりでいたがかなり面白かった！田中圭一さんというのは漫画家で、ふだん絵を描かない人がカンタンにマンガを（ビジネス用途まで想定してるようだ）作れるようなソフトがほしいということで、ウェブテクノロジさんと一緒になって要件定義をしたりモックアップの作成をしたらしい。ウェブテクノロジさんといえば減色エンジンや携帯向け画像変換ツールを開発しているところ。これはちょっと、記憶に残ったよ。
【18-B-6】
Chrome、Chrome OSとChrome Web Store
北村英志 氏 / 及川卓也 氏
及川氏にベストスピーチ賞をあげたい。何回も話しているので早口になってしまう・・・と本人が言っていたので、慣れてるってことなんだろうけどね。さて、Chrome OSの思想は分かるんだけども、あれがほしいかと言われると躊躇してしまう。確かに今のwindows pcは、不要といって差し支えないくらいたくさんの機能がゴテゴテしているが、ではChrome OS搭載PCが進化していった先にはどんな便利なPCがあると、彼らは思い描いているんだろう？その説明があったほうがいいと思った。
2011年2月12日土曜日
会社は従業員に対しても社会貢献をする責任がある
よその会社の話だけども、知人の上司が脳梗塞で倒れたらしい。
容易に想像できるが、血圧が高くて太っていたという。
その人の食生活はよく知らない。だから不摂生がたたったのか元々そういう体質だったのかも分からない。
とはいえ、もし自分に部下がいてその子が会社で変な時間におやつなどモリモリ食べているようなら、
多少は干渉しようかなぁと思う。会社での人間関係が少しも家族化してはいけないってことはないだろうから。
会社にとって、従業員が健康に気をつけてくれるのは非常に有り難いことのはずだ。
健康に気をつけることが可能な時間は、プライベートの時間だけではなく業務時間も含まれる。適切な気分転換、適切な姿勢と姿勢転換、エレベーターの代わりに歩く、残業を減らして夕食の時間が遅くなりすぎないようにする、等々。
でもその努力が有難がられることは、実際にはあまりない。それどころか、会社によっては残業が少ない人に対してもっと残業させようとしたり、気分転換や姿勢転換をサボりと見なすことさえあるだろう。
それが蔓延することによって会社中が気分転換だらけになったら困るというのは確かにある。でもそれなら、気分転換をどれくらい許すかによってチームの雰囲気や達成タスク量がどう変わるか、それぞれの管理職が見ればいい。
残業のほうは、それが個人の活力につながって達成タスク量が増える場合もあるだろうが（例えばプログラミングがノッてきて面白くて仕方ない場合とか）、人によっては２・３時間やる程度ではほぼ増えない場合もあるだろう。
例えばこういうことだ。持久走をするときランナーは、何ｋｍ走るか決めてから走る。なるべく早く走ろうとする人Ａもいるし、ゆっくり走る人Ｂもいる。この持久走を取り仕切る先生が、Ａにだけ150%のノルマを課したとしよう。この意図は、ＡとＢが走り終わる時刻を近づけることである。この時Ａは２種類に分かれる。ノルマが増えてもなお全力で走ろうとする人Ａ１と、自分の体力を考慮して初めからペースを落とすＡ２である。
※どの程度ペースを落とす必要があるかは個人の体力による。Ａ２の場合、普段の1/2としておこう。
Ａ１は（体力があれば）先生の意図通りＢとほぼ同時刻にゴールする。Ａ２はペースを半分に落とした結果、大幅に遅れてゴールする。というわけで、Ａ２に追加ノルマを課した先生の意図は失敗している。そのうえ単位時間あたりの走破量も落ちている。
一日の初めに「今日は２・３時間残業しよう」と決めることは、持久走の追加ノルマに相当する。
そう決めた人がＡ２タイプであれば、単位時間あたりの走破量すなわち効率が落ちることにより、タスク達成量は何時間か残業したあとにやっと（残業なしの日より）多くなり始める。仮にその時刻が２１時だとして、２２時まで働くと（落ちた効率）×１時間分のタスクを余分にこなせることになる。
一方、夕食の時間が遅くなったり自由時間が少なくなったりすることで健康とモチベーションの両面で悪影響が予想される。さて、余分にこなせるようになったタスク量はこの悪影響に見合うか？ましてや、長い会社生活の中で150%ノルマを続けていった時、効率の低下幅がずっと同じで済む保証はない。
ストレスが過食につながりやすい人だっているのだ。その因果関係を疑ってもみないで、ストレスを低減できる働き方を部下に提案してあげもせず、ある日病気になったら運が悪かったね、ひどい時には自業自得だなどと言う、僕は幸いそういう上司は見たことはないが、もしいるとしたらいかがなものかと思う。
相談にのるのはまだ良いほうだが、グチを聞いているだけなら無能の範疇を出ない。忙しいのは分かるので一人一人に丁寧に働きかけろとは言わないが、自分で健康やモチベーション管理をするよう奨励し、すでに実践している人は評価するべきだ。自分のチームの業績だけを気にするあまりつい業務偏重な命令をしてしまったとする。部下からそれを指摘されたら、ハッと気づいて訂正する。指摘しやすい空気を作る。管理職自ら実践する。こういった文化に理解のない、さらに上の偉い人から部下を守る。どれもそんなに面倒くさいことじゃない。
追記１：
Ａ１がＡ２より評価されるのは仕方のないところ。しかし上司はＡ２を認めなければならない。
また、Ａ１は150%のノルマなら全力で走れるが、これが200%とか300%とかどんどん増えても全力で走ろうとするなら危険である。自分の体力を考慮しない未熟さを上司が黙認すると、最悪の場合は過労死ということになる。
追記２：
ある意味、残業は会議と似たところがある。残業をたくさんしていれば、自分は精一杯のことをしていると思って安心するからだ。しかし特に社外とのやりとりが多い業務形態の場合、営業時間内の応答頻度と質を高めることが重要になる（正しい問題の立て方、正しい内容の応答をすることによって、プロジェクト完了までに必要な総コミュニケーション量が減らせる）。
十分な対話をこなさないまま営業時間外に突入したら、作業系の業務はどうにかなっても外部コミュニケーション系の業務は置いてきぼりだ。そして往々にして、プロジェクトが遅れる原因はコミュニケーションのまずさにある。残業には残業代というインセンティブがあるが、対話を円滑に進めることについてはそれほど強力なものがない。
だからこそせめて管理職は、下っ端の人間と一緒になって残業神話を崇拝していてはいけないと考える。
容易に想像できるが、血圧が高くて太っていたという。
その人の食生活はよく知らない。だから不摂生がたたったのか元々そういう体質だったのかも分からない。
とはいえ、もし自分に部下がいてその子が会社で変な時間におやつなどモリモリ食べているようなら、
多少は干渉しようかなぁと思う。会社での人間関係が少しも家族化してはいけないってことはないだろうから。
会社にとって、従業員が健康に気をつけてくれるのは非常に有り難いことのはずだ。
健康に気をつけることが可能な時間は、プライベートの時間だけではなく業務時間も含まれる。適切な気分転換、適切な姿勢と姿勢転換、エレベーターの代わりに歩く、残業を減らして夕食の時間が遅くなりすぎないようにする、等々。
でもその努力が有難がられることは、実際にはあまりない。それどころか、会社によっては残業が少ない人に対してもっと残業させようとしたり、気分転換や姿勢転換をサボりと見なすことさえあるだろう。
それが蔓延することによって会社中が気分転換だらけになったら困るというのは確かにある。でもそれなら、気分転換をどれくらい許すかによってチームの雰囲気や達成タスク量がどう変わるか、それぞれの管理職が見ればいい。
残業のほうは、それが個人の活力につながって達成タスク量が増える場合もあるだろうが（例えばプログラミングがノッてきて面白くて仕方ない場合とか）、人によっては２・３時間やる程度ではほぼ増えない場合もあるだろう。
例えばこういうことだ。持久走をするときランナーは、何ｋｍ走るか決めてから走る。なるべく早く走ろうとする人Ａもいるし、ゆっくり走る人Ｂもいる。この持久走を取り仕切る先生が、Ａにだけ150%のノルマを課したとしよう。この意図は、ＡとＢが走り終わる時刻を近づけることである。この時Ａは２種類に分かれる。ノルマが増えてもなお全力で走ろうとする人Ａ１と、自分の体力を考慮して初めからペースを落とすＡ２である。
※どの程度ペースを落とす必要があるかは個人の体力による。Ａ２の場合、普段の1/2としておこう。
Ａ１は（体力があれば）先生の意図通りＢとほぼ同時刻にゴールする。Ａ２はペースを半分に落とした結果、大幅に遅れてゴールする。というわけで、Ａ２に追加ノルマを課した先生の意図は失敗している。そのうえ単位時間あたりの走破量も落ちている。
一日の初めに「今日は２・３時間残業しよう」と決めることは、持久走の追加ノルマに相当する。
そう決めた人がＡ２タイプであれば、単位時間あたりの走破量すなわち効率が落ちることにより、タスク達成量は何時間か残業したあとにやっと（残業なしの日より）多くなり始める。仮にその時刻が２１時だとして、２２時まで働くと（落ちた効率）×１時間分のタスクを余分にこなせることになる。
一方、夕食の時間が遅くなったり自由時間が少なくなったりすることで健康とモチベーションの両面で悪影響が予想される。さて、余分にこなせるようになったタスク量はこの悪影響に見合うか？ましてや、長い会社生活の中で150%ノルマを続けていった時、効率の低下幅がずっと同じで済む保証はない。
ストレスが過食につながりやすい人だっているのだ。その因果関係を疑ってもみないで、ストレスを低減できる働き方を部下に提案してあげもせず、ある日病気になったら運が悪かったね、ひどい時には自業自得だなどと言う、僕は幸いそういう上司は見たことはないが、もしいるとしたらいかがなものかと思う。
相談にのるのはまだ良いほうだが、グチを聞いているだけなら無能の範疇を出ない。忙しいのは分かるので一人一人に丁寧に働きかけろとは言わないが、自分で健康やモチベーション管理をするよう奨励し、すでに実践している人は評価するべきだ。自分のチームの業績だけを気にするあまりつい業務偏重な命令をしてしまったとする。部下からそれを指摘されたら、ハッと気づいて訂正する。指摘しやすい空気を作る。管理職自ら実践する。こういった文化に理解のない、さらに上の偉い人から部下を守る。どれもそんなに面倒くさいことじゃない。
追記１：
Ａ１がＡ２より評価されるのは仕方のないところ。しかし上司はＡ２を認めなければならない。
また、Ａ１は150%のノルマなら全力で走れるが、これが200%とか300%とかどんどん増えても全力で走ろうとするなら危険である。自分の体力を考慮しない未熟さを上司が黙認すると、最悪の場合は過労死ということになる。
追記２：
ある意味、残業は会議と似たところがある。残業をたくさんしていれば、自分は精一杯のことをしていると思って安心するからだ。しかし特に社外とのやりとりが多い業務形態の場合、営業時間内の応答頻度と質を高めることが重要になる（正しい問題の立て方、正しい内容の応答をすることによって、プロジェクト完了までに必要な総コミュニケーション量が減らせる）。
十分な対話をこなさないまま営業時間外に突入したら、作業系の業務はどうにかなっても外部コミュニケーション系の業務は置いてきぼりだ。そして往々にして、プロジェクトが遅れる原因はコミュニケーションのまずさにある。残業には残業代というインセンティブがあるが、対話を円滑に進めることについてはそれほど強力なものがない。
だからこそせめて管理職は、下っ端の人間と一緒になって残業神話を崇拝していてはいけないと考える。
登録:
投稿 (Atom)