読書メモ：「世界一流エンジニアの思考法」

どんな内容？

コンサルティングやプロジェクトマネジメントを中心に活動していた方が昔から夢であったプログラミングをやりたくて外資系の企業に入って、実際に海外の人たちと接する中で得た思考の違いの気づきをまとめた本です。

このメモについて

私はテストに携わっているのでプログラムをしているとは異なるのですが、テストに置き換えながら本を読みました。その時の自分自身の気づきをつづっています。
実際、自分自身があまり意識していないようなことが書いてあり新しい気付きを得るとともに普段、自分でも思っていることが書かれていて共感した内容もありました。
あとあくまでメモですのでまとまりはないのでご容赦ください。

印象に残った内容とその時何を思ったのか

ドキュメントは簡潔にコードと行き来する

テスト設計でも同じだな、と思った。テスト条件導出からテストケース化していくのだがテストケース化してはじめて気づくテスト条件の漏れや不備もある。その時は再度テスト条件から見直しをかけることもある。そういうこともあるのでテスト条件導出でそこまで時間をかけすぎてしまうとロスが発生しやすくなるのでテスト設計においてもアジャイルな思考は重要もしくは利用価値があるなと感じました。

準備に時間をかけたり、持ち帰って検討することをやめてその場で解決する

日本では会議というと事前準備をして終わった後に議事録を書いたりして様々なタスクが存在する。なんなら会議の効率化のために事前の会議資料の閲読を義務付けしたりしているところもあります。それが大手自動車メーカーのやり方だったりするからたちが悪い。しかし、著者の会社では会議の場だけで完結するとのこと。これは私も同意で会議の中で議題を明確にすればおよそ会議は準備がなくても成り立つし、議事録も要点だけをかければその場で議事録も書ける。あとでボイスレコーダーで聞き直しながら議事を書くことに何の意味があるのかと思うので非常に共感できる部分でした。

マルチタスクを避けてプログラミングに集中する時間を自分自身でアサインメントしている

アサインメントする場合には自分が集中できる時間や邪魔されにくい時間を見極めてそこに作業する時間を割り当てるといいかと思いました。

日ごろから誰かに聞かれることを想定して準備をしておく

自分自身の効率化について考えることはあってももし誰かに問い合わせがきたときのことを考えて準備しておくことは少ないので新しい気付きを得ることができた。また、誰かのためにと準備しておくことは自分自身の頭の整理にもつながるので非常に良い方法だと思った

気軽に聞ける空気づくりと気軽に聞くことの効率の良さ

これは自分がまたIT未経験からITに携わったときに「知らないことは聞いてね」と言われて聞くと「そんなのも知らないの？」って返されることがあったのを思い出しました。結果、自分で回り道をして調べて非常に効率が悪かったのを覚えています。そして「聞けばいい」というのは相手に求めて自分は何もしようとしていないんですよね。「聞ける雰囲気を作る」は自ら行動することになるのでその点においても空気を作り出そうとするのは大切だと感じました。自分自身は自分の嫌な思い出もあるのでできるだけ聞きやすい環境づくりと、あとは、聞いてこない場合には自分から尋ねるように意識しています。それを繰り返すことで聞いてくれるようになったりするもんなので。

フィードバックがポジティブ

自分の経験した会社では、特に何か失敗したときにはじめてアクションをとる。失敗したことに対して何が悪かったのかを分析させ、責任を追及する。そういったことをしている限りは失敗を恐れずにチャレンジしていく精神なんて育たない。なのに新しいことにチャレンジしろというんですよね。

大手SIerが技術からプロジェクトマネジメントに軸足を移したあたりからおかしなことになっていった

これは今のテスト会社でも同じことがいえるかもしれないと思いました。テスト会社でもPMOのような（そして本来のPMOとは異なる）PMを支援するだけのサービスに軸足をおいているところがあります。そこでは品質に関わることはほとんどせずに（テスト会社であるにも関わらず）PMとしての責任も取らずに横からただ口だけを出すことで生計を立てているようなサービスがある。これではテスト会社としての将来を危惧していたのですが、やっぱりそうだよなと改めて思いました。