"なぜ、システム開発は必ずモメるのか?"を読んで

なぜ、システム開発は必ずモメるのか？

この本を読むまでの経緯はいろいろあったのだが、簡単にいうと勧められたので読んだ本。開発プロセスの工程別にシステム開発でモメた裁判事例を紹介しつつ、どういったことをマネジメントし、プロジェクトを遂行していくのかをストーリー形式で読める本だった。一読して、後輩にあげてしまった。ちなみに裁判をするまで、こじれたプロジェクトは過去一度も経験したことはないのだが、仕事を請け負うにあたり、システム開発でモメてしまったら、プロジェクトマネジメントとしての「義務」があることをきちんと認識しておきたい。ここ、とても重要。（そもそもモメるべきではないが）。この本だけでなくネットではシステム開発のトラブルで裁判事例が出ているので、結構目を通すようにしているつもり。

"人月の神話"を読んで

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

20年以上前に書かれた本。読むのに苦労した記憶がある（字が小さい、なんだか全体的に分かりづらい）。「人月」はIT業界において、見積りとスケジュールの単位として用いられているのだが、現在も往々にして「人」と「月」は交換可能な単位として見做されている。結論から言うと遅延しているプロジェクトへ人を追加して、遅れを取り戻そうとしたところで、人を追加すれば解決するという考え方は非常に危険であり、実はスケジュールを遅延させる要因になりうるというもの（ブルックスの法則）。また、この前提で組んだスケジュールは大体失敗するので、基本的には、人を追加してリカバリするのではなく（人を追加したところで、多少のオーバーヘッドができることを考慮する）、リスケジュールするか、開発規模を見直すべきであるとも言及していたと思う。センスがいい人はこの辺理解しているものの、プロジェクトオーナーや、システム部門と連携するビジネス部門のユーザーにとっては理解できない（想像できない）世界なので説明を求められた際には、きちんと応えられるようこういった説明を準備すべきなのかなと思う。

"ソフトウェアテストの教科書”を読んで

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

社会人２年目の頃読んだ。あの頃は常に炎上案件、本番障害対応と凄惨たる状況だった。また当時は残念なことにテストドキュメントや、品質評価もチームとしては機能していなかったと思う。これには別の要因が多々あるのだが…今はそのような状況から立ち直り、基本的な手順・ルールが機能しているので当たり前を当たり前にこなすことができるので安心している。本の内容としては下記の３つのPartで記載されているのだが、アカデミックな内容でもあり教科書と言うだけあって座学で学んでいる感じの印象であった。
Part1.ソフトウェアテストの基礎
Part2.さまざまなテスト技法
Part3.テストドキュメントとモニタリング

"ずっと受けたかったソフトウェアエンジニアリングの新人研修"を読んで

ずっと受けたかったソフトウェアエンジニアリングの新人研修

入社前か、入社したての頃に勧められて読んだ本。今パラパラと読み返すと、ウォーターフォール型の開発プロセスなどを工程別にこんなことやるんだよぉ〜と紹介していて、本当にド新人だったあの頃の僕にはピッタリだったと思う。

"子どもが体験するべき50の危険なこと”を読んで

子どもが体験するべき50の危険なこと (Make: Japan Books)

姪と一緒にこの本の内容で遊びたいなと思って買ったが、姪は安全志向で危険を好まない慎重な性格だったので結局実践していない。対象年齢は小学生向けだと思うので夏休みの自由研究に是非。あと今は、姪ではなく自分の子供とやろうと思う。

"Arduinoをはじめよう"を読んで

Arduinoをはじめよう (Make:PROJECTS)

何か動くものを作ってみたくてArduinoのベーシックな入門キットを購入して、この本で勉強した。結局、LEDがチカチカつく程度のプログラミングしかしなかった。

"外資系コンサルの資料作成術"を読んで

外資系コンサルの資料作成術---短時間で強烈な説得力を生み出すフレームワーク

フレームワークにそって資料作成する実践的な内容の本だった。たまにコンサルの人が作った資料に目を通して、あぁよくもまぁこんな綺麗にまとめるなと感心することがある。PMOという立場で仕事していた時期に、現場の情報をかき集めて短時間で資料作成していたのでその時は有効だった。