たとえば、管理ツールのオペレーションのミスが起こった時に、再発を起こしたくないという理由で、どういう手順で起きたのか、管理ツールに問題があるなら改善したいから言って欲しいというようなことを伝える。 あるいは、期待したアウトプットと違った時に、せっかくやってくれたことはありがたいが、ズレがあったことを伝えて、その目的からすり合わせようとする。 のようなケースで、自分としては、相手を責めるつもりなど一切なくて、とはいえそう捉えられないようにその目的から伝える努力をしているつもりなのだけれども、 ご迷惑をお掛けして申し訳ありませんでした。以後このようなことがないよう徹底いたします。 みたいな反応をされてしまうと、それ以上の発展は望めないし、ああ僕はこの人を謝らせてしまったんだなとなり惨めな気持ちになる。 確かにこういうのは大概他の部署の方とのコミュニケーションだし、事前に信頼関係が出来ているわけ
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
