パフォーマンスに関する具体的なフィードバックは、しばしば「パフォーマンスレビュー」という形で、ソフトウェア開発者のさらなる成長において中心的な役割を果たす。この記事では、パフォーマンスレビュー、年次パフォーマンスレビュー、パフォーマンス評価など、さまざまな状況、つまり1対1の会話や接触のあらゆる形で、ソフトウェア開発者に–フィードバックを与える方法の実践例をいくつか紹介する。
なぜソフトウェア開発者にとってフィードバックが重要なのか(そして難しいのか)?
内向的なソフトウェア開発者のためのモチベーションを高めるフィードバック
ソフトウェア開発者は伝統的に、他の人と働くことよりも、技術的な詳細を扱うことに関心がある。そのため、マネージャーにとって、特に内向的なソフトウェア開発者に対して、効果的でやる気を起こさせるような方法でフィードバックを伝えることは、難しいことかもしれない。
しかし、ソフトウェア開発者のマネージャーとして、あなたは評価面談の際に建設的な方法で肯定的なフィードバックと否定的なフィードバックの両方を伝えることを学ばなければならない。この記事で紹介するフィードバックの例は、その助けとなるだろう。
定期的な1対1のミーティングについての一般的な紹介に興味があれば、このテーマについての記事をご覧いただきたい: ガイド:1対1の会話を成功させるための6つのヒント。
注意:ソフトウェア開発者を個別に評価する
参考: 研究によると、ソフトウェア開発者は伝統的に内向的である。しかし、最近の傾向として、ソフトウェア開発者の性格タイプは多様化している。従って、自分の向かいに座っているのがどの性格タイプなのかを常に精査・評価し、それに応じてコミュニケーションをとるべきである。
ソースはこちらだ: ソフトウェア・エンジニアの性格プロフィールの進化
フィードバック・ディスカッションのための質問とアンケート
ソフトウェア開発者の評価面接:典型的な質問
ソフトウェア開発者との評価面談のための例文やテンプレート、フレーズをたくさん紹介する前に注意したいことがある:もちろん、IT業界に限らず、現状認識–の共通認識をまず確認するために質問をしてリードすることは、多くの場面で意味がある。
そこで、ソフトウェア開発者を対象とした従業員評価のための質問をいくつかまとめてみた:
ソフトウェア開発者への1対1の質問:フォーカス
- 仕事の集中を妨げるものは何か?
- 仕事で最後にフロー状態を体験したのはいつだろう?フローに入るのは簡単か?
- いつ、どのようにして、自分の「仕掛品の限界」を超えていることに気づいたか?今後、適切なWIPを達成するために、何を変えられるか?
- チーム内でのスピーチはどのように配分されているか?その中で自分の役割をどのように振り返っているか?
- 企業としての顧客とはどのような人たちなのか、また、彼らのニーズを満たすために具体的にどのような仕事をしているのか。
- 会社の同僚やその先の同僚について考えるとき、あなたが学びたいことは何だろうか?
ソフトウェア開発者への1対1の質問:ビジネスマインドセット
- 何が顧客のニーズを満たすことを妨げているのか?
- われわれの事業目標についてどう思うか:理解しやすく、わかりやすく、やる気を起こさせるものであるか。
- どうすれば、あなたの日々の仕事と当社の事業目標との結びつきを強めることができるか?どのようにすれば、あなたが当社の事業目標に貢献できるようになるか?
- 最後にプレーしてからの日数」の指標を見てみよう: 「前回からの日数 (1対1のミーティングでも、チームの振り返りでも役に立つ)。
これを読めば、このような鑑定インタビューにどのようにインテリジェントにアプローチすればよいかがわかるはずだ。具体的な調査もご希望であれば、最初のテンプレートを提供することもできる。
ソフトウェア開発者評価インタビュー:調査
対応する調査は、ソフトウェア開発者の成長を長期的に測定できるようにするのに役立つ。
しかし、合同ディスカッションのための双方向的な土台としても大いに役立つ。
以下の調査は、ソフトウェア開発者にとって重要な4つの分野に焦点を当てている。これらの記述は通常、例えば1(強く同意しない)から7(強く同意する)の尺度で評価される。
従業員インタビュー調査:ソフトウェア開発者向け
- 私は、#チームの目標と#の顧客のニーズを理解した上で、私たちの仕事を精査している。
- チームの継続的改善に積極的に貢献する。#チームプレー
- 私は#の顧客の課題や問題を知っている。
- たとえ外部からの#フィードバックが必要であっても、私の仕事の進捗は非常に速い。
注:本鑑定面接テンプレートでは、Health Check項目(質問項目)に対する同意を1~7段階で尋ねている。
すでに述べたように、EchometerのOne-on-Oneソフトウェアには、評価面談で社員を育成するのに役立つ多くのテンプレートが含まれている。特にアジャイルチームのためのテンプレートもあり、中にはインタラクティブで視覚的なものもある。–でその簡単な例を見ることができる。
1対1通話テンプレート 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ミーティングにおけるソフトウェア開発者へのフィードバック例:コード品質
タンヤ(Tanja)👩🏼🦰 がチームリーダー役、マルク(Marc)👨🏽 が従業員役である。
状況を説明する
👩🏼🦰
Tanja(チームリーダー):"前回のコードレビューでは、ダッシュボードに新機能を実装するためのあなたのプルリクエストを見た。コードは機能的に正しく、要件を満たしていた。"
👨🏽
マルク(従業員):"ああ、覚えているよ!"
観察された行動
👩🏼🦰
"私は、かなり複雑で読みにくい文章についてコメントした。例えば、いくつかの責任を組み合わせた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 👨🏽)である。
状況を説明する
👩🏼🦰
タンヤ(チームリーダー)だ:あなたの人事考課のテンプレートにある "Ownership "を評価したところ、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のミーティングや年度末のミーティングでソフトウェア開発者にやる気を起こさせるようなフィードバックをするのは、それほど難しいことではないことがわかるだろう?正真正銘の慈悲深さを保ち、藪を叩かず、共同解決に興味があることを示そう。
評価面談やそれ以外の場面でも、感謝と誠実さを示すことで「ラディカル・カンドゥア」を実行に移せば、あなたが思っている以上にポジティブで建設的な反応が返ってくるかもしれない。
次のフィードバック・セッションも頑張ってほしい!
そして、もしあなたの生活を楽にするハックがお好きなら、私たちのEchometerソフトウェアをお勧めする。完全に無料で試すことができる。
当社の1対1ミーティング・ソフトウェアは、ソフトウェア開発者との社員ミーティングのための様々なテンプレートを提供し、社員の能力開発を測定可能にする。私たちのツールを見て、次のテンプレートを試してみて:
世間話もなく、気まずい間もない。この1対1のテンプレートは常に機能します。
- 私が気づいていないだけで、何か誇りに思っていることはありますか?
- どのような小さな変化を起こせば、すぐに仕事が向上するだろうか?
- 仕事でもっと時間を取りたいことは?
...