futoase

よろしくお願いします。

アート・オブ・プロジェクトマネジメントを読んだ

アート・オブ・プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

を読んだ。

プロダクトの計画から、終わり、政治までが書いてある

2006年に邦訳の初版が出ている。少し古い本だが(2006年は10年前...!)、
内容は今読んでも、今抱えている計画の立て方、チームの進捗のありかた、
メンタルの持ち方(チームとして)、個人のエゴは持ち出さないなど、
普通に今でも利用できることが書いてあった。

仕様書の記述に焦点が結構当たっている

印象を感じた。
仕様書については初期設計時に書いておくことで、
初期仕様からかけ離れていてもゴールは決めている(形)し、
ドキュメントにあげているのでどこでどういう変更が行われたか、
またどういう軌道修正が必要なのか、ということが切々と書いてあった。

今勤めている会社ではDesignDocというコーディングを行う前に
初期仕様、目的、ゴールについていろいろな人を巻き込んで(エンジニア以外も)
書く文化になっているが、まさにそれだった。

また、検死という物騒な表現になっているが振り返りも大事だよと書かれていた。

情報の共有についても重点が置かれている

印象を受ける。というかいくら採用してるアーキテクチャが素晴らしく立って、
言葉を受け取り、解釈し、仕様を解釈したりマーケティングにどう出すかとか
わかってないとだめだ。ただの日本語・英語のやり取りだけだと相手が認識したかわからなかったりする。
その点についても細かく書かれていた。

コードが仕様という表現が個人的にあまり思わしくない。
コードが起こされた背景なんて書いた当人と関わった数人しか知らないし、
人間の記憶なんてすぐに改ざんされてしまうし。

いろいろと考えさせられた。

政治について最後の章で沢山書かれてた

やんちゃばっかりしても誰も見向きしてくれなくなったら終わりだよ、という
簡単に言うとそんなことが書かれていた。

どんなに技術的に優れていてもサイコパスだったらダメだよね、という。

部長とかリーダーとか、いろいろあるけど
ロールによって扱う責任が大きければその分大変なんだよってことが最後の章に書かれていた。

短めの感想ではあるが

30代になって、昔体験してたけど改めて言うべきではないいろいろな話がある。
今まで経験してきた、絶対に二度としたくないこと、他の人に経験させたくないこと、
それについてどうすればいいのか、について復習できた。

この本はおすすめだ。(たとえ20代だとしても)。

Copyright (c) 2013-2017 Keiji Matsuzaki