深沢隆司『SEの教科書 成功するSEの考え方、仕事の進め方』

SE の教科書 ~成功するSEの考え方、仕事の進め方 (技評SE新書001)

bossに薦められて読んだ本。

プロジェクトマネジャーは、「コミュニケーションに90％以上もの時間を費やす」とされている職種です。(p.24)

沁みます。いろんな道具使ったりして、もっともっとやれることはあるよなー。素人にちょっと毛の生えたくらいの僕が、楽をしようなんて10年早いってことですよ、きっと。もっともっと励まなきゃいかん。
以下、メモ。

p.24
「
プロジェクトマネジャーは、「コミュニケーションに90％以上もの時間を費やす」とされている職種です。
」

p.28
「
要するに、「開発がうまくいくために行なわなければならないことで、その人が行なえばよいことはすべてSEの仕事である」というわけです。この考え方に基づいて仕事をしてきたことによって、これまで担当してきた開発プロジェクトが成功したと思っています。
」
※SEとプロマネはもちろん、読み替え可能。

p.38-39
「
このようなコミュニケーションを軽視した姿勢を誘発する要因には、「知らない、理解していないと言えない」気持ちや、「知らない、理解していないことをバカにする、あるいは怒る」気持ち、さらには「わかるまで説明するのを面倒くさがる」気持ちがあります。
したがって、コミュニケーションの改善策は、本来、基本的にシンプルです。発信者と受信者が、相互に理解したことを確認できるまで、「確認する」「説明する」「議論する」ということです。そしてそのために、発信者・受信者どちらの立場にあっても、SEという立場において、「目標達成に必要な情報で、自分や相手のそれぞれ知らないことと、知っていることを常に明確に区別しながら話をすること」ができなければなりません。そしてそれを、「明るく、そして滑舌よく」行なえる必要があります。
」
↓
p.40
■コミュニケーションを成功させる条件

• 話す内容の理解はどれだけ必要か？
• 予行練習は？
• そもそも、苦労して話して、何をどうしたいのか？
• 声の出し方は大丈夫なのか？
• 誰かに聞いてもらったほうがよいのではないか？
• 他の人はどうしているのか？
• 「仕様説明がうまい」と思える人はどこが違うのか？
• マイナス要因を切り出すときに、どんな話し方をしているか？
• 会議や議事録の記述は、これまでのやり方でよいといえるのか？

↓
p.41
■これらの疑問について考えてみよう

• 話す内容については、できる限り詳細に、顧客よりも詳しく知っておいたほうがよい
• 予行演習は、可能であればシチュエーションを揃えて行なうのがベスト。全体として論理が通っているか、おかしな言い回しはないか等、最低一回は通して音読するほうがよい
• 実現したいことが明確になっていて、論理がそこへ向かっているかを確認する
• 声が小さいかどうかは、実際に誰かに聞いてもらわないと安心できないから、誰かに頼んで聞いてもらう
• 他の人がどうしているかを見学しに行くか、過去の記憶からさまざまな疑問点に対する一応の見解を導き出す

p.63-64
「
プロジェクトマネジャーがプロジェクトを通して作る物は、少なくとも2つあるということです。「成果物」と「プロジェクトそのもの」です。要するに、「プロジェクト」が成功といえるためには、プロジェクトの「（最終）成果物」が出来上がりさえすればそれでよいかというと、それだけではないということです。「プロジェクトそのもの」も、うまく出来上がっていなければなりません。
つまり、「（最終）成果物」だけに気を持っていかれて、残業や徹夜続きでチームメンバーの体を壊してしまったり、士気を落とさせてしまって、次のプロジェクトのときにはプロジェクトメンバーがIT業界から身を引いてしまっていたというのでは、プロジェクトマネジャーとして成功とはほどとおいということです。
」
↓

• 業務システム開発では、「システムを作る労働力」を提供するのではなく、「作ったシステムが稼動した結果、発生するサービス」を提供する
• プロジェクトマネジャーの本当の納品物は、「成功したプロジェクト」
• SEの本当の納品物は、「顧客が承認していて、実装担当者が理解して実装できる、仕様変更のないシステム設計」
• プログラマーの本当の納品物は、「設計どおりに実装された、バグのないプログラム」

p.71
「
SEやプロジェクトマネジャーは、自分の配下のチームメンバーに対してはどう考えればよいのでしょうか。
基本的には、自分の配下のSEや実装担当者は高いモチベーションを持っていると信じて行動すればよいと思います。（略）本来持っているモチベーションを「落とさないように」気をつけるということです。
」

p.73
マグレガーのX理論・Y理論：
すべての人は2つのタイプに帰属している
http://koukouseiventure.blog34.fc2.com/blog-entry-3.html

X理論
元来人は怠け者で、作業を行なう能力もなく、常に監視する必要がある

Y理論
元来人は監視されていなくても積極的に働こうとし、自ら何かを達成しようとする

↓
「
たいていの人がY側ですから、まずはY側の人々が間違った作業を高いモチベーションと高い生産性で行なってしまわないようにだけ注意して、日頃のコミュニケーションを「丁寧」に行ないます。そうすればあとは、優先的にX側の人々にどうやってY側になってもらうかに注意していけばよいわけですし、そのための時間も、Y側の人々のおかげで得られていることになります。たまに、X側だと思っていた人が、とてつもないパワーを発揮することがあります。
」

p.78
従来型の会議の失敗パターン

• 「言った・言わない」論争→議事録の解釈の違い
• 「気に入らない」→相互不信感
• 憶測中心の会議→その場しのぎの憶測で進める会議。憶測を軸に考えたことは、すべて憶測。
• 発言形式の議事録→会議の成果物は「参加者合意の上での決定事項」「誤解のない表現をする必要」を認識する必要あり
• 問題指摘型の会議進行

↓
コミュニケーション重視型の会議術

• 情報の開示（データやPCなどですぐに見られるように）
• リハーサル
• プロジェクタとモニタ（議事録を共有しながら作っていく）
• 記録機材（ICレコーダー、デジカメ）

p.195
「
直接開発作業をするのではない人の視点のまま、いい加減に業務分析や要求定義等、業務システム開発の上流工程を進めてしまうことが、さまざまな問題を引き起こします。上流工程を担当する人々は、自分がプログラミングをするわけではありませんから、後の工程を行うプログラマーへの情報伝達もいい加減だったりします。
プロジェクト計画も、往々にしてプロジェクトの最終成果物やそれを作り上げる実際の作業を、おおよそでしかイメージしていないものです。書籍等に書いてあるものの受け売りだったりして、見た目は立派です。だからこそ、後から参加した要員には、それまでの経緯等の情報がないこともあって、反論のしようもありません。
」
↓
その結果、想定外のバグが発生し、想定外の仕事が発生し、スケジュールが遅延していく。
↓
マネジメントがうまく機能していないことが原因
↓
「
難しいプロジェクトをいかに無理のない形で実現できるようにするか、徹底的に努力を重ね、常にプロジェクトが成功するような環境を識別し、それを実現する自分の行動を管理するという、マネジメントの機能を果たすことを心がけるようにしましょう。自分自身を含め、実際に作る人々が「うまくいっている」という実感の中で計画を具体化できるようにするのが目標です。スケジュール遅延もコスト超過もなく、繰り返しプロジェクトを成功できるようにするのです。
」