読者です 読者をやめる 読者になる 読者になる

冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Mng.Strangelove

その他 結論もなくダラダラと

または私は如何にしてプログラミングをするのをやめてマネジメントを愛するようになったか。

すみません、言いたかっただけです。

engineer.crowdworks.jp

このポエムは、上記記事ではなくブクマの反応を見ての感想です。皆さんマネジメントお嫌いなんですね。まあ、タイトルはこのもにょりに対する煽りが少しだけ入ってます。

それと、マネジメントと一口に言っても対象によってアプローチも醍醐味も違うと思うので、ここはチームのマネジメントに絞って話をします。

マネジメントの面白さ

チームで仕事をすることって、私のように圧倒的クリエイティビティの欠如を劣等感にしている人間にとっては、クリエイティビティを発揮して貢献していくためのほぼ唯一の手段なんですよ。自分の働きかけでチームがより力を発揮できるようになって、チームが想定もしていなかったようなハイパフォーマンスを発揮し出す瞬間は本当に見てて楽しいです。AI作って学習させて行ってたら、いつしか自分を超えてしまった感覚ってこんな感じなんでしょうか?

で、このようにちゃんと機能するチームにはそのメカニズムがあり、それは人が集まっただけで出来上がるわけではないということです(タックマンモデルを例に出すまでもなく)。レベルの高いチームのパフォーマンス(生産性と創造力)が単純な総和ではなくそれ以上になるのは、個人のスキルやクリエイティビティの組み合わせが増えるからです。チームはカードを持っていればいるほど強くなるけど、組み合わせ方にコツがいる。マネジメントはそこに働きかける仕事だと思っております *1

ただまあ、実装依存とスキルセットの違いは激しいですね。これが悩ましいところといえばその通りですが、経験値はリセットされてもステータス自体がリセットされるわけではないと思ってます。

管理は支持統制じゃない

これは私にとって非常に大事なことなので、何度でも書きますが、管理は支持統制じゃないんですよ?同じだったらなんで「マネージャ」と呼んでるんですかね?「コマンダー」や「コントローラ」と呼ばないんですかね?管理は行動を規制することじゃありません。

そりゃ、手段の一つとして支持統制を使わざるを得ないことはありますが、あまり筋のいいものではありません。支持統制はそれが当たり前になると自分の頭で考えることを放棄します。そうなるとどんな小さなことでもトップが意思決定しなくちゃいけなくなるんですよ。チームにボトルネックを作ってしまって、パフォーマンスが頭打ちになります。

スキルセットが違うし。。。

おっしゃる通り。正直なところ、マネージャやろうと思ったらその前にどんな経験を積めばいいのかはよくわかっていません。チーム状況によって変わるので、チームが変わると必要なスキルセットが変わる可能性もあるし。

私は、マネージャにエンジニアリングスキルが必要という立場に賛同します。が、Tech Lead系の役割でなければ、メンバーとコミュニケーションをとる時のプロトコルというかS/N比というか、とにかくコミュニケーションの質を維持するために必要だという位置付けです。というのも、過去、一緒に仕事をしたマネージャを思い出すと、エンジニアリングスキルがなくてもエンジニアから信頼されているマネージャがいたからです。なので、エンジニアリングができるというよりは、エンジニアリングが何を根拠にしているのかを理解して話せるか、というのが重要だと思います。

メンバーがどういう考え方をベースにして仕事をしているのか、ということに対する理解と、それがチームの目的に反しないようにするためのスキルがコアとしてあり、そのサブセットとして、エンジニアリングがあったりということだと思います。

比較的実装依存がないのは、モデリングと図示するスキルではないかと思います。コミュニケーションする上でも、抽象化しながらそれをビジュアルで示すことの効果は絶大です。これって、割とプログラマが得意なことではないかと思ってるんですが(コードってそもそも抽象だし)。。。

チームの課題解決プロセスを設計、実装する

これは、どういうつもりでマネージャの仕事をしていたか、ということ。要はプログラミングと同じです。ライブラリや処理系はメンバーや置かれた環境。テスト環境がなくて常に本番環境で稼働していることが違うくらいですかね。

KPTで定期的にふりかえるとか、完全にTDDと同じ発想ですよ。KeepとProblemでRedとGreenを検知し、Tryでテストを書いて1週間動かす。そしたらまたKeepとProblemで計測するの繰り返しって、TDDでRed > Green > Refactoringを回すこととほぼ同じように感じています。

他のことにかんしても同じじゃないですかね?コードじゃなくて言葉や絵や態度で処理系とコミュニケーションするんですよ。

マネジメント楽しいよ?

なんか全く伝わってる気がしませんが、そんなにエンジニアリングから離れたことやってるとは思ってない、ってトコだけ感じ取ってくれればいいかな、と(ちょっとハードルを下げた)。デメリットは、十分成長しきったチームは自律してくるので、自分の居場所がなくなってしまうことくらいですかね。その時どうするか?他のチームを強くしに行けばいいんじゃないですかね。

*1:上との折衝やなんやらはマネジメントの仕事というよりは役職としての仕事だと思っております