得てして優秀なプログラマは気分屋だ。ただし気分屋のプログラマがすべて優秀とは限らないが。
プログラマはプログラムを書く。小規模な開発であれば全員が「作る」だけで事足りるが、プロジェクトの規模が大きくなり、ステークホルダーが増えて来ると「作る」以外の役割が必要とされる（と言われている）。それがマネージャだ。
理想的には、経験を積み、技術にも精通した上でプロジェクト全体を見通せる能力を持つものがマネージャとして据えられるべきだろう。
ところが理想的に行かないのが世の中で、マネージャの任に就く者が所謂"新人"であるケースも多々ある。そしてとりわけ、新人マネージャが気分屋プログラマと一緒に仕事をするようなケースでは "Manage"する側は非情に苦労する。もちろん、いやおそらくはそれ以上に、プログラマも苦労する。
- ろくなプログラミング経験もないのに、マネージャをやることになった。
- 好きなようにコーディングしていたと思ったら、いつのまにか管理する側に回されていた。
- マネージャとして中途で入社したら「新参のくせに...」みたいな空気で言うこと聞いてくれない。
この記事は、そんな人のための一助となれば良いと思って書いたものだ。
とはいえ、ソースはいつもながら僕個人の経験でしかないため、ひょっとしたらプログラマやらマネージャやらに関係なく仕事を進める上でいつも必要な要素かもしれないし、
逆に弊社の事情に特化した、全く広がりのない（むしろ一般的には有害ですらある）要素も含まれているかもしれない。
汎化できていない点は大目に見てくれるとありがたいが、そもそも間違っている点に関しては、多いに指摘していただければ反省して改善します。
はじめに
僕は決して優秀なプログラマではないし、残念ながらそもそもプログラマではない。趣味として、また仕事の一環として簡単なスクリプトを書いたりサーバを弄ったりMySQLやらPostgreSQLにselect文を投げて唸ってたりするけど、基礎がボロいし、プロのレベルには遥か遠い。対象として面白いので勉強を続けたいとは思うが、これで食って行こうとはとてもじゃないが思えない。
そんな僕は、修士過程を修了した後に入社したこの会社で、顧客の要件を聞き出し、中国のエンジニアと設計を相談し、プロジェクト全体の進行を管理したりという....所謂"マネージャ"的な立ち位置に（幸か不幸か）据えられることとなった。
入社して9ヶ月が経過した今、とりあえず言えるのは、
百害あって一利無しの、"マネージャは「管理」する"という解釈を今すぐ捨て去るべき
ということだ。
こんてんつ
- テーブルの同じ側から問題を眺めること。
- ストーリーに参画してもらうこと。
- プログラマの仕事に興味を持ち、教えてもらうこと。
- ダイレクトな接触を心がけること。
- 現場のレイヤーに降りること。
- 自分の仕事に自信を持つこと。
1. テーブルの同じ側から問題を眺めること。
テーブルの同じ側から問題を眺めること。
そもそも、マネージャとプログラマは仲間であるはずだ。同じ問題に違う立場で取り組む、チームメイトであるべきだ。
ところが、互いにいがみ合う関係になってしまっているケースを見かける。
※こんな姿勢ではだめです。
充分な実力がないか、まだ実力を示す機会に恵まれていない新人が「俺は立場が上だ」という思考で"命令"/"指示"していればまず失敗するし、そもそも信頼関係を構築出来ないだろうJK。
上からあれこれ言うだけでは、気分屋プログラマは付いて来ない。
自分自身がマネージャ的な立場で仕事をしてみて、新人マネージャ+気分屋プログラマという組み合わせは、確かにうまくやらないと「仲間」であることすら忘れてしまう危険性を孕んでいることに気がついた。
啀み合いになる原因を解消する方法については次項以降で考察しているので、とりあえずこの概論だけは踏み外さないことを意識したい。
2. ストーリーに参画してもらうこと。
ストーリーに参画してもらうこと。
これはすなわち、情報を共有し、プロジェクトの経緯と達成すべき目的を共有することに他ならない。
僕が思うに気分屋プログラマは、いくつかの選択肢があった場合、作って面白い部分から先に着手する。
優秀なプログラマは将棋の百面指しのごとくあらゆるプロジェクトに引っ張りだされてるため、全貌が見えないものは後回し、後回し....そうこうしているうちに遅延が予断を許さないレベルに達する。新人マネージャが原因で、プロジェクトが多いに滞ってしまう。
実を言うと、去年の7,8月頃の僕は、この点がうまくできておらず、盛大に失敗した。
必要な情報を渡していたつもりだったが、そもそも入社3,4ヶ月のペーペーが顧客の要件を正確に噛み砕いて何が「必要」なのか判断できるわけがない。その点を自覚していなかった。知っていたが、理解していなかった。
この点を反省し、プログラマに対しては昨年下旬から「やってもらいたいこと」だけではなく、「なぜその作業をやる必要があるのか」「問題は何なのか」「そもそも要求されている結果は何なのか」という点に重点を置いて説明するようにした。
こうして方針を転換して以降、非情に話がスムーズになり、「その結果が欲しいのなら、こうやればいいんじゃない？」とベターな選択肢を提示してくれるようになった。
結果として、少し「テーブルの同じ側から問題を眺める」ことが出来るようになったと思っている。
これは、生粋のWF型プロジェクトだとまた事情が別かもしれない。
が、個人的に、ガチガチのWF型プロジェクトは、IBMレベルの軍隊組織を結成しない限り、決して幸せな結果を生まない気がしている。
3. プログラマの仕事に興味を持ち、教えてもらうこと。
プログラマの仕事に興味を持ち、教えてもらうこと。
それぞれどちらが上ではなく役割が違うということを自覚していても、どうしてもマネージャとして働いていると「命令」するようなニュアンスが出てしまうことがある。
作業が当初の予定通りに進まなかった時など、責めているわけじゃないのに（そもそもの予定設定に無理があった可能性もある）糾弾するような質問をせざるを得なかったりする。
というわけで、僕は、いかに役割が違うとはいえ...否、役割が違うからこそ起こりうる無意識の上下関係を根絶するために、
新人マネージャは彼らの作業に興味を持ち、すごい成果には素直に感心することが大事だと思っている。
予定していたよりも作業が速ければ感謝の意を示し、難しいと思っていた部分が簡単に解決出来ればスゲーと賞賛する。
お互い気分良く仕事をするためのプロセスと考えればこれも仕事の一環だし、何より勉強になる。
僕の経験上、この時「これ凄いね！どうやってんの？」と聞けばノリノリで教えてくれて、半分プライベートな状況で教えてもらった内容の方がよく頭に残るものだ。
4. ダイレクトな接触を心がけること。
ダイレクトな接触を心がけること。
気分屋プログラマは...いや、たぶん気分屋かどうかに関わらずなんだろうけど、効率化を求めてTRACやRedmineなどプロジェクト管理ツール、Excelの煩雑なタスクリストでやりとりを完結させようとすると逆に非効率になってしまうし、場合によっては無理ゲーになる、...と思う。
形式だけのやりとりで済ませようとすると、意味の見えない作業が嫌いな彼らはとりあえず「出来ます」「もう少し」と言った後にあっけらかんと「これどうやるの」と基本的なことを聞いてきたり、それどころか「あれって何のこと」とそもそもマネージャの要望を理解してくれていない、というケースもある（これは酷いケース）が、そこでオイオイと突っ込まないでちゃんと説明することが大事。
突っ込むと意固地になり、出来上がるまで出してこない（ = 出来ない場合はそのまま期限を迎える）モード（「俺シラネ」モード）になってしまうこともあり、そうなれば後に待つのは悲劇しかない。
この問題を解決するには、顔を突き合わせて -- 第一の原則"テーブルの同じ側から問題を見る"に則って -- 報告、連絡、相談の機会を持つことだ。
顔を合わせることで双方にチームとしての自覚が生まれ、前述のような「俺シラネ」問題が発生するのを防ぐことができる。
正直最初は「ホウレンソウ（笑）」とか思ってたけど、マネージャもどきをやってみて、ホウレンソウの大切さを痛感した。いや、ホント大事。情報が循環しないと本気で仕事にならない。ここが詰まってると、うまく行くものもうまく行かない。
情報を流してもらうためには、ダイレクトな接触、すなわち「人対人の信頼関係」という基盤が必須なのだ。
| 一人前社員の新ルール (アスカビジネス) | |
 | 黒川 勇二 まこといちオフィス 2009-05 売り上げランキング : 178480 Amazonで詳しく見る by G-Tools |
また、気分屋プログラマは、書類整備や社内手続きは大の苦手だ。
仕事に専念してもらうために、極力、面倒な手続きを挟まないように取り計らうことも彼らの生産性を上げると思う。
というわけで、面倒な部分はマネージャ側で片付けてしまおう。その際、第二の原則"ストーリーへの参画"がなおざりにならないように気を配ることも忘れずに。
5. 現場のレイヤーに降りること。
現場のレイヤーに降りること。
最初に書いたように、マネージャに技術力があるに越したことは無いが、もちろんすべてが同じレベルで分かる必要はない（プログラマと同レベルのプログラミング能力があるならマネージャが開発すれば良い話だ）。
かと言ってまったく分からないのも困り者で、あまりにひどいと話がズレたままお互いにコミュニケーションを取っているつもりで進み、最後に絶望的な意識のすれ違いが明らかになって大爆発、というシャレにならない状況に陥ることも覚悟しなければならない。
ここで大事なのは「相手の仕事を尊重しよう」という姿勢だ。この姿勢は日々の言動でも示すことが出来るが、最も大事なのは、現場のレイヤーに降りる -- 技術を尊重すること、だ。
技術を理解しようとすることは、相手の仕事を尊重することに繋がる。
わかる範囲でいいので、技術の言葉を使う。現場の土俵で会話する。やりとりのなかに簡易コードを混ぜたり、スクリプトを書いてテストした結果を付け加えると話がスムーズになるのはこの一例だと思うし、日々勉強して技術力を少しでも向上させる努力を怠ってはならない。
そして、同僚の言葉を借りれば「必要とあらば自分の手を動かすことを厭わない」マネージャは信頼を勝ち得る。大変な状況を一緒に乗り越えようとしてくれる、という確信は、良質な関係を築く上で欠かせないものだ。
逆に、スキルが無いくせに妙な線引きをして「あんたら作る側だろ、俺知らねーよ」という態度のマネージャが信頼を得られるはずも無く。
おおざっぱに言ってしまえば技術を軽視する企業に未来はないのと同様、技術を軽視するマネージャにも未来はない。
現場レイヤーまで降りて来ないマネージャには「詳細を伝えてもしゃーねーや」となり、技術的な問題が起こったとしても、本当の問題を共有することができない。結果として「難しいです」という報告だけ受け、顧客に伝えるときも「えっと、なんかわかんないけど出来ないそうです」としか言えず、....糞マネージャの一丁上がりである。
6. 自分の仕事に自信を持つこと。
自分の仕事に自信を持つこと。
知らないことは素直に聞く、出来ないことを明確化しておく。どちらも大事なことだが、それだけではタダの「ちょっと良い奴」だ。いい子いい人どうでもいい奴。
非力なマネージャには誰も付いて来ない。
新人マネージャとしていかに自分がやべぇ状態だと思っていても、かならず出来ることがある。自分のやるべきことがある。そこに責任を持ち、自信を持つことだ。
- 「この範囲の仕事は僕に任せて欲しい」
- 「君がここまでやってくれたら、後の部分はこちらでなんとかする」
最初はちょっとしたことでも良い。ドキュメント取りまとめるよ、とか、仕様の不明点を一緒に考えて顧客に伝えるという仕事であっても、
プログラマに言われてからではなく、こちらから「この仕事は俺に任せろー！＼バリバリ／」と申し出ることだ。
そもそもプログラマの方から作業の指示を貰っている時点で、彼らをスペシャリストとしての仕事に専念させられていないことになり、マネージャ失格だ。
誰だって自信のある人と一緒に働きたいし、能力だけでなく"自信"があるからこそ、安心して背中を預けられるのだと思っている。
いじょ
僕の解釈がそう大きく外れていないことを願うが、どうしても現場でバリバリ開発をやった経験が無い以上、汲み取れ切れていない部分があると思う。至らない点は指摘して頂ければありがたいです。
結局、仕事のベースになんのは"信頼関係"だな、と思う。
信頼があってこそ関係の発展があり得るわけだし、もっと面白い仕事ができるってもんだ。
 | はじめての課長の教科書 酒井穣 ディスカヴァー・トゥエンティワン 2008-02-13 売り上げランキング : 995 Amazonで詳しく見る by G-Tools |
