エンジニアリングのマネージメント

2014/12/02

こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。

このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。

さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。

エンジニアリングマネージャーとはどのような責任を持っているか

エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。本題に入る前にまずは「責任」という言葉の定義について確認しておきます。

「責任」と一言で言うと様々な意味合いがあるかと思います。様々な解釈や定義がある中で、最近最も自分の中でしっくり理解できたのが次の説明です。

日本語の「責任」の意味するところには、英語で言うLiability, Responsibility, Accountabilityの三つの語義が混じっている。Liabilityは法的責任（主に賠償責任）、Responsibilityは最後まで任務を完遂する実行責任、そしてAccountabilityは出処進退を伴う説明責任を意味する。ところが「説明責任」というのは（苦心の訳語だったろうと思うのだが）、最近ではいつのまにか意味するところが矮小化されて、「説明という行為をする責任」という風に使われることが多い。
（トラブル原因分析を、責任追及の場にしてはいけない（タイム・コンサルタントの日誌から）より）

Liabilityは法令はもちろんのこと会社などに対する契約が該当します。この点については明文化されているはずですからあまり疑いの余地はありません。
Responsibilityを考えてみると、マネージャーという役割における実行責任というとグリーの「常に前向きに挑戦する。成功するまでやり続ける。」といった行動規範やドラッガーによる

組織は最終的な決定を下すものを必要とする。危機にあっては、その者が指揮をとる。
(PFドラッガーチェンジリーダーの条件 p118より)

というところから危機においてもやりきる、というような責任のことだと考えるのが良さそうです。
次にAccountabilityは説明責任と訳されているときにはあまりピンと来ませんでしたが、出処進退をともなう、という意味合いからよりうまく理解できるようになりました。「けじめをつける」などというときの文脈における責任として考えると適当かもしれません。

優先順位はどのように決めていくのか

責任について理解が進んだところで、エンジニアリングマネージャーの仕事の内容について考えたいところですが、ぐっと我慢して先に優先順位について考えておきます。この記事を何度も書き直しながら考えましたが、仕事の優先順位についてはJohnson & Johnsonによる我が信条(Our Credo)に書かれている順序しかないだろうと思っています。大まかには

  1. 我々のサービスを使用してくれるお客様、取引先
  2. 全社員
  3. 地域社会
  4. 株主

という順に責任を持つべきとしています。エンジニアリングマネージャーとしての優先順位もこれに準じるべきと考えています。

グリーのようなゲームやSNSなどのサービスを使ってくださるお客様はもちろんのこと、取引先の方々についても我々は責任を持っていくべきということです。ゲームやSNSのインフラ開発を担当している私たちのチームは、サービスを利用してくださるお客様だけでなくゲームやSNSを開発している社内外の方々も当然最優先であると考えていく必要があります。ただ、これはなんでもお客様の要望を聞いていくということではなく故三波春夫氏による「お客様は神様です」と同様に、故三波春夫氏によれば「完璧な藝をお見せすること」、Johnson & Johnsonによれば「顧客一人一人のニーズに応えるにあたり、我々の行なうすべての活動は質的に高い水準のものでなければならない」という姿勢であると理解しておくべきと考えています。

次に、全社員とありますがマネージャーになるとついつい自分の属するチームのメンバーを中心に考えてしまいがちですが、周囲に関わる多くの社員に対しても責任があると考えておく必要があると考えています。組織が大きくなると政治的な意識が働くこともあり、次第に自分の属しているチームに対する個別最適手段を取ってしまいがちです。それらの個別最適が、第一の責任であるお客様に対する不利益となることもしばしばありますから、いかに大変であったりしても、広い視野に立ち返り優先順位を見直していく必要を感じています。チームメンバーに対してはキャリアパスやモチベーションといった能力開発に関わる考慮も必要となります。

3つめの地域社会とは、地理的な地域以外にもオープンソース・コミュニティーへの貢献なども含まれると考えていいでしょう。

最後の株主に対する責任は、Johnson & Johnsonによれば「事業は健全な利益を生まなければならない」とあるとおり、利益に対する責任を考えておく必要があります。利益について優先度が第4番目であることも理解しておきたいところです。ドラッガーによれば

利益と収益性は個々の企業にとって重要であるとともに、社会にとってはさらに重要である。だが利益は、企業と企業活動にとって、目的ではなく制約条件である。
(PFドラッガーチェンジリーダーの条件 p27より)

とあるとおり、利益は制約事項であるとのことですから、ひたすら利益を最大化するという舵を切るのではなく、我が信条(Our Credo)にある4つの優先順位を見直し確認していくことが必要となります。

ここまで書いてみて、なかなか硬くて偉そうな文章になったものだと、見返しているのですが、どこまで上手に自分が立ち振舞えたかはまた別の機会に反省するとして、様々な失敗をするたびにこの優先順位を思い出してはそのたび、この優先順位以外ありえないのではないかと実感しています。

エンジニアリングマネージャーの役割

責任と優先順位について理解が進んだところでエンジニアリングマネージャーの役割について考えてみます。役割についてもいくつか分類ができるとおもいます。いろいろな角度での切り口があるかと思いますが、ここでは下記3つに分類してみました。

  • プロジェクトマネージメント … プロジェクトのスケジュール、人員アサイン、コスト、品質などについて責任を持つ
  • ピープルマネージメント … メンバーの能力開発、モチベーション、体調、勤怠などについて責任を持つ
  • 技術ディレクション … プロダクトや組織としての技術的な方向付けについての責任を持つ

組織やプロジェクト規模によってはそれぞれプロジェクトマネージャー、人事的なマネージャー職(課長・部長等)、アーキテクトやリードエンジニアといった役割を基準に役割を複数名に分割していくこともあります。グリーのインフラ開発では、規模と技術的な要求からプロジェクトマネージャーについては専任のチームが存在しますが最終責任ということではエンジニアリングマネージャーが責任を持っています(どちらかというとプロジェクトマネージメントチームの役割はPMOに近い)。

これらそれぞれの役割と実際にやってみたこと・やろうとしていることについてもう少し詳しく見ていきます。

プロジェクトマネージメント

プロジェクトマネージメントはPMBOKやPRINCE2など様々な体系や方法論がありますし、ITプロジェクトマネージメントでいえばウォーターフォール開発やアジャイル開発といったプロジェクトの進行方法など様々な選択肢があります。
このような様々な選択肢に対して、プロジェクトの性質に応じて方法論を組み合わせていくのがエンジニアリングマネージャーの役割の一つだと思っています。

メリット・デメリットを考慮した上でPMBOK、PRINCE2、RUPなどしっかりと知識体系化された方法論を導入していけば、悩むことも多少なりと減っていくように思えますが、現実的にはそれらの知識体系をしっかり身につけるようなトレーニングを受ける時間もとれないケースがほとんどです。グリーのサービスのように数週間〜数ヶ月といった短期間で作り上げてリリースするようなプロジェクトでは、数年間かけて作り上げられる金融や公共インフラといったプロジェクトとちがい、これまでに経験してきたプロジェクトでの反省や経験を生かしながら、プロジェクトごとにカスタマイズされた軽量な管理手法を編み出していくしかありません。

たとえば次のような簡単にはじめられる取り組みから少しずつプロジェクトに導入していき、チームからのフィードバックをうけながらプロジェクトの性質に合わせて改良してきます

  • JIRAを使ったタスクかんばんでプロジェクトの状況・タスクを確認する
  • プロジェクトを2週間程度のスプリントに分割する
  • ホワイトボードとポストイットを使ってPERT図を表現し、スタンドアップミーティングで確認
  • プロジェクトメンバー全員に状況をヒアリングしながらレポートをまとめる
  • プロジェクト関係者のミーティングを調整する(内容・頻度)
  • ガントチャート等を使ってスケジュールとリソース配分を調整する

グリーに入社して以来いくつものプロジェクトに参加してきましたが、プロジェクトの性質やフェーズ、優先度などに応じて刻々とやり方を変えていく必要がありました。言い換えると、どんどんやり方を改良していかなければいけない状況があるため、あまり重く大きなプロセスを導入することはできませんでした。

連続した時間

プロジェクトマネージメント、特にスケジュール調整などにおいて最も注意深くマネージメントしたいのは「連続した時間」が取れることです。30分 * 4の作業時間と2時間の作業時間では生産性は圧倒的に違います。課題が難しければ難しいほど、割り込みをなくし、集中して考えたり検証をするといったプロセスが必要です。

このため、特にミーティングのように時間を拘束する必要があるようなコミュニケーション手段を用いる場合はなるべくトピックをまとめて1度に済ませたり、ミーティングは月曜日・金曜日といった形で曜日を固定して集中できる時間を取れるようスケジュールしていきます。

ただこれも言うは易しで、実際には様々なプロジェクトが平行に動いていて、それぞれの文脈で情報共有・意思決定が必要となります。伝達が必要なメンバーそれぞれのスケジュール、部屋の空き状況、ミーティングの準備時間など様々な条件を満たしながら妥当なスケジュールを設定していくことになります。

ピープルマネージメント

エンジニアリングマネージャーとして特に気をつけているところは能力開発についてです。
能力開発において一番こころに響いたのは「教育とは、器を満たすことではなく、火をつけること」（ザ・ジャストインタイムより）という言葉です。技術は満点が何点なのかすらわからない分野ですから、何かの試験をして100点を取れるようになるまで何かを繰り返すようなことではなく、何か分野の方向性を示して面白そうだと火をつけていくことを大事だと思っています。
幸いにしてグリーのエンジニアは能力開発についてモチベーションが高く、勉強会や新しい技術習得について抵抗感がありません。ですから、あとはいかに効率よく技術習得ができるかその仕組みを考えたり、面白そうだという方向性を見つけていくことがエンジニアリングマネージャーとしての仕事だと思っています。

今年は社内勉強会などはもちろんのこと、インフラ開発合宿といった取り組みを行いました。
個人的な取り組みとしてはなるべく他業種あるいは古い技術などを見直す事によって、新しい発見ができるのではないかと思い、製造業や流通業などの文献などを参考にチーム内に展開するといったことを行いました。

その他これから実施してみようと考えている施策などについて紹介します。

20%ルール

業務時間の15〜20%を各スタッフの裁量によって自由な研究時間とする制度として多くの組織で実践されています。Googleが採用し、Google NewsやAdSenseといったプロダクトの誕生したり、古くは1948年、3Mにより始められPost-itなどの発明が生まれたことでも知られています。
このような発明が生まれた効果がある一方で、効果が得られず止めてしまったという話もよく見聞きします。グリーでもこの20%ルールに近い施策を何度か試しています。

組織間の調整が必要がない場合に効果的

業務時間の15〜20%というと1週間あたり6〜8時間、1ヶ月で3〜4日分になります。この時間内にある程度モチベーションを保ちながら、成果物として区切りを出そうとすると様々な人と合意を取りながら進めるのはかなり難しいと考えていいでしょう。アフリカのことわざで「If you want to go fast, go alone. If you want to go far, go together.（早く行きたいならばひとりで行きなさい、遠くへ行きたいのならばみんなで行きなさい）」という言葉があるそうですが、20%ルールの制約を考えるのであればなるべくひとりで完結するテーマを選ぶべきでしょう。

ゴミ箱モデルを採用するならば成果物の方向づけやデータベース化が必要

たとえば20%ルールをつかって、何かのアルゴリズムやツールを作るとして、技術的興味からスタートするとそれらは多くの場合何かに対する「解」であることが多いのではないかと思っています。DockerとSerfとConsulを組み合わせてクラスタ構成をつくってみた、とか、Kubernetesを試してみた。といったなんとなく未来を感じる技術に触れてみたいといったときに、20%ルールは役に立ちそうに感じますが、何かの「解」になるだろう。ということはわかってもすぐに使う場所を見つけられるとは限りません。

意思決定のモデルとしてゴミ箱モデルという方法があります。

人、問題、解をゴミと見立て、そのゴミをゴミ箱に見立てた「意思決定機会」に入れると、意思決定機会が満ちたときに結果が出ると考えたモデルである。
(Wikipediaより)

たとえばMap Reduceのような何かの「解」となるアルゴリズムがあったときに、たんにMap Reduceというアルゴリズムだけでは役に立ちません。大量のデータを高並列に集計したいといった「問題」があって、それを使いたい「人」がいないと実際には利用されません。
このため、20%ルールをつかってお客様に貢献していくためには、「人」「問題」「解」をデータベース化して(データベースといっても後でまとまって参照できるようになっていれば定型/形式的なものでなくても良い)いくのが良さそうだと思っています。

ただIT技術は一度何か「人」「問題」「解」のすばらしい組み合わせが発見されても、たかだか1〜2年の賞味期限であることがほとんどで、ほとんどの組み合わせは埋没していきます。このためあまりにも分野を不特定なまま20%ルールを適用しても費用対効果として合致しないため、「人」「問題」「解」それぞれにおいてある程度の見通しを立てて分野を限定していく必要があります。

技術ディレクション

さてエンジニアリングマネージャーの役割最後の一つとして技術ディレクションについて振り返ってみます。グリーのインフラでは今ではおなじみとなっているようなOpenStack、Chefのような技術や、ScalaやHaskellのようなプログラミング言語を使った開発など様々な方向性を模索し、また実際にかなり早い段階から商用サービスに適用してきました。

様々な技術を利用していることもあり、場合によっては当初目論んだ通りに性能や機能が満たせずに利用を停止するケース、場合によっては技術負債として時間をかけながらリプレースをしていかなければならないケースもあります。

ある意味手探り状態で様々なトライアンドエラーを繰り返し、技術負債といった痛みを伴いながら運用を続けてきたこともあり、必然的にある程度筋の通った技術を使っていこうという考えが芽生えています。筋の通った技術というのは、たとえばビジネス要件やスケジュール上、妥協案として浮かび上がってくるソリューションを排除して別の見通しの良い技術を導入するようなことです。このように、ビジネス要件やスケジュールの調整を行ってでも長期的な視点でのメリットを共有して意思決定していくといったところが技術ディレクションをしていくところの難しいところですが、面白いところでもあります。

ただ一方で、当初見通しの良いと思っていた技術でさえ時間が経てば技術負債となることもあったり、後から考えると間違った選択であったということもあります。そう言った間違った意思決定となることもふくめて、責任をもつのがエンジニアリングマネージャーだと思っています。

以上、かなりダラダラと、こうあるべきというような振り返りをしていきました。この一年、様々な文献を読んだりいろいろな方とお話をしたり、実際のプロジェクトで経験をしたことのまとめにはなっているかなと思っています。このまとめはそれほど外れていないと思っていますので、来年はこの考えをベースとして楽しいサービスが提供できるように努力していこうと思っています。

GREE Engineers’ Blogなのに2日連続でマネージメント的な話が中心になりましたが、いよいよ明日は松橋さんによる技術的なお話です。お楽しみに。