マネジメントに対する認識

昔からマネジメントに対して強い苦手意識があった。
しかし、最近マネジメントに対して以前よりも抵抗が少なくなり、マネジメントをもっと学びたいと思うようになった。
そこで、自分なりにマネジメントについて整理してまとめてみる。
（主にソフトウェア開発の業界におけるマネジメントになります。）

マネジメントが苦手と感じる理由

管理が苦手

マネジメントは直訳すると「管理」と訳されることが多い。また、日本では「管理職」と呼ばれる役職があり、管理職の人がマネジメントをする人というイメージがある。しかし、私は何かを「管理」することがとても苦手な自覚があり、マネジメントに対しても苦手意識がある。

計画が苦手

マネジメントをする立場になると、自分より上の立場の人から計画を求められることが多い。しかし、ソフトウェア開発の仕事はやってみないと分からないとが多く、計画を立てるのが難しい。そして、最初に立てた計画通りに開発を進められることがほとんどない。

そのような経験から、私にはマネジメントは向いていないと思うようになった。

 きっかけ

上記の理由からマネジメントに対して苦手意識があり、マネジメント力を向上したい欲もあまりなかったのだが、きっかけがあって今は以前よりもマネジメントを学びたい欲が出てきている。きっかけは、現在私が参画している開発案件におけるプロダクトマネージャーの存在である。

現在私が関わっている案件では、開発チームの中にマネージャーの立場の人間はいない。
代わりに、お客さんの中にプロダクトマネージャー（PdM）と呼ばれる役割の人がいて、その人と日々コミュニケーションを取りながら開発を進めている。そのプロダクトマネージャーの方と一緒に仕事をしていると、マネジメント力が高く、めちゃくちゃ仕事ができる人だというのが伝わってくる。

しかし、開発に関する細かなスケジュールやタスクなどはプロダクトマネージャーが管理しているわけではなく、開発チームメンバーが自分たちで管理している。
また、そのプロダクトマネージャーは開発者としての経験はなく、ソフトウェア開発に関する専門的な知識はあまり持っていない。
開発に関するリソースを細かく管理しているわけでもなく、技術的な知識を持っているわけでもないのに、マネジメント力が高く、仕事も早く、相談もしやすい信頼できる人である。

そんな人と仕事をするようになって、マネジメントに対して様々な疑問が生じた。

• なぜマネジメント力が高いと感じるのか

• なぜ信頼できると感じるのか

• なぜ技術的な知識がないにも関わらず、問題解決時に相談したいと思えるのか

• そもそもプロダクトマネージャーとは何をする人なのか

• マネジメントの本質とは何なのか

そのような疑問を解決すべく、マネジメント、そしてプロダクトマネジメントについて自分なりに勉強してみた。

プロダクトマネージャーとは

恥ずかしい話、今の案件に関わるまでプロダクトマネージャーという職種を知らなかった。今までプロジェクトマネージャーの人とは多く接してきたし、自分自身がプロジェクトマネージャーとして働いていたこともある。
しかし、プロダクトマネージャーがいる案件は今関わっている案件が初めてであった。

仕事内容は名前の通りプロダクトの価値を高めることを目的としたマネジメントをすること。

• プロダクト開発の方向性を決める

• 開発計画を立てる

• 開発に必要な情報収集をする（ユーザーヒアリングをするなど）

• 開発した機能の効果を測定する

• 開発に関する課題解決

など。
仕事を進める上で必要な能力としては以下の要素がある。

• コミュニケーション力

• 論理的思考力

• 情報収集力

• 分析力

• 意思決定力

プロジェクトマネージャーとの比較

一方でプロジェクトマネージャーの仕事は何か。
一般にプロジェクトはQCD（Quality, Cost, Delivery）を守ることが目的になることが多い。つまり、決められたコスト（リソース）で決められた納期までに一定の品質で納品すれば無事プロジェクトの目的達成となる。

つまり、プロダクトマネージャーはプロダクトの価値を高めることを目的とした仕事をする人で、プロジェクトマネージャーはQCDの達成を目指して仕事をする人ということになる。

それぞれの必要性

プロジェクトマネージャーとプロダクトマネージャーはそれぞれ役割が違う。どちらかが必要でどちらかが不要というものではなく、プロジェクトの特性やプロダクトの特性、チームの特性やメンバー構成などの違いでそれぞれの必要度合いが異なってくる。
私が現在関わっている案件には身近にプロジェクトマネージャーの役割の人はおらず、プロダクトマネージャーとしか関わっていない。それでも開発はうまく回っているが、開発内容によってはプロジェクトマネージャーの方が必要になることもあるだろうし、両方が必要になる場合もあるだろう。

開発手法による必要性の違い

ソフトウェア開発の進め方は大きくウォーターフォール型とアジャイルに分かれる。一般にウォーターフォール型の開発ではQCDを達成することが目的になることが多く、アジャイル開発の場合は顧客やユーザーへの価値提供が一番の目的になることが多い。
QCDの達成をゴールとする場合には、リソースを効率よく使っていく必要があるため、プロジェクトマネジメントが大事になる。一方で価値提供を目的とする場合、プロダクトの価値を高める必要があるため、プロダクトマネジメントが大事になる。
もちろん、ウォーターフォール型の開発でも多くの人が価値あるものを提供したいとはっているだろうし、アジャイル開発でも納期が設定されて期限までに間に合うように開発を進めなければいけない場合もある。
開発手法や開発目的、優先度に応じて何に重きを置いてマネジメントすべきかをうまく見定めることが大事であるように思う。

マネジメントとは

ここまで、プロダクトマネジメントとプロジェクトマネジメントについて説明してきたが、ここでやっとマネジメントそのものを深ぼる。

マネジメント（management）はGoogle翻訳で直訳すると「管理」となる。
一方、マネジメントの原点であるドラッガー先生の言葉によると、マネジメントとは

と説明されている。
では、そもそも「管理」とはどういう意味なのか。

個人的な感覚としてはこの2つがイコールで結びつく感覚はない。
ただ、大量生産のモノづくりのような、決められた作業を繰り返していくような仕事の場合、上下関係を明確にして上の立場の人が下の立場の人を管理することが、成果を上げさせるための最適な手段なのかもしれない。
つまり、業種・業態によっては「管理」がマネジメントの最適解となる場合もあるのかもしれない。

ソフトウェア開発のマネジメント

では、ソフトウェア開発の場合はどうだろうか。
ソフトウェア開発は不確実性の高い仕事であるため、プロジェクトの開始時に精度の高い見積りや計画を作ることは難しく、計画通りに進めることも難しい。
このような仕事では「管理」をすることが成果を上げるための最適な手段になることはなく、成果を出すためには適宜必要な人とコミュニケーションを取りながら柔軟に変更に対応していく必要がある。
「プロジェクトマネージャーの仕事の9割以上はコミュニケーション」と主張している記事や書籍は多く、プロダクトマネージャーについても仕事ぶりを見ていると多くの人とコミュニケーションを取ることに時間を割いているように感じる。
「マネジメント＝コミュニケーション」と定義するのはさすがに乱暴かもしれないが、少なくとも、ソフトウェア開発においては管理よりもコミュニケーションが成果を出すために必要な道具ではあるように思う。

リーダーシップとの違い

日本ではリーダーとマネージャーの違いが曖昧になっているケースが多いように感じる。「上に立つ人＝管理職」であり、管理職がリーダーでありマネージャーである空気感がある。ここではリーダーシップとマネジメントの違いを深掘りする。

書籍「アジャイルリーダーシップ」では違いを以下のように説明している。

書籍「7つの習慣」では以下のように説明している。

書籍によって解釈の仕方は色々だったが、私なりにまとめると以下のようになる。

• リーダーシップは人を動かすスキル

• マネジメントは人の動かし方を最適化するスキル

• マネジメントはリーダーシップを内包する

• つまり、マネジメントはリーダーシップを伴う人が行うもの

リーダーシップのあり方

マネジメントの話とは少し逸れてしまうが、マネジメントはリーダーシップを内包するため、ここでリーダーシップについても触れておく。
リーダーシップには明確な答えはなく、リーダーの性格や特性に合わせて様々なリーダーシップのあり方が存在する。例えば以下のようなタイプがある。

• 自ら率先して他のメンバーを引っ張るタイプ

• メンバーを俯瞰で見ながら支えていくタイプ

• 明確なルールを作って仕組みで人を動かすタイプ

どのようなリーダーシップが良いのかはリーダーの考え方次第だが、組織構造やメンバー構成によってもリーダーシップの最適解は変わってくるように思う。

アジャイルリーダーシップ

書籍「アジャイルリーダーシップ」ではアジャイル開発におけるリーダーシップの特徴を以下のように説明している。

アジャイルリーダーシップの中では、ピラミッド型の組織は組織1.0と定義しており、比較的変化が少ない環境ではうまくいくが、変化の激しい時代においてはうまくいかないとしている。

ピラミッド型組織のリーダーシップ

書籍「リーダーの仮面」では、ピラミッド組織構造を推奨しており、メンバーと一定の距離を置き、権限やルールによって人を動かすことによるリーダーシップを推奨している。

個人的な好みはあるだろうが、どちらが正しい、間違っている、という話ではなく、自身が所属する組織やチームの構造や特性に合わせて最適なリーダーシップのあり方を選択できる状態が良いと思う。

経験談

私が新卒で最初に入社した企業は、ウォーターフォール型の開発手法が多かった。そのような開発プロジェクトでリーダーを経験したことがある。
私は上記でいうところのアジャイルリーダーシップ型のリーダーシップを好んでいて、自分自身の振る舞いで人を動かそうとしていた。

結果、自分のことを信頼してくれていた後輩は、予想以上の働きをしてくれ、とても助けられた。しかし、私より経験のある先輩や、関係性が薄いメンバーは、指示された以外の仕事はせず、頼りになる存在とは言い難い働きしかしてくれなかった。
今考えると、自分のことを信頼している人に対してはアジャイルリーダーシップ的なリーダーシップが有効で、そうではない人に対してはリーダーの仮面的なリーダーシップが必要だったのだと思う。
同じ仕事の中でも、関わる人が多くなると相手によってリーダーシップのあり方を最適化していくことが大事なのだろう。

開発者のキャリアと役割分担

開発者のキャリアとして今でも一般的によくあるのが、開発者を数年経験した後にマネージャーになるという道である。
しかし、それが本当にキャリアアップなのかはとても疑問である。
どちらかと言えばキャリアチェンジであると思う。

私が現在の案件で接しているプロダクトマネージャーの方は、開発者としての経験はない。しかし、とても信頼できるマネージャーであるし、私が歴代一緒に仕事をしてきたマネージャーの中でもずば抜けて仕事ができる人だと感じている。
一方で、技術に長けている人がマネジメントをしている案件において、マネジメントが上手だなと感じた人はほとんどいない。むしろ、「技術はすごいけど、育成やマネジメントは向いていない」という人の方が多かった印象がある。私自身、社内で技術力を評価してもらえた中でプロジェクトマネージャーを経験したことがある。開発者としてはプロジェクトに貢献できたが、マネジメントがうまくできていたかと言うと、あまり自信はない。

つまり、開発者としてのスキルとマネジメントのスキルは相関関係はない。
将来マネージャーを目指したい人は、開発者としてのスキルは最小限にとどめて、マネジメントに特化したスキルを磨いた方が良い。
逆に、開発者としてのスキルを伸ばしたい人は、下手にマネジメントする立場にならない方が良いのかもしれない。
自分には何が向いていて、何にやりがいを感じるかはやってみなければ分からないことも多いので、経験として開発者とマネージャーの両方の立場を経験するのはありだと思うが、最終的に目指す方向を1つに決めて進んだ方が良いのではないかと思う。

知らないからこそうまくいく

何度か言及しているが、私が現在一緒に仕事をしているプロダクトマネージャーの方は開発経験がない。だからこそだと思うのだが、新しい機能開発の話が浮上した際には、実際に開発する人に見積りを依頼してくれる。また、課題を相談した際には、その課題を解決してくれそうな知見を持つ技術者を探して話す場を設けてくれる。
自身が開発について深い知識がないからこそ、コミュニケーション力によってうまく人と人をつなげて最適な形で課題解決を図ることができているのかもしれないな、と思うようになった。
また、開発のスキルがないからこそ、いつも開発者や開発者のスキルを尊重していることが伝わってくる。
技術者のことを尊重して頼ってくれるからこそ、こちらも信頼できるし、ストレスなく仕事を進めることができる。

開発者を経験してマネージャーになった人は、自分自身の感覚で見積りやスケジュールを作成してしまい、現場とのギャップが生まれてしまうことも珍しくない。マネジメントが高いが開発者としてのスキルがあまりないというのは、実はソフトウェア開発のマネジメントをする上では強みとなり得るのではないかと思っている。

開発者の成果の見える化

最近、ソフトウェア開発のマネジメントにおいて重要だと思うのが、開発者の成果の見える化、及び成果を測定すること。
ソフトウェアというのは、アウトプット自体が価値を生むわけではない。
出来上がったツールやサービス、機能を使うことでどのような価値が生まれたのかが大事なのだが、その効果を正しく測定するのはなかなか難しい。

私が今関わっている案件で開発しているのは、とある企業の社内システムである。オペレータの作業を効率化する目的で社内システムの小規模改善を行っている。社内システムはあくまでもオペレーターの作業効率化ツールのため、便利になっても直接的に企業の売上に貢献されるわけではない。
それでも、今の開発チームは1年以上継続して存続している。
チームを存続させるには当然それだけの予算が必要になるが、我々の開発によりどれだけ作業効率が上がって効率化されたのかをプロダクトマネージャーやオペレーターが協力して計測を行ってチーム存続のために動いてくれている。

ソフトウェア開発の仕事は、一般にスキルを評価するのが難しいし、開発の成果が直接的に価値になるわけではないので、成果とお金を結び付けるのも難しいケースが多い。そのため、開発者としては、開発のスキルによる貢献度をマネージャーが測定してくれるのは非常にありがたく、とても感謝している。このようなマネージャーの元で働けるのは幸せだし、自分がマネジメントする立場になったときにも、現場の開発者がどれだけの成果を出しているのかを計測して感謝を伝えられるマネージャーになりたいと思った。

改めてマネジメント対する認識の整理

管理に対する認識

先にも書いた通り、私は何かを「管理」するのが苦手である。
管理の煩雑さは手動で頑張らずに便利な技術を使って解決した方が賢いと思う。また、スケジュールや仕事の進め方を人に管理されるのも苦手である。
人に管理されるのが苦手なので、人を管理するのも苦手である。
それゆえ、マネジメントに興味が出た今でも、「管理職」という名前の役職
には全く興味がない。

計画に対する認識

計画を立てること、計画通りに進めることも未だ苦手なのだが、計画に対する捉え方も最近になって変化があった。
そもそも不確定要素の高いソフトウェア開発の仕事において、正確な見積もりや計画を立てることは非常に難易度が高く、どれだけ経験を重ねても無謀であることがわかった。不確定要素の高い仕事については、計画づくり自体を繰り返しながら徐々に制度を上げていく取り組みをする方が大事だと思うようになった。

マネジメントに対する認識

マネジメントに対する考えを整理する中で、「マネジメント＝管理」という考えは徐々になくなってきた。この認識は早く日本社会からなくなってほしいし、「管理職」という言葉もなくなってほしいなと思う。
管理には興味はないが、マネジメントについては学んでいこうという気持ちになっている。仕事の価値を高めていくために必要なスキルを「マネジメント」と捉え、今後より深く学んでいきたいと思う。

まとめ

• マネジメントとは、成果を上げるための道具

• ソフトウェア開発のマネジメントにはプロジェクトマネジメントとプロダクトマネジメントがある

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

  • プロジェクトのQCD達成のためのマネジメント

  • ウォーターフォール型開発向き

• プロダクトマネジメント

  • プロダクトの価値を高めるためのマネジメント

  • アジャイル開発向き

• どちらのマネジメントも重要なのはコミュニケーション

  • お互いの立場やスキルを尊重することで、信頼関係が築け、スムーズに仕事を進めることができる

• リーダーシップは人を動かすスキル

• マネジメントは人の動かし方を最適化するスキル

  • マネジメントはリーダーシップを内包する

  • リーダーシップの最適解は組織構造に大きく依存する

• 開発のスキルとマネジメントのスキルは関係がない

  • つまり、開発ができなくてもマネジメントはスキルは身につけられる

  • 逆に、開発ができるからといってマネジメントスキルが高いとは限らない

• 開発者の成果を計測することはマネジメントの中の重要な仕事

参考にした書籍