親切なエンジニアリング

親切さとは？

Kind is about being invested in other people, figuring out how to help them, meeting them where they are.

親切さとは、他者に心を配り、どう助けられるかを考え、その人が必要としているところに応えることです。

— Tanya Reilly, Continuous

親切さとは、上でTanya Reillyが述べているように、人に心を配ることです。単に優しくすることではなく、相手の立場に立って、その感情や背景を理解することを意味します。あらゆる状況で万能ではありませんが、さまざまな問題を解決する助けになります。

思いやり

• 「プロフェッショナルであること」を超えて、自分の仕事にしっかり向き合いましょう。
• オープンで人間味のあるふるまいをして、信頼を築きましょう。
• 人と直接向き合いながら、思慮深く気を配りましょう。
• 罪のない嘘は悪くないかもしれませんが、人を成長させることはできません。
• 思いやりを失わず、良い行動は称賛し、改善点はきちんと伝えましょう。

非同期(async)コミュニケーション

• 変化については「何を？」や「どうやって？」だけでなく、「なぜ？」もより深く理解しようと努めましょう。
• 悪意や無能さを前提にしないでください。
• 強い言い方や物議を醸しやすい発言ではなく、心を開いた問いかけをしましょう。
• 指摘する前に、ラベル付けが明確であることが重要です。
• 指摘が多すぎると、かえって仕事の妨げになることがあります。
• 意見が多い場合は、コミュニケーションを順次的な方法に切り替えましょう。

心理的安全性

• チームや同僚に、まず最初にフィードバックを求めましょう。
• フィードバックの構成は、次のようにシンプルです:
  • うまくいったこと
  • うまくいかなかったこと
  • 後でやること
• 人々の背景、経歴、そして個人的な好みをオープンに受け入れましょう。
• 会議や文書に大きく貢献できていない人に目を配り、その人たちが声を上げられる方法を探しましょう。
• 人々が自分にとって正しいと感じるどんな方法でも自己表現できるよう、声を上げましょう。
• 個々の失敗は、実際にはプロセス、環境、またはワークフローの失敗に起因していることがよくあります。
• 私たちは一緒に成功し、一緒に失敗します。
• すべての「失敗」や出来事は、成長し学ぶための機会として祝福されるべきです。
• イノベーションを促進するには、人々がリスクを取り、挑戦し、そうした行動が安全だと感じられるように後押しする必要があります。

フィードバック/批評

• 最初から評価する側ではなく、まず評価を受ける側になりましょう。
• 個人的な問題にしないでください。
• フィードバックや称賛をするときは、できるだけ具体的で丁寧に伝えるよう努めましょう。
• 誰かに批判的なフィードバックをするなら、解決策も示してみましょう。
• 自分が好むフィードバックの受け方を理解しましょう。
• 聞いて理解したうえで、フィードバックをくれた人に感謝しましょう。
• すぐに反応せず、時間を取って考えを整理し、フィードバックを受け止めましょう。
• 説明や例を求めましょう。
• フィードバックを行う3つの要素を覚えておきましょう:
  • 感情
  • 信頼性
  • 論理
• 自分ではなく、聞き手の感情を考慮しましょう。
• 専門性と謙虚さを示しましょう。
• 自分の仕事の進め方と、結論に至る方法を示しましょう。

---

• 技術業界の有害な語り口の問題、直していこう！

[arfwene]

当然のことですが、実践するのは難しいですね..

[aster]

上の資料をもとに、開発ではどのように親切なエンジニアリングを適用できるのか。
いわゆる KDD(Kindness Driven Development) を AI の助けを借りてまとめてみました。

コード作成

• コメントとドキュメント化は「なぜ？」に重点を置いて書きましょう。コードが存在する理由と背景を説明することが重要です。
• 複雑なロジックにはドメイン用語を活用した変数名と関数名を使い、他の開発者が理解しやすいようにしましょう。
• 新しい技術やパターンを導入するときは、チームメンバーの学習曲線を考慮しましょう。
• レガシーコードを非難しないでください。当時の制約や文脈があったはずです。
• 将来の保守担当者のために、エッジケースと失敗ケースへの対応を文書化しましょう。
  アーキテクチャ設計
• システム設計では運用チームと QA チームの視点も考慮しましょう。
• 監視やデバッグをしやすくすることも、親切な設計の一部です。
• 拡張性のある設計は、未来のチームメンバーへの配慮です。
• 技術的負債を管理するときは、完全な解消ではなく「管理可能なレベル」を目標にしましょう。
• 新機能を追加しやすい構造を作ることが重要です。
  コードレビュー
• レビューを依頼するときは、変更内容のコンテキストを十分に説明しましょう。
• 「こうしてみるのはどうでしょうか？」のような提案型のフィードバックを使いましょう。
• 良かった点にも必ず触れましょう。「この部分、とてもすっきりしていますね」
• 代案を示すときは、その理由もあわせて説明しましょう。
• 緊急ではない改善事項は別途 Issue として登録し、現在の PR のスコープを尊重しましょう。
  テストコード
• テストが失敗したときは、明確なエラーメッセージを提供しましょう。
• テストケースには文書化の役割もあります。ビジネスルールをよく説明するテストを書きましょう。
• 他の開発者がテストを簡単に追加できる構造を作りましょう。
• テストデータには、理解しやすい実際の事例を使いましょう。
• テスト環境の設定を自動化して、参入障壁を下げましょう。
  デプロイと運用
• デプロイスクリプトには十分な説明とガイドを含めましょう。
• 障害発生時のデバッグに役立つログをあらかじめ準備しておきましょう。
• 設定変更が必要な場合は、影響範囲を文書化しましょう。
• 新機能をリリースするときは、ロールバック計画もあわせて準備しましょう。
• 運用ガイドは、新人開発者の視点で書きましょう。
  知識共有
• トラブルシューティングの経験を文書化して共有しましょう。
• 新しい技術を導入するときは、学習資料を作って共有しましょう。
• コード作成ガイドには「なぜこのようにすることにしたのか」を含めましょう。
• 定期的な技術共有の時間を通じて、チームの成長を促しましょう。
• 質問しやすい環境を作ることは、ジュニア開発者の成長を助けます。

[bbulbum]

別に文章として書いてもいいくらいの内容ですね（笑）

[laeyoung]

とても良いですね！

[aer0700]

とても良いコメントですね。