1 on 1（ワンオンワン）とは、マネージャーとその直下のソフトウェアエンジニアが定期的に行う面談のことである。アメリカのIT系の会社では一般的だったが、最近少しずつ日本の会社でも導入されてきた。しかしながら導入したものの何を話したらよいかわからないという声をよく聞くので、筆者の経験からまとめてみたい。筆者はマネージャーとエンジニアどちらの経験もあるので、両者の立場からそれぞれ説明する。
ソフトウェアエンジニアが話すこと
まず、1 on 1は「マネージャーと話す定期的な自分の時間」であることを強く意識しよう。考えてみてほしい。マネージャーとは席が離れている。とても忙しそうであまり席にいない。週次のチームミーティングで顔を合わすが、話すことは多くない。筆者はそこまで社交的ではないので、自分から積極的に話しかけに行くことはほとんどない。半年に一度の評価面談で話すのがほぼ唯一の機会である。そういう関係のマネージャーが自分の仕事を正しく理解してくれているだろうか。自分はマネージャーが何を考えているか理解しているだろうか。そういう関係のマネージャーと定期的かつ強制的に1対1で話す機会をもらえるのが1 on 1なのだ。その自分の時間を最大限に利用してマネージャーとコミュニケーションをとろう。
次に話すべきはプロジェクトについてだ。プロジェクトの進捗を正しく伝えて意識の差をなくそう。あなたはメールや朝のスタンドアップミーティングなどで進捗をすでに共有しているかもしれない。だがマネージャーが正しく全体像を把握しているとは限らない。またスタンドアップでは言いづらいこともある。プロジェクトの遅延、時間のかかる相談、プロジェクト内の「人」に関わる相談などは、1 on 1でのほうが話しやすい。またプロジェクトがうまく行っていても、「うまく行っています。大丈夫です」で済ませないように。入り口は大まかな進捗でよいが、どのマイルストーンを達成したか、ターゲットリリースはいつなのかなど、タイミングや進捗率を共有しよう。
キャリアマネジメント
この先5年、10年、どうなっていきたいのかをよく相談しよう。自分は何が得意で、何を改善しなければいけないのか。マネジメントに進みたいのか、技術を極めたいのかなどを話すと良いだろう。自分自身について客観的なフィードバックを定期的にもらう機会として1 on 1を利用しよう。
一番防ぎたいことは、半年に一度の評価面談で「君は○○が苦手だから改善が必要です」とか「○○の部分が期待を上回りませんでした」などと寝耳に水のマイナス評価を受けることである。1 on 1でも小さなフィードバックループを維持するよう心がけよう。
チームプレイヤーであることは良いエンジニアの必要条件である。1 on 1の時間が余ったら自分たちのチームについて話そう。チームで困っている人はいないだろうか。ミーティング、ワークフローなどで改善できることはないだろうか。チームやマネージャーの生産性向上に貢献できればすばらしい。
1 on 1をスムーズに行うための工夫
マネージャーと自分だけが見られる1 on 1ドキュメントを作り、共有しよう。毎週の1 on 1の前に話したいことを箇条書きで書いておくと、話を進めやすい。また、マネージャーと仕事以外の共通の話題が1つでもあると導入部分に使えて、場の雰囲気が和むのでお勧めである。ゲームやアニメなど趣味の話、子育ての話などだ。マネージャーも人間なので、仲良く打ち解けて話せたほうが良い。
マネージャーは通常、チーム内のプロジェクトの進捗管理や、エンジニアのキャリアマネジメントに責任を負っている。それを念頭に置きつつ話を聞こう。上でも述べたが、1 on 1はマネージャーの時間ではなくエンジニアのための時間だと考えよう。特にチームミーティングなどであまり発言する機会のないエンジニアの話をじっくり聞こう。目安としては8割ほどの時間を相手が話す時間に使うべきだ。
1 on 1で話した重要なことは箇条書きでよいのでメモをとろう。EvernoteやGoogle Docsを利用して、エンジニアごとにドキュメントを残しているマネージャーも多い。また、助けを求められたりフォローアップのアクションが必要だったりした場合はただちに実行し、忘れない工夫をしよう。勇気を出して相談してもらったのに、忘れたり放置したりしたら意味がない。
パフォーマンスマネジメント
パフォーマンスマネジメントもマネージャーの大事な仕事の一つである。1 on 1で定期的に、そのエンジニアが期待されている役割やパフォーマンスを一緒に見ていこう。よくできている部分、改善できるポイントを指摘しよう。よくできている部分は大げさなくらいほめるべきだ。マネージャーは「できていない」部分を指摘しがちだが、きちんとバランスをとるようにしよう。そうでないと毎回改善すべき点ばかりになってしまい楽しくない。また、できていない部分を指摘するときには、「できていない」という否定の説明ではなく、「もっと良くなる」という肯定的な説明をしよう。肯定的な改善ポイントから説明することで、エンジニアが落ち込まずに次のアクションを取ることができる。改善の進捗を見ていくので、毎回ドキュメントにメモをとりながら進めると良いだろう。
