マクレランドの欲求理論

動機づけ理論からもう一つ、「マクレランドの欲求理論」を紹介します。
これは、作業者が欲する欲求（動機）には、以下の3つがあるという理論です。

・達成欲求…作業を効率よく達成したい、問題を解決したい、複雑なタスクをやり遂げたい
・親和欲求…暖かで友好的な対人関係を確立、維持したい
・権威欲求…自分でコントロールしたい、他人から尊敬されたい

各作業者に、このような欲求があると理解し、この欲求を満たすような作業を当てはめることが、人的資源マネジメントでの活用方法となります。

具体的には…
・達成欲求
　→適度な難易度の作業を与える。
　　結果に対してフィードバックを行い、進め方をさらに工夫してもらい、さらに高い難易度の作業を実施させる。
　　本人のスキルが向上していることを実感させることが重要。
・親和欲求
　→協同で仕事をする環境を与える。
　　チーム内でサポートを行うポジションで、たくさんの作業をこなしてもらう。
　　役に立っている、と実感させることが重要。
　　自らリーダになることはあまり望んでいない？
・権威欲求
　→人を管理して、チームとして結果を出す機会を与える。
　　目標を達成するための手段を考えさせ、結果を出してもらう。
　　ゴールまでの道のりを考えさせ、計画させることが重要。これにより出した結果が、本人の欲求を満たすこととなる。

いずれについても、「この人はこれだから、これを任せておけばOK！」と当てはまるとは限りません。
その人の成長段階により、複数の要因が混ざっている場合も多いです。
これもやはり、決めつけではなく本人としっかり話をした上で、どのような作業を振ればよいか、適切な計画を立てていく必要があります。

マズローの欲求5段階説

自チームのメンバーに、どんな作業を任せるべきか？どんな教育を与えるべきか？
に悩むこともあるかと思います。
特効薬ではありませんが、方針を立てるための知識として、
動機づけ理論のひとつ、「マズローの欲求5段階説」を紹介します。

○マズローの欲求5段階説
　個人が叶えたいと思う欲求は、大きく以下の5段階に大別されます。
　
　　5：自己実現の欲求　…自己を成長させたい。実現させたい。
　　4：尊重の欲求　　　…他者から認められたい。
　　3：社会的欲求　　　…他者との関係。集団への帰属。
　　2：安全の欲求　　　…生命や収入の危険から身を守りたい。
　　1：生理学的欲求　　…生存に必要な、衣食住が欲しい。
　
　数字の大きいものが上位の欲求で、下位の欲求が満たされると、上位の欲求を満たそうとする、というのがマズローの欲求5段階説です。

これを、システム開発チームに当てはめてみると…
「1：生理学的欲求」「2：安全の欲求」については、会社務めをしている場合、既に満たされている場合が多いと思います。
（例外も思いつきますが、、ここでは記載しないことにします。。）

まず、「3：社会的欲求」ですが、これは主に新入社員や、新しくチームに加わった人が該当すると思います。
この段階では、まずはチームの一員として働くことができるようになること、戦力になりたい、ということを考えていることが多いと思われます。
ですので、一人で基本的な作業が行えるような教育や、比較的簡単な作業を振るべきです。
時には手取り足取りで、しっかりついていてあげることも必要です。実はそれ自体が、集団への帰属を満たす方法でもあります。しっかりケアしてあげましょう。

次に、「4：尊重の欲求」です。この段階に来る頃は、作業を一通り覚え、一人である程度できるようになっています。
そうなると湧いてくるのが、もっとスキルを向上させたい、能力があると認められたい、という欲求になります。
この段階では、徐々に難易度の高い作業を与えていくことが重要です。本人のスキルを高めるとともに、難しいことをやり遂げたことで、あいつはこんなことができるようになった、と認めさせる材料になります。
ただし、まだまだ成長途中です。やり遂げるためのアドバイスをしっかり行いましょう。

最後に、「5：自己実現の欲求」です。この段階では、能力が十分につき、周囲からもそれを認められています。
そうなると、いつまでも言われたことをこなすのではなく、自分の考えた方法で進めたい、実現させたい、という欲求ができてきます。
この段階に来たら、思い切って作業を任せてみることです。明確なゴールのみを与え、そこまでの道のりを考え、進めてもらうようにします。
ただし、投げっぱなしではいけません。要所で確認を行い、ゴールへの道筋が正しいかを見ていきます。
…が、過度に手出しをしてはダメです。どこがいけないかを考え、修正してもらうようにします。
こういった経験を積むことで、判断力や応用力を養い、リーダーとして独り立ちしていく、という流れになります。

以上のように、欲求が順次変わっていくことを理解し、対象者がいまどのフェーズにいるのかを見極めた上で、適切な教育や作業を与える必要があります。
対象者のフェーズの見極めはとても難しいです。フェーズの間にいる人もいるでしょう。一番確実なのは、本人に聞き取りを行うことです。どんなことをやりたいか、どんな時に楽しいと感じるか、を聞き取り、育成に役立てていきましょう。

リストを用いた作業の合意

「作業を振るとき、振られるとき」にて、「作業目的を理解し、指示漏れがないか、再確認することも重要です」ということを説明しましたが、
ただ、「他に無いでしょうか？」と聞いても、十分な回答が得られない場合もあります。
双方の認識のずれをなるべく少なくするには、口頭だけではなく、目に見える形にして確認すると、有効な回答を引き出しやすくなります。回答を引き出した上で、これでOKですね？と作業範囲の合意を行います。
ここで、合意のために使用できる、効果的なツールを1つご紹介いたします。

★リスト
（ツールと言えるものかわからないですが…）
ご存じの通り、項目を箇条書きなどにして、一覧にまとめたものです。
まず自分で、必要な作業を考えてみます。今までの経験から判断したり、機械的に検索をかけるのも良いです。
ここで得られた作業を、一覧化します。紙でも表計算ソフトでもOK。

　修正対象
　・○○通知書
　・××通知書
　・△△納付書

一覧化したら、作業を出した人にそれを見せます。必要と判断した根拠も合わせて説明。
一覧化してあれば、これが足りない、これは不要、ということが判断しやすくなります。
結果、「△△納付書」は修正不要、「□□調査票」を追加してくれ、という回答をもらいました。

　修正対象
　・○○通知書
　・××通知書
　・□□調査票

修正後、この内容で進めます、という合意をとります。
これで、双方の認識のずれが無くなったことになります。
やっと本格的に作業開始となります。

作業中も、作成したリストは活躍します。
作業しながら、終わったものを消していけば、

　修正対象
　・○○通知書
　・××通知書
　・□□調査票

作業のやり漏れを防ぐことができます。
せっかく合意したのに、やり忘れました、じゃカッコ悪いですしね。

このようにして、作業を一覧化して、目に見えるようにすることは大変重要です。
日々の作業に活用してみてください。

※なお…作業を漏れなく定義し、一覧化する、という意味では、WBSもリストの一種と言えますね。目的としてはほぼ同じです。

WBSは何のため？

システム開発のプロジェクトに携わっていると、
「WBS（Work Breakdown Structure）」という言葉が時々出てきます。
これって、いったい何のために作るんでしょうか？

「作業がたくさん書いてあるやつ…わかったスケジュールのためだ！」
という間違いをしやすいです。
的外れというわけではないですが、作成する意図は別にあります。

WBSは、作業スコープを定義するために作成します。
システムを開発するために必要な作業や成果物をすべて洗い出し、ツリー構造にまとめるのです。

その手順としては、まず、システムに必要な機能を、「A機能」「B機能」などとして洗い出します。
「A機能」を作成するためには、「基本設計」「詳細設計」「プログラミング」「単体テスト」などの作業が必要です。
さらに、「基本設計」には「画面レイアウト仕様書」「帳票レイアウト仕様書」といった成果物が含まれます。
このように上位から下位に分解（ブレークダウン）していったときの、最下位レベルの構成要素を、「ワークパッケージ」と呼びます。
※どこをワークパッケージとするかは難しいですが、「実施する基本単位（≒フェーズ）」や「成果物の種類」などととらえるといいようです。

作成したWBSをもとに、ワークパッケージ「画面レイアウト仕様書」をやるべき作業に分解すると、
「A画面作成」「B画面作成」というように分解できます。
ワークパッケージを作成するための全作業一覧を、「アクティビティリスト」と呼び、
作業のことを「アクティビティ」と呼びます。

厳密にWBSというと、ワークパッケージまでのことを言うのですが、
実務では、アクティビティまでブレークダウンして、WBSとして作成することも多いです。
このフェーズでは、作業の漏れが無いように、やるべき作業を定義することが最重要です。

WBSまたはアクティビティリストを作成したあと、
各作業に対してどれくらいの時間がかかるのかを見積もり、
やるべき作業と作業時間を紐づけたものが「スケジュール」となるのです。
開発メンバから見ると、作業をさらに人ごとに割り当てたものが、よく見る「スケジュール」になります。
（これは、「プロジェクト・タイム・マネジメント」の内容となります。）

関連はあるが目的が違う、「WBS」と「スケジュール」。
その目的を理解しましょう。

スケジュール短縮技法

いつまでに完成させる、システムを稼働させる、
スケジュールが最優先となるプロジェクトは多いかと思います。
計画したスケジュールに対し、遅れが発生した場合、PMは対応策をとらなくてはいけません。
PMBOKでは、対応策として「クラッシング」「ファストトラッキング」の2つが紹介されています。
いずれも、見たことあるものと思いますが、メリット・デメリットがあるので、ここに着目してみてください。
現在の状況から、どれが最善策なのかを判断し、対策を打つこととなります。

○クラッシング
要員の追加を行い、作業を行ってもらう方法です。
プロジェクト内で空いている人を当てるのでえあればよいが、外部から調達する場合は、コスト増となります。
作業を分担してできる場合に効果があります。例えば、打ち合わせが遅れているのに、要員を追加しても、遅れは回復できません。
テストやプログラム製造など、手分けして作業ができる場合のみ、効果があります。
追加要員の作業環境（テスト端末など）にも注意する必要があります。人は来たけど端末がない、では意味がありません。

要員の追加の際は、一時的に生産性が落ちることを考慮することが必要です。
追加された人が作業に慣れるまでは時間がかかるし、質問とかで既存の作業者の生産性が落ちることもあります。
1人分の作業を実施できるようになるため、「立ち上げ工数」が必要であることを認識しましょう。
これを見越して、実際の遅れ日数より、多めに投入する必要があります。10人日の遅れであれば、12人日とか、少し多めに投入しないと、遅れを取り返すことができません。

○ファスト・トラッキング
順番に行う予定であった作業を、先行して着手することです。
作業の入れ替えだけであるため、コスト増はありませんが、不確定な状態で先に進んでしまうため、手戻りによるコスト増や、品質低下などのリスクが発生します。
元々、意味があって順番で行う予定になっていたはずです。設計が全部終わってから、製造を開始するなど。これを崩すということは、やはりリスクを抱えることになるのです。
コスト増がありませんので、クラッシングより、こちらを適用することを、先に検討すべきです。

具体的に…
Aフェーズ完了後、Bフェーズに入る予定であった場合
Aフェーズの残り2機能が、ユーザ打ち合わせの遅れにより終わらない。およそ10%分の時間。
→その10%分の時間で、Bフェーズを進めておく。
→リスクは、ユーザの打ち合わせにより、進めたBフェーズの内容に変更が発生する可能性があること。
　これを軽減するため、なるべく変更の可能性の低いものを厳選し、着手する必要がある。

自分の作業を行う場合も、
リーダに確認しないとこれ以上進まない、という場合に、
その日はもう何もしないのではなく、次の作業を先読みし、先行着手しておくと、無駄がなくてよいです。

以上が、2つの対応策の内容です。
メリット、デメリットを理解し、適切な策を適用できるようにしましょう。