概要

こちらの本は、具体的なエピソードを交えながら、仕事の無駄を排除し、生産性を高めるための「仕事の進め方・考え方」が解説されています。 著者が現役のCTOということもあり、エンジニアにとって共感しやすいエピソードが多くなっています。

第１章　「谷」を埋めるな、「山」を作れ！

「山」がはっきりしていないのに「谷」を埋めることばかり考えるのは、楽だが無駄な仕事

山を作る３つのコツ

・まだ誰もやっていない

・他業種や他国の成功例のエッセンスを取り入れる

・ギャップに目を付ける

トライアンドエラーを繰り返し、一定の答えが見えたところで、もう一度過剰品質の美学を取り入れる

第２章　「ハンマーと釘」の世界の落とし穴

「If all you have is a hammer, everything looks like a nail.」

（ハンマーしか持っていないと、すべてが釘に見える。）

「ハンマーと釘」の罠を防ぐには

・その技術が課題解決にどう役に立つのか

• 「新技術だからとりあえず使ってみたい」という場合は黄色信号。

・他のやり方では実現できないことか

• 「選択肢となりうる他の技術」を即答できない場合も黄色信号。今回採用する技術が望ましい理由は明確にしておくこと。

・その技術を使ったことはあるのか

• その技術の手応えを確認しておくこと。

DCAPで動くべき3つの領域

・未経験、未知の領域

・既知だが不確実性の大きい領域

・途中で要件が変化していく領域

「これから来そうだという技術は習得しておき、使うべき時が来るまでは無理して

使わないように」

• 技術と課題解決が一致してこそシステムに価値が生まれる

第３章　「ラストマン戦略」で頭角をあらわせ

グールプ内で一番になれそうな領域を決め、スペシャリストを目指すこと

ラストマン戦略のメリット

・最初の目標が低いので実現できそうな期待が持てる

・低い目標でさえ実現できない場合は方針転換できる

・目標が段階的に高くなっていくため、自信をつけながらストレスが少ない形で成長できる

・新人であっても周囲の人から頼られ、自らも「このテーマは自分がラストマン」なのだと誇りを持って仕事に取り組める

ワンオブゼム

突出した特性や技能を持つ人同士が互いに補い合いながら強いチームを作っていく時代

自分がすべきこと

・組織内で「満点」を目指すことをやめる

・マニュアルにとらわれず、むしろマニュアルがないことにこそ取り組む

エンジニア風林火山

風のエンジニア

迅速な設計・実装によってチームを加速させる。風のエンジニアがいない開発チームでは、他に先駆けて新製品やサービスをリリースすることが困難になる。

林のエンジニア

突発的なトラブルが発生しても冷静に対処し、チームに「乱れぬペース」を提供する。林のエンジニアがいない開発チームでは、トラブル発生時に的確な判断を行えず、混乱に陥りやすい。

火のエンジニア

新しい技術・方法・ツールの積極的な導入によって、チームやその成果物の競争力を高める。火のエンジニアがいない開発チームでは、イノベーションが起こりにくい。

山のエンジニア

厳密なエラーチェックと堅牢なプログラミングによって成果物の安定性を高める。山のエンジニアがいない開発チームでは、常に品質の低さに起因する不安にさいなまれる。

風と火の要素は１人のエンジニアの中に共存しやすく、林と山の要素も同様である。

風または火のエンジニアに足りないものを、林または山のエンジニアは補ってくれることが多い。

第４章　「ToStopリスト」をいますぐ作る

「一番近く」と「一番遠く」だけをみる

今後自分が取り組むべきことが見えてくる「仕事」と「私生活」でそれぞれ書き出してみる

第５章　職場は「猛獣園」である

人を傷つけずに、問題点を指摘するーーー「ひよコード」

・優しく言う

・自分が過去に同じミスをした話から入る

・相手に敬意を払う

「俺がやったほうが早い病」の治し方

・俺がほめたほうが早い

・俺が教えたほうが早い

・俺が見本を見せたほうが早い

採用に効く２つのアプローチ

・会社や部署、プロジェクトのメッセージを明確にする

・カッコつけないで、ありのままに会話する

まとめ

具体的なエピソードが多くて、読みやすくなっているために、最初から最後まであっと言う間に読み切ることができました。

中でもエンジニア風林火山のタイプ分けは、自分も含めて社内のエンジニアに適用しても、きれいに分けることができるな！と、感動しました。（自分は火と風のエンジニアの様です。）

この本から得られたヒントを参考に、必要なお仕事に注力して生産性を高めていきたいと思います。