会社のお偉いさんから「これ読んで感想聞かせて」とのお達しがあったので読んだ。
概要
元エンジニアの著者が、自らの経験をもとにエンジニアとしての心得を説いた指南書。
エンジニアを志す学生やエンジニアとして就職した新入社員に対する入門書と位置付けられている。
難解な専門用語はあまり登場しないため、他分野に携わる人が「エンジニア」という職業を知る上でも適した一冊と言える。
私見
出版されたのが2004年ということもあり、少々時代錯誤に感じる部分もある。
だが概ねは、現代でもエンジニアの基本として教えられるであろう事柄がまとまっている。
(5Sとか。)
基本的にはエンジニア初心者に向けた内容だが、ベテランエンジニア、特に管理職の人も読むべき内容がある。
その最たる部分が「プロジェクトのマネージメント」に関する内容だ。
著者はプロジェクトチームのメンバーの選出方法について、
・各階層から広く的確に集める
・社外からも集める
・得手不得手や興味の強さを考慮する
といった条件を挙げているが、果たしてこれを忠実に遂行できている企業がどれほどいるだろう？
自分が所属している会社でもプロジェクト・チームというのは存在するが、基本的には開発プロジェクトの場合は対象製品に特化した人材で構成される。
(もっと言うと課がそのままプロジェクトチームになってしまう。)
ゆえに集められる人材は普段から仕事をともにするメンバーとさほど変わらないし、個々の得手不得手や興味の強さなどはそもそも考慮されない。
また
通常プロジェクト・マネージャーが独断で進めることはありません。プロジェクト・メンバーはお互いに対等です。
加藤ただし「エンジニアのための開発生活ガイド」
ともあるが、プロジェクト・マネージャーが課長となってしまっている現状では、建前はあっても本音では対等になれないのが実情だ。
基本的には現代でも教えられるエンジニアの心得がまとめっているが、以下の点などいくつか素直に首肯できない部分も存在する。
・(読者に推薦してはいないが)業務用書類の整理や業務の段取り決めなどを業務時間外に実施する。
⇒業務は業務時間内で完結させるべき。
・章を割いてまで睡眠の重要性を説いておきながら、睡眠不足に陥りながら顧客要求を満たした話を美談にする。
⇒例に出すのは良いが「本来ならあるべき姿ではありませんが」と一言添えるべき。
・優れた技術でも、顧客が魅力を感じないなら無価値と切り捨てる。
⇒あからさまに酷いものでなければ、顧客に提供できる形に変換できるか否か検討する、もしくはその技術を軸にした新事業を考えるくらいはやるべきでは？
またこれは著者と直接は関係ないかもしれないが、いくつか挿絵の表現に受け入れがたいものがある。
特に子猫をダンボールに入れて捨てていく挿絵、虫を食べる挿絵は、例えの表現としてもセンスが無い。
新装版を出すなら挿絵全体を変えるべき。
終わり
どの分野でもそうだが、基本や常識はある種の「伝統」として様々な方向から何度も言い聞かせれられる。
だが、何でもかんでも「昔からそうしてきた」と「伝統」を盲目的に押し付けるのは間違っている。
常識と言うのは時代に応じて変化するものであり、それは現代でも変わらない。
経営者が口を揃えて言う「時代の波に乗れ」を社員に求めるなら、まずはコミュニケーション方法を「飲みにケーション」から脱却するべき。
自分の身の振りも変えられない人間に、人はついていかない。
(あまり本書に関係ない話になってしまったがいいか…)
END
コメント