ソフトウェア開発者のパフォーマンス・レビュー：6つのフィードバック例
具体的なパフォーマンスに関するフィードバックは、多くの場合「パフォーマンスレビュー」という形で、ソフトウェア開発者の能力開発において中心的な役割を果たします。この記事では、面談、年次従業員評価、業績評価など、あらゆる形の一対一の会話やコミュニケーションにおいて、ソフトウェア開発者にどのようにフィードバックを与えるかについて、実践的な例をいくつか紹介します。
ソフトウェア開発者にとってのフィードバックの重要性
ソフトウェア開発者にとってフィードバックが重要なのはなぜか（そして難しいのか）？
内向的なソフトウェア開発者のためのモチベーションを高めるフィードバック
ソフトウェア開発者は伝統的に、他の人と働くことよりも、技術的な詳細を扱うことに関心がある。そのため、マネージャーにとって、特に内向的なソフトウェア開発者に対して、効果的でやる気を起こさせるような方法でフィードバックを伝えることは、難しいことかもしれない。
しかし、ソフトウェア開発者のマネージャーとして、あなたは評価面談の際に建設的な方法で肯定的なフィードバックと否定的なフィードバックの両方を伝えることを学ばなければならない。この記事で紹介するフィードバックの例は、その助けとなるだろう。
定期的な1対1のミーティングについての一般的な紹介に興味があれば、このテーマについての記事をご覧いただきたい： ガイド：1対1の会話を成功させるための6つのヒント。
注意：ソフトウェア開発者を個別に評価する
参考： 研究によると、ソフトウェア開発者は伝統的に内向的である。しかし、最近の傾向として、ソフトウェア開発者の性格タイプは多様化している。従って、自分の向かいに座っているのがどの性格タイプなのかを常に精査・評価し、それに応じてコミュニケーションをとるべきである。
ソースはこちらだ： ソフトウェア・エンジニアの性格プロフィールの進化
フィードバック：質問と調査
フィードバック・ディスカッションのための質問とアンケート
ソフトウェア開発者の評価面接：典型的な質問
ソフトウェア開発者との面談のための例、テンプレート、フレーズをたくさん紹介する前に、念のため申し上げておきます。IT業界に限らず、多くの状況において、まず現状についての共通認識を確認するために、質問を通して導くことが有益であることは言うまでもありません。
そこで、ソフトウェア開発者を対象とした従業員評価のための質問をいくつかまとめてみた：
🎯 ソフトウェア開発者向け1対1の質問：焦点
- 仕事中の集中力を途切れさせるものは何ですか？
- 最近、仕事中にフロー状態を経験したのはいつですか？フロー状態に入るのは簡単ですか？
- 個人的な「Work In Progress Limit」を超えていることに気づいたのはいつ、何についてですか？今後、あなたが適切なWIPを達成するために、私たちは何を変えることができるでしょうか？
- チーム内での発言の貢献度はどのように分散されていますか？その中で、あなたは自分の役割をどのように振り返っていますか？
- 企業としての私たちのお客様は誰で、お客様のニーズを満たすためにあなたの仕事は具体的にどのように貢献していますか？
- 社内外の同僚のことを考えると、あなたが学びたいことは何ですか？
これを読めば、このような鑑定インタビューにどのようにインテリジェントにアプローチすればよいかがわかるはずだ。具体的な調査もご希望であれば、最初のテンプレートを提供することもできる。
ソフトウェア開発者評価インタビュー：調査
対応する調査は、ソフトウェア開発者の成長を長期的に測定できるようにするのに役立つ。
しかし、合同ディスカッションのための双方向的な土台としても大いに役立つ。
以下の調査は、ソフトウェア開発者にとって重要な4つの分野に焦点を当てている。これらの記述は通常、例えば1（強く同意しない）から7（強く同意する）の尺度で評価される。
🪞面談アンケート：ソフトウェア開発者向け
- 私は、#TeamZieleと#Kundenのニーズに対する自分の理解に基づいて、私たちの仕事に疑問を投げかけます。
- 私はチームの継続的な改善に積極的に貢献します。#TeamPlay
- 私は#Kundenの課題と問題を認識しています。
- 私の仕事は通常、外部からの#Feedbackが必要な場合でも、非常に迅速に進捗します。
注：この面談テンプレートでは、ヘルスチェック項目（アンケート）への同意を1〜7のスケールで尋ねます。
Echometerの一対一ソフトウェアには、従業員が面談で成長するのを助ける多くのテンプレートがあります。特にアジャイルチームのために、インタラクティブで視覚的にデザインされたテンプレートもあります。簡単な例はこちらにあります - 下のボタンをクリックして、私たちのツールもぜひご覧ください。
Echometerソフトウェアの一対一会話テンプレート
- ここに示された分野を見てみましょう。あなたとあなたのチームは、どこに最大の改善の可能性があると思いますか？
出典：Echometer 1:1ミーティングソフトウェア
緑色のボタンからわかるように、これらのテンプレートは私たちの1対1ミーティングツールEchometerでも無料で使うことができる。その他、質問テンプレートやコーチングテンプレートも多数用意している。
さまざまな1対1ミーティング（毎週、毎年、扱いにくい従業員との1対1など）の詳細なテンプレートに興味がある場合は、ブログに別の記事があります。 編集可能な15の実績ある1-1ミーティングのテンプレート（無料） .
さて、本題に戻りましょう。ソフトウェア開発者へのフィードバックの具体的な例とフレーズを見ていきましょう。
ソフトウェア開発者へのフィードバック用テンプレート
ソフトウェア開発者\*向けの一般的なフィードバックテンプレート
フィードバックサンドイッチのような古典的なフィードバック方法を避ける
1対1の会話におけるフィードバックのテンプレートは、サンドイッチ法に基づいていることがよくあります。ソフトウェア開発者にはこれを使用しないでください。従業員との会話での「回りくどい言い方」は誰の役にも立たず、特にソフトウェア開発者はこのような方法にアレルギー反応を起こすことがよくあります（以下を参照）。 フィードバックのためのサンドイッチ・メソッド批判).
ソフトウェア開発者は通常、マネージャーが一般的な肯定的フィードバックを与えるとき、それが相手の気分を良くするための道具に過ぎないことに気づく。
幸い、その方がうまくいく。
Radical Candor：ソフトウェア開発者にとってより効果的なフィードバック方法
1対1のミーティングのフィードバックを、フィードバックサンドイッチで無駄話で包むのではなく、ラディカル・キャンダー方式をフィードバック・テンプレートの基礎として推奨します。ちなみに、これはソフトウェアIT業界だけでなく、プライベートな分野でも役立ちます。さらに深く掘り下げてみましょう。
Radical Candourとは、評価面談において可能な限り正直で直接的なフィードバックを与えることを意味する。同時に、共感を示し、相手の幸福に焦点を当てることも意味する。Radical Candorは、どちらか一方を選ぶ必要はないことを示している：率直で正直か、共感的で思いやりがあるかだ。むしろ、両方を同時に行うことができるのだ：
さらにその下にある： ラディカル・キャンダーとは何か？
ソフトウェア開発者は、あなたが否定的なフィードバックで単刀直入に言ってくれればありがたいと思うだろう。
Radical Candorに基づくソフトウェア開発者向けフィードバック・テンプレート
このテンプレートはSBIモデル（状況、行動、影響）に基づいている。誠実で率直、しかも感謝の気持ちを伝えるのに役立つ。
こちらも参照のこと。 「フィードバック・プレイブック
以下は、フィードバック・テンプレートの各パーツの説明である：
フィードバック・テンプレートその1：事前の準備
フィードバックをする前に、数分かけて以下の点をよく考える：
- 状況：具体的にどのような状況を指しているのか？
- 行動その人からどのような行動を観察したか？
- 影響：その人の行動は（あなたや他の人に）どのような影響を与えたか？
- 願望：どのような状態を達成したいですか、またその理由は？（注意：ここでは、特定の方法を直接希望することではありません。それは対策の一部です（下記参照）。むしろ、なぜその影響があなたにとって問題なのかという、より大きな背景について述べています。）
- 行動：その人にどんな提案があるか？どのような行動の変化が目標状態に近づけるだろうか？どんなサポートができるか？
会話中に忘れ物がないように、ポイントを簡潔に書き留めておくのがベストだ。
フィードバック・テンプレートその2：会話を始める
長々とした1対1のミーティングのフィードバック・サンドイッチから始める代わりに、会話のきっかけとして状況を直接聞くことができる：
- 「私たちが…」と言ったときの状況について話したかったのだ。
状況を説明し、それから尋ねる：
- 「まだ状況を覚えているか？
フィードバックテンプレートその3：行動
それから、評価面接で観察したその人の行動を取り上げることができる：
- 「あなたはその状況に首を振り、こう言った。
効果について話す前に、相手にあなたの知覚や記憶についてコメントする機会を与える：
- “あなたの視点から見て、私はこれを正しく映しているだろうか？”
物事に対する自分の見方を説明するスペースを相手に与える。どちらの視点も、それについてコメントすることなく、対等な立場でその場に立たせるようにする。相手の視点の内容について質問する程度にとどめる。
フィードバック・テンプレート パート4：インパクト
この部分でのみ、その行動の影響について議論することになる。最初はできるだけ客観的な立場を保つ：
- 「私の印象では、あなた（の行動観察）の後、同僚のマルクは非常に気分を害したようで、私たちと協力的に仕事を続けようとはしなくなった。
しかし、その影響が自分にも及んでいるのであれば、それも共有することが重要だ。もちろん、常にプロフェッショナルであるべきだが、人間的な面を見せることもできる：
- “私自身、あの状況では正直恥ずかしかったし、その時点から会話は不愉快なものだと感じていた”
フィードバック・テンプレートその5：願い
鑑定インタビューのこの部分で、具体的な要望を述べる：
- 「同僚のマルクと再び協力するための良い基盤を見つけることは、私にとって重要なことだ。
もう一度文脈を整理してみよう：
- 「そしてそれ以上に、近隣のすべての専門地域と良好な協力関係と関係を維持するために協力し合うことが、私の大きなニーズである」。
また、なぜそのような願望を持つのか、関連する目標についても言及する：
- 「良好な関係があってこそ、この会社でチームとして目標を達成することができる。また、社内でチームとして良い評判を得ることも重要だ。“
フィードバック・テンプレート その6：測定
自分の解決策を提示する前に、1対1の会話でオープンな質問をすることができる：
- “これについてはいくつか考えがある。だが、まずは君の意見を聞きたい：どうすれば目標を達成できると思う？”
その後、アイデアを共有することができる。拘束力のある具体的なフォローアップについて合意する。これを文書に記録する。
フィードバック・テンプレート その7：不合格
鑑定面接が相手にとって役に立ったかどうか、答えられない質問があるかどうかを尋ねる。次にその話題について話すときのために、チェックインを手配する。
オープンな対話に感謝の意を示し、相手の洞察力と協力に感謝する。
フィードバック・テンプレートその8：フィードバックを振り返ってみる
すべてのフィードバック・セッションの終わりに、次のような質問を自分に投げかけるべきだ：
- 正直さ：自分の意見を正直に、できるだけありのままに伝えたか。
- 感謝：相手は私のフィードバックに価値を感じているか？
すべての質問に「はい」と答えられたなら、あなたのフィードバック・セッションはとてもうまくいったことになる。そうでなかったとしても、心配することはない。今後、どのように違う形で物事を進めることができるかを考えてみよう。繰り返しになるが、これらのヒントのほとんどは、ソフトウェアIT業界だけに当てはまるものではない。
この際、対応するフィードバック・ディスカッションや、ソフトウェア開発者の長期的なコーチングを簡素化するソフトウェアももちろんあることを指摘しておきたい。
当社の1対1ミーティング・ソフトウェアは、ソフトウェア開発者との社員ミーティングのための様々なテンプレートを提供し、社員の能力開発を測定可能にする。私たちのツールを見て、次のテンプレートを試してみて：
世間話もなく、気まずい間もない。この1対1のテンプレートは常に機能します。
💬 テンプレートから：
- 私が気づいていないだけで、何か誇りに思っていることはありますか？
- どのような小さな変化を起こせば、すぐに仕事が向上するだろうか？
- 仕事でもっと時間を取りたいことは？
…
では、この評価面接のテンプレートを使って、いくつかの実践例を見てみよう！
1:1ミーティングのフィードバック例コードの品質、オーナーシップ
1対1のミーティングにおけるソフトウェア開発者へのフィードバックの例
1対1ミーティングにおけるソフトウェア開発者へのフィードバック例：コード品質
タンヤ（Tanja）👩🏼🦰 がチームリーダー役、マルク（Marc）👨🏽 が従業員役である。
状況を説明する
「前回のコードレビューでは、ダッシュボードに新しい機能を実装するためのプルリクエストを確認しました。コードは機能的に正しく、要件を満たしていました。」
「ええ、覚えています！」
観察された行動
“私は、かなり複雑で読みにくい文章についてコメントした。例えば、いくつかの責任を組み合わせた50行以上のメソッドがあった。しかし、あなたはこのコメントについて表面的にしかコメントせず、それ以上踏み込まなかった。”
「私には、そのコメントはオプションの提案に聞こえた。また解決策を変えるのは手間がかかりすぎるように思えた。”
インパクト
「とにかく、あなたのコメントには正直ちょっとイライラさせられたし、あなたからの修正を主張する代わりに、どうせすでにコードの中に自分のやり方を考えていたのだからと、その後に自分でメソッドを改良しただけだ」。
「そうだったのか。
目標と欲望
“我々の共通の目標は、コードが機能的であるだけでなく、保守性が高く、誰にとっても理解しやすいものであることを保証することだ”
「まさにその通りだ。
対策
“今後、このようなケースでよりスムーズにコードの品質を向上させるにはどうしたらよいか、何か提案はあるか？”
“コメントで、改善が提案されているだけなのか、要求されているだけなのかがわかりやすくなれば助かる。”
「わかりました。そうしましょう。これをチーム会議にもう一度持ち込みます。さらに、あなたの側でもフォローアップが必要だと思います。」
“次のトピックでは、コード品質の要件について私の理解を深めるために、一緒にペアプログラミングに入るのはどうだろう？”
結論
“2つの良いフォローのようだね！じゃあ、このままいこう。ペア・プログラミングを始める日を、来週の中頃に決めたいんだ」。
“よし、楽しみだ！“
1対1のミーティングにおけるソフトウェア開発者へのフィードバック例： オーナーシップ
タンヤ（Tanja）👩🏼🦰 がチームリーダー役、マルク（Marc）👨🏽 が従業員役である。
状況を説明する
「マーク、エクスポートプロセスのための新しい機能を開発した、最後のタスクについて話し合いたいと思います。その機能は現在稼働していますが、途中でいくつかの課題がありました。」
「ええ、覚えています。具体的に何のことですか？」
観察された行動
“テスト用にコードが引き渡された後、いくつかの長い遅延があったことに気づいた。例えば、QAの同僚からのコメントには何日も返事がなかった。また、レビュー漏れについて2度も思い出させなければならなかったこともあった。”
「ふーん、そうなんだ。正直なところ、かなり多くのことが起こっていて、テストは並行して続けられると思っていたんだ」。
インパクト
「その結果、この問題のために配備を延期せざるを得なくなった。
「そうだったのか。急用が入ったら連絡をくれると思っていたよ」。
目標と欲望
「我々の目的は、不必要な遅延を最小限に抑え、開発者が実装中にオーナーシップの考え方を採用することだ。これは、全員が自分のチケットが最初から最後まで–を通過することを積極的に確認することを意味し、これにはQAとのコミュニケーションも含まれる。”
「言いたいことはわかる。プロセスをもっと円滑に進めたい。”
対策
“あなたの立場から言えば、このような状況下であなたがより積極的に行動し、オーナーシップを発揮できるようにするために、私たちは何ができるだろうか？”
「例えば、テスト段階で未解決の問題については毎日チェックインする。そうすれば、やり残しがないようにすることができる」。
「それはいいね。そして、コードが確定した後の次の主要なタスクについては、本番のローンチまでどのようにこのトピックを進めたいのか、簡単な計画を立てることを提案したい。その計画を私かQAの同僚に見せるといい」。
「そうだね。そうすれば、私自身が物事をよりよく見守ることができる」。
結論
「素晴らしい。この2つの対策をこう記録しよう：テスト段階では毎日チェックインを行い、次の大きな仕事ではフォローアップを計画する。それは実現可能か？”
「そうだね。そのまま日記に書こう」。
「素晴らしい。きっと大きな違いになるだろう。次回の1対1のミーティングでは、対策の状況をもう一度見てみよう。ありがとう！“
質問を通して導く：1:1ミーティングのテンプレート
経営学の文献に、「質問することによってリードせよ」という名言がある。そしてそれには多くの意味がある。
定期的に継続的に1対1のミーティングを実施し、その中で従業員と一緒に質問をしながらフィードバックについて振り返ることで、問題が「蓄積」されることはありません。
そこで、従業員とのEchometerツールで使用できる別のテンプレートを紹介したい。原則的に、このテンプレートを定期的に使用することもできる。
下のボタンをクリックするだけで、試してみることができる（ログインは不要）：
はじめに
- 今週はいかがでしたか？
📊 プロジェクトの最新情報
- 現在のプロジェクトの進捗状況はいかがですか？大きな成功や障害はありますか？
- 議論または共同で検討したい技術的な課題はありますか？
💻 コードの品質と開発
- 最近のあなたの仕事の質についてどのように感じていますか？
- 改善したい、または新しいスキルを習得したい分野はありますか？
🤝 チーム、コラボレーション、次のステップ
- チーム内のコラボレーションはうまくいっていますか？コミュニケーション不足はありますか？
- 私たちが使用しているツールとプロセスは、あなたの仕事を効果的にサポートしていますか？
- 今後1〜2年で、あなたはご自身のキャリアをどのように考えていますか？
- あなたが成功するために、私はどのようにサポートできますか？
まとめ
- 今後数ヶ月で最も楽しみにしていることは何ですか？
- 他に質問や懸念事項はありますか？
⁉️ 気分チェック（アンケート）
パフォーマンスレビューのフィードバック例：チームワーク、オーナーシップ
パフォーマンス・レビューにおけるソフトウェア開発者へのフィードバックの例
注：伝統的なパフォーマンスレビューは、ソフトウェア開発者にもマネージャーにも不人気な傾向がある。見てみよう： 「フォーブス誌による「業績評価は無意味で侮辱的だ。
しかし、人事考課はまだ社内で決められた形式であることが多い。もちろん、トップダウンの評価に限定するのではなく、従業員との目線での対話として業績評価を行うことを止めるべきでない。以下の1対1の対話の例は、それがどのように機能するかを示している。
注：すでに述べたように、従業員評価用のテンプレートは、もちろんフィードバックを建設的に伝えるのに役立つ。このトピックに興味があるなら、以下のブログ記事が参考になるだろう： 定期的な従業員チェックのための5つのテンプレート .
パフォーマンスレビューにおけるソフトウェアエンジニアへのフィードバック例チームワーク
チームリーダーはタニャ（Tanja 👩🏼🦰）、ソフトウェア・エンジニアはマーク（Marc 👨🏽）である。
状況を説明する
「あなたの業績評価テンプレートで『チームワーク』の項目を評価しなければならなかったとき、残念ながら10点満点中5点しかつけられませんでした。この点について改善する機会を公平に与えるために、その理由を説明したいと思います。」
「ああ、わかりました。理解できるように手伝ってください。」
観察された行動
“ここ数カ月、チームとのコラボレーションが最適でない状況があることに気づいた。例えば、前回のスプリントでは、他の人と一緒に解決した方が良いにもかかわらず、自分ひとりでタスクに取り組んでいたケースがいくつかあった。具体的な例としては、新しいAPIの統合があった。私たちは、あなたとアレックスが一緒に作業することを検討していたが、あなたはほとんどのステップを一人で引き受け、アレックスには最小限のことしか関与しなかった。”
「自分で手早くやったほうが効率的だと思った。それが問題視されているとは知らなかった。”
インパクト
「しかし、これはチーム内の透明性を失うことにつながった。アレックスは後に、APIがどのようにセットアップされているのか正確に知らなかったため、関連する仕事に関わるのが難しいと感じた。また、他のチームメンバーからも、十分な関与が感じられないことがあり、質問があってもサポートしてもらうのが難しいというフィードバックを受けた。”
「正直、驚いたよ。頼まれたら手伝うつもりだったんだ」。
目標と欲望
「チームとしての目標は、効率的に仕事をするだけでなく、知識を共有し、全員を巻き込むことだ。そうすることで、コラボレーションが強化され、全員が互いを代表できるようになる。今後は、知識を積極的に共有し、他のメンバーに力を与えるために、このチームにおける知識キャリアとしての役割をもっと活用してほしい。チームの生産性は個人のパフォーマンスよりも重要だ。
「わかったよ。これまでは自分の生産性に集中しすぎていたんだと思う。”
対策
“チームを仕事に巻き込み、知識を共有することにもっと注意を払うために何が役立つだろうか？”
「誰がどのように大きなタスクに取り組むことができるかを、最初の段階で明確にする習慣を身につけることができた。また、タスクのキックオフのようなものを設けて、主要なアーキテクチャー決定について合意し、他の誰かが単独で行うべきタスクや、ペアプログラミングで行うべきタスクを特定することもできるだろう。”
「それはいいね。毎週のチームミーティングで進捗状況を報告するだけでなく、コードやアーキテクチャの決定について積極的に意見を述べる習慣を身につけたらどうだろう？”
「それはいいことだ。そうすれば、経験の浅い同僚たちが後で私のコードに取り組みやすくなるだろう”
結論
「いいね。では、そのフォローアップを業績評価用のテンプレートに記録しよう：
- これからは、ウィークリーで自分の知識やアーキテクチャー上の決断を積極的にチームと共有していくことになる。
- これからは、あなたが担当するテーマについて、別の開発者と一緒にキックオフを行い、解決策を共同で考案し、実装を分担してください。
「いい感じだ
「わかりました。両方の対策について、まずは2か月後のレビューで確認することにします。その後、1対1の会話で状況を話し合い、今後の進め方を検討しましょう。」
そうだね。それから、“チームワーク “の点数を上げられないか見てみよう。少なくとも10点満点中8点は取りたいね”
「それを聞けて嬉しいよ！私は絶対にそれが現実的だと信じているし、できる限りサポートするつもりだ。”
「ありがとう
ソフトウェアエンジニアのパフォーマンスレビューへのフィードバック例オーナーシップ
次の1対1の会話例では、所有権に関するソフトウェア開発者へのフィードバックを扱おう。
チームリーダーはいつものようにタニャ（Tanja 👩🏼🦰）、ソフトウェア・エンジニアはマルク（Marc 👨🏽）である。
状況を説明する
「あなたの業績評価テンプレートで『オーナーシップ』の項目を評価しなければならなかったとき、10点満点中6点しかつけられませんでした。その理由を説明し、この分野でさらに成長する機会を与えたいと思います。」
「ええ、それは少し意外です。チームの他のメンバーよりも多くのテーマに取り組んできたからです。説明してください。」
観察された行動
「ここ数カ月、あなたのタスクにしばしば遅れが生じていることに気づいた。あなたからのQAコメントやコードレビューが長期間回答されなかった例がいくつかある。その結果、あなたのトピックは何週間も遅れてようやく本番を迎えた。具体的な例としては、エクスポートのバグ修正があった。QAからのフィードバックに答えたのは再三のリクエストの後であり、変更が本稼働するまでに合計3週間を要した。”
「ああ、覚えているよ。同時に他の2つのトピックに取り組んでいたので、そんなに早くフィードバックを入力することができなかったんだ。”
インパクト
「これはチーム全体のスピードと生産性に影響を与えた。QAは何度もフォローアップをしなければならず、彼らの能力を縛ってしまった。リリース計画も延期せざるを得なかった。加えて、自分の問題解決に全責任を負っていないように感じられ、チーム力にも負担がかかる。何人かのチームメンバーは、“依存関係に関しては、あなたに頼っていいのか不安に感じる “と私に言った。
“ああ、それはすまなかった。気づかなかったよ。並行してタスクをこなそうとしたんだけど、どうやらうまくいかなかったみたいだね”
目標と欲望
「私の目標は、あなたが少ないトピックに集中し、各タスクに最初から最後まで全責任を持つことだ。つまり、最初のコードを書くだけでなく、QAフィードバックを迅速に処理し、トピックがスケジュール通りに進むようにすることだ。こうすることで、未解決のタスクが長引いたり、他のタスクの妨げになったりするのを防ぐことができる。”
「それは理にかなっている。同時にたくさんのトピックを抱えすぎて、圧倒されてしまうことがよくあった。少ないタスクに集中した方がいいのかもしれない。
対策
“いくつかのトピックに集中させ、それを完全に実行する責任を負わせるにはどうしたらいいのだろう？”
「1スプリントあたりのトピックは2つまでとし、同時に3つ以上のトピックに取り組まないようにする。また、定期的にコメントやレビューに取り組むために、カレンダーに決まった枠を設けて、取り残しがないようにする。”
“それは賢明だと思う。加えて、同時に多くのトピックに取り組んでいる場合は、スタンドアップで積極的に助けを求めるといいと思う。トピックを引き継いでくれる人がいるはずだ。”
“OK、フェアだ”
結論
これらの対策を、今後2か月の目標として設定しましょう。
並行作業が減る：
- スプリントごとに最大2つのトピックを担当し、3つ以上のトピックを並行して担当することはない。
- スタンドアップでチームに積極的なサポートを求める
- コメントとレビューを処理するための固定された時間枠をカレンダーに設定します。
「現実的だね。そうしよう」。
「素晴らしい。これらの対策が功を奏したかどうかは、2カ月後の業績評価で確認できるし、業績評価で『オーナーシップ』の評価を再び上げることができるかどうかもわかる」。
「ありがとう、タニヤ。それを実践するよう努力するよ。以前は “オーナーシップ “でいつもトップの評価を得ていたんだ。次の人事考課までには、またそこに到達できると思う？”
「それは喜ばしいことだ。そうだね、この対策で急速な改善は絶対に達成可能だと思う。2週間に1度のマンツーマン・ミーティングで、現状とサポートが必要かどうかを話し合おう。”
「ありがとう！そうだね、数週間以内にここが顕著に改善されれば嬉しいね！“
年次ダイアログ フィードバックの例役割変更を望む
年次レビューにおけるソフトウェア開発者へのフィードバックの例
もしすでに、1年の間に開発者と定期的に1対1のミーティングや業績評価を行っているのであれば、もはや詳細な年次ミーティングは必要ないだろう。パフォーマンス、フィードバック、さらなる開発に関するやりとりは、すでに継続的な対話になっているはずだ：
とはいえ、古典的な年次査定を要求する会社もある。
💡
ソフトウェア開発者のマネージャーとして、すでに定期的な1:1ミーティングや業績評価を行っているのであれば、年次レビューは形式的なものに過ぎないはずだ：
ソフトウェア開発者はすでにフィードバックに気づいており、開発の可能性に取り組んでいるはずだ。
そこで、もしあなたがソフトウェア開発者のマネージャーとして、（場合によっては定期的な1対1の面談に加えて）年度末面談という形式を満たさなければならないのであれば、ソフトウェア開発者との年次社員評価の例も見てみよう。
ところで、この時点でもうひとつヒントを：新入社員との初めての1対1ミーティングが目前に迫っているのなら、このテーマに関する我々の記事をお勧めする： 新入社員との個別面談における5つのヒント .
ソフトウェア開発者との年次ミーティングのアジェンダとテンプレートのサンプル
- レビューとパフォーマンス
- 成功事例：どのプロジェクトやタスクがうまくいったか？期待を上回ったのはどこか？
- 課題：何がうまくいかなかったのか、それはなぜか？これらの課題を将来どのように克服できるか？
- 振り返り: 開発者は自分のパフォーマンスをどう見ているか?チームやマネージャーはどのようなフィードバックをしているか？
- 協力とチーム文化
- コミュニケーション：チーム内や監督との協力関係はどのように受け止められているか？
- 職場の雰囲気：チーム文化や職場環境に改善の可能性はあるか？
- リーダーシップに関するフィードバック: マネージャーは開発者をどのようにサポートできるか？
- 開発者からのフィードバック：プロセス、ツール、またはワークカルチャーの改善に関する提案はあるか？
- ワークライフバランス：現在の仕事量についてどう感じているか？残業やストレス要因はあるか？
- リソース：ツール、プロセス、フレームワークの条件は、効率的に作業するのに十分か。
- 専門知識、目標、開発
- 強み：開発者を特徴づける技術的、方法論的、社会的スキルは何か？
- さらなるトレーニング開発者はどのような新しい技術やスキルを学びたいのか？関連するコース、カンファレンス、プロジェクトはあるか？
- キャリアの目標：開発者は、中長期的にどのような地位や責任を目指しているのか。どのようなステップでそこに到達するのか？
- プロジェクトの焦点：開発者がより集中的に取り組みたいプロジェクトや技術は何か。
- 報酬
- 業績連動報酬：給与や賞与を調整する必要があるか？
- 結論
- 短期的な目標：来年の具体的な目標は何か？
- 合意：それぞれの施策について、次のチェックインはどうするのか？
以下は、年度末レビューまたは年次業績レビューにおけるフィードバックの典型的な例である：従業員からの役割変更の要求。
年次総会でのフィードバック例役割の変更を望む
チームリーダーはタニャ（Tanja 👩🏼🦰）、ソフトウェア・エンジニアはマーク（Marc 👨🏽）である。
エントリーと状況
「マーク、今日はあなたの年間フィードバックと目標について話し合うことができてうれしいです。特に重要なテーマはありますか？」
「ええ、自分のキャリアアップについて考えてみました。ソフトウェアアーキテクチャの方向に進みたいと思っています。以前から興味があり、アーキテクチャの決定や戦略的な技術管理についてもっと深く学びたいと思っています。」
「エキサイティングだね、マーク。君が明確な目標を持っているのは喜ばしいことだ。そのためにどう準備すればいいか、話し合おう。次のステップに進む前に、君がさらに成長する必要があると思う点がいくつかある。”
フィードバックをする
「まず第一に、今年、特に実装の質と新技術への対応において、あなた方が多くの進歩を遂げたことを強調したい。また、新しいキャッシング・システムの導入など、大局を見る目を持っていることも示した。”
“ありがとう、そう言ってもらえると嬉しいよ！”
「しかし、ソフトウェア・アーキテクトの役割について考えるとき、現状ではまだ十分に満たされているとは思えない要件がいくつかある。たとえば、チームとコミュニケーションをとり、技術的な決定に他人を巻き込むことは重要な要素だ。あなたにはまだ可能性があると思う。チームを十分に巻き込むことなく、独自に意思決定することが多い。”
「わかったよ。時々誰かを束縛したくはなかったが、それが建築家という役割にとって理想的でないことは理解している。”
目標と欲望
「その通りだ。ソフトウェア・アーキテクトはコーチであり、コミュニケーターでもある。他の人たちを仲間に引き入れ、技術的なコンセプトを伝え、一緒にソリューションを開発するんだ。”
「なるほどね。また、自分の建築に対する考えをチームメンバーに効果的に伝えることがまだできていないことにも気づいた。”
プラン対策
「今後6ヶ月の間に、あなたがその役割を果たす資格を得られるよう、一緒に取り組んでいけると思う。具体的な対策を明確にしたらどうだろう？”
「そうしたいね。何を考えている？
“何よりも、ソフトウェア・アーキテクチャの決定プロセスを、自分で決めるのではなく、司会進行してほしい。次の主要なトピックごとに、アーキテクチャー・キックオフのモデレーターを務めるのはどうだろう？目的は、意思決定プロセスで同僚をサポートし、その後、彼ら自身に解決策を実行させることだろう。”
「それはいいですね。自分で全てを実行するのではなく、コーチとして影響力を行使する方法を学ぶことができます。」
「さらに、ソフトウェアアーキテクトの役割に開発者を準備するための良いコースがあると思います。これらのコースでは、ハードスキルに加えて、その役割に必要なソフトスキルも間違いなく教えられるでしょう。」
「ええ、実はもうコースを見つけています。」
結論
「素晴らしい、では年次面談で以下のことを記録しておきます。
- 開発目標：ソフトウェア・アーキテクト
- 対策だ：
- チーム内で建築のキックオフを司会する
- ソフトウェア・アーキテクトのためのコースに参加する
もちろん、これらのテーマについては1対1のミーティングで継続的に話し合いますが、次の公式チェックインは3か月後の業績評価になります。
「いいですね。それまでに、ある程度の成果を上げているはずです。」
「私もそう思います！その間に、この件で私にできることがあれば、いつでも声をかけてください。」
「3か月後に私の希望する役割変更についてもう一度話し合うことはできますか？」
「もちろん、役割変更については何も約束できません。しかし、あなたの希望をメモしておき、できる限りサポートするように努めます。」
「ありがとう
結論：1:1ミーティング、パフォーマンス・レビュー、年次評価でソフトウェア・エンジニアにフィードバックする。
結論：ソフトウェア開発者のモチベーションを高めるフィードバック
例とテンプレートを見れば、1対1のミーティングや年度末のミーティングでソフトウェア開発者にやる気を起こさせるようなフィードバックをするのは、それほど難しいことではないことがわかるだろう？正真正銘の慈悲深さを保ち、藪を叩かず、共同解決に興味があることを示そう。
社員との面談などで、感謝と正直さを示すことで「Radical Candor」を実践することができれば、あなたの思う以上にポジティブで建設的な反応が得られるかもしれません。
次のフィードバック・セッションも頑張ってほしい！
そして、もしあなたの生活を楽にするハックがお好きなら、私たちのEchometerソフトウェアをお勧めする。完全に無料で試すことができる。
当社の1対1ミーティング・ソフトウェアは、ソフトウェア開発者との社員ミーティングのための様々なテンプレートを提供し、社員の能力開発を測定可能にする。私たちのツールを見て、次のテンプレートを試してみて：
世間話もなく、気まずい間もない。この1対1のテンプレートは常に機能します。
💬 テンプレートから：
- 私が気づいていないだけで、何か誇りに思っていることはありますか？
- どのような小さな変化を起こせば、すぐに仕事が向上するだろうか？
- 仕事でもっと時間を取りたいことは？
…
