モチベーションについての考察
よく、「モチベーションが上がらない」というメンバーの話を聞きますが、正直どうでもいいと思う事が多々ある。
ピープルウェアなんかを読むと、エンジニアのモチベーションを上げる為に最大限配慮するような事が書かれているが、
あれはお国柄的な話で、エンジニア＝超優秀なエンジニアだと思う。
新卒2,3年目のまだ社会人として怪しいメンバーのモチベーションを考慮すると、マネジメントコストがかかり組織としてやらなければいけない戦略が滞る。
結果としてモチベーションの上がらない仕事が増えてしまう。
マネジメントがやるのはメンバーのモチベーションを上げる事ではなく、戦略を立案する事と、その実行である。
とするのであれば、戦略を実行するに辺りモチベーションが上がらない人がいる事は害悪になるので、戦略に納得してもらう必要はある。
また、モチベーションが上がらない理由の中に、戦略不備や組織不備がある可能性もあるのでそのヒアリングは細かくしておく方が良い。
個人的な見解としては、毎日牛丼を食べても、その都度食べ方を変える事によってモチベーションは担保できると思っているので、
モチベーションが上がらない人は仕事に工夫のない人だと思っている。
卵の入れるタイミング、紅しょうがの量、肉とごはんの配分、醤油の量など工夫はいくらでもできるのだ
工場生産方式ではエンジニア組織は上手くいかない
個に執着すると、それぞれがタスク化され一見分かり易くなります。
ただ、昨今のwebシステムでは顧客のニーズや要望は絶えず変化するものなので、不確実性だけが高まってしまい、コミットメントが難しくなります。
各々がタスク化した作業を業務レベルで理解し、顧客のニーズをくみ取りながら連携して作業に当たらなければ、プロジェクトは失敗します。
エイミー・C・エドモンドソン
「チームが機能するとはどういうことか」
にもありますが、チームは”動詞である”と。
この中で、チームを学習する組織にする為にプロセス分解して説明してくれています。
- チームワークの必要性を認識する
- 個人と個人がコミュニケーションを図る
- 手順や相手に任せるべきことを調整する
- 相互依存の行動をとる
- 省察/フィードバックをする
これらプロセスを通して、チームは正しい”チームワーク”が身に付きます。
PMはまず、チームではなく、個に焦点を当てしっかりとしたコミュニケーションを取り期待値調整しながら
チーム作りをする事が、チームビルディングの最初の行動になります。
チームが機能するって？
各々が役割を全うする事？とにかく急ぎ作業を前倒す事？
皆で一生懸命やり遂げる事？
微妙に的が外れてますね。。。
チームが機能するというのは、『成果に対して各自が最善を尽くす事』を目的とした行動がチーム全体で行われている事だと思います。
エンジニア側から見れば、自分の作業を効率化する為に、周りの雑音をシャットアウトしただ黙々と作業し続ける事が生産的であり、目的達成に最善だと思われるかもしれませんが、
チームであるという事はそれだけではありません。
時には、自分の作業を後ろ回しにしても、他人に教えたり、プルリクを見たりする事で全体の効率が良くなる事が必要になります。
例えば、牛丼を作る過程で、2人で作るとします。
１）Aさんはご飯を並盛、大盛、並盛で作り、Bさんへ渡す。
２）Aさんはご飯を並盛、並盛、大盛で作り、Bさんへ渡す。
１と２でどちらの方がBさんは牛丼を盛りやすいでしょうか？
当然２の方ですよね。同じ処理をさせた後に別の処理をした方が牛丼という生産において圧倒的に楽です。
※ただし、Bさんが超プロフェッショナルであれば、どちらにしても問題ないです。
その場合は、Aさんのスペック次第で考慮すべきで、１のパターンで作った方が早い可能性もあります。
プロジェクトマネジメントのスコープ
責任範囲は多岐に渡る
- スコープ
- 時間
- コスト
- 品質
- 人的資源
- コミュニケーション
- リスク
- 調達
- 総合管理
プロジェクトが成功した後、あなたはどんな気持ちになるだろう？
「厳しかったけれど，どうにか乗り越えられたよ」
「一時はどうなるかと思った」
こんな言葉が聞かれると思う。何事も無い平穏無事なプロジェクトなどPMが不要なのだから、PMがいる時点で難敵であることは間違いない
では、プロジェクトが失敗した時にはどんな気持ちになるだろう？
「最初から無理なプロジェクトを営業がとってきた」
「到底不可能な納期設定だった」
成功も失敗も、定性的に見た場合それ程、違いが無い。逆に失敗した場合は常に言い訳がましくなる。
どちらも厳しく過酷な条件の中、一方は成功し一方は失敗となる。
そこにはどのような違いがあるだろうか。
これは上記記載の責任範囲の中で、PMがどれだけ自分事として動けたか、リスクを未然に防げたかで決まる。
どんなプロジェクトであろうとも、PMの動き一つで成功と失敗が分かれるのだ。
これは、牛丼屋の店長と同じ動きである。
プロジェクトマネジメントの3つの特徴
プロジェクトマネジメントには3つの特徴がある。
- 明確な目的が存在すること
- 繰り返しではない1回限りの活動であること
- 時間・コスト・経営資源の制約があること
明確な目的が存在すること
現実にはプロジェクトに関わっている関係者が目的を十分に理解してない事が多々ある。
プロジェクトの目的と成果を混同したり、目的があいまいなままプロジェクトの成果物を作り出す事に専念してしまうと、
成果物が無駄になる事がある
繰り返しではない1回限りの活動であること
プロジェクトは1回限りの活動であるから、始めと終りが存在する。
つまりプロジェクトは開始と終了時期を明確に規定できる。
プロジェクトの曖昧さはコストに繋がってしまう。
時間・コスト・経営資源の制約があること
プロジェクトを遂行するにあたって、さまざまな制約の中でいかにバランスを取りながら目的を達成するかが重要になる。
全てが自由なプロジェクトは生産性において成功するとは言えない。
牛丼一つ作るにしても、お客様の満足の為の目標であっても、そこには時間・コスト・資源の制約がありお客様毎の唯一の活動であると言える。
280円の牛丼を食べるのに10分待てる人はほとんどいないのと同じことだ。
