マイクロマネジメントしない技術、されない技術

プロダクトマネージャとして、年商数億円レベルのサービスのWebシステムのプロダクトマネージャを3年ほどやっている。
マネージャだけど、マネジメント自体はやりたくもないし、マネジメントされたくもない。

なぜ、マイクロマネジメントされない技術、しない技術が必要なのか

プロダクトマネージャとして、プロダクトのシステム大方針検討・決定（技術的負債の返済計画、注力すべき方向性、定期的なKPIの設定）、システム改善案の企画的レビューから、コード、テストケースレビュー等まで、開発の流れ改善、KPIの結果悪化時の分析等を行っている。
空いた時間で（あまりないのだけど）、たまに実装やら、インフラ的な改善を行っている。
開発者2名、QA1名という体制で、専任のデータ分析担当、デザイナーはいない。
プロダクトをどうするかの方向性の責任（プロダクトマネージャ）と、開発における責任（プロジェクトマネージャ）を負っている。
プロダクトマネージャからの評価が高い書籍「INSPIRED」でも、プロダクトマネージャとプロジェクトマネージャは分けるべきということが書かれているとおり、まあ、時間が足りない。
最近は、元々のサービスに加えて、新規サービスの立ち上げに関わり、こちらでもプロダクトマネージャ兼プロジェクトマネージャみたいな役割で入り、さらに時間が足りなくなった。
こんな中、チームメンバーをマイクロマネジメントしていたら、とてもじゃないが仕事がまわらない。そして、チームメンバーも細かくうるさくマイクロマネジメントされるのもほとんどの人は好きじゃないはず。
ただし、最近は、マイクロマネジメントされる方が好きな人もいるんだろうなぁとは思ってきてはいる。マイクロマネジメントされる方が、自分で考えないですむし、責任を取らなくてよいから。

きちんとシステム戦略、システム方針を作る

・年間で月別に何に注力するか、何をやるかという大項目の概要をわかるようにする（いわゆるプロダクトのロードマップみたいなもの）
・大項目の優先順位を付けている
・市場状況、サービスの課題によって、見直し、変更することもあるので、定期的に説明もする
これによって、メンバーがサービスは、今何が重要な課題で、どこに向かっているのかを把握することができる。すると、大量にあるタスクの中で、メンバーが優先順位を判断しやすくなるので、マネージャがいちいち指示しなくてもすむ。

バックログ（タスク）を管理する

ビジネスサイドとのバッグログの管理

事業責任者含むビジネスサイドとエンジニアでシステム改善案を定期的に、やるかやらないか優先順位、要件、仕様整理を行った上で、バッグログに転記している。この定期的な要件、仕様整理もポイントで、基本的にビジネスサイドは、まるっとした曖昧な起票しかできないことが多いので、起票の仕組みから、どのレベルまで仕様を整理するかを改善してきた。

起票の仕組み

フォーマットを用意して、
■背景
■課題
■要望案
■効果をどう測るか
を書いてもらうようにしている。

この中では、課題が一番重要である。
課題の大きさによって、対応の優先度、課題を解決できたことによる効果が高いので、何よりもいい課題を出してもらうことが重要である。
課題に、住所を登録できないこと 要望案に、住所を登録できるようにすること みたいな、それは課題ではない。住所が登録できないことによって、何が課題なのか？というやり取りもするのだけど、少しずつ改善しているような気はする。

要望案は、あくまで案であり、要件、仕様整理の結果、変わることはしょっちゅうある。「課題」を書かず、「要望」だけを起票してもらっていたときは、思いつきな要望が多く、たしかに、これ対応したら、便利かもしれないけど、それって、重要だっけ？みたいなやりとりが多かったように思う。それを毎回ゼロからヒアリングして、再整理するのも時間がかかる。

効果をどう測るのかは、いい要望案なんだけど、なんとなく良くなったか分かるよりも、ちょっと仕様を変更して、確実に改善したかどうかが分かる仕様にすることがけっこうある。
起票者が言いっぱなし、エンジニアが実装しっぱなしにならないで、きちんとABテストなり、データ集計なりで効果をわかるようにしており、機能としては、実装したけど、実は測れないんじゃね？となり、あとから追加でデータ項目なり計測の仕組みを実装して、デリバリーが遅くなることも防ぐことができる。
曖昧な機能は、ささっとAdobe XDで画面、画面遷移イメージを作ってしまって、合意を得てしまう（Adobe XDはわりとPhotoshop, Illustratorと比較して、エンジニアでもささっとキャッチアップできてしまうので、お勧め。キスピーディなキャッチアップの方法は、Adobe XDを最短で習得する方法　に記載している）。
手戻りがかなり減るのと、要件、仕様検討に入っていないエンジニアに正確にスムーズに仕様把握してもらえるのでメリットがかなり大きい。基本的に、起票内容とAdobe XDがあれば、ある程度のシステム改善のコミュニケーションはうまくまわる。中、大規模の場合は、キックオフ的な感じで、ビジネスサイド、エンジニアと対面で認識あわせをしている。

エンジニアサイドでのバックログの管理

・ビジネスサイドとのバックログ管理で優先度が高いタスクのみ（要望全部は絶対やらない）
・エンジニア改善（リファクタリング、バージョンアップ、技術的な新しい仕組みの導入）タスク
・不具合タスク
のみをエンジニアのタスクとして管理している。
エンジニア改善は全工数の20%以内なら、自由にやってよいとビジネスサイドと合意を得ているので、ある程度自由にやっている。JIRAでバックログ（タスク）を管理していて、JIRAにのっていないタスクはやらない。絶対やらないし、絶対やらせない。
ただし、雑務的な時間はどうしても発生するので、雑務というタスクを作っていて、雑務の時間をトラッキングして、スプリントで雑務の時間が多かったら、振り返りをして対策をしている。なので、マネージャである自分のタスクもみんなからチェックされている。優先度もついているので、その順にメンバーにタスクを進めてもらえばよい。QCD上のC（コスト）のチェックになる。Qは本番環境での不具合数なりでトラッキング、コードレビューで担保している。D（デリバリー）的には、CがOKであれば、リリースも早いでしょうという思想。実際は、マルチタスクだったり、どこかでボトルネックが発生したらデリバリーに影響があるが、そこらへんは、スプリントの振り返りで気づいて、改善できるようにしている。

エンジニアの毎日のタスク管理（セルフマネジメント）

Google カレンダーにその日やったことと次の日の予定を入れてもらう

googleカレンダーの画面キャプチャをslackに記載してもらっている。あー、これにこのくらいかかったのかとか、これ詰まっているんじゃないとか分かる。貼ってもらったslackの画像を見て、何このタスク？みたいなときに、slackで聞ける。

よかったこと。困っていることも毎日書いてもらう

困っていることをすぐに解決できる。スプリントで振り返りを行っているのだが、2週間ごとなので、どうしても課題があったときに、対策、アクションまでにタイムラグが発生してしまう。そのため、スプリントの振り返りを待たずに、困っていることに気づき、対策を取ることができる。
ただ、「困っていることを書いてください」と伝えても、なかなか書いてもらえないのが難しい。QA担当者が「特に、困っていることなし」と書いているのだけど、どう考えても、QAに着手できるPRがなくなってきつつあるタイミングがあり、ホントに困ってないですか？というやり取りをしたことがある。それって、困ってません？みたいな。それ以降、そういうタイミングでは、自発的に共有してくれて、開発者が、仕掛中のPRを早めに仕上げてくれたり、それぞれのメンバーがアクションをとってくれるようになった。ある程度はマネージャーである自分が、テコ入れするが、これが、メンバーがチームとして共同作業として、自走できる下地になる。
困っていることを気付くということは、ホントに難しい。これは、今のプロジェクト的に、エンジニアは2人とも別のところで働いているし、QA担当者も別のところで働いていて、自分も在宅勤務をすることがあるので、困っていることは非常に気づきにくいので、こういう施策はとても有効だ。
困っていることは、さらに改善すると自省を促し、日次で振り返って、自分で何らかの対策案を考えて、次の日にでも試すことを狙っている。少なくとも、自分はそうしている。これ課題だけど、明日、これ試して解決してみっかみたいな。

タスクのプロセスを改善する

以前は、bitbucketを利用していたが、ラベルをつけられなかったのでgitlabに移行した。なぜ移行したかというと、PRに対して、ラベル管理ができなかったから。ラベルでPRの状況、誰がタスクを持っていて、どんなアクションをすればよいかわかるようにして、マネージャである自分が指摘しなくても、タスクがスムーズにまわるようにした。

まとめ

ポイントは
・ゴール、成果イメージを定義して、そこにメンバーが自走できるようにすること
・タスクのプロセスを定義して、改善を回せるようにすること
・課題にすぐ気付けるようにして、いざとなったら、テコ入れできるようにすること

つまりは、
・人ではなくアウトプットとタスクのプロセスをマネジメントすること
・細かいタスクの進め方はメンバーにセルフマネジメントしてもらうこと

逆に、マイクロマネジメントされる側の立場として、どうすべきか

ゴールが曖昧だったり、背景を省略される事が多い。ゴールが曖昧だからこそ、とりあえずxxやってください、yy作ってくださいみたいな御用聞きみたいな事になる。
タスクの大、小に関係なく、依頼者がビジネスサイド、何らかのマネージャーかに関係なく、背景を理解し、ゴールを徹底的に詰める。まずはそこからだ。
背景があり、どんな課題があり、どうなって欲しいのか（=ゴール）。ゴールに対して、どんなアプローチ（方法、タイミング）があるのかを複数提案、決定、揉んでいく。
そこまでいけば、マイクロマネジメントどころか、いつの間にか自分でタスクをコントロールしていることになる。

大事なことは、QCDと信頼関係

品質、コスト、デリバリーに問題があれば、それはビジネスサイドなり、マネージャなりがマネジメントするためにテコ入れ、マイクロマネジメントすることのきっかけになる。それは、問題が大きいほど、たくさんあるほど管理項目、トラッキング項目、頻度を増やすことになる。QCDと信頼、鶏と卵的な関係があるが、信頼があれば、QCDへの管理は弱まるし、QCDへの満足があれば、信頼関係も高まる。
結果、アウトプットを見えるように出そう。