Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ITエンジニアのPDCA設計
Search
monotalk.xyz
November 20, 2019
Technology
0
91
ITエンジニアのPDCA設計
メンティーとメンターが1対1で行うPDCAのやり方についてまとめました。
monotalk.xyz
November 20, 2019
Tweet
Share
More Decks by monotalk.xyz
See All by monotalk.xyz
Githubのオープンソース貢献 のモチベーションと職業プログラミングのギャップについて
kemsakurai
0
270
エンジニア視点で見たGoogle Analytics
kemsakurai
1
230
Other Decks in Technology
See All in Technology
モダンフロントエンド 開発研修
recruitengineers
PRO
3
350
Yahoo!ニュースにおけるソフトウェア開発
lycorptech_jp
PRO
0
360
ZOZOTOWNフロントエンドにおけるディレクトリの分割戦略
zozotech
PRO
18
5.4k
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
1
310
LLM時代の検索とコンテキストエンジニアリング
shibuiwilliam
2
1.1k
現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある / Team-oriented Organization Design 20250827
mtx2s
5
1.1k
制約理論(ToC)入門
recruitengineers
PRO
3
310
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
AIエージェントの開発に必須な「コンテキスト・エンジニアリング」とは何か──プロンプト・エンジニアリングとの違いを手がかりに考える
masayamoriofficial
0
390
Go で言うところのアレは TypeScript で言うとコレ / Kyoto.なんか #7
susisu
7
1.8k
帳票Vibe Coding
terurou
0
140
実践アプリケーション設計 ②トランザクションスクリプトへの対応
recruitengineers
PRO
3
170
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.6k
Side Projects
sachag
455
43k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
820
Designing Experiences People Love
moore
142
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Thoughts on Productivity
jonyablonski
69
4.8k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Rails Girls Zürich Keynote
gr2m
95
14k
Transcript
IT エンジニアの PDCA 設計 IT エンジニアの PDCA 設計
このスライドに書くこと このスライドに書くこと なんとなく実施してきたPDCAを改めて、書籍を元に学習した。 学習した結果を踏まえて、⾃分⾃⾝なりに1対1でPDCAを実施するフローを設計したの で、まとめた結果を共有する。 共有により得たいもの
共有により得たいもの 資料に対するフィードバック PDCA設計の改善 留意点 留意点 PDCAは1対1で実施するとして、本⼈はメンティー、PDCAの結果にアドバイスする ⼈をメンターと記載する。 メンターとしての視点で記載している。 ITエンジニア組織のチームリーダ、先輩社員がチームメンバに⾏うPDCAをイメージ している。
⽬次 ⽬次 改めてPDCAを学習することの背景、意義 INPUT資料 PDCAイメージ図 PDCAイメージ図の各要素の深掘り タイプ別のPDCA まとめ
改めて PDCA を学習することの背景、意義 改めて PDCA を学習することの背景、意義 改めてPDCAを学習する背景、意義について
背景 背景 個⼈的な⾒解 ( 偏⾒ ) 個⼈的な⾒解 ( 偏⾒ ) 仕事ができる⼈できない⼈ 企業には仕事ができる⼈がいる。何故できるのかは⾔語化されていない部分が多 い。 企業には仕事ができない⼈がいる。何故できないのかは⾔語化されていない部分 が多い。 成⻑できる⼈できない⼈ 最初は皆、仕事ができないが、成⻑してできるようになる。 最初は皆、仕事ができないが、成⻑できない⼈もいる。
背景 背景 いつまでも成⻑できない⼈と企業の関係 いつまでも成⻑できない⼈と企業の関係 どちらも不幸。 この状態をできるだけ無くしたい。
仕事ができる⼈が教えるのが上⼿いとは限らない 仕事ができる⼈が教えるのが上⼿いとは限らない 仕事ができる⼈はレベル4 無意識的有能(考えなくてもできる)。 レベル5にならなくても仕事はできる。 学習の5段階レベル - NLP学び⽅ガイド(NLPとは)|資格セミナー総合情報サイト| 協会 公式
背景 背景 レベル5が難しいと感じる理由 レベル5が難しいと感じる理由 個⼈的な経験 新⼈のOJTを担当した。
新⼈研修の質問を受けたが、新⼈の求める回答を返すことができなかった。 求める回答とは? 質問者が回答の内容を理解でき、実践できる回答。 新⼈研修の回答は回答内容はあっているが、質問者が理解、実践できる内容ではなか った。
意義 意義 仮説 仮説 成⻑できる⼈はPDCAを意識的に、うまく実施できていて、成⻑できない⼈はPDCAを うまく実施できていない。
成⻑できる⼈はなんらかののきっかけでPDCAにあたる技術を⾝に付けた。 成⻑できない⼈がPDCAの実施⽅法を学んで実施すると、成⻑できるのではないか? 成⻑できない⼈が成⻑できるようになる 成⻑できない⼈が成⻑できるようになる 本⼈も企業も幸せ。 成⻑できない⼈がPDCAの学ぶことは意義がある。
INPUT 資料 INPUT 資料 直接的な INPUT
直接的な INPUT PDCAの基本的な考え⽅は以下の書籍をINPUTにした。 間接的な INPUT 間接的な INPUT 直接PDCAには関係しないが、以下もINPUTにした。 ⼀⽣⾷えるプロのPDCA | 清⽔久三⼦ | ビジネス・経済 | Kindleストア | Amazon エンジニアの知的⽣産術 ―効率的に学び、整理し、アウトプットする WEB+DB PRESS plus | ⻄尾 泰和 | コンピュータ・IT | Kindleストア | Amazon エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリン グ | 広⽊ ⼤地 | コンピュータ・IT | Kindleストア | Amazon
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になる。
PDCA イメージ図の各要素の深掘り PDCA イメージ図の各要素の深掘り 各要素について、1段階詳細化する。 WILL
、 MUST 、 CAN フレームワーク WILL 、 MUST 、 CAN フレームワーク 誰が最初に⾔い出したのかは実はよくわかっていないらしい。 参考 キャリアプランニングの視点 “Will, Can, Must”は何を根拠にしたものか ・⾃覚された才能と能⼒= can ・⾃覚された動機と欲求= will ・⾃覚された態度と価値= must
WILL の深掘り WILL の深掘り 専⾨職ではなく、正しく深掘りするのは難しい。 仕事から離れたWILLの深掘りはしない。 仕事に関することでやりたいことを確認する。 質問
仕事で使うもの、使わないもので⾝につけたい技術はありますか? 社内でも社外でも、お⼿本とする⼈はいますか? 周囲、⾃分⾃⾝で変えたいことはありますか? 参考 mentr/README.md at master · kawasima/mentr
WILL の質問の前に WILL の質問の前に メンティーの知識がどの状態なのかを考える。 ⾃分の知識領域がない、狭い。 先輩社員、上司から教えてもらい、効率良くその分野の知識を⾝に付ける。 先輩社員、上司と同じ領域で知識がついてきた。
先輩社員、上司とは違う分野の知識を学んで⾝に付ける。 参考 知識交換の必要条件 - ⻄尾泰和のScrapbox ⾃分経営戦略 - ⻄尾泰和のScrapbox
CAN の深掘り CAN の深掘り CANの深掘り。以下を明らかにするのが良いと思う。 知っているCAN メンティーができると思っていて、できていること メンティーができると思っていて、できていないこと
メンティーができていないと思っていて、できていること メンティーできていないと思っていて、できていないこと
知らないCAN メンティーが認知していない、できていること メンティーが認知していない、できていないこと 他者が認知していない、できていること 他者が認知していない、できていないこと 参考 ジョハリの窓 - Wikipedia mentr/README.md
at master · kawasima/mentr
MUST の深掘り MUST の深掘り MUSTは直近のタスクに関連する。WILL、CAN をINPUTにMUSTを設定できると良 い。 WILLがない場合もある。
難易度もあるが、基本的に経験したことがあるタスク、経験したことがないタスクであ れば、経験したことがないタスクを担当させるのが良いと思う。 参考 エンジニアとマネージャーは、いつも勝負をしているのだと思う
VISION & QUESTION VISION & QUESTION
、 、 を明確にする。 を明確にする。 WHY なぜやるのか? WHERE 何を⽬指すのか?
2 つの 2 つの まだいったことがない⽬的地 WHERE⾃体が仮説。 現状の先に⾒える⽬的地 WHEREはわかりきっているので、WHATの仮説がより重要になる。
ITプロジェクトは、研究開発、スタートアップなどではない場合、 アプリケーション開発、運⽤保守などWHEREがわかりきっていることが多い。
PDCA サイクル PDCA サイクル の 内容で重要だと思ったことを抜粋して紹介する。
PLAN PLAN 計画を具体化するには? タイムマシン法を使う。 2年後が最終ゴールであれば、その半分である1年後、さらに半分である6⽉後、その 半分である3⽉後、と前に半分ずつチャンクダウンして⽬標を⽴てる。 どこまでチャンクダウンするか? 1⽉後までの状態を決める。KPIを設定して、1週間から1⽇単位の⾏動に落とし込ん でいく。 ⼀⽣⾷えるプロのPDCA | 清⽔久三⼦ | ビジネス・経済 | Kindleストア | Amazon
KPIを決める Key Goal Indicator KGI 売上や利益など最終的な⽬標数値。結果⽬標。⽇々の⾏動で直接コントロールし にくい。 Key Performance Indicator
KPI KGI達成のための重要な活動を測定した数値。先⾏指標。⽇々の活動によって 個々⼈が調節コントロールできる。 数値化しづらいKPIでも仮説で考える 最初から明確に品質定義できない仕事もある。 まず、KPIは仮置きする。 KPIを⾒極めることで Do が実装しやすく、かつ⾏動できたのか、⾏動できてないの かが明確になる。
よくあるダメな PLAN の⽴て⽅ よくあるダメな PLAN の⽴て⽅ KGI だけでPlanを⽴ててしまう。
緻密なスケジュールを⽴ててしまう。 仮説検証を素早く回しながら成功に近づいていくためには向いていない。 計画を⽴てる⼈と実⾏者が異なっている。 PDCAのPlanはあくまでも実⾏者のもの。
DO DO まず、やらないことを決める PDCAのサイクルを回す時間の捻出のためにやらないことを決める。 劣後順位を決めて時間を⽣み出す。 劣後順位を決めるための4つの視点 やめる やめることには勇気が必要
頻度を減らす ⼈に任せる ⾃動化する エンジニアは⾃動化が得意領域なので、ここで⼒を発揮できる。 ⾏動を記録する PDCAノートを作る。できるだけ⾏動を細分化する。記録⼤事。 集中してやり切る。 完璧でなくても、終わらせる。
CHECK と ACTION CHECK と ACTION Check実施時のポイント なぜ成功したのか、何が良い結果に結びついたのか、何がよくない結果になった
のかを振り返る。 責任追及ばかりしていてはダメ。 反省 ではなく内省 。 ⾃分と向き合い、⾃分の⾏動を振り返って気づきを得て、 と未 来に結びつける。 確証バイアス 仮説を検証する際にそれを⽀持する情報ばかり集めてしまう。
Check実施時のポイント 振り返りは学びそのもの 悪いところばかりあげるのではなく、学んだことをあげてみる。 Harvesting (収穫) する。 メンバ全員で得られたことを話し合い、他の⼈が使える形で⽂書化、データベー スに登録する。
振り返りの初⼼者がつまづきがちなことの対処法 (個⼈の場合) 性格改善になってしまうと⾃⼰否定につながり⾟くなってしまう ⽬に⾒えて実⾏できる⾏動を変える。 ⾃分の今の実⼒を超えたActionを考えてしまう 原因となる⾏動や要因を特定して解決する。 ⾃分の今の実⼒について認識した上で、振り返りで改善のActionを考える。 ⾒積もりの⽢さのせいにしてしまう ⾒積もり⾃体が仮説なので、外れることは珍しくない。 ⾒積もりの精度を上げるActionはPlanを精密化したり、バッフォを積むしかなく
なり、スピードを落とすことになってしまう。 ⾒積もりは、外れることを前提として、⾏動を細分化してPloblem、Actionを特 定する。 毎回同じPloblemが出てくる ⾏動、要因を分解仕切れていないと、結局課題を特定できないまま、Problemと してまた現れてしまう。
振り返りの初⼼者がつまづきがちなことの対処法 (チームの場合) 他の⼈の意⾒や顔⾊をうかがってしまう。 お互いの出⽅の探り合いとなり、KeepやProblemを本⾳で議論しにくい。 事前に書き出してもらうなどしておく。 Problemがリスクの洗い出しになってしまう。 実際に起きていないことは振り返らない。 状況、結果、⾏動の3点セットで出すルールにする。 リスクマネジメントを振り返りと別のタイミングで実施すべき。 責任追及の場になってしまう
具体的な⾏動レベルで話し合う。 進捗会議とは切り離して、別に⾏う。
KPT KEEP/PROBLEM/TRY KPT KEEP/PROBLEM/TRY Check と Action は、KPT
で実施する。 KPT実施時のポイント 仕事の進捗や達成状況の確認とは分けて考える。あくまでも⾏動を振り返る。次 に何をすべきかを考える。 スモールKPT、ビッグKPTを実施する。 仕事を進めながら⾏うスモールKPT、仕事の区切りがついたタイミングで全体の 振り返りを⾏うビッグKPT。 KPTが不要な状況上司が部下の仕事について事細かに指導できる状況の場合は、 KPTは不要。 KPTの時間を短縮する。 Doの時に、⾏動や状況、それによって得られた気づき、思い浮かんだ改善のアイ デア、効率よくするためにすべきことなどを記録しておく。 KPT記録のためのツール ボイスレコーダを使って記録する。 ホワイトボードを使う。
KPT実施時のポイント 時間がかかり過ぎるため、KPTの⼈数多くても、5-6⼈で実施する。 KPTのフォーマット 状況、⾏動、結果を3点セットで洗い出す。Problem は、状態 ではなく、 結果 行動 に着⽬する。進捗のリカバリ対策は別途⾏う。 ある⼈にとってのKeepは、ある⼈にとってのProblem
楽観的過ぎても、悲観的すぎても良い振り返りとは⾔えない。
どのようにTryを考えるか 4つのTryのタイプがある。 Adjust 4つの中では最も継続性が⾼い。 三現主義、現場、現物、現実を意識する。 Challenge Planを上⽅修正する。 ⽬標をあげる。期⽇を早める。⽬標を上げる。 勇気が必要。 Pivot
Adjustの検証結果がよろしくない場合は、⽅向転換、路線変更する。 個⼈のキャリアアップであれば、転職や独⽴が⼤きなピボット Do's and Don'ts べし、べからず集をつくる。 三現主義で得られたことから、原理・原則を⾒出す。 知識データベースを作ると、組織としてのPDCAがより速く⼤きな規模で回る。 技に名前をつけて、再現性を⾼める。
タイプ別の PDCA タイプ別の PDCA に は、以下の7タイプのPDCAが紹介されている。 ⽬標達成型売り上げ⽬標などKGIが明確に決まっている場合のPDCA 業務品質向上型PDCA
プロジェクト型PDCA 学び型PDCA 新しい知識や、スキルを習得するためのPDCA キャリア開発型PDCA ⾝の回り型⽣活の質を向上させるためのPDCA 個⼈的な状況だと、業務品質向上型 と 学 型 がマッチしたので、 この2つについて詳細を記載する。 ⼀⽣⾷えるプロのPDCA | 清⽔久三⼦ | ビジネス・経済 | Kindleストア | Amazon
何故2つのタイプの違う PDCA を実施するのか? 何故2つのタイプの違う PDCA を実施するのか? 業務品質向上型PDCA Will、Must、Can
の Must に 対するPDCA。 得意な⼈はメンティー以外にいて、メ ンティーがキャッチアップしてほしい技術、タスクに対して設定する。 PDCAが上⼿くいくと、Must、Canの重なりが増える。 学び型PDCA Will、Must、Can の Will に 対するPDCA。 メンティー⾃⾝が興味がある技術、学びたい知識に対して設定する。 PDCAが上⼿くいくと、Will、Canの重なりが増える。 重なりが増えた部分は今後のMust設定時に勘案する。 どちらかのみ実施するなら、業務品質向上型PDCA を実施する。
業務品質向上型 PDCA 業務品質向上型 PDCA 定常業務の品質を向上するためのPDCA。 KGIとして設定される指標 ミスをゼロにする。 時間を半分に短縮する。
⼿戻りゼロ。 ITエンジニアとしての指標 予算内にリリースコストを抑える。 リリース後の不具合発⽣率。 各⼯程での不具合率。 Pull Request数。
Plan設定のために実施すること 仕事を の3つに分解、改善ポイントを⾒つける。 IPO のボトルネックを⾒つける。 インプットボトルネック プロセスボトルネック アウトプットボトルネック ボトルネックを解消する。 3つのボトルネックを解消するための⾏動を具体化する。
劣後順位、優先順位を決める 予実の⽐較 予定と、実績を⽐較する。
PDCAのPlan設定時の注意点 メンティー側のレベルによってはボトルネックの分析ができない、改善施策が出 ないケースもあるのでフォローをする。 Planが漠然としたものになると、改善できない。例えば、Planがレビュー指摘事 項を減らす だと 減らない。具体的な⾏動、指標が定量的なPlanを設定する。
学び型 PDCA 学び型 PDCA 技術の学習に対するPDCA。基本的に個⼈で実施する類のPDCAだと思う。 書籍を読んで重要だと思ったポイントを記載。 重要だと思ったポイント Planの段階でアウトプットの機会も計画しておく。
⾃分で検証の機会を作る ブログで学んだことを投稿 勉強会を企画する 社内、部内研修の講師として他者に教える 学んだことを実践する機会を設ける ⾒識者、専⾨家にあって習得レベルを確認する
重要だと思ったポイント ASAPモデル Acquire 覚える Structure 構造化する Attempt 試⾏する Perform 達成する
参考 「能⼒のピーク」が40代以降に来る⼈の思考法 | 30代から⾝につけたいキャリア ⼒実戦講座 | 東洋経済オンライン | 経済ニュースの新基準
企業で実施する場合の留意事項 企業で実施するとしたら勉強会を計画、実施、そこにPDCAを置く 前へ出ないタイプのメンティーの場合は、 調査報告会 という形式での仕事にする 参考 毎朝15分の勉強会で若⼿の⾏動が驚くほど改善した話 - Qiita 勉強会アンチパターンへの対処例(随時更新)
- Qiita
まとめ まとめ 気づいたこと 改めて、PDCAの学びなおしをして、個⼈的に以下の気づきを得た。 IT技術以外も学ぶべきことはある。IT技術以外の技術 重要。 成長 仕方
人 が、成⻑の仕⽅がわかると幸せになれそう。 メンティーのWillの前に、メンターである⾃分のWillを固めたい。 今後 実際にこれでやってみて、駄⽬だった部分を修正していく。 後⽇、経験学習を知った 以上。 職場が⽣きる ⼈が育つ 「経験学習」⼊⾨ | 松尾 睦 | ビジネス・経済 | Kindle ストア | Amazon