ドラッカーに学ぶ、MBOとは（連載第6回/25回）

# 前回の記事
https://qiita.com/rf_p/items/8ac5df53da5bc53b5ca2

# 連載の構成
- この記事は、[マネジメントについて一人で考える Advent Calendar 2022](https://qiita.com/advent-calendar/2022/management-solo)の連載記事です
    - 1記事目から読んでいただいても良いですし、気になる記事から読んでいただいても問題ありません
- 全25回分の構成は、次の通りです
    - 第1〜6回：ドラッカーの『マネジメント』を中心に解説します
    - 第7〜13回：『図解人材マネジメント入門』を中心に解説します
    - 第14〜22回：『エンジニアのためのマネジメントキャリアパス』を中心に解説します
    - 第23〜25回：私の経験談を中心に、まとめに入ります

# MBOとは何か
- 目標による管理です
- 組織によって異なるでしょうが、
    - 上司と部下で面談し、目標設定をする
    - 3ヶ月や半年といった決められた期間で、達成を目指す
- といった仕組みが取られていることが多いのではないでしょうか

# MBOは何の略か
- "MBOとは？"でググると、以下2つがヒットしやすいです
    - Management By Objectives
    - Management By Objectives and self-control
- 元の定義としては後者の**Management By Objectives and self-control**です

# self-controlの重要性
- この省かれがちのself-controlが、実はすごく重要な概念であることは、いくつかの書籍で語られています

> また、最初に目標管理が提唱された当時は、MBOだけではなかった。正確には、Management by Objectives and Self-Controlだった。つまり、「目標を一つの道具として使いながら、マネジメントを効果的に進めよう。そうすることで、最終的にはセルフコントロール（今の言葉ではセルフマネジメント）を実現しよう」ということなのである。
> この本の前段で強調した、セルフマネジメント型の人材をつくっていこうというのは、実は最近の考え方ではなく、数十年も前から言われていたことなのである。ところが、いつの間にか、その一番大切な目的である後半部分がなくなり、MBOだけとなってしまったために、ノルマ管理的な制度へと変身してしまったのである。  
> 引用：[会社を変える社員はどこにいるか―ビジネスを生み出す人材を育てる方法](https://www.amazon.co.jp/dp/4478440468)

>  **目標管理（MBO）の最大のポイントはSelf-control**   
> 目標管理（MBO＝Management By Objectives and Self-control）とは、P.F.ドラッカーによって提唱されたマネジメント哲学です。目標を手がかりにすることで自らの仕事ぶりをマネジメントすることを言います。一人ひとりが責任を持って目標を立て、目標に照らして自らの成果を評価できなければなりません。Self-control（自己管理）による強い動機づけが最大のメリットなのです。  
> 引用：[図解 人材マネジメント入門 人事の基礎をゼロからおさえておきたい人のための「理論と実践」100のツボ](https://www.amazon.co.jp/dp/4799326120)

# 陥りがちな罠
- では、self-controlが抜け落ちることで何が問題なのでしょうか？
- 引用した2冊の書籍でも語られているように、セルフマネジメントの動機づけができなくなるのは問題です
- ここが抜け落ちていることで、"上司から言われたノルマを粛々とこなす"だけになってしまいます
    - それではモチベーションも上がりづらいです
    - 上司の指示が無いと動けない人材になり、独り立ちや後継者に成長することは難しくなります

# ITエンジニアにおけるMBO
- ITエンジニアにおいて、MBOで特に気をつけるべき観点は何でしょうか？
- 私が思いつくところを2つ挙げてみます
    - 弱点を無くす方向に偏りがち
    - 期限曖昧にしがち

# 弱点を無くす方向に偏りがち
- フロントエンド・バックエンド・インフラの3分割をした際、どれが弱みか？に目が行きがちです
- 一時期、『フルスタックエンジニア志望』と聞く機会が多かったです
    - フルスタックエンジニアを否定するわけではないですし、すごいITエンジニアは確かに、全領域高いレベルを維持していることも多いと感じます
    - ですが組織に所属するITエンジニア、特に大規模チームの場合は、フルスタックよりも専門領域に特化したケースで活躍できる機会も多いです
- Web業界の技術は流行り廃りが激しいです
    - 特にフロントエンドに追従するためには、プライベートの時間でもかなりの学習が必要です
    - それが全領域となると、追いきるのは至難の業です
    - 初学者の頃はある程度広い領域の知識が必要でしょうが、一人前になってからも常に全領域追い続けていると、強みを作れず苦労するのではないでしょうか

# 期限曖昧にしがち
- MBOは、3ヶ月/半年/1年の期間で目標を設定し、評価をする運用が多いのではないでしょうか
- ですが"いつの時点をもって評価するのか？"曖昧なことがあります
    - 例えば長期のシステムリプレイスプロジェクトは、いつ時点でどう評価するか？
    - 保守運用がメインで、いつ時点のどんな成果をもって評価するのか？
- このあたりが曖昧だと、評価が主観に寄りやすくなります
    - 主観に寄りやすいと、評価者である上司と本人の間で、認識のズレが起きやすく、不満に繋がります
- 評価期間最後のタイミングで、何を持ってできた/できていないと評価するか？を、あらかじめ定量化できると良いでしょう

# SMARTの法則
- 良い目標として、SMARTの法則があります

> **S**pecific：「具体的、分かりやすい」を意味する  
> **M**easurable：「計測可能、数字になっている」を意味する  
> **A**chievable：「同意して、達成可能な」を意味する  
> **R**elevant：「関連性」を意味する  
> **T**ime-bound：「期限が明確、今日やる」を意味する  
> 引用：[SMARTの法則とは？ 目標設定の重要性、目標の立て方、具体例について](https://www.kaonavi.jp/dictionary/smart-criteria/)

- これは業界職種問わず、共通して使える概念です
- また、頭文字を取ってSMARTですが、単語は割と諸説あります
    - 個人的には **Attractive(ワクワクするか？)** が好きです
        - ワクワクしない目標はだいたい"義務感"から来るもので、モチベーションも上がりづらいためです

# Will Can Must
- リクルート発祥の、Will Can Mustも有名ですね

> Will⇒やりたいこと  
> Can⇒できること  
> Must⇒やるべきこと  
> 引用：[Will Can Mustとは？【リクルート発祥】シート、具体例](https://www.kaonavi.jp/dictionary/will-can-must/)

- この3つが重なる点を目標として置くと、機能しやすいです
- 逆にバランスを崩している場合、
    - Will強すぎる
        - 会社組織の貢献に繋がらず、評価されづらい
    - Can強すぎる
        - 難易度が低すぎたり、貢献に繋がりづらい
    - Must強すぎる
        - やらされ目標で、モチベーションが上がらない
    - といった弊害が生まれやすいです
- 組織にとって貢献に繋がり、自分が少し背伸びしたら達成できそうで、やりたい/目指したいと思える目標が良いです

# 最後に
- MBOにおけるSelf-controlの重要性はご理解いただけたでしょうか
- また、目標設定のコツも解説しました
- ドラッカーに関する連載は以上で、次回からの連載は人材マネジメントに移ります

# 次の記事
https://qiita.com/rf_p/items/48b924ba42303f9efbef

- 連載記事一覧
    - [マネジメントについて一人で考える Advent Calendar 2022](https://qiita.com/advent-calendar/2022/management-solo)