エンジニアリング組織論を読んだ

2018年6冊目

タイムラインで複数の人がオススメしていたので読み始め見た。

まだ2割くらいかな。ってところで思うところが多すぎてメモを更新するスタイルとする。

前の記事のアプリケーション設計でもそうだが、ハイライトが多すぎて後でハイライトを追うスタイルだと理解まで落とし込むまでに次のハイライトに進んでしまい理解が追いつかない。ちょい出しで進めたほうがよさそう。

認知的不協和

認知の歪み

事実と解釈

怒りを悲しみとして伝える

この部分がチーム開発に重要と思っている。

サイボウズのチームのことだけを考えたでも話していたが、事実と解釈を誤って伝えるとどうしてもコミュニケーションの中でフィルタや増減がかかってしまうので意識したい。

冒頭で書いていた、以下はいつも思ってることなので、これは読もう！とすぐに感じた。

最近設計関連を読むことが多いのはテスト容易性を高めるためであり、テスト容易性のコード設計は正しいドメインの理解と、コードレビューでは指摘できない部分の強化、つまりチーム内における開発手法や思想の共有、それはチームとしての価値観につながる。

いいコードを書きたい

だから、

いい設計をしたい

だから、いいチームを作りたい

そのチームが事業に売り上げをもたらす強さを持てば最強じゃないか

■当たり前のことを意識してやるアクノレッジメントは 、

・ちゃんと挨拶する

・無視しないで話を聞く

・相手に感謝を伝える

・気にかけて話しかける

・自分本位でなく相手本位で話をする

書いてあるように本当に小学生の標語のようだ。実際はこれが人の基本という事だな。

小学生の時の校長先生が常にいっていたのは

1、挨拶

2、学習

3、読書

だったな。挨拶が一番にくるあたり、コミュニケーションの基本ということになるな。

最初にも書いてあったが、

エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方

これに尽きると思う。見積りもスケジュールもすべてこれをベースに考えたい。