今まで
学習した
目次
- 改めてPDCAを
学習する ことの 背景、 意義 - 2.1. 背景
- 2.1.1. 個人的な
見解(偏見) - 2.1.2. いつまでも
成長できない 人と 企業の 関係 - 2.1.3. 仕事が
できる 人が 教えるのが 上手いとは 限らない
- 2.1.1. 個人的な
- 2.2. 意義
- 2.2.1. 仮説
- 2.2.2. 成長できない
人が 成長できるようになる
- 改めてPDCAを
- PDCAイメージ図の
各要素の 深掘り - 5.1. WILL、
MUST、 CANフレームワーク - 5.1.1. WILLの
深掘り - 5.1.2. WILLの
質問の 前に - 5.1.3. CANの
深掘り - 5.1.4. MUSTの
深掘り
- 5.1.1. WILLの
- 5.2. Vision & Question
- 5.2.1.
WHY
、WHERE
を明確に する。 - 5.2.2. 2つの
WHERE
とは?
- 5.2.1.
- 5.3. PDCA
サイクル - 5.3.1. Plan
- 5.3.2. よく
ある ダメな Planの 立て 方 - 5.3.3. Do
- 5.3.4. Check と
Action - 5.3.5. KPT Keep/Problem/Try
- PDCAイメージ図の
- タイプ別の
PDCA - 6.1. なぜ
2つの タイプの 違うPDCAを 実施するのか ? - 6.2. 業務品質向上型PDCA
- 6.3. 学び
型PDCA
- タイプ別の
1. 前提
この文書の
ITエンジニア組織の
チームリーダ、 先輩社員が チームメンバに 行うPDCAを イメージしている。 PDCAは
1対1で 実施するとして、 登場人物を 以下のように 記載する。 - PDCAを
実施する 本人
メンティー - PDCAの
結果に アドバイスする 人
メンター
- PDCAを
誰に読んでもらいたいのか
PDCAのメンター 読んでもらいたい。
2. 改めてPDCAを 学習する ことの 背景、 意義
改めてPDCAを
2.1. 背景
2.1.1. 個人的な 見解(偏見)
職場には
仕事が
できる 人できない 人 - 企業には
仕事が できる 人が いる。 何故できるのかは 言語化されていない 部分が 多い。 - 企業には
仕事が できない 人が いる。 何故できないのかは 言語化されていない 部分が 多い。
- 企業には
成長できる
人できない 人 - 最初は
皆、 仕事が できないが、 成長してできるようになる。 - 最初は
皆、 仕事が できないが、 成長できない 人もいる。
- 最初は
2.1.2. いつまでも 成長できない 人と 企業の 関係
外資だと、
仕事が
解雇を
2.1.3. 仕事が できる 人が 教えるのが 上手いとは 限らない
学習の
に
- 仕事が
できる 人は レベル4 無意識的有能(考えなくてもできる )以上に いる。 企業だと 部下が いる 可能性が 高い。 - レベル4で
部下が いる 人は 教える ことが 苦手。
レベル4なら
以下、
個人的な
経験
新人のOJTを 担当した。
新人研修の質問を 受けたが、 新人の 求める 回答を 返すことができなかった。 求める
回答とは ?
質問者が回答の 内容を 理解でき、 実践できる 回答。
新人研修の回答は 回答内容は あっているが、 質問者が 理解、 実践できる 内容ではなかった。
2.2. 意義
PDCAを
2.2.1. 仮説
以下のように
1. 成長できる
2. 成長できる
3. 成長できない
2.2.2. 成長できない 人が 成長できるようになる
本人も
3. 参考資料
3.1. 直接的な 参考資料
一生食える
プロの PDCA | 清水久三子 | ビジネス・経済 | Kindleストア | Amazon
PDCAの基本的な 考え方は この 書籍を 参考に しました。 mentr/README.md at master · kawasima/mentr
ITエンジニアのWILL、 MUST、 CANフレームワークの 利用方法に ついて 参考に しました。
3.2. 間接的な 参考資料
直接PDCAには
エンジニアの
知的生産術 ―効率的に 学び、 整理し、 アウトプットする WEB+DB PRESS plus | 西尾 泰和 | コンピュータ・IT | Kindleストア | Amazon
エンジニアの学習の 仕方が 参考に なりました。 学ぶことの PDCAを 回している 気が します。 エンジニアリング組織論への
招待 ~不確実性に 向き合う 思考と 組織の リファクタリング | 広木 大地 | コンピュータ・IT | Kindleストア | Amazon
メンタリングの章が 参考に なりました。
4. PDCAイメージ図
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イメージ図の 各要素の 深掘り
各要素に
5.1. WILL、 MUST、 CANフレームワーク
誰が最初に
PDFの
・自覚された
才能と 能力= can
・自覚された動機と 欲求= will
・自覚された態度と 価値= must
5.1.1. WILLの 深掘り
専門職ではなく、
以下のような
- 前提
- 仕事から
離れたWILLの 深掘りはしない。 - 仕事に
関する ことでやりたいことを 確認する。
- 仕事から
WILLを
- 質問
- 仕事で
使う もの、 使わない もので 身に つけたい 技術は ありますか? - 社内でも
社外でも、 お手本と する 人は いますか? - 周囲、
自分自身で 変えたいことは ありますか?
- 仕事で
上記の
5.1.2. WILLの 質問の 前に
WILLの
業務上必要な
知識領域が ない。
キャッチアップフェーズにいます。
先輩社員、上司から 教えてもらい、 効率良く その 分野の 知識を 身に 付ける 必要が あります。 先輩社員、
上司と 同じ 領域で 知識が ついてきた。
開拓フェーズにいます。
先輩社員、上司とは 違う 分野の 知識を 学んで、 独自の キャリアを 作っていく 時期だと 思います。 参考
5.1.3. CANの 深掘り
CANの
知らないCANは
知っている
CAN - メンティーが
できると 思っていて、 できている こと - メンティーが
できると 思っていて、 できていないこと - メンティーが
できていないと 思っていて、 できている こと - メンティーできていないと
思っていて、 できていないこと
- メンティーが
知らないCAN
- メンティーが
認知していない、 できている こと - メンティーが
認知していない、 できていないこと - 他者が
認知していない、 できている こと - 他者が
認知していない、 できていないこと
- メンティーが
参考
5.1.4. MUSTの 深掘り
MUSTは
メンティーに
未経験の
- 未経験の
タスクの 分野に 興味を 持つ 可能性が ある。 - 未経験の
タスクの 気づきが、 経験した タスクの パフォーマンスに 良い 影響を 与える 可能性が ある。
5.2. Vision & Question
Vision & Question の
5.2.1. WHY
、WHERE
を 明確に する。
Plan を
WHY
なぜやるのか? WHERE
何を目指すのか ?
5.2.2. 2つのWHERE
とは?
WHERE
にはWHERE
が
まだいったことがない
目的地
WHERE 自体が仮説。 現状の
先に 見える 目的地
WHERE はわかりきっているので、 WHAT の 仮説が より 重要に なる。
ITの
アプリケーション開発、
5.3. PDCAサイクル
一生食える
5.3.1. Plan
計画を
具体化するには ?
タイムマシン法を 使う。
2年後が最終ゴールであれば、 その 半分である 1年後、 さらに 半分である 6月後、 その 半分である 3月後、と前に 半分ずつ チャンクダウンして 目標を 立てる。 タイムマシン法で
どこまで チャンクダウンするか?
1月後までの状態を 決める。 KPIを 設定して、 1週間から 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の
劣後順位を
決める ための 4つの 視点 - やめる
やめることには勇気が 必要 - 頻度を
減らす - 人に任せる
- 自動化する
エンジニアは自動化が 得意領域なので、 ここで 力を 発揮できる。
- やめる
行動を
記録する
PDCAノートを作る。できるだけ 行動を 細分化する。 記録大事。 集中してやり
切る。
完璧でなくても、 終わらせる。
5.3.4. Check と Action
Check実施時の
ポイント なぜ成功したのか、
何が 良い 結果に 結びついたのか、 何が よくない 結果に なったのかを 振り返る。 責任追及ばかりしていては
ダメ。 反省
ではなく内省
。
自分と向き合い、 自分の 行動を 振り 返って 気づきを 得て、 どうすればいいのか
と未来に 結びつける。 確証バイアス
仮説を検証する 際に それを 支持する 情報ばかり 集めてしまう。 振り返りは
学び その もの
PDCA > PDSA
悪いところばかりあげるのではなく、 学んだことを あげてみる。 Harvesting (収穫) する。
メンバ全員で得られた ことを 話し合い、 他の 人が 使える 形で 文書化、 データベースに 登録する。
振り
返りの 初心者が つまづきがちなことの 対処法 (個人の 場合) 性格改善位なってしまうと
自己否定に つながり 辛くなってしまう。
目に見えて 実行できる 行動を 変える。 自分の
今の 実力を 超えたActionを 考えてしまう
原因となる行動や 要因を 特定して 解決する。
自分の今の 実力に ついて 認識した 上で、 振り返りで 改善の Actionを 考える。 見積もりの
甘さのせいに してしまう。
見積もり自体が 仮説なので、 外れる ことは 珍しくない。
見積もりの精度を 上げる Actionは Planを 精密化したり、 バッフォを 積むしかなくなり、 スピードを 落とすことになってしまう。
見積もりは、外れる ことを 前提と して、 行動を 細分化して Ploblem、 Actionを 特定する。 毎回同じPloblemが
出てくる
行動、要因を 分解仕切れていないと、 結局課題を 特定できないまま、 Problemと してまた 現れてしまう。
振り
返りの 初心者が つまづきがちなことの 対処法 (チームの 場合) 他の
人の 意見や 顔色を うかがってしまう。
お互いの出方の 探り合いとなり、 Keepや Problemを 本音で 議論しにくい。
事前に書き出してもらうなどして おく。 Problemが
リスクの 洗い出しになってしまう。
実際に起きていない ことは 振り返らない。
状況、結果、 行動の 3点セットで 出す ルールに する。
リスクマネジメントを振り返りと 別の タイミングで 実施すべき。 責任追及の
場に なってしまう
具体的な行動レベルで 話し合う。
進捗会議とは切り離して、 別に 行う。
耳が痛い、
個人的に
直接的な
指示系統以外の 先輩社員、 上司が メンターに なる。
直接的な指示系統に いる 先輩社員、 上司は メンティーとの 関係が こじれている 可能性が あります。
関係がこじれていると アンチパターンに 陥りやすいかなと 思います。
指示系統以外のメンターだと、 第3者的な 視点で メンティーと 対話できるのではと 思います。 叱らない。
アドバイスを する。
メンター次第ですが叱ると、 マイナス方面の 反応が 返ってくる 可能性が あります。
叱らず、あくまで アドバイスを するのが 良いと 思います。 書籍を
読むのを 薦める。
口頭で伝えると、 どうしても 感情が 入ってしまい、 頭では 分かってるけど 心が ついていかない 状態に なる 場合が あります。
書籍だと感情が 入らないので、 マイナス方面の 反応が 返ってくる 可能性が ある 領域の 指摘は、 その 領域の 知識、 概念を サポートする 書籍を 勧めても 良いかもしれません。
5.3.5. KPT Keep/Problem/Try
一生食える
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>考えるか
が
Do's and Don'ts
は
この
6. タイプ別の PDCA
一生食える
- 目標達成型売り
上げ 目標などKGIが 明確に 決まっている 場合の PDCA - 業務品質向上型PDCA
- プロジェクト型PDCA
- 学び型PDCA
- 新しい
知識や、 スキルを 習得する ための PDCA - キャリア開発型PDCA
- 身の回り
型生活の 質を 向上させる ための PDCA
個人的な業務品質向上型PDCA
と学び<wbr>型PDCA
が
6.1. なぜ 2つの タイプの 違うPDCAを 実施するのか?
業務品質向上型PDCA と、
業務品質向上型PDCA
WILL、MUST、 CAN フレームワーク の MUST に 対する PDCA。
得意な人は メンティー以外に いて、 メンティーが キャッチアップしてほしい 技術、 タスクに 対して 設定する。
PDCAが上手く いくと、 MUST、 CANの 重なりが 増える。
キャッチアップフェーズのPDCA。 学び
型PDCA
WILL、MUST、 CAN フレームワーク の WILL に 対する PDCA。
メンティー自身が興味が ある 技術、 学びたい 知識に 対して 設定する。
PDCAが上手く いくと、 WILL、 CANの 重なりが 増える。
重なりが増えた 部分は 今後の MUST設定時に 勘案する。
開拓フェーズのPDCA。
若手の
ベテランエンジニアでできる
6.2. 業務品質向上型PDCA
定常業務の
- KGIと
して 設定される 指標 - ミスを
ゼロに する。 - 時間を
半分に 短縮する。 - 手戻り
ゼロ。
- ミスを
ITエンジニアと
- ITエンジニアと
しての 指標 - 予算内に
リリースコストを 抑える。 - リリース後の
不具合発生率。 - 各工程での
不具合率。 - Pull Request数。
- 予算内に
Plan設定の
ために 実施する こと - 仕事を
IPO Input/Process/Output
の3つに 分解、 改善ポイントを 見つける。 IPO の
ボトルネックを 見つける。 - インプットボトルネック
- プロセスボトルネック
- アウトプットボトルネック
ボトルネックを
解消する。 - 3つの
ボトルネックを 解消する ための 行動を 具体化する。 - 劣後順位、
優先順位を 決める - 予実の
比較 - 予定と、
実績を 比較する。
- 予定と、
- 3つの
- 仕事を
IPO Input/Process/Output
の
個人的に、
PDCAの
Plan設定時の 注意点 メンティー側の
レベルに よっては ボトルネックの 分析が できない 場合が ある。
改善施策が出ない ケースも あるので、 ボトルネックの 分析、 改善施策の 検討を サポートする。 Planが
定量化できないと、 改善できない。
例えば、Planが レビュー指摘事項を 減らす だと 減らない。 具体的な 行動、 指標が 定量的な Planを 設定する。
6.3. 学び 型PDCA
技術の
書籍を
重要だと
思った ポイント Planの
段階で アウトプットの 機会も 計画して おく。 自分で
検証の 機会を 作る - ブログで
学んだことを 投稿 - 勉強会を
企画する - 社内、
部内研修の 講師と して 他者に 教える - 学んだ
ことを 実践する 機会を 設ける。 - 見識者、
専門家に あって 習得レベルを 確認する
- ブログで
重要だと
思った ポイント ASAPモデル
- Acquire 覚える
- Structure 構造化する
- Attempt 試行する
- Perform 達成する
参考
「能力のピーク」が 40代以降に 来る人の 思考法 | 30代から 身に つけたい キャリア力実戦講座 | 東洋経済オンライン | 経済ニュースの 新基準
基本的に
企業で
企業で
実施する 場合の 留意事項 毎朝
15分の 勉強会で 若手の 行動が 驚く ほど 改善した 話 - Qiita
企業で実施するとしたら 勉強会を 計画、 実施、 そこに PDCAを 置く。 勉強会アンチパターンへの
対処例(随時更新) - Qiita
勉強会だと、自発的に 実施する イメージ。
前へ出ない タイプの メンティーの 場合は、 調査報告会
という 形式での 仕事に する。
7. まとめ
PDCAを
以下、
気づいたこと
改めて、PDCAの 学びな おしを して、 個人的に 以下の 気づきを 得ました。 - ITテクノロジ以外も
学ぶべきことは ある。 ITテクノロジ以外の 技術重要。 成長の<wbr>仕方が<wbr>わからない<wbr>人
が、なぜわからないのかが わかると 幸せに なれそう。 - メンティーの
WILLの 前に、 メンターである 自分の WILLを 固めたい。 - ITカンファレンスとか
勉強会は、 QCサークルと 少し似ていると 思えてきた。
- ITテクノロジ以外も
今後
実際にこれで やってみて、 改善点を 修正していきたいと 思います。
8. 参考
以下、
以上です。
コメント