今までなんとなくPDCA実施してきたのですが、そういえば良く知らないと思い、改めて書籍を元に学習しました。
学習した結果を踏まえて、自分なりに1対1でPDCAを実施するフロー設計についてまとめたので、まとめた結果を記載します。

目次

1. 前提

この文書の前提となる情報を記載します。

  • ITエンジニア組織のチームリーダ、先輩社員がチームメンバに行うPDCAをイメージしている。

  • PDCAは1対1で実施するとして、登場人物を以下のように記載する。

    • PDCAを実施する本人
      メンティー
    • PDCAの結果にアドバイスする人
      メンター

  • 誰に読んでもらいたいのか
    PDCAのメンター読んでもらいたい。

2. 改めてPDCAを学習することの背景、意義

改めてPDCAを学習する背景、意義について記載します。

2.1. 背景

2.1.1. 個人的な見解(偏見)

職場には仕事のできる人、できない人がいて、仕事のできない人は成長できる人、できない人に分かれるのではないかと思います。

  • 仕事ができる人できない人

    • 企業には仕事ができる人がいる。何故できるのかは言語化されていない部分が多い。
    • 企業には仕事ができない人がいる。何故できないのかは言語化されていない部分が多い。

  • 成長できる人できない人

    • 最初は皆、仕事ができないが、成長してできるようになる。
    • 最初は皆、仕事ができないが、成長できない人もいる。

2.1.2. いつまでも成長できない人と企業の関係

外資だと、解雇という選択肢があるのかもしれませんが、日本の企業は解雇という選択をすることは少ないように思います。
仕事ができず、いつまでも成長できない人と企業の関係は、どちらも不幸です。
解雇をしない日本企業でも、この状態をできるだけ無くすことができると良いと思います。

2.1.3. 仕事ができる人が教えるのが上手いとは限らない

学習の５段階レベル - NLP学び方ガイド（NLPとは）｜資格セミナー総合情報サイト｜協会 公式
に学習の５段階レベルの記載があります。このイメージから以下のように考えました。

  • 仕事ができる人はレベル４ 無意識的有能（考えなくてもできる）以上にいる。企業だと部下がいる可能性が高い。
  • レベル４で部下がいる人は教えることが苦手。

レベル４ならレベル５に努力して上がれば良いと思います。
以下、個人的な話ですが自分はレベル４にいるなという経験をしました。

  • 個人的な経験
    新人のOJTを担当した。
    新人研修の質問を受けたが、新人の求める回答を返すことができなかった。

  • 求める回答とは？
    質問者が回答の内容を理解でき、実践できる回答。
    新人研修の回答は回答内容はあっているが、質問者が理解、実践できる内容ではなかった。

2.2. 意義

PDCAを学び、実施する意義についての仮説です。

2.2.1. 仮説

以下のように考えました。
1. 成長できる人はPDCAを意識的に、うまく実施できていて、成長できない人はPDCAをうまく実施できていない。
2. 成長できる人はなんらかののきっかけでPDCAにあたる技術を身に付けた。
3. 成長できない人がPDCAの実施方法を学んで実施すると、成長できるのではないか？

2.2.2. 成長できない人が成長できるようになる

本人も企業も幸せになるので、成長できない人がPDCAの学ぶことは意義があると思いました。

3. 参考資料

3.1. 直接的な参考資料

3.2. 間接的な参考資料

直接PDCAには関係しませんが、以下も参考にしました。

4. PDCAイメージ図

PDCA.png - Google ドライブ

4.1. 図の説明、基本的な考え方

  • 一生食えるプロのPDCA を読んでイメージした図、基本的に書籍のPDCAの流れを踏襲している。

  • WILL、MUST、CANフレームワーク が Vision & Question のベースの考えを固める。

  • Vision & Question が PDCA の INPUT になる。

  • PDCA の CA は、KPT フレームワークで実施する。

  • IT エンジニアは業務品質改善型 PDCA と、学び型PDCAを同時進行で実行する。

  • 業務品質改善型 PDCA の ACTION は、WILL、MUST、CANフレームワーク の MUSTとCANのINPUTになる。

  • 学び型 PDCA の ACTION は WILL、MUST、CANフレームワーク の WILLとCANのINPUTになる。

5. PDCAイメージ図の各要素の深掘り

各要素について、1段階詳細化していきます。

5.1. WILL、MUST、CANフレームワーク

誰が最初に言い出したのかは実はよくわかっていないらしいです。

PDFの内容を引用しますが、WILL、MUST、CANは以下のように説明されています。

・自覚された才能と能力＝ can
・自覚された動機と欲求＝ will
・自覚された態度と価値＝ must

5.1.1. WILLの深掘り

専門職ではなく、正しく深掘りするのは難しいと思いました。
以下のような前提を引くのが良いと思います。

  • 前提
    • 仕事から離れたWILLの深掘りはしない。
    • 仕事に関することでやりたいことを確認する。

WILLを確認するために、以下３つの質問をします。

  • 質問
    • 仕事で使うもの、使わないもので身につけたい技術はありますか？
    • 社内でも社外でも、お手本とする人はいますか？
    • 周囲、自分自身で変えたいことはありますか？

上記の質問に対して更になぜかを聞いて理由も確認しておきます。

5.1.2. WILLの質問の前に

WILLの質問の前に、メンティーがどのような状態なのかを考えた方が良いかと思います。

5.1.3. CANの深掘り

CANの深掘り。以下を明らかにするのが良いと思います。
知らないCANはメンティー、メンターが明らかにした段階で、知っているCANになります。

  • 知っているCAN

    • メンティーができると思っていて、できていること
    • メンティーができると思っていて、できていないこと
    • メンティーができていないと思っていて、できていること
    • メンティーできていないと思っていて、できていないこと

  • 知らないCAN

    • メンティーが認知していない、できていること
    • メンティーが認知していない、できていないこと
    • 他者が認知していない、できていること
    • 他者が認知していない、できていないこと

  • 参考

5.1.4. MUSTの深掘り

MUSTはタスクに関連します。WILL、CAN を 参考 に MUST を設定します。
メンティーによっては、WILLが出てこない場合もあります。
その場合は、タスクの難易度もありますが、基本的に末経験のタスクを与えるのが良いと思います。
未経験のタスクを与えるのは以下の理由からです。

  • 未経験のタスクの分野に興味を持つ可能性がある。
  • 未経験のタスクの気づきが、経験したタスクのパフォーマンスに良い影響を与える可能性がある。

5.2. Vision & Question

Vision & Question の内容は、ほぼ、一生食えるプロのPDCA の引用です。

5.2.1. WHY、WHERE を明確にする。

Plan を 決める前に、なぜそのタスクを実行するのか、タスクのゴールは何かを明確にする必要があります。

  • WHY
    なぜやるのか？

  • WHERE
    何を目指すのか？

5.2.2. 2つのWHEREとは？

WHERE には 2つの WHERE があります。

  • まだいったことがない目的地
    WHERE 自体が仮説。

  • 現状の先に見える目的地
    WHERE はわかりきっているので、WHAT の仮説がより重要になる。

ITのプロジェクトは、研究開発、スタートアップ企業などではない場合、
アプリケーション開発、運用保守などWHEREがわかりきっている場合が多いと思います。

5.3. PDCAサイクル

一生食えるプロのPDCA の内容で重要だと思ったことを抜粋して紹介します。

5.3.1. Plan

  • 計画を具体化するには？
    タイムマシン法を使う。
    2年後が最終ゴールであれば、その半分である1年後、さらに半分である6月後、その半分である3月後、と前に半分ずつチャンクダウンして目標を立てる。

  • タイムマシン法でどこまでチャンクダウンするか？
    1月後までの状態を決める。KPIを設定して、１週間から1日単位の行動に落とし込んでいく。

  • KPIを決める

    • Key Goal Indicator KGI
      売上や利益など最終的な目標数値。結果目標。日々の行動で直接コントロールしにくい。

    • Key Performance Indicator KPI
      KGI達成のための重要な活動を測定した数値。先行指標。日々の活動によって個々人が調節コントロールできる。

  • 数値化しづらいKPIでも仮説で考える
    最初から明確に品質定義できない仕事もある。
    まず、KPIは仮置きする。
    KPIを見極めることで Do が実装しやすく、かつ行動できたのか、行動できてないのかが明確になる。

5.3.2. よくあるダメなPlanの立て方

耳が痛いアンチパターンに思いました。

  • KGI だけでPlanを立ててしまう。

  • 緻密なスケジュールを立ててしまう。
    仮説検証を素早く回しながら成功に近づいていくためには向いていない。

  • 計画を立てる人と実行者が異なっている。
    PDCAのPlanはあくまでも実行者のもの。

5.3.3. Do

劣後順位をメンティーに意識してもらうことが非常に重要に思いました。

  • まず、やらないことを決める

    • PDCAのサイクルを回す時間の捻出のためにやらないことを決める。
    • 劣後順位を決めて時間を生み出す。

  • 劣後順位を決めるための４つの視点

    • やめる
      やめることには勇気が必要
    • 頻度を減らす
    • 人に任せる
    • 自動化する
      エンジニアは自動化が得意領域なので、ここで力を発揮できる。

  • 行動を記録する
    PDCAノートを作る。できるだけ行動を細分化する。記録大事。

  • 集中してやり切る。
    完璧でなくても、終わらせる。

5.3.4. Check と Action

  • Check実施時のポイント

    • なぜ成功したのか、何が良い結果に結びついたのか、何がよくない結果になったのかを振り返る。

    • 責任追及ばかりしていてはダメ。

    • 反省ではなく内省。
      自分と向き合い、自分の行動を振り返って気づきを得て、どうすればいいのか と未来に結びつける。

    • 確証バイアス
      仮説を検証する際にそれを支持する情報ばかり集めてしまう。

    • 振り返りは学びそのもの
      PDCA > PDSA
      悪いところばかりあげるのではなく、学んだことをあげてみる。

    • Harvesting (収穫) する。
      メンバ全員で得られたことを話し合い、他の人が使える形で文書化、データベースに登録する。

  • 振り返りの初心者がつまづきがちなことの対処法 (個人の場合)

    • 性格改善位なってしまうと自己否定につながり辛くなってしまう。
      目に見えて実行できる行動を変える。

    • 自分の今の実力を超えたActionを考えてしまう
      原因となる行動や要因を特定して解決する。
      自分の今の実力について認識した上で、振り返りで改善のActionを考える。

    • 見積もりの甘さのせいにしてしまう。
      見積もり自体が仮説なので、外れることは珍しくない。
      見積もりの精度を上げるActionはPlanを精密化したり、バッフォを積むしかなくなり、スピードを落とすことになってしまう。
      見積もりは、外れることを前提として、行動を細分化してPloblem、Actionを特定する。

    • 毎回同じPloblemが出てくる
      行動、要因を分解仕切れていないと、結局課題を特定できないまま、Problemとしてまた現れてしまう。

  • 振り返りの初心者がつまづきがちなことの対処法 (チームの場合)

    • 他の人の意見や顔色をうかがってしまう。
      お互いの出方の探り合いとなり、KeepやProblemを本音で議論しにくい。
      事前に書き出してもらうなどしておく。

    • Problemがリスクの洗い出しになってしまう。
      実際に起きていないことは振り返らない。
      状況、結果、行動の３点セットで出すルールにする。
      リスクマネジメントを振り返りと別のタイミングで実施すべき。

    • 責任追及の場になってしまう
      具体的な行動レベルで話し合う。
      進捗会議とは切り離して、別に行う。

耳が痛い、アンチパターン集に思いました。
個人的に考えるPDCAのメンターのルールとして以下があります。

  • 直接的な指示系統以外の先輩社員、上司がメンターになる。
    直接的な指示系統にいる先輩社員、上司はメンティーとの関係がこじれている可能性があります。
    関係がこじれているとアンチパターンに陥りやすいかなと思います。
    指示系統以外のメンターだと、第３者的な視点でメンティーと対話できるのではと思います。

  • 叱らない。アドバイスをする。
    メンター次第ですが叱ると、マイナス方面の反応が返ってくる可能性があります。
    叱らず、あくまでアドバイスをするのが良いと思います。

  • 書籍を読むのを薦める。
    口頭で伝えると、どうしても感情が入ってしまい、頭では分かってるけど心がついていかない状態になる場合があります。
    書籍だと感情が入らないので、マイナス方面の反応が返ってくる可能性がある領域の指摘は、その領域の知識、概念をサポートする書籍を勧めても良いかもしれません。

5.3.5. KPT Keep/Problem/Try

一生食えるプロのPDCA では、PDCA の Check と Action は KPTフレームワークを使うことを推奨しています。

  • KPT実施時のポイント

    • 仕事の進捗や達成状況の確認とは分けて考える。あくまでも行動を振り返る。次に何をすべきかを考える。

    • スモールKPT、ビッグKPTを実施する。
      仕事を進めながら行うスモールKPT、仕事の区切りがついたタイミングで全体の振り返りを行うビッグKPT。

    • KPTが不要な状況。上司が部下の仕事について事細かに指導できる状況の場合は、KPTは不要。

    • KPTの時間を短縮する。
      Doの時に、行動や状況、それによって得られた気づき、思い浮かんだ改善のアイデア、効率よくするためにすべきことなどを記録しておく。

    • KPT記録のためのツール
      ボイスレコーダを使って記録する。 ホワイトボードを使う。

  • KPT実施時のポイント

    • 時間がかかり過ぎるため、KPTの人数多くても、5-6人で実施する。

    • KPTのフォーマット
      状況、行動、結果を3点セットで洗い出す。Problem は、状態ではなくよくない<wbr>結果に<wbr>つながってしまった<wbr>行動に着目する。進捗のリカバリ対策は別途行う。

    • ある人にとってのKeepは、ある人にとってのProblem
      楽観的過ぎても、悲観的すぎても良い振り返りとは言えない。

  • どのようにTryを考えるか
    4つのTryのタイプがある。

    • Adjust
      4つの中では最も継続性が高い。 三現主義、現場、現物、現実を意識する。

    • Challenge
      Planを上方修正する。
      目標をあげる。期日を早める。目標を上げる。
      勇気が必要。

    • Pivot
      Adjustの検証結果がよろしくない場合は、方向転換、路線変更する。
      個人のキャリアアップであれば、転職や独立が大きなピボット

    • Do’s and Don’ts
      べし、べからず集をつくる。
      三現主義で得られたことから、原理・原則を見出す。
      知識データベースを作ると、組織としてのPDCAがより速く大きな規模で回る。
      技に名前をつけて、再現性を高める。

どのように<wbr>Tryを<wbr>考えるか がしっかり言語化されていて、なんとなく改善として実施していたことが4タイプに別れていることがわかりました。
Do's and Don'ts は チェックリスト というアウトプットが、IT企業では多い気がします。
この辺りはIT技術で自動化していきたいところです。

6. タイプ別のPDCA

一生食えるプロのPDCA には、以下の7タイプのPDCAが紹介されています。

  • 目標達成型売り上げ目標などKGIが明確に決まっている場合のPDCA
  • 業務品質向上型PDCA
  • プロジェクト型PDCA
  • 学び型PDCA
  • 新しい知識や、スキルを習得するためのPDCA
  • キャリア開発型PDCA
  • 身の回り型生活の質を向上させるためのPDCA

個人的な状況だと、業務品質向上型PDCA と 学び<wbr>型PDCA がマッチしたので、 この２つについて詳細を記載します。

6.1. なぜ２つのタイプの違うPDCAを実施するのか？

業務品質向上型PDCA と、学び型PDCA には以下の特徴があると思いました。

  • 業務品質向上型PDCA
    WILL、MUST、CAN フレームワーク の MUST に 対するPDCA。
    得意な人はメンティー以外にいて、メンティーがキャッチアップしてほしい技術、タスクに対して設定する。
    PDCAが上手くいくと、MUST、CANの重なりが増える。
    キャッチアップフェーズのPDCA。

  • 学び型PDCA
    WILL、MUST、CAN フレームワーク の WILL に 対するPDCA。
    メンティー自身が興味がある技術、学びたい知識に対して設定する。
    PDCAが上手くいくと、WILL、CANの重なりが増える。
    重なりが増えた部分は今後のMUST設定時に勘案する。
    開拓フェーズのPDCA。

若手のメンティーだと、業務品質向上型PDCA かと思います。
ベテランエンジニアでできる人は学び型のPDCAを個人で実施していそうに思いました。

6.2. 業務品質向上型PDCA

定常業務の品質を向上するためのPDCAです。

  • KGIとして設定される指標
    • ミスをゼロにする。
    • 時間を半分に短縮する。
    • 手戻りゼロ。

ITエンジニアとしての指標として以下が浮かびました。

  • ITエンジニアとしての指標
    • 予算内にリリースコストを抑える。
    • リリース後の不具合発生率。
    • 各工程での不具合率。
    • Pull Request数。

  • Plan設定のために実施すること

    • 仕事を IPO Input/Process/Output の３つに分解、改善ポイントを見つける。

    • IPO のボトルネックを見つける。

      • インプットボトルネック
      • プロセスボトルネック
      • アウトプットボトルネック

    • ボトルネックを解消する。

      • ３つのボトルネックを解消するための行動を具体化する。
      • 劣後順位、優先順位を決める
      • 予実の比較
        • 予定と、実績を比較する。

IPO Input/Process/Output のボトルネックの分析は非常に有用に思いました。
個人的に、Plan設定時の注意点として以下が浮かびました。

  • PDCAのPlan設定時の注意点

    • メンティー側のレベルによってはボトルネックの分析ができない場合がある。
      改善施策が出ないケースもあるので、ボトルネックの分析、改善施策の検討をサポートする。

    • Planが定量化できないと、改善できない。
      例えば、Planがレビュー指摘事項を減らす だと 減らない。具体的な行動、指標が定量的なPlanを設定する。

6.3. 学び型PDCA

技術の学習に対するPDCAです。基本的に個人で実施する類のPDCAだと思います。
書籍を読んで重要だと思ったポイントを記載します。

  • 重要だと思ったポイント

    • Planの段階でアウトプットの機会も計画しておく。

    • 自分で検証の機会を作る

      • ブログで学んだことを投稿
      • 勉強会を企画する
      • 社内、部内研修の講師として他者に教える
      • 学んだことを実践する機会を設ける。
      • 見識者、専門家にあって習得レベルを確認する

基本的に自主的な学習に思いますが、成長の仕方がわからないメンティーだとメンターからのサポートが必要だと思います。
企業で実施する際の留意事項として、以下が思いあたりました。

7. まとめ

PDCAを実施するフロー設計 について検討しました。
以下、まとめます。

  • 気づいたこと
    改めて、PDCAの学びなおしをして、個人的に以下の気づきを得ました。

    • ITテクノロジ以外も学ぶべきことはある。ITテクノロジ以外の技術重要。
    • 成長の<wbr>仕方が<wbr>わからない<wbr>人が、なぜわからないのかがわかると幸せになれそう。
    • メンティーのWILLの前に、メンターである自分のWILLを固めたい。
    • ITカンファレンスとか勉強会は、QCサークルと少し似ていると思えてきた。

  • 今後
    実際にこれでやってみて、改善点を修正していきたいと思います。

8. 参考

以下、その他の参考にした記事になります。

以上です。

コメント

最近の投稿