エス・エム・エスで開発組織のマネージャーをしている @sunaot です。余談ですが、このブログでは名乗るときにいくつかの言い方を過去にしていて、「技術責任者」「技術組織のマネージャー」なども名乗っています。面接の場では「プロダクト組織のマネージャー」と言っていたりもします。これは次々肩書きが変わっている...というわけではなく、どれもロールとしてはやっているので、そのときのコンテキストで一番適切なものを名乗っていました*1。今回は、開発組織のマネージャーとしての側面から話すのが適切でしょう。
さて、5月28日に開催されたファインディ株式会社主催のイベントで、「継続性視点での開発生産性マネジメント」というタイトルで発表しました。今回の発表内容は、映像が YouTube アーカイブに、スライドは Speaker Deck にそれぞれアップロードされ公開されています。
イベントのアーカイブ動画 『継続性視点での開発生産性マネジメント』
スライド 『継続性視点での開発生産性マネジメント』
そのため、細かな内容はそれぞれを見てもらうものとして、この記事では、
- 当日話した内容への補足
- 今回このテーマを選んだ動機
について説明をすることにします。
発表内容の概要と補足
発表内容を一文で説明するとしたら、「戦略志向の組織マネジメントを通して高い組織パフォーマンスを実現し、ビジネスと開発それぞれの継続性を手に入れよう」です。
戦略を考えるステップについてはスライド p44 に紹介しています。いかにこのコンテンツをつくるかについては、より具体的な事例を話すしかなく、今回はつっこんで話すことができませんでした。ここでは少しその補足をします。
まず、このようなプランを考えるときになにをやるのかやそのプラクティスがどれだけ切れ味鋭いかっこいいものかといったことへ意識がとられますが、そうした WHAT よりも大事なのが WHY にあたる部分です。このスライドでは、 「どのような状況か」「その中でどのような状態を目指すのか」「その過程でのイシューはなにか」の部分になります。今の状況をどう解釈するのかには無数の可能性があります。その中で将来に対しての見地から、「今はこのような状況だと見ている」というスタンスを明確に置くのがまず最初の重要な仕事です。多くの場合、ここがなんとなくの現状認識・共通見解というところからスタートしてしまい、その後のアプローチが弱いものになる傾向があります。
ここでスタンスを明確にしていくにあたり重要になるのが「その中でどのような状態を目指すのか」です。物事の良し悪しの評価というのは文脈によって変わってきます。今どのような文脈だと考えればよいかの指針となるのが目指すべき状態になります。
最後に「その過程でのイシューはなにか」です。おおよその文脈が定まり、現在地へのスタンスを明確にしました。それでも、そこからゴールへたどり着く道筋はたくさんあります。まずはその道筋の中から考慮に値するものを選択肢として挙げていきます。そして、それぞれの選択肢を評価していく中で、どのルートをたどるにしても壁になってくる問題というのが浮かび上がってきます。それが組織全員で取り組むべき重要なイシューです。イシューの設定が良質なほど、その後の解決のフォーカスや実現過程の組織の動きがぶれずに問題へ立ち向かうことができます。
一連のストラテジーを作るのは EM 一人の仕事かというと、そうとも限りません。どこまでのパートを一人で考えるか、周りを巻き込み答えをつくっていくかは状況によって最適解が変わってきます。組織でこのプランを組み立てられるようにしていくのが EM の大事な仕事になります。
このテーマとした動機
今回のイベントは Findy さんが主催し、開発生産性をテーマにこれまでも多数の発表がされてきているものです。発表の機会をもらえたときに、当然なにを話すのかを考える必要がありますが、実はやや内容に迷いました。というのも、私はあまり開発生産性を目的としてなにかを考えたことがなかったからです。
もちろん、デリバリーの効率を上げるために開発者体験を向上させることや、ムダを省くこと、早い失敗から開発のサイクルへ継続性をもたらすことといった開発生産性へつながるプラクティスの一つ一つは大事にして来ています。むしろ人よりもそこへ費やした時間は長い方だと思います。ただそれらは Time to market を短くしたいと求めた結果であって、開発生産性へこだわってやってきたわけではなかったりします。
そして、発表の中でも少し触れましたが、そうやって開発生産性の高い状況を求めても容易にそれが壊れうることも知っています。その最たるものはビジネスの状況悪化ですが、そこまで大きな要素でなくても、フィーチャー開発の過程でも環境への理解不足からデリバリーの効率のために投資したはずの環境はやはり壊れることがあります*2。
そうした理解の中で、開発生産性をことさらに取り立てて扱うことよりも、それを通して何を実現するのかへ目的を置いた発表内容にしたいと考えていました。そして、一般解としてのデリバリーの効率が高い状態を目指すのでなく、その効率というのも何に対して最適化させるかを考えるということを話すことにしました。ドメイン固有の問題を特定し、その問題に最適化をした解決をすることで、デリバリーの効率を上げることという機能効率の問題から、そのビジネスにおいて何がパフォーマンスを決めるのかという目的志向の問題へ問題設定を変えたかったのです*3。
発表では必要なプロセスの説明はしましたが、具体的な話をあまりできなかったので、こちらにも補足をしておきます。たとえば、ソーシャルゲームの開発をしている場合によくある話としては繰り返し行われるイベントをどう扱うのかという話があります。類似したフォーマットのイベントを繰り返すことでビジネスの成長は得られるため、そこへ最適化をして効率を高めるというのはよく採られている選択だと思います。ドメイン固有の解の一例でしょう。
では、これは良い選択なのかというと、組織の視点では様々なことが考えられます。イベントにはフォーマットがあるため、基本的にはフォーマットに沿ってパラメータを変える程度の開発へ人やプロセスを最適化したとします。これは他の新しい機会を開拓する能力を下げるかもしれません。反対にそこで生み出した時間の余裕によって、新しいチャレンジをする機会をつくることができるという理解も可能です。今自分たちが扱っているソーシャルゲームというものをどういうプロダクト、マーケットだと理解をするのかという前提の置き方で、答えは変わってきます。
こうしたことを考えながら、自分たちの組織にとって組織のパフォーマンスが出ている状態というのはどのような状態なのかを定義し説明可能にしていくことはとても重要なことだと考えています。なぜなら、それは長期的な組織マネジメントの土台になっていくからです。
*1:参考：「sunaotに聞いてみた・後編 あえてCTOを名乗らない理由」。
*2:だから無意味だというのでなく、だから常にメンテナンスを怠らず面倒を見続ける必要があり、たゆまぬその活動には高い価値があるという話です。
*3:デリバリーが重視される背景には、高いデリバリーの能力を持つことで結果的にマーケットに対する検証が高速に進み、それが次の価値を生む可能性を高めるという考えがあります。それ自体は否定していません。ただ、同時にドメインの視点も持ちながら考えていくことが良いと考えています。
