このエントリーははてなディレクターアドベントカレンダー2016の15日目の記事です。また、このエントリは先日の はてなエンジニアセミナー #7 でお話したことを、書き起こしたものでもあります。
Mackerel というサーバー監視・管理SaaSの開発チームのディレクターを務めている 
id:Songmu です。はてなのチーフエンジニアも兼務しています。
これまでの経歴としては、中国でITベンチャーの立ち上げに関わったり、その後語学学校で営業兼システム担当、SIer、Web企業でソーシャルゲームのリードエンジニアなどの経験を経て、2年ほど前にはてなに入社しました。
現在兼務している、ディレクターとチーフエンジニアという職位は、一般の企業では両方共課長格くらいで、W課長みたいな社内では珍しい立ち位置です。
Mackerelのディレクターとしては、プロダクトマネージャーとスクラムマスター的なことをしています。マネージャーがスクラムマスターをするのは本来アンチパターンではありますが。
ちなみに、現在のはてなでエンジニアがディレクターをやることは実は珍しく、3人しかいません。
僕がディレクターになった経緯を思い返すと、2年前、はてなに入社してから数ヶ月、当時CTOでMackerelのプロデューサーでもあった 
id:stanakaから「Mackerelのディレクターやりませんか？」と聞かれて、その場で「はい、やります」と即答したことを覚えています。
当時は、現CTOの 
id:motemen がMackerelのディレクターでした。彼のエンジニアリング能力の高さはエンジニア界隈に知られており、僕ももちろん彼のことは入社前から知っていました。いざ、はてなに入社して一緒に働いてみると、彼のエンジニアとしての優秀さのみならず、リーダーとしての全体観にも驚かされることになります。
そんな motemen の後任として、Mackerelという大事なプロダクトのディレクターをやることにはプレッシャーはありましたが、引き受けた理由には以下の様なことがあります。
まず、Mackerelというプロダクトが純粋に好きだしもっと好きになれそうだったから。そして、エンジニア向けのSaaSを任せてもらうことでもっとエンジニアとしてもレベルアップができそうに思ったからです。それに、Mackerelはリードエンジニアがしっかりしていたので自分はディクレターという形で関わる方が機能するだろうなという思いもありました。
エンジニアリング的な側面からすると、はてなの優秀なエンジニアチームを率いることができるのは魅力的です。自分が考えた機能をはてなの優秀なエンジニアに実現してもらえることは、自分一人でコードを書いていると感じることができない、自分の手が増えたような感覚が味わえます。
そして、ポリシーとして「仕事は断らない」ようにしているということがあります。自分の実力以上の仕事をさせてもらえる方が必死でやらないといけない分、やりがいもあって成長につながるし幸せなことだと思っています。仕事が来るうちが花だし、そこで断ってしまうともうそれ以上の仕事が来なくなるんじゃないかという危機感も持っています。
ディレクターは「エラい人」
ディレクターになって分かったのはディレクターは「エラい人」だということです。恥ずかしながら、同僚数人から「おめでとうございます」と言われて人事上は昇進だったということに遅まきながら気づいたのです。ディレクターははてなではマネージャー職であり、チームメンバーの評価などもおこなう立場です。
「エラく」なることには抵抗がありました。僕はなるべくフラットな組織で働きたいと思っているのでそのために自分がマネージャーとしてどういう行動をするかを考えるようになりました。
スタンフォード監獄実験 という恐ろしい実験があります。これに見られるように、立ち位置によって人間はいとも簡単に自分を見失います。自分のことを偉いと勘違いしてしまうと、途端に自分が権威を持っていると思い込み、簡単に裸の王様になってしまうのです。
なので、僕は、マネージャーはチームの中でのロールであり「偉くない」ということを肝に銘じるようにしています。
LINE執行役員の池邉さんが、YAPC::Asia Tokyo 2013のキーノートで「マネージャーは南ちゃんだ」とおっしゃっていたのが結構しっくりきています。南ちゃんは個人的にはあまり好きではないんですが。(ちなみに最近の若い人には南ちゃんがタッチのヒロインだと通じないかもしれませんね)
マネージャーとしてのスタンス
僕が、マネージメントを始める中で先ず思ったのが、自分が現場にいて嫌だった事はやらないようにしようということです。自分の周りにいた過去のマネージャーを反面教師になっています。例えば以下の様なことです。
- スキルを磨かない
- いつまでも決めない
- 情報を開示しない
- オーナーシップを渡さない
なので以下のようなマネージャーであろうと考えました。これは思い返してみると、これまで僕の周りにいたマネージャーの理想像の一つでもありました。
- プレイングマネージャー
- 決める
- 言葉を発っしてビジョンを示す
- チームを尊重する
僕は、オーナーシップ中心マネージメントとでも言うべきマネージメントスタイルをとっています。メンバーにオーナーシップを持ってもらうこと、簡単に言えば、チームメンバー全員が「これがオレのプロダクトだ」って思ってもらえるようにするということです。それが一番メンバーも楽しいしやりがいを持って取り組んで、結果として成果を出してもらえると思っているからです。
オーナーシップを渡すためにチームが以下のようになることを意識しています。
- オープンであること
- フラットであること
- 遊びをもたせること
従業員に対して「経営者目線になれ」というような言説はよく聞かれます。それが有効なのが確かですが、情報や権限を渡す努力をせずにそれが実現できるはずがありませんし、それなのにそういう態度を要求することはパワハラでしょう。チームビルディングにも同様のことが言え、オープンでフラットであることを心がける必要があるでしょう。
遊びをもたせることは、メンバーが自主的に改善してもらえるような余裕を作ることを意図しています。
実際の仕事の中で気をつけていることは「決める・責任を取るのがマネージャーの仕事だ」ということです。良くないサーヴァント型リーダーの落とし穴として「みんなで決めましょう」などと言っていつまで経ってもやることや仕様を決めない、というのがあります。判断や決断が遅れることはチームを迷走させることになるため、自分で決断する必要があります。
オーナーシップを委譲する・自律的な系を目指す
また、実際にタスクを渡す時に心がけていることは「メンバーに作るものの意義や期待を伝えた上でメンバーを信じるということ」です。
そのためにも、タスクをブレークダウンしすぎず、ある程度の大きさでまるっと任せてしまうようにしています。これは例え話ですが、食べやすいようにと気遣って、りんごを擦り下ろして与えることは、寧ろその人を馬鹿にしているようなものです。りんごを丸のまま与えて、素材を活かして自由に食べてもらったほうがメンバーとしてはやりがいがあるはずです。メンバーの消化能力を信じるようにしています。
大きめのタスクを渡すことでメンバーにその部分にオーナーシップを持ってもらうことを期待しています。その上で、成功したらメンバーの成果、失敗したら任せたマネージャーの責任だと捉えるようにしています。
ここまで書いてきたように、遊びをもたせたり、メンバーにタスクを細かくせず渡したり、情報を整理しすぎないで伝えることには、勇気が要ります。
ベロシティが安定しなかったり、メンバーがタスクを消化できなかったり、情報の海に溺れてしまったりすることを懸念してしまうかもしれません。実際そういうことは起こるでしょう。ただ、メンバー自身にその問題を乗り越えて自律的に動けるようになってもらうことで結果的に強いチームが実現できると考えています。
例えば、Mackerelには愛知からリモートワークで働いているメンバーがいます。彼は1年半前に自宅勤務に切り替えたのですが、リモートワークを始めた当初はたまにチームのオンライン朝会に遅れてくることがありました。それが今では全く遅れなくなりました。これは彼が自律を獲得した一つのケースかなと思っています。
少しリモートワークの方向に話を逸らすと、リモートワークの良い点として「その制約を逆手に取って利点を生み出す」という側面があるように感じています。それは、規則で縛りづらい中でメンバーが自律を獲得することや、リモートメンバー間の情報共有が困ることで逆にドキュメント化が促進される、などです。
Webエンジニアの世界では最近のインフラトレンドとして、Immutable InfrastractureやContainer、Functionなどのムーブメントがありますが、これらも、制約を敢えて作ることで逆に運用しやすく、疎結合でスケーラブルなシステムを作りやすくするという側面があり、似ている部分があるように感じています。
話を戻しますが、Mackerelではリモートメンバーに限らず、チームメンバーには「規則だから思考停止して守る」のではなく「自由な環境で自分から規律を作る」ように心がけてほしく思っていますし、僕自身も仕事に限らずそのように心がけています。全員が自主的にオーナーシップを持って自律的に動けるよう状態が理想であり、もちろんメンバーがそうなるまで信頼して待とうとも思っています。
これもまた、エンジニアの性で、自律分散的なシステムがかっこよく効率が良いという憧れがあり、プロジェクトチームもそのようになっていると美しいな、と思うというのもあります。
実際、Mackerelチームは、日常的にメンバーが自律的に改善を行うことができていると感じています。まあこれはマネージメントがうまくいったというよりかは、チームメンバーがすごい、という話だったりするのですが。
評価について
最近、仕事と評価は密接に絡み合っているということに改めて気が付きました。オーナーシップだけではなくて「誰に、どのように評価されるか」も大事だということです。エンジニアが多い組織の中でエンジニアの僕が評価者をやることは他のディレクターに比べてアドバンテージがあるな、とも感じるようになりました。
評価をやる以上、自分が評価者であることに納得してもらえるかが大事です。なので、はてなの優秀なメンバーの評価者をやる以上は、自分もより学び続けて成長し続けなくてはいけないということを意識しています。
また、評価において、中間管理職であるディレクターの役割は、評点を付けて優劣をつけるのではなくて、チームメンバーの成果を拾い上げて、上にまとめてアピールするエージェントのような役割だと思っています。
なので、被評価者にも評価者は優劣を付ける敵ではなくて、成果を上に代わりにアピールしてくれる味方だと思ってくれると嬉しいな、と思っています。この人と一緒にやれば自分は成長できるだろう、と思ってもらえるように、僕自身も精進しないといけないと日々思っています。
2年間Mackerelのディレクターをやってみて
そんなこんなでMackerelのディレクターをやってきて、はや2年近くが経とうとしています。
監視システムはSoRだと考えられがちですが、MackerelはSoEな側面も強く持っているユニークなプロダクトです。
また、エンジニア的な観点では、Mackerelが採用している技術も多岐にわたり、システムとして興味深いこと、ドッグフーディングしながら開発できること、ユーザーが利用している技術もキャッチアップする必要があるなど、非常にチャレンジングな環境です。
ユーザーの皆様もとにかく温かく、エンジニアコミュニティーの素晴らしさを改めて感じています。世界にもっと挑戦していけるプロダクトに成長させていく予定ですが、それについてもユーザーの皆様が応援してくださっているのも感じていて、ありがたい限りです。
そんな中でディレクターを任されていることは本当に幸せなことで、これまでエンジニアとしてキャリアを積んできてよかった、と実感しています。
仕事やキャリアに対するスタンス
僕は「自分の働き方は自分で決める」と思っています。キャリアは見えないくらいのほうがその場その場で自分で決められて、結果として楽しいし安定してるんじゃないかと思っています。変化が激しく成長している業界か、固定化して停滞気味になっている業界か、どの辺りに自分の身をおくかは選択の問題ですが、僕にとってはWeb業界はかなりフィットした業界だと感じています。
僕はわがままなので、やりたいことだけをやりたいし、今本当に自分のやりたいことができているかは自問しています。「今はつらくてもいい」とか「我慢している」というのは自分への言い訳で、思考停止だと考えています。そういう状態でも、なんで今やっていることがつらいのか、どうやれば楽しくなるのか、面白くなるのか、を自問するようにしています。
それを踏まえて自分のやりたいことを考えると、僕はコードを書きつづけてエンジニアとして成長し続けつつ、その技術で問題を解決して、チームでモノ作りがしたい、と思っています。はてなには、素晴らしいエンジニア陣の他にデザイナーもプランナーも、編集も営業も総務もプロフェッショナルが揃っていてそれを実現するには良い場です。
ディレクターになって、コードを書く機会は以前より減りました。仕事の内容も変わってきているため、ピーターの法則に抗って歯を食いしばっている日々です。
ただ、全員が同じ働き方をし続けて上に上がって行く組織の方がピーターの法則に嵌りやすいのではないでしょうか。また、組織構造上、新しい働き方ができるようになっていないとどうしてもピーターの法則は起こってしまうように思います。なので今、僕が単なるエンジニアではない働き方ができているのは多様性の観点からも喜ばしいことです。これからも、社内で、新たな働き方を模索し続けて、自分と会社を成長させ続けられると良いな、と思っています。
理想論気味なことも書きましたし、僕自身もまだまだ実現できていない理想的なことも書いてしまいましたが、はてながそういう理想論が通じる組織であり続ければいいな、と思っていますし、そういう組織であり続けられるように僕自身もはてなにコミットしていくつもりです。
自分の働き方は自分で決める。それが一番実現できる環境だと思っているので、僕は今はてなで働いています。
