「作業は 2 倍、時間は半分」のコードをクラックするためのプログラマー向けガイド

理論的な管理はおじいちゃんでいっぱいです。デミング、ゴールドラット、大野、ドラッカーの作品を読みました。 Ackoff と Juran のことは聞いたことがあります。どの本を読んでも人道的で慎重な態度が気に入りました。決してそうではありませんでした：「人々を疲れ果てて搾取する」。ピーター・ドラッカーは、その著書「Management Rev Ed」の中で、21 世紀の経営者である私たちに、私たちが何をすべきかを教えてくれました。 20 世紀における経営陣の最も重要で真にユニークな貢献は、製造業における肉体労働者の生産性が 50 倍に向上したことです。同様に、21 世紀に経営陣が行う必要がある最も重要な貢献は、知識労働と知識労働者の生産性を高めることです。 21 世紀に入って 20 年が経ちましたが、ソフトウェア開発の世界でこの野心的な目標を達成するのにどれくらい近づいているのでしょうか?私たちはそれから遠く離れていることがわかります。私たちがどこにいるのか、どのような問題を抱えているのか、そしてそれらに対して何ができるのかを探りましょう。 ソフトウェア開発の効率化への広範なアプローチの調査 「半分の時間で 2 倍の作業を行う技術」は、このフレームワークの共著者である Jeff Sutherland による「 」本のサブタイトルです。私はこのサブタイトルが好きです。これは、プログラミング作業をどれだけ効率化できるかを強く反映しているからです。ただし、すべてが雲ひとつないわけではありません。ここで最初に遭遇する問題は、私たちの仕事の効率性を理解するのが難しいということです。次の複雑な問題は、時間の経過とともに効率が向上するかどうかを理解することです。 スクラム しかし、最終的に効率性を求めるのはなぜでしょうか。まあ、それは同じことをより少ない労力で行うことであり、私たちの生活の多くの分野で、同じまたはより良い結果をより速くまたはより低い価格で得られることは素晴らしいことです. 質問に戻りましょう。スクラムの実践者は、タスクの測定としてストーリー ポイントを提案します。 があります。 scrum.org Web サイトからの定義 ストーリー ポイントは、個々のスクラム チームが決定して使用する相対的な測定単位であり、要件を完了するための労力の相対的な見積もりを提供します。 ストーリー ポイントは、参照タスクに関連する複雑さの度合いです。あなたと私は、それほど難しくないタスクを実装するのにどれだけの労力がかかったと感じています.新しい仕事に 3 ストーリー ポイントかかるとしたら、前の仕事の 3 倍は大変だと思います。それは私の推測であり、それがどれほど難しいかは誰にもわかりません。 効率性についてもう一度考えてみましょう。このスプリントで 25 ストーリー ポイントで見積もられたタスクを実行した場合、15 しかなかった前回のスプリントよりも優れているでしょうか?それとも、もっと注意深く、同じ努力に対してより高い見積もりを出していたのでしょうか?しかし、どうすれば比較できますか？ソフトウェア エンジニアリングでは、工場規模の反復作業は行いません。サービスを提供する情報工場を設計・実装します。私たちの業界に効率性について話し合う場所はありますか? こうした話し合いの場があります。少なくとも、意図的に速度を落とすことはできます。たとえば、先延ばしにしたり、あるタスクから別のタスクにジャンプしたりできます。効率の悪いことをすることができれば、逆の希望があります。ただし、ここではストーリー ポイントが有用な測定手段とは考えていません。彼らは、意図的または意図せずに簡単に虐待される可能性があります。もっと良いものを探す必要があります。 測定対象の定義 プログラミング作業の速度を上げる方法を定義する前に、測定したいこの作業を決定する必要があります。業界全体で使用できるものは見当たりませんが、効率向上のためにそれほど広い範囲を必要としないという利点があります。必要なのは、プログラミング製品を開発する上で意味のある作業ステップを説明する何かです。エピック、タスク、機能、または開発中のシステムの積極的な調整を表すその他のものを使用できます。 私の現在の場所では、3 つの異なるレベルを使用しています。 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task). 次の特性を持つように調整する必要があります。 開始時間と完了時間があります。 定期的に発生します。 ここで定義するのは「この大きな作品」です。記事の結果部分で と名付けましょう。すべてのアクションが同じというわけではありません。上記の例では 3 種類を示しました。 アクション 定期的に行動する必要があります。 この要件は、最初から最終的に効率的であることはできませんが、時間の経過とともに効率が向上する可能性があるという事実に由来します。これは、説明したアプローチの欠点ではありません。スクラムはこのように機能し、トヨタ生産方式はこのように機能し、科学はこのように機能します。現在の状態を発見し、それを継続的に改善するには、再現性が必要です。 究極的に最適化された効率で新しいことをできるのは、たまたまです。そして、アクションが複雑になればなるほど、その可能性は低くなります。事前準備が役立ちます。ただし、事前に準備できるということは、アクションまたはそのサブアクションが過去に発生し、それらに関する知識があることを意味します。まったく新しいものを用意する必要はありません。一方で、私たちは人生で完全な目新しさに出会うことはほとんどありません。以前の経験の一部は、経験したことのない状況に常に関連しています。 要約すると、測定する本質としての種類のアクションがあります。 ある種の行動を測定する方法は？ 一見すると、前のセクションには何も追加されていません。私たちはある種の行動をします。ストーリー ポイント、T シャツのサイズ、または動物で測定されるタスクよりも優れている点は何ですか?名前は単一の利益ではありません。種類のアクションには 2 つのタイムスタンプがあり、完了から開始を差し引くことでその期間を測定できます。持続時間は、日常の現実言語への鍵であるため、ここでは優れた利点です。 エピックを完了するのにどれくらいの時間がかかりましたか? 着手から完成まで39日かかりました。 素晴らしい。 他に得られるものはありますか? 私たちの行動に対する 2 番目の要件である定期的な発生は、信じがたいほど多くのことを私たちに与えてくれます。まず第一に、ある種の行動の流れを得る。以下は、Daniel Vacanti 著の「 」という本からのフローの定義です。 Actionable Agile Metrics for Predictability 簡単に言えば、フローとは、プロセスを通じて顧客価値を移動し、提供することです。 アクションの開始と完了という 2 つのタイムスタンプの要件により、新しいメトリックの適切なセットが得られます。ここにそれらはまったく同じ本からのものです： (特定の時点で作業しているアイテムの数)、 (各アイテムがプロセスを完了するのにかかる時間)、および (単位時間あたりに完了するアイテムの数) ）。 進行中の作業 サイクル タイム スループット ここにあるのはそれだけだと思うなら、興味をそそられます。私たちはまだ始まったばかりです。流れが私たちに与えてくれるもうひとつの宝物は、時間の経過とともに残る痕跡です。このトレースにより、システムをよりよく理解できます。いくつかの図を使用してそれを捉えることができます。それらの 1 つは、サイクル タイムの散布図です。 その楽しさは、「ここでのやり方」を捉えているところにあります。プロセスから何も必要とせず、特定の方法論も必要ありません。サイクル時間散布図を使用して歯磨きの流れをキャプチャしますか?早くやれよ。あなたの地域に建てられた家にも同じことを望みますか?絶対に大丈夫です。新機能の開発後に行われる A/B 実験を含め、開発ライフサイクルを追跡しますか?始めてやってください。 この図では、右側に 50%、70%、85%、および 95% で署名されたパーセンタイル ラインも表示されます。彼らはどういう意味ですか？左側には日があります。次の方法で 85% と 16 日を読み取ることができます。 当期にシステムに入ったアイテムの 85% について、システムから出るまでにかかった日数は 16 日以内でした。 このセクションで「システム」という言葉を使用するのは 2 回目です。どういう意味ですか？このストーリーでは、次のように定義しましょう。 システムとは、ある種のアクションを実行するものです。 上記の住宅建設システムの例における一種のアクションの 1 つは、家を建てることです。ここでは、1 キロメートルの道路を作ることはアクションとしてカウントされません。それは別の種類のアクションであり、別のシステムです。とはいえ、具体的な区分はありませんが、歯磨きやA/Bテストによるソフトウェア開発はもちろん、家も同じでありたいと思っています。十分に異なるものについては、別のシステムを考え出すことができます。 もう 1 つの重要な成果 強化作業の精度を確保するのに役立つもう 1 つの効果について説明する時が来ました。チームがあり、新しいソフトウェアを作成する必要があると想像してください。ユーザー ストーリーは、進行状況の測定値として、アクションとして捉えます。最初のストーリーを完成させたら、次は振り返りを行って、次回はどこを改善できるかを確認します。 この論理には、私たちを罠に導く何かがありますか?詳しく見てみましょう。 最初のユーザー ストーリーの実装中、主な障害は、必要なライブラリについて合意し、必要なソフトウェアをインストールすることでした。時間もかかり、本当にしんどかったです。ふりかえりの間に、チームはそれがどれほど苦痛であったか、そして次回はどのように改善できるかについて話し合いました.非常に明らかなミスは、次回はライブラリに同意してソフトウェアをインストールする必要があることです。図書館は通常、長期間存続します。ソフトウェアのインストールは、新しいメンバーのオンボーディングの一部になりますが、2 番目のユーザー ストーリーで既に確立されているチームを悩ませることはありません。それは十分に異なっており、今ではオンボーディング システムの一部になることができます。 Donald Knuth ( ) による次のプログラミングの知恵を見てみましょう。 または Tony Hoare 時期尚早の最適化は諸悪の根源です。 これは、ソフトウェア開発の初期段階でパフォーマンスについて考えてはならないことを示していると思います。この知恵を次の形で見たことがあるかもしれません。 機能させる、正しくする、速くする。 ライブラリのインストールに関する例は、格言がコードとコーディング チームに関連していることを示しています。ここで出会う謎！ミステリーではなく、システムの属性です。最初の試みの後に機能強化に飛びつくことを避けるべき理由が少なくとも 2 つあります。 すぐに強化に踏み切らない統計的理由 種類のすべての完全なアクションには、その期間があります。期間は 2 つの部分で構成されます。1 つは一般的な理由によるもので、もう 1 つは特別な理由によるものです。 もう一度歯磨きの例を見てみましょう。通常、歯ブラシに歯磨き粉を塗るには数秒かかります。特別な場合には、クローゼットから歯磨き粉を取り出し、開けて使用する必要があります。ここでは、アクション全体に数分かかります。なんらかの理由で、歯磨きにおける歯ブラシのコーティング サブアクションの効率を考える必要がある場合、最初のサブアクションの後にそうするのは誤解を招く可能性があります。最初のアクションには余分な部分が含まれており、高速化したい通常のアクションとは異なります。 特別であることの性質は、特別な期間の理由の一貫性のない外観につながります。常に示されているのは、私たちの行動の核心であり、私たちの機能強化の実りある目標です。 制約の理論 すぐに強化に飛びつかない理由 制約の理論は私たちに何を教えてくれますか?これは、何かを生産する全体が、最も生産性の低い部分と同じくらい生産的であることを示しています。小さな 1 階建ての家を建てる会社があると想像してください。当社の年間生産能力は次のとおりです。 地下6階、 24セットの壁、 52屋根。 年間何軒の家を建てることができますか？あなたは 6 と答えるかもしれませんが、私は 6 以下と答えることをお勧めします。私たちの建築プロセスは、地階→壁→屋根という必然的なものです。最後の6番目の家を終えると、年末に遅れる可能性があります。 建てる壁や屋根の数を増やすと、会社全体の能力が変わるでしょうか?前述の「6 個以下」より多く生産する予定はありますか?いいえ、地下室はまだ私たちを制限しています。 上記の容量の数値は、この表面的な会社の経験に基づいています。最初のユーザー ストーリーを実装した後は、このような経験はありません。各サブアクションがどれくらい続くかわからないため、ユーザーストーリー構築システムの制約をまだ決定していません。ユーザー ストーリーの開発プロセスの一環として品質保証を行うことを検討してください。ユーザー ストーリーのテストは 4 時間続きます。ユーザー ストーリーの作成には、通常 5 営業日かかります。 1年に250営業日あるとしましょう。最後に 50 のユーザー ストーリーが完成する予定ですか、それとも 730 ですか?家屋や地下室と同様に、年間最大 50 件です。私たちの行動の形とその最も生産性の低い部分を理解するには、統計を収集する必要があります。 機能強化を開始するには、何回のアクションを完了すれば十分ですか? 完全に確実にするために、この時点で完全なアクションの数を ∞ にすることをお勧めします。この正確な数を取得したら、最初に何を強化するかを 100% 確信できます。🥁 純粋数学の世界以外の人のために、次の考えを考えてみましょう。 「 」本を参照する「 」本からの参照は次のとおりです。 何でも測定する方法 予測可能性のための実用的なアジャイル指標 たとえば、Douglas Hubbard (彼の著書「How to Measure Anything」は参考文献に掲載されています) は、クライアントに「 」についてアドバイスしています。Rule of Five - 母集団の中央値がその母集団からランダムに抽出された 5 つのサンプルの最小値と最大値。 Rule of Five システムの改善について深く考え始めるには、5 つのアクションで十分に思えます。 最初の 5 つのアクションを変更することをタブーと見なさないでください。健康上の安全、チームの結束など、他の側面も考慮してください。 機能強化はどこから始めますか? テレビのボタンを押して電源を入れるなどの基本的な動作をとれば、全体として考えることができます。動きの回数と全体の時間を減らすには、クリッカーを購入して、ソファの近くに 1 か所に保管してください。この例では、最初のアクションには約 20 秒かかり、2 番目のアクションには 1 秒かかります。おめでとうございます！以前に必要だった時間の 95% を短縮しても、同じ価値を得ることができます。なんて素晴らしい無駄遣い！ すべてのアクションがそれほど単純であるとは限りません。前述のユーザー ストーリーの開発は複雑です。そこの改善を 1 回のジャンプで処理するのは困難です。家を建てる例のように、物事をサブアクションに分解する必要があります。次のライフサイクルから始めることができます。 分析、 発達、 テスト、 終わり。 どこから始めれば？ リーン製造では、この記事で名前が付けられている作成プロセスまたはアクションは、次の 3 種類のサブアクションで構成されます。 付加価値活動; 必要な非付加価値活動。 無駄。 ユーザー ストーリーの策定、ソリューションの設計、およびコーディングは、すべて付加価値のある活動です。開発中に git ブランチを使用することは、付加価値のない必要なアクティビティと見なされる場合があります。この変更に何も追加しませんが、プロセス全体を整理します。浪費は、正当な理由なくしばらくの間、価値の蓄積を妨げます。稼働していないデータベースを待つのは無駄です。 無駄のない生産方式では、無駄 ( ) は、トヨタ生産方式の作成者である大野耐一氏によって知られ、定義されています。少なくとも、それらは自動車メーカーであるトヨタの会社に対して定義されています。他の業界にはそれぞれのバリエーションがあります。以下は、Mary と Tom Poppendiecks が「 」の本で作成したものです。 ムダ リーン ソフトウェア開発 部分的に完了した作業、 余分なプロセス、 余分な機能、 タスク切り替え、 待っている、 モーション、 欠陥。 それともこれら？同じ著者による「 」の本から: Implementing Lean Software Development 部分的に完了した作業、 余分な機能、 再学習、 不必要な引き継ぎ、 タスク切り替え、 遅延、 欠陥。 少なくともソフトウェアエンジニアは動けるようになりました!😅 私たちの業界では、これらの柱がわずか数年でどのように大きく変化したのでしょうか?その答えは、将来の廃棄物の十分なリストを持つことが不可能であることにあると思います。トヨタでさえ、ある時点で8番目の無駄を思いついた. 私たちの業界のリストが根本的に変化したことは素晴らしいことです.この変化は、廃棄物とは何かについての私たちの考えを継続的に再考する心を開きます。ソフトウェア開発の無駄な部分について、もう 1 つの見方を次に示します。 ソフトウェアの世界における最大の誤解の 1 つは、コードの価値です。しかし、この本で繰り返し述べているように、コードには責任があります。より多くのコードを記述すればするほど、複雑さとリスクが増大します。 David Anderson と Mark McCann & Michael O'Reilly による " " からの引用です。うわー、なんて乗り心地だ！ The Value Flywheel Effect では、どのように始めますか？最も生産性の低いサブアクションを見ることによって。私たちは何を求めていますか？付加価値のないサブアクション。 ユーザーストーリー開発ワークフローの再考 以前のワークフローを思い出してください。 分析、 発達、 テスト、 終わり。 通常、これらはさまざまな担当者が担当するため、引き継ぎを待つ時間が常にあります。それを文書化しましょう： 分析アクティブ、 分析完了、 開発アクティブ、 開発完了、 テスト、 終わり。 私はこれらの手順を考案しませんでした。 からそれらを取り上げました。それらを信頼できますか？私は実際のデータのさまざまな例を見てきましたが、これはそれに近いように見えるので、はいと言います。次のステージの統計を調べてみましょう。平均を示しています。 ActionableAgile Analytics 製品のデモ システム サイクル タイムは 9.37 日です。このステートメントは、タスクが ステージに到着し、次のすべてのステージを通過し、 for を離れることを意味します。このパスには平均で 9.37 日かかります。名前に「アクティブ」が含まれるステージは、 だけでなく、結果にも有用性をもたらすようです。 「完了」で終わるステージは、待ち行列であり、待機中であり、何の役にも立ちません。フロー効率図を使用して適切にマークすると、平均して、1 つのユーザー ストーリーに費やされる時間の 40% だけが価値があることがわかります。 Analysis Active Testing Done テスト この図には、追跡されたブロックされた時間と、すべての時間を「完了」段階で費やした奇妙なタスクも含まれています。それらを除外すると、このデモ例のフロー効率は約 50% になります。 発見された時間の無駄に対処する デモンストレーション用のデータ セットに関する情報が少なすぎるため、「チーム E により優れたコンピューターを提供する」などの具体的な推奨事項はありません。ただし、あなたの場合、あなた自身を刺激するのに十分な考えがあります。私たちのプロセスで最も生産性の低い部分は、 段階です。待っていることを表しているので、そう呼ぶことさえできません。ただし、すべてのタスクのほぼ 29% を占めています。ここでの理由は何でしょうか？ 分析完了 アクティブな開発段階は遅くはないように見え、アクティブな分析部分よりも完了するのに必要な時間が短くなります。平均 WIP を見ると、問題が浮き彫りになります。分析部門は、より多くのユーザー ストーリーを同時に処理できます。 たとえば、より多くの開発者をチームに参加させることで、このバランスを取ることが解決策になる可能性があります。ただし、ここで性急になりすぎないでください。理由はかなり違うかもしれません。 ステージには、おとり捜査を含めることができます。開発者は要件の品質に満足していない可能性がありますが、この問題を体系的に解決できず、この段階で時間をかけて要件を強化することはできません。境界条件の発見、非同期リクエストの UI 処理の提案など。 Analysis Done 解決策を提案する前に、根本原因分析を適用します 、 などを使用します。 。5 つの理由 フィッシュボーン 適用された変更の成功の確認 前のセクションの問題に対処したとしましょう。提案された変更が機能したことをどのように確認できますか?もう一度データを蓄積する必要があります。上記の5つのルールを覚えていますか?ここでも使えます。私たちのシステムは現在調整されています。もう一度測ってみましょう。 私の仕事では、実験の結果を測定するために 2 つのツールを使用します。 累積フロー図、 サイクル タイム散布図のトレンド ライン。 のシアンの領域が表示されますか?少なくとも時間の経過とともに薄くなり、せいぜい消えることを期待してください。 Analysis Done このすでにおなじみの図に表示されている緑色の破線を見てください。これは、過去 N 日間の 85% のサイクル タイムの傾向を示しています。変更を実証するのに十分安定しているため、N の代わりに 30 を使用します。発見されたソリューションが十分に深い根本原因を処理する場合、この線は約 30% 減少して 11 日になると予想されます。 大きなデータ変更がない場合は、他の解決策を探すときです。 次のステップ 次の明らかな改善点は、 段階です。私たちもそれに対処したと想像してみましょう。ユーザー ストーリーを完成させるために最初に必要な時間を 50% 削減しました。ただし、ストーリーのタイトルは、生産性が 4 倍になることを約束しています。この場合、 ステージについて考え始めることができます。次に、 Testing をそれと で並列化してみてください。 開発完了 Analysis Active Development Active それにもかかわらず、ここでそれが必要かどうかはわかりません。 2 日ごとに新しい機能を追加するソフトウェアを使用していると想像してください。市場はその準備ができていない可能性があります。市場は私たちのシステムにとって制約になります。この発見は、私たちの改善が常に制限されているという意味ではありません。通常、価値を生み出す複数の開発システムがあり、機能には 9 日以上かかります。私の経験では、6 か月間続くアイテムの鳥瞰図では、付加価値時間の 30% しか発見されませんでした。 30% 内のタスクのより詳細な図は、付加価値時間の正確な 30% を示しています。 180 日間全体で、付加価値のある活動があったのは 16 日間だけであることが判明しました。 11 倍の改善の可能性が見られます。 アプローチのまとめ あなたのシステムを発見し、 その制約を発見し、 制約がなくなるまでムダをなくし、 繰り返す。 有効な質問 このアプローチは、20 世紀のコントリビューション マネジメントを行う上で高い可能性を秘めていると感じています。この方法について誰かに話すとき、私は通常、いくつかの質問に直面します。 これはプログラミングの楽しさを壊しませんか? ソフトウェア開発は非常に予測不可能であり、非常に創造的です。その効率に取り組むことについてどのように話すことができますか?! その提案は、プログラミングの楽しさを壊すものではありません。何も起こらなかったプロセスの穴をなくすことに取り組んだことに気付いたかもしれません。作成したばかりのタスクを実行できることは、2 日後にタスクを実行するのと同じくらい楽しいことです。もう 1 つの喜びは、自分のコードを変更中のシステムと見なし、チームを同じように見なすことです。プログラミング ツールの新しい土地があり、アプローチが開かれました。 以前はオンライン モブ プログラミング ツールが必要だったのはなぜですか?速くなるには？しかし、当時は何が速かったのでしょうか。明示的なソフトウェア設計段階が必要なのはなぜですか?あはは！私たちの開発チームはバグに悩まされています。そのため、ユーザー ストーリーは、開発者がバグを修正するまでライフサイクルの最大 30% 待ちます。それらを防ごうではありませんか。 プログラミングの楽しさを損なっているのは、タスクを完了するために定期的 なければならないことです。より良い方法、ツール、知識で力を与えられても、喜びがなくなるわけではありません。 に肉体を切り離さ はい、ソフトウェア開発の作成は確かに予測不可能であり、日常的ではありません。しかし、それは無限に予測不可能ですか？未処理のタスクを 1 年で完了するには、1 年で十分でしょうか?十年くらい？それらの変化の性質はとらえどころがなく、私たちがそれについて何もできないのでしょうか?サイクルタイム散布図の存在は、ソフトウェア開発のバリエーションに限界があることを示しています。タスクによっては、テキスト定数の迅速な修正が必要な場合もあれば、数日間の調査が必要な場合もあります。私はこれに同意しますが、次のこともお尋ねします。「これらのタスクの存在は、必然的なソフトウェアの性質の結果ですか、それとも、使用するソフトウェア アーキテクチャの結果ですか?プロセス内の 、そんな混乱の理由は？」 大きな泥のボールは よりスムーズな開発フローの必要性は、最終的に、技術的、アーキテクチャー、およびプロセス上の負債に対処する絶対的な理由ではないでしょうか? はい、最も変更に適したアーキテクチャであっても、私たちが望んでいるよりも多くの時間を必要とする難しい問題が発生する可能性があります。そして、サイクル タイムの散布図の 95 パーセンタイル ラインより上に、それらを処理する場所が既にあります。しかし、それらは例外であり、すべてが例外になることは望んでいません。 私たち管理者は、消火活動を行うべきではなく、システムの設計とそのバリエーションに取り組むべきです。 明らかで間違った手順を回避する この業界で効率を求めるのは私が初めてではありません。求職者の中には、そのトピックについてすでによく知っていると考えている人もいます。彼らのアプローチは、雇用主のコンピューターに追跡ソフトウェアをインストールし、仕事ではないものとして扱われる人を罰することです。この方法は、ソフトウェア開発効率の源泉を完全に認識していないことを示しています。大きな緊張の結果として大きな成功を収めるという考えは、悪いだけではありません。それは致命的です。それは、私たちのシステムを 1 つの側面のみに制限します。あなたの個人的な経験は、燃え尽き症候群の人々の十分な例を提供します.歴史は、各国がこの罠に陥り、多くの犠牲者を出したことを示しています。いいえ、一生懸命働くことは継続的な改善への道ではありません。しかし、それは何ですか？ 始める場所を見つける 1 世紀以上前に、フレデリック テイラーは、現在科学的管理として知られていることに関する研究を開始しました。彼は同僚を見て、彼らが仕事をするためのより効率的な方法を探しました。 テイラーは科学的方法によって、人間が与えられた仕事のそれぞれを実行するのにどれくらいの時間がかかるかを発見することを決意しました. 1882 年の秋、彼は科学的管理の最初の機能を運用に移し始めました。 テイラーが当時取り組んでいたビジネスの構造はわかりません。彼の生産ステップが特にそうである可能性があり、これはまた、テイラーが局所的な部分最適化の罠に陥ったことを意味する可能性もあります。それは、架空の住宅建設会社が処理できる屋根の数を増やすことに関するものです。たとえそうであったとしても、テイラーの発見の影響力は衰えることはありません。今、私たちはこの罠の危険性を知り、より賢く行動できるようになりました。 アイテムが 6 か月または 180 日続く私の例を覚えていますか?エンジニアが働くインナーアイテムのムダをなくすことができれば、38日節約でき、大型アイテムは142日残せます。チーム全員で作業するアウターに同じことをすると、126 日節約でき、同じ大きなアイテムに 54 日かかります。大勝ちしたいのであれば、残業やオフィスのベッドで開発者を拷問することは意味がありません。鳥瞰図から価値提供プロセスを見て、このレベルでの改善の余地がなくなったら、さらに深く掘り下げてください。