少し前に JIRA is an antipattern という記事があり、盛り上がっていた。どうも ticket を assign するという形で micromanage されることがあり、それが嫌という話らしい。

これはツールの濫用/誤用であるというのが主要な反論で、そうだろうとは思う。一方でツールやプロセスが暗に促す方向というものもあり、JIRA は micromanagement を遠ざけるような力を持っていない。それはそれできっと事実なのだろう。

自分は勤務先内製の bug tracker に長いこと不満を持っているわけだが、ひとつだけ良いこともあると気づいた。このツールは管理職が下々を micromanage するには出来が悪すぎるのである。一方、むかし Pivotal Tracker を使っているチームの TL/M によるものすごい micromanage を目撃したことがあり、あのチームでだけは働きたくないと思ったのを覚えている・・・というのは嘘で、当時は Pivotal いいなー使ってみたいなーと思った。しかし今振り返るとアレはないわ。無理。

そんなことを考えたきっかけは、やはり少し前にあった Why 95 Percent of Software Engineers Lose Nothing By Unionizing という記事。これを書いた mchurch というのは HN から ban された過去を持つ筋金入りのクソブロガーだが、それでも Scrum とか micromanage だよね、という話は自分の心に刺さるものがある。

なぜか。自分が昔々 Scrum ごっこをしていた頃のことを思い出すと、あれは micromanage だったと思うからだ。当時の自分はどちらかというと manage する側だったので「うむ、チームワーク」とか思っていたわけだけれど、他の人はどう思ってたのかねえ。管理されてる感あったんじゃないかな。

Scrum や Agile は teamwork の皮をかぶった相互監視 micromanagement methodology である・・・と主張するつもりはない。Agile が people を empower することはできると思う。一方で JIRA と同じくこうしたプロセスというのはどうしても管理者、あるいは管理性向のある個人に濫用されがちで、それを防ぐ仕組みも特にないのではないか。

Agile に関する語りはだいたいそうした管理者や管理性向パーソン ("scrum master") によって行われており、これは管理職やリーダシップに関する語りと同じ問題をはらんでいる。つまり、あなたの周りのひとはほんとにハッピーになったんですかね、という問いには答えてくれない。

出来損ないの agile が招く潜在的な micromanagement から身を守るには自分とその周辺の仕事を自分で manage しておいた方がよくて、そのためには逆説的だけど軽く agile のような計画の話とかを勉強するのはいいんじゃないかなあ。GTD とかの生産性ライフハックだけだとちょっと心もとないよね。

自分も何か読み直そうか。10 年前からなんか進歩したかな agile 方面。Lean がでてきたくらいだろうか。調べないとわからないね。

ランダムなマネージメントの話。マネージャはコードを書くべきか。

なおここでいうマネージャは Engineering Manager で、TL は他にいるものとする。この前提だと、conventional wisdom は「マネージャも重要なものはともかく少しはコードを書いた方がいい」くらいな気がする。

自分は個人的にはマネージャにはコードを書いてほしくない。全然。なぜならマネージャの書いたコードは扱いがめんどくさいから。そしてどうせならコード書き以外の面倒に時間を使ってほしいから。

例。あるとき上司の上司が crash bug の修正コードを書いてきた。普段はコードを書かないがプログラマ出身の人物。そのバグは当人が現役だった頃に使っていたのと同じライブラリのよくある問題に起因していた。その知識を活かして問題を特定し、修正を試みたのだった。

問題の特定まではよかった。でもコードをみると直し方がいまいち。コードベースの抽象やパターンに従わず、力技で片付けている。全体のデザインを正して似たような問題が起こらないようにするといった配慮がない。しかし通りすがりの上司の上司に正しいデザインのあり方を説明しコードを書きなおしてもらうなんてやりたくない。気を使うし、コードベースに対する理解の程もわからない。忙しい相手だけに素早いイテレーションも期待できない。ただバグを登録してくれるだけでよかったのに・・・。

うげーめんどくせーと顔をしかめる同僚たち。結局心臓の強い同僚の一人が容赦なくダメだししてパッチはお蔵入りとなり、その強心プログラマが自らマシな修正をした。チームメイトに同じことをしたら喧嘩になるところだけれど、この時に限っては正しい対応だったと思う。

上司のコードをレビューするのはそれなりに気を使う。相手がまともな人間でコードレビューに手こずったくらいでは気分を害さないくらいは期待していい。それでも自分にそう言い聞かせ権力構造から心を切り離さないといえないのは疲れる。

しかもマネージャには他に本業があり、結果としてコード書きの対応は遅れがち。一方でレビューは間隔があくほど認知の負担が上がるので、イテレーションの遅いレビューはそのぶん疲れる。普段コードを書いておらず共有するコンテクストが少ないのもコミュニケーションの敷居を上げる。

更に言うと、管理職は必ずしも良いプログラマではない。才能の優劣ではなく、下々のプログラマに比べて読み書きしている仕事コードの量が違う。頼れるチームメイトである度合いと言ったほうが良いかもしれない。片手間でコードをみているマネージャよりより、プロジェクトのコードベースに馴染んでいる現場のプログラマの方がよくコードをかけるのは当たり前。それが役割分担じゃん。

要するに: 権力を無視して正しく振る舞うのは疲れる。通りすがりの相手も疲れる。ぱっとしないコードを読むのも疲れる。だからコードはプログラマにまかせマネージャは本業に専念しておくれ、と思う。

Good First Bug

コードを書いては欲しくない。でもコードは書けて欲しい。少し理不尽な言い分だとは思う。でも現場に近いマネージャであるほど、下々が上司に巻き取って欲しい仕事にはコードを書けないと現実的でないものが多い。

例。とある夕方、翌日の UX レビュー会議で動くデモが必要とわかる。一応コードはあるものの、まだコードレビューがおわっておらずマージされてない。担当者はもう帰ってしまった。しかも明日の会議で必要なパッチは二つ。こいつらを手元でマージし、アプリをビルドしないといけない。

このとき職場に残っているプログラマにビルドの雑用を頼むのでなく、自分でささっとビルドできる・・・くらいはマネージャに期待したい。似たような場面はいくらでもある。

そしてちょっとした雑用にプロダクション以外の書捨てコードで自動化や分析ができると便利な場面は多い。そんな仕事に上司が手作業で時間を無駄にしてたら、ちょっと興醒めでしょ。

コードを書かないとコードを書けるようにはらなない。プログラマからマネージャに転身した身であっても、時がたてばコードやインフラは変化し、昔の知識は使えなくなってしまう。

そんなマネージャがプロジェクトのコードを学ぶためにコードを書く。これは必要なことだと思うし、現場のプログラマとしても協力してあげたい。コードそれ自体がプロジェクトの役に立たなくていい。たとえば優先度の低いしょぼいバグをなおすとか、あってもなくても大差ないちょっとした API を生やすとか、入門のためにかけるコードは色々ある。Open source でよくある good first bug というやつ。

マネージャが書くコードの面倒くささは、有用なコードをキメたつもりになっている本人と現実のギャップに起因することが多い。学びのためのコードにそうした勘違いはない。むしろちょっと応援したくなったりもする。

それに、マネージャが通りすがりで雑用をさばけないのはコードのデザインやインフラが腐っている兆候かもしれない。そうした歪みや技術的負債の痛みを体験したマネージャなら、負債返却や自動化強化を求めるチームからの声にも意味のある形で応えることができるだろう。

コードをめぐるプログラマとマネージャの関係は、そのくらいが円滑じゃないかな。

この文章はマネージャに向けたものではなく、自分とおなじそこらへんのプログラマを読み手として念頭においている。上司の書くいまいちなコードを見て複雑な気持ちな人に自分の感覚を信じて欲しい。下々のプログラマも声を出そう。これを読んだマネージャは一定の割合でムカついているとおもうけれども、そういう人は世に溢れるキリッとしたマネジメント語りを読んで元気だしてね。

ランダムなマネージメントの話 (Randomly On Management, ROM) つづき。カテゴリを振り分けることにしました。

自分の勤務先では、むかしマネージメントに関する調査プロジェクトをやっていた。Project Oxygen という名前。そのことをふとおもいだした。上の記事にある「調査でわかった良いマネージャの振る舞い」に、自分の上司は半分くらいは該当している。この記事によれば管理職向けトレーニングとかも社内でやってるというし、上司のまともさは人事な人たちの成果なのだろうか。

と思って、このあいだその上司に「そういえば Project Oxygen って知ってます？」と聞いてみたら「知らないなにそれ」という反応だった。ははは。まあそんなものだよな。トレーニングとかなしでも結構良いマネージャだという事実は別に悪い話でもないし。みくびってごめんなさい我が上司よ。

なお上の記事にでてくるマネージャフィードバック用のアンケートは今でも実施されており、結果をチームに共有のうえ議論するみたいなことも、少なくとも自分の上司はちゃんとやっている。ので Project Oxygen の名前は知らないにせよ間接的な恩恵はうけてるといえるかもしれない。

ランダムなマネージメントのはなし。

今の勤務先以前の会社にいたマネージャというのは、いま自分や自分の勤務先がマネージャに期待している機能はほとんど果たしていなかった。テクニカルな度合いも低かった。一方で多くはステレオタイプな昼行灯みたいにヒマそうでもなかった。

自分の以前の勤務先は多かれ少なかれみな受託開発をしており、受託開発をするソフトウェア会社の管理職の主要な仕事は接客や渉外だった。そういた仕事はある種の専門性がいるし、時間もかかる。なのでこうした管理職はコードを全く書かないにも関わらずプレイングマネージャだったと言える。そして接客渉外に向いた人とソフトウェア開発のマネージャに向いた人は、必ずしも同じでない気がする。あれは色々不幸な仕事だったろうなと今更思う。

そういうプレイング管理職と働いた結果自分はマネージメントに期待をしなくなり、あまり manage されない働き方をするようになった気がする。なので結果としてはよかった。ただマネージメント軽視で arrogant な TL 的存在たる自分と一緒に仕事をしていた、自分のまわりの、場合によっては気の弱い人々は、もしかしたら本来的な意味でのマネージメントの介入があったらよかったかもしれない。なんつうか、ごめんね。

どうすればよかったのか。よくわからない。受託開発は大変、ということかもしれない。なお接客の影響からマネージメントへの期待値が低い会社で接客をしていないマネージャは、単にぱっとしなかった。

Kzys が管理職についてなんか書いていたので、自分も便乗して何か書こうかと思ったものの、その前に最近たまに考えていることを書いてみる: 下っ端でもマネージメントやリーダーシップについて思うことがあるなら書いたほうが良い。マネジメントの都合でなく、自分の都合でそれを語って良い。

自分と同世代の同業者は、マネージメントなりリーダーシップなりの仕事をやっている人が多い。そうでなければフリーランスやコンサルタント。特にインターネットの世界で名だたる有名人ほどこの傾向が強い。そうした人々はしばしば当事者としてマネージメント（以下字数節約のためにマネージメントとリーダーシップをひっくるめてマネージメントと呼ぶ）について色々かっこいい話をする。長年の経験や成果に裏付けらているだけあって説得力もある。

マネージメントをめぐる議論は、あるべき下っ端の姿を様々な形でほのめかす。なにしろ下っ端をマネッジしたりリードしたりするわけだから。つまりマネージメント語りはマネージメント当人(マネージャ、リーダー)についてだけでなく下っ端についても語っている。

下っ端も自分について語ることがある。けれど下っ端の語りにマネジメントへの意見がはっきりと現れることは少ない。多くは個人的な「生存戦略」みたいなものとして消化される。

結果として、マネージメントの意見は組織と個人双方に影響を与える一方で下っ端の意見は個人に影響することはあれ組織を動かす力がない。あっても弱い。

発言に影響力のある人がマネージメントに偏っているのもつらい。そういう人々の語りの中で定義される（組織にとって都合の良い）下っ端のあり方に影響をうける人は多いと思う。影響力がある人のかっこいい話を流されずに消化するのは正直けっこう難しい。かっこいいんだもの。

マネージメントと下っ端の都合が常に相反するわけではない。足並みを揃えられることは沢山ある。とはいえ下っ端も当事者として自分の望みを語らないと、他の都合が優先されてしまう。

政治と比べてみる。マネージメントだけが組織のあり方を議論している現状は、政治家や官僚だけが政治を議論しているのに似ている。政治家も官僚も国民すなわち下っ端（※言葉の綾です）のために働くことになっている。が、この前提は色々な圧力や思惑や誤解によって崩れがちだと多くの下っ端は信じている。だから activist や journalism が存在するし、政治に意見のある下っ端・・・というかふつうの市民・・・も多い。

下っ端会社員は必ずしも投票権を持っていないから、市民とはすこし違うかもしれない。一方で組織の execution に直接参加しているぶん、ふつうの市民が政治にもつより大きな影響力を持っている面もある。公務員みたいなかんじと言えなくもない。

国家公務員は内部告発の権利を保証されている。内部告発は政治の床屋談義はおろかふつうの journalism よりだいぶ覚悟がいる activism の極地だけれど、この法律は組織の姿勢を正す下っ端の存在意義をよく表しているとも思う。

下っ端プログラマがマネージメントについてなにか言うのは床屋談義に毛が生えたようなもので、極端な場合を別にすると国家公務員の内部告発みたいな覚悟は必要ない。マネージメントを悪者とみなす必要もない。ただ、それでも声をだした方が良い。音量のバランスがよくなるし、なにか悪いことが起きて本当に声を上げる必要があるときによく声が通る。たとえば Susan Fowler の記事は当人が勇敢かつ優れた書き手であっただけでなく、tech industry の sexism に関する年来の議論があったからこそ可能だった。

と、そんなに肩肘はらなくていい。幸い多くのプログラマは特段酷い目にあっているわけではない。概ね楽しくやってる。そういう平和な時分、仕事をより良いものにする上でどうしてほしいかを語ればいいだけの話。一定以上まっとうなマネージメントなら下っ端の声は聞きたいと思ってるよ。たぶんね。

Daniel Pink が Free Agent Nation を書いて 15 年。プログラマの中にはやっていき宣言みたいにロックなことを言う人もいて、ソフトウェア開発者をはじめとする知的ブルーカラーのあるべき生き方はこっちなのかな、と思うこともある。一方で会社に雇われて働くのはまだまだメインストリームだし、いいところも多い。

特にソフトウェア開発の世界では Agile manifest を発端に組織のなかでもボトムアップに個人を empower する流れが生まれた。その agile 世代にキャリアを踏み出し、個人として empower され成果をだした人々がいまマネージメントに舵を切っている。でも彼らはみな偉くなってしまったので、いま下っ端な個を応援する声はちょっと弱くなった気がする。カウンターがほしい。Erik Meijer の One Hacker Way はその extreme な例だとおもうけれども、もうちょっと穏当かつ持続的な切り口として下っ端のマネージメント語りがあってよいと思う。

追記

間を置きつつ断片的に書いているので ROM(Randomly On Management) というカテゴリに振り分けておくことにした。