学び直す
前の投稿が2017年だから、かれこれ4年前のブログを掘り起こしたことになる。随分と放置していて恥ずかしいが、また投稿を始めようと思ったのは、自分が今置かれている状況や考えを落とし込む場所を探してのことである。
さて、4年の間に何が起きていたかのかというと、ゆっくりとだが確実に人生の山場を迎えていたということになる。
・経営を学びに社会人大学院に通った
・責任者だったプロジェクトがうまく進捗をせず責任をとった
・経営学修士となったタイミングで異動となった
・4歳、歳をとった
ということで、4年前は思いもつかないことをいまやっている。そして50歳が見えてきた今、これからどうやって生きていくかを考えて、またコードを書き始めている。
yak shavingを恐れない、だがのめり込まない
「あれこれ準備していくうちに、過ぎていくのが人生だ」とジョン・レノンが格言めいたことを言っていたことは知っていたが、この「準備」のことは、エンジニア的に言うとyak shavingのことだ。エンジニアであれ、マネージャーであれ、誰にでも起きる。
「本質的な問題を解こうとして、必要となるかにみえる別の問題を解決しに行ってしまう」ようなことは頻繁に起こる。これがよく言うyak shavingという奴だ。ただ、気をつけて欲しい。効率化のために◯◯を行うことが、本当に最終的に効率化してあなたの稼働を減らし、今すぐ家に帰ってカウチでポップコーンを食べながらテレビを見られるレベルのものか、よくよく考え直したほうが良い。特にエンジニアからマネージャーになった人間は、とかく「技術で不整合を是正しよう」とする。くだらないメールの返信を自動化し、部下の勤怠サイトをスクレイピングし、それらをダッシュボードに映し、悦に浸る前に考えることがある…それで問題は解決したか？
幸運なことがある。エンジニアのyak shavingは誘惑的でかつ問題解決からかなりの遠回りであることが多いが、マネジメントのそれはちょっと面倒だが問題解決には役に立つことが、まだ割合として多い。それほどマネジメントの仕事には退屈でくだらなく、生産性の無いということだ。そういうものがあったら、エンジニアリングの力で解決しにいくのも手である。ときに10倍、100倍の効果があるものであれば、一計を案じるだけの価値はあるだろう。
ただ、それにのめり込まないように。せいぜい3時間のコーディングで、8時間以上の稼働が削減できるようなレベルのものでなければ、目を綴じて淡々と作業をしたほうが割に合う。エンジニアリングにバイアスがかからないそういう判断ができるようになるのも、マネジャーになるために必要なことの一つである。
注釈：ジョン・レノンは「Beautiful Boy」という歌の中で「Life is just what happens to you, While your busy making other plans」と歌っている。が、これは直訳だと「人生はまさに過ぎてしまう。君が違う計画を立てている間に」という意味になり、「予定通りにいかない」ことを指しているという解釈のほうがしっくりする。超訳が独り歩きした構図になっているようだ。
チームのボトルネックを無くす
私のチームには、もう何年もその仕事に従事していて、能力もホスピタリティも高く仕事をしてくれるメンバーがいた。彼は非常に優秀だったが、残念ながら欠点もあった。自分の仕事をあまりオープンにしたがらないのだ。彼が理想としている状況は「チーム内外の誰もが自分を頼ってくる」ことであり、チームそのものの生産性にはあまり気を止めていなかった。
しかし、それは私には些細な問題だと感じていた。彼のパフォーマンスは十分だし、彼以外にその仕事を頼むのは、その時点では非効率であることは明らかだった…彼が退職するまでは。
実際、彼は退職するわけではなかったが、私はボスに言われたのである。彼のパフォーマンスが良いのは判るが、単一障害点となっているかぎりチームのパフォーマンスが向上することがない。彼が退職すると言ったら、我々は３倍の給与で引き止める必要になる、と。
正直な所、チームの各メンバーが何をしているか、詳細まで把握するのは難しい。ならばドキュメントに落とすように日頃から徹底することにする。週次の報告は、その詳細が手順として文書化され、オンラインで共有化されているだろうか。その文書は、少なくとも自分がそれを読んで同じことができるだろうか。
誰もが、自分が不要となる瞬間を迎えたくないと考えている。チームマネージャーは、手順を残すことも仕事の一つであり、自分しかできないタスクを抱え込んでいるメンバーは評価が低いことをチームメンバーに明示する必要がある。
チーム内のエンジニアを評価する
エンジニアの評価は一言で言ってしまうと非常に難しいものである。ひとえにソフトウェアエンジニアと言っても、ウォーターフォールで開発をし続けていたSIerの中のプログラマーと、ベンチャー企業でスクラムをぶん回してシングルページアプリケーションを作っているプログラマーとでは、持っている技術セットもマインドセットも大きく違う。だが、2017年現在はどこもかしこもソフトウェアエンジニアが枯渇して、有象無象の中から採用をしてプロジェクトを回す必要がある。プロジェクトに採用している言語を、多少齧ったことがある、というだけで参画してくるエンジニアも珍しくはない。
そんな彼らが果たして活躍するだろうか？それは実のところ誰にもわからない。経歴書に踊っている技術も、実際のところは全く使い物にならない（そしてそれは改善されない）こともあるし、力なく「頑張ってみます」と言った若者がメキメキと頭角を表すことも有る。そしてその生産性は10倍以上差がついてしまう。そういうところで戦っているしソフトウェアエンジニアを正当に評価するのは至難の業だ。（生産性が１０倍の彼に１０倍の給料を払えるところは別だが）
実際のところ、エンジニア自身も評価をされたがっているのだから、マネージャーはその評価軸に乗ってしまうのが良いだろう。もちろんある程度の指針はあるべきで、たとえば新卒２年目は技術の習得を目指し、１０年選手はアーキテクト責任者かリーダーかを選ばせるのは自然の流れだろう。その上で、エンジニア自身に「自分はどういう形で仕事をして、所属する企業に貢献するか」を考えさせると良い。エンジニアは自分のなりたい姿を想像して、どのように仕事がしたい、と言ってくるはずだ。そうなればしめたもので、あとは「ある程度の指針」に添って、彼らにミッションと言うかたちで目標に整理させる。たとえば、新卒２年目は「１つの言語を習得し、品質に貢献」程度で良いだろうし、１０年選手は「新技術領域の習得し、習得した技術のアーキテクチャ担当をの全う」といった形になるだろう。
あとはマネージャーが、ミッション難易度の高い低いをチーム全体を見ながら調整すれば良い。そしてそのミッションが達成できれば評価は並、それ以上はハイ達成として評価をあげてやる。そうすることで、エンジニア側から見れば最終的にミッションをコミットすることでチーム内での活動を正当に評価される、と感じられるようになるだろう。
コンテキストを意識する
特にエンジニア出身だから、ということではなく、チームメンバーとのコミュニケーションではコンテキストを意識することは重要である。比較的長い間一緒に仕事をしてきたメンバーでも、タスクを依頼しゴールの期待値をすり合わせる際には、可能な限りローコンテキストなコミュニケーションを心がけるべきだ。
しかし実際のところは、仕事ができる部下はハイコンテキスト〜すなわち曖昧な指示〜でもマネージャーの意図を汲み取り、あるいはゴールの期待値をしっかりすり合わせて評価を勝ち取っていく。マネージャーの立場からはそういった部下は非常に頼りがいがあるが、その関係性は暗黙知を産みチームのあるべき姿とは離れてしまう。
メンバーへのコミュニケーションを直接的で分かりやすく、単純でシンプルにすることで、チームを常に開いた状態にし、期待されるゴールへと向かいやすくすることがマネージャーとしての役割である。
