まあまあ。どんな話か忘れてて四巻読み返したら結局最初から読み直してしまった。曲射がよかった。
マージナル・オペレーション（５） (アフタヌーンコミックス)
- 作者: 芝村裕吏,キムラダイスケ
- 出版社/メーカー: 講談社
- 発売日: 2016/01/22
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
マージナル・オペレーション（5）
最近読んだもの
自分が「雑用（あえてそうよぶ）」を拾いたがるタイプなので自戒を込めていうが、そういうひとは仕事の優先順位づけができていない。本職がおろそかになり、仕事に穴を開けて結局はチームに迷惑をかけるハメになる。
自分が雑用拾いに精を出しがちなときはたいてい「本職がダルいのでサボりたい」か「本職が手に余るので逃げたい」のどちらかだった。雑用は「緊急だがすぐ片付く」内容が多いので、サボっていると思われず、安易に達成感も得られてクセになってしまうのだ。
雑用拾いを他のひとにやらせないのも良くない。周りが育たないし、遅かれ早かれ「自分はこんなに貢献してるのに評価されない」という悪魔の考えに取り憑かれてしまう。おそらく周囲からは「雑用はいいから本来やるべき仕事をオンスケでこなすことで貢献してくれよ…」と思われているだろうことにも気づかずに、だ。
ああ耳が痛い。
雑用に逃げがちなとき、以下のようなことに気をつけている。
- トラブルや困りごとを見つけてもすぐに食いつかない。気づいてても気づいてないふりをしてしばらく放置してみる。放置ではまずい状況なら「スヌーズ」されるはずだから、それまでは我慢して待つ。
- 他のひとが反応するのを待つ。誰も反応しないのだとしたら、実はたいして重要なことではないのかもしれない。不要な仕事を自ら作り出すマッチポンプはすべきではない。「重要なこと」の認識が周囲とズレている可能性もある。
- 拾ってしまったら、二度と自分が拾わなくてもいいように調査方法・対応方法・コマンドやコードのスニペットなどを徹底的に文書化する。次からは拾った人や拾ってくれない人に URL を送りつければ済むし、自分一人しかいなくても将来役に立つ。
ところで、雑用を拾わないスクラムマスターって何のために存在するの？と思った（スクラム詳しくないので「そういうものだ」といわれたら仕方ないが、じゃあそんなポジションいらないだろ、とも思う）
outlook/jobs
Microsoft に買収された Sunrise の、デベロッパー・デザイナー採用ページのようだが、以下の点が興味深かった。
- 特定のプログラミング言語やライブラリ・フレームワークとは無関係の、普遍的な問いかけをしている。書籍で語られたり、コードレビューで引き合いに出されるような「良いコード、読みやすいコード」とは何か、ということに、候補者がどの程度精通しているのか、を測れる可能性を感じるとともに、 Sunrise チームがこのような事柄に強い関心を持っているということを雄弁に示している。言葉でどんなに「我々はコードの品質に気を使っています」などと書き連ねるよりも、よほど説得力がある。
- 各ポジション向けの具体的な課題において、指示される「お題」がわかりやすい。完成形がすでにあるので、成果物の評価もやりやすそう、かつ候補者自身にも納得感がある。「お題」についてベースとなるコードなどを準備しなくてよいのもよい。手間が省けるし、「お題」のスタート地点が開示されることでヒントを与えてしまうこともない。
- 課題の提出方法がエレガント。個人でプライベートリポジトリを持っていることを要求する、つまり GitHub の有料プランを契約していることを要求するのは是非がわかれるところだが、応募時に一時的に契約するだけでもよいのだし、個人的には「その数ドルの投資を惜しむかどうか」ということも、チームメイトとして迎えるかどうかの判断基準のひとつになりうる、と思う。オープンなリポジトリで「提出は Pull Request を送れ」とすると、過去の候補者の提出内容を参考にするチートができてしまう（のでリポジトリを作り直すなど、運用に手間がかかる）メールで ZIP を送れ、だとレビューしづらい。よって、プライベートリポジトリで Pull Request を「いつものように」みるのが最も効率が良い。
