ビジネスプロセスにカンバンを導入する予定はありますか? ここから始めましょう。 カンバン システム: カンバン システムとは何か、どこから始めるか、実装方法、主な原則

カンバン方式、その基本用語、適用範囲についてできるだけ簡単に説明します。

カンバン方式、その基本用語、適用範囲についてできるだけ簡単に説明しました。

1. カンバン方式とは何ですか?

カンバン方式は業務を改善するための手法です。 何をするにしても、カンバン方式を実践すると仕事がさらにうまくできるようになるという仮説があります。 カンバンの観点から見ると、これは顧客の期待にさらに応えることができることを意味します。

IT 管理ツールとしてのカンバンは、Microsoft (2005 年) と Corbis の David J. Anderson によって導入されました。 そしてこの方法は広く普及し、2007 年に名前が付けられました。

2. カンバン方式とトヨタカンバンは同じものですか?

(最大のカード)。 確かにそのような意味ではありません。 トヨタ工場のかんばんは無駄のない生産であり、その定義原理は「ジャストインタイム」の概念です。 管理用語としてのカンバンは、実際にはトヨタから来たものです。 日本語に翻訳すると、この言葉は「信号」または「カード」を意味します。 自動車工場では、このようなカードは、必要な部品の数と部品に関する情報をある段階から次の段階に伝達するために使用されました。

短い例を見てみましょう。 3 台の車を「ジャストインタイム」で作る必要があります。 これは、特定の段階で必要な部品の数を事前に正確に決定できることを意味し、この車を作成するために必要な数の部品を端から取り出して、次の質問に答えます。 「必要ですか？」、「ホイールは何個ですか？」、「エンジンは何個ありますか？」 等々。 したがって、余剰スペアパーツを余剰として発生させず、倉庫、物流、その他のコストを節約します。

カンバン方式でも「ジャストインタイム」の概念が貫かれていますが、トヨタの工場とは異なり、ここでは知的労働について話しています。 言い換えれば、プログラマーのコードやマーケターのアイデアは、最終的な製品やサービスになるまでは、一般の人が触ったり見たりすることはできません。 そこで、知的作業の流れを可視化し、未完了の作業を減らすためにカンバン方式が用いられます。 これにより、最終消費者へのサービス提供の均一かつ予測可能な速度が達成されます。

3. カンバン方式は IT 以外でも使用できますか?

はい。 カンバン方式は、創造的で知的な作業の流れを視覚化するのに適しています。 しかし、サービス パラダイムのプリズムを通してそれを使用する方がはるかに効果的です。 あなたがサービスとして何をしているかを見てください。 サービスが提供されるまでにどのような段階を経る必要がありますか? サービスが顧客の期待に沿って提供されているとどのような基準で判断しますか? これがカンバン方式の使用の開始点です。 カンバン実務者はこの点を「今あるものから始める」と呼んでいます。

4. カンバンはスクラムに似ていますか?

いいえ。 スクラムは、厳格なルールと境界を持つフレームワークです。 スクラム内ではさまざまなツールや方法論を使用できますが、スクラムで必要なものを放棄した場合、それはスクラムとは見なされなくなります。 カンバンは、一連の実践と原則を備えた方法であり、ツールです。 すべてのプラクティスを使用することも、一部のプラクティスを使用することも、まったく使用しないこともできます。 カンバンには、何がカンバンで何がカンバンではないのかという厳密な概念はありません。 ただし、プラクティスを賢明に使用することは、最高品質のサービスを提供し、顧客の期待に応えるのに非常に役立ちます。

5. カンバンには価値観がありますか?

はい。 それは、透明性、バランス、コラボレーション、顧客重視、フロー、リーダーシップ、理解、合意、尊重の 9 つです。

6. カンバンの原則について書きました。 彼らは何ですか？

カンバンには、変更管理原則とも呼ばれる基本原則があります。

  1. 今持っているものから始めましょう。
  2. 進化的発展については同意する。
  3. あらゆるレベルでのリーダーシップの育成を奨励します。

カンバン方式はサービス パラダイムに基づいているため、次の原則に従います。

  1. 顧客のニーズと期待を見つけます。
  2. 仕事を管理し、それを中心に人々を組織させましょう。
  3. パフォーマンスを向上させるためのルールを作成します。

7. カンバンの実践方法は何ですか?

次の 6 つもあります。

  1. 視覚化します。
  2. 未完了の作業を制限します。
  3. 仕事の流れを管理します。
  4. 明示的なルールを使用します。
  5. フィードバック ループ (リズム) を導入します。
  6. 改良し、進化させます。

これらは、私たちが仕事を改善し、サービスの品質を向上させるために使用する直接的な実践的なテクニックです。

8. ああ、ケイデンス！ カンバンのケイデンスとは何ですか?

ケイデンスとは音楽用語です。 カンバン方式の文脈では、これはリズムを意味します。 ケイデンスは定期的な会議であり、フィードバック ループでもあります。 規則性によって、仕事の流れのリズムが決まります。 7 つのリズム:

  1. カンバン会議（毎日）。 ここでは、ブロックされたタスクのステータスについて説明します。
  2. キュー補充ミーティング (通常は 2 週間ごと)。 私たちはサービスとして責任を持って行います。
  3. 納品計画の会議 (通常は 2 週間ごと)。 履行した義務はお返しします。
  4. サービスレビューミーティング (通常は 2 週間ごと)。 指標を使用して、サービスの品質と、必要に応じてそれを改善する方法について話し合います。
  5. 運営会議（通常月1回）。 関連サービスのインタラクションの品質についてメトリクスを使用して説明します。
  6. リスク検討会議（通常月1回）。 ブロックされたタスクがサービスの運用に及ぼす影響について、メトリクスを使用して説明します。
  7. 戦略検討会議 (通常は四半期ごと)。 戦略の変更について指標を使用して説明します。

9. サービスクラスについて聞きました。 これは何ですか？

カンバンでは、サービス クラスを使用して、特定の種類の作業や顧客に優先順位を付けたり、遅延コストなどのビジネスへの影響を軽減したりします。 遅延コストとは、サービスの提供が遅れたために発生する利益の損失またはコストです。 例を使用して、遅延コストと対応するサービス クラスの影響を見てみましょう。

  1. 加速クラス - 緊急応急処置 - 蘇生。 専用車線を走行します。 問題の解決を先延ばしにする時間はありません。 できるだけ早く必要です。
  2. 固定日付クラス – 一定期間が経過すると遅延コストが大幅に増加します。 例: 開始日が固定された連邦法の形式のプロジェクト。 時間までに間に合わないと免許を剥奪される恐れがある。
  3. 標準クラス - 遅延のコストは時間に比例して増加します。 すぐに実行すれば、すぐに利益が得られます。 長くやれば、長く利益が得られます。
  4. 無形のクラス - 私たちはそれを行いますが、この作業は明らかな利益をもたらさず、遅延のコストはゆっくりと増加します。 たとえば、家の掃除。 定期的に掃除する必要はありませんが、半年後には徹底的に掃除する必要があります。

10. 指標についてはどうですか? サービスの有効性を測定するにはどうすればよいですか?

カンバン方式には、ワークフローの問題は何か、サービスのスループットはどれくらいか、実行時間はどれくらいか、ロック解決時間はどれくらいか、サイクルタイムはどれくらいか、などの質問に答えることができるメトリクスがあります。どのような種類の作品が配信されていますか？ これらすべてにより、サービス管理者は蓄積されたデータに基づいてサービス品質の開発と向上に関する意思決定を行うことができます。

11. カンバンの実装中に直面する課題は何ですか?

主な課題は、カンバン方式の価値、つまり進行中の作業の可視化と制限をあらゆるレベルの人々に説明することです。 人々は知的労働の量を目にすることができないため、自分がさらされている負荷を理解することが困難です。 しかし、たとえば脳は上腕二頭筋と同じ筋肉です。 ジムを想像してみてください。入ってきてバーの重量を見て、「わかりました、それは少なすぎます。 そして今ではそれは多すぎます。 でもこれがちょうどいいんだ！」 同じように脳を使って作業する必要があります。「これは大きな仕事で、これは小さな仕事ですが、一般的には、どういうわけか私は多くのことを引き受けてきました。 荷物を制限させていただきます。」 あらゆるレベルでエンドツーエンドの作業の流れを視覚化し、進行中の作業量を制限すると、ナレッジワークのプル原則が確立され、その結果がクライアントに均一に渡されるようになります。

12. カンバン方式にはどのようなプログラムがありますか?

それらもたくさんあります。 このメソッドのために特別に開発された、専門的なもののみをリストします。 ロシアの開発「回天」に心より敬意を表します。 それに加えて、TargetProcess、SwiftKanban、LeanKit などもあります。

13. カンバン方式をすでに使用している企業はどこですか?

ロシアの銀行には、Alfa-Bank、Home Credit Bank、Pochta-Bank、Dodo Pizza、HeadHunter、Clever などが含まれます。 海外から: Wargaming、Microsoft、Automotive IT、Blizzard Sports、Dr Dobb’s、Siemens、Tupalo。 このリストは長期間続けることができます。

14. 他に重要なことはありますか?

はい。 最後に、カンバン方式における 2 つの役割の重要性について触れておきたいと思います。 これらは、サービス配信マネージャーとサービス要求マネージャーです。 1 つ目は、供給の流れの障害物を取り除く役割を果たします。 2 つ目は、多くの顧客からのサービスへのリクエストのフローを管理するためです。 これら 2 つの役割がパートナーとなって連携することが非常に重要です。

15. わかりました、わかりました。 組織内でカンバンの導入をどこから始めればよいでしょうか?

組織でカンバンの導入を開始するには、S.T.A.T.I.K ツールを使用します。 – カンバンの使用に対する体系的なアプローチ。 詳細については、インターネットで読むことができます。 ただし、このツールをビジネス ゲームの形式で教えるトレーニングに参加することをお勧めします。 サービス (組織) を例として使用すると、その後の戦闘状況で使用するためのカンバン システムを設計できます。

アジャイル手法のトレーナー兼コンサルタント、Scrumtrack。

こんにちは

テスト チーム コーディネーターとしての私の専門的な関心の 1 つは、ソフトウェア開発方法論です。 現在、いわゆるアジャイル手法、特にスクラムとカンバンの人気が高まっています。 不謹慎な「トレーナー」は「誇大広告」を利用しており、セミナーや認定資格 (「認定スクラムマスター」、「認定プロダクトオーナー」など) は飛躍的に成長しています。

ほとんどの不謹慎な記事やトレーニングでは、コミュニケーションの問題を即座に解決し、個々のチームメンバーを無能から即座に救う魔法の特効薬として、あらゆる方法論が紹介されています。 一般に、問題を正確に解決するのに役立ちます。 今年、私は人的資源管理テクノロジーの学位を取得してベラルーシ州立大学の修士課程に入学する予定で、最も一般的なソフトウェア開発手法の長所と短所、および適用可能性の限界について詳しく検討する予定です。

仕事の過程で、方法論ツールの誤解や誤った解釈、文脈を考慮せずに流行の方法論を使用することによく遭遇しました。 記事を読んだ後、この問題はローカルなものではなく、グローバルなものであることがわかりました。 今日は、カンバン、その歴史、基本原則、および考えられる適用範囲について少し見ていきたいと思います。

用語の歴史
カンバンは、20 世紀の 60 年代にトヨタで生産に関連して使用され始めた日本語の用語です。 この原理は、コンベヤー生産方法と、生産における個々の技術操作を実行するためのさまざまな速度に基づいています。 指で説明してみます。 どのような生産にも、主生産（「メインコンベア」）と追加生産（「追加コンベア」）があります。 最終製品の生産速度はメインコンベヤーによって設定されますが、追加のコンベヤーでは製品のリリース速度を上げることはできませんが、必要な部品が時間通りにリリースされない場合は遅くなる可能性があります。

また、制作中に優先順位が変更される場合があります。 たとえば、組み立てラインには 15 台の車両があり、両方のタイプのミラーが 15 個必要であるのに対し、左側のミラーを生産したステーションは 20 個、右側のミラーを生産したステーションは 10 個を生産したことがわかりました。 指標の矛盾があります。生産量は量的には減少していません（追加のコンベヤーにより予定通りに 30 個の製品が生産されました）が、依然として生産が停止するリスクがあります。 カンバンはこの問題を解決するために設計されています。

最も単純な形式のカンバンには、次の 2 つの単純なルールが含まれています。

  • 生産ステーションには部品の生産計画 (「バックログ」) があります。 計画は優先度によってソートされており、いつでも変更できます (たとえば、左側のミラーが多すぎるステーションは、できるだけ早く右側のミラーに切り替えることができる必要があります)。
  • ステーションで同時に実行されるタスクの数は制限されています (つまり、同時に作成できるミラーの数は指定された数だけです)。 この制限は、ステーションでの生産速度と計画変更への対応速度を制御するために必要です。
現在形
最近、カンバンはソフトウェア制作において非常に人気が高まっています。 この方法論が非常に便利であると考えるチームもあれば、「カーゴカルト」として使用するチームもあります。 私の経験に基づくと、純粋なカンバンは製品チーム (「コア パイプライン」と読んでください) ではうまく機能しませんが、次のようなサポート チームではうまく機能します。
  • ソフトウェア サポート グループ。「計画」は重要ではありませんが、変更への対応速度が重要です。
  • テストチームは開発チームとは別に作業します。
  • サポートサービス;
  • 「非必須産業」の他の例。

これとは別に、カンバンは、明確な計画はないものの、積極的に開発に取り組んでいるスタートアップ企業ではうまく機能することに注意してください。 ソフトウェア開発におけるカンバンの使用例を考えてみることを提案します。 見苦しいイラストですので予めご了承ください。 1 人の開発者のチームが小さなプロジェクトに取り組んでいると想像してみましょう。 開発計画（バックログ）は作業の優先度順に並べ替えられ、プロセス内のタスクのチーム制限は 1 個です。

プロセスを管理するために、プロジェクト マネージャーは次のことができます。

  1. 作業中のタスク数の制限を変更します。
  2. できるだけ早く実行されるように、優先度の高いタスク (p0 など) を追加します。

作業プロセス中に、作業がブロックされる場合があります (ホスティングが故障した、必要なフレームワークがダウンロードされていないなど)。 一般に、ブロックされた作業はバックログに戻され、最も優先度の高い新しいタスクが選択されます。 タスクの性質やチームの種類に応じて、制限は増減する場合があります。 たとえば、開発者は登録フォームを描画すると同時に、新しいサーバーの展開プロセスを監視することができます。 ただし、タスクの完了時間が必要よりも短い場合、プロジェクト マネージャーは制限を減らすか、チームを増やすことができます。 したがって、適切な管理により、カンバンは特定のチームに可能な限り最高の作業速度と変更への最大の対応速度を提供し、同時に方法論をサポートするための「コスト」を削減します。 さて、それだけです！ カンバンは簡単でも単純でもありません。 とても簡単です！

製品チームでカンバンを使用する場合、次のような制限があります。

  • この方法論は大規模なチーム (5 人以上) ではうまく機能しません。
  • カンバンは、純粋な形では、部門を超えたチームとはうまく機能しません。 それらの。 スクラムとは異なり、テストと開発を 1 つのチームで組み合わせるのは困難です。 より良いアイデアは、プロセスを開発「ステーション」とテスト「ステーション」に分割し、マネージャーとバックログを別々にすることです。
  • カンバンはその歴史と特性により、長期的な計画を目的としたものではありません。
結論
結論として、「誰がよりクールか」という原則に基づいてあらゆる方法論を比較することは生産的ではなく、非建設的であると付け加えておきたいと思います（Captain Obvious）。 多かれ少なかれ一般的な方法論にはそれぞれ長所、短所、および適用の限界があります。 さらに、アジャイル手法は本質的に、チームメンバーのチームワークと経験に対してより大きな要求を課します。

興味があれば、カンバンについてさらに詳しく検討し、その後、スクラムと RUP を断片と図に分類することを提案します。

より詳細かつ明確に見ることができます。

カンバンとは何ですか? カンバン カードにはどれだけ興味深い情報が含まれていますか?また、そのメソッドは本番環境でどのような機能を果たしますか? この記事では、カンバンを効果的に使用するためのルールを詳細に説明するとともに、対応するカードの使用スキームを具体的な例を使用してわかりやすく説明します。 さらに、この資料に慣れた後は、なぜカンバン ボードが必要なのか、生産以外にどの分野でこの方法を使用することが推奨されるのか、カンバン ボードの優れた代替手段となるものは何なのかを学ぶことができます。

コンセプトの本質と手法の主な特徴

今日、在庫を保管するためのコストが増加する傾向が明らかであり、これがカンバン システムを含む「即時」在庫管理複合体が形成される主な理由です。 日本語から翻訳すると、「カンバン」は「タグ」、「バッジ」を意味します。 プル型システムにおいて、プロダクトの作成や除外（転送）を許可したり指示したりするための情報の手段です。

情報を伝達するために提示されたオプションにより、情報カードを使用して特定の製造オーダーを次のステージから前のステージに転送することで、無駄のない生産ラインを完全に管理できます。

このような生産的なシステムの開発者はトヨタ自動車であり、提示されたアイデアはジャストインタイム方式を実用化する最初の試みの 1 つであると説明しています。 カンバン システムによれば、生産は次のルールに従って実行されます。つまり、企業の各部門には、注文を完了するために必要な明確に定義された期限までに、特定の数量のリソースが供給されます。

プロセスの詳細

提示された方法のスキームは非常に単純ですが、生産プロセスの組織化に非常に効果的な影響を与えます。 企業の部門にリソースを供給した後、進行中の作業の必要量の詳細な計算が実行されます。これは最後から2番目の段階から直接行われます（したがって、完成品の注文は最終段階です）。プロセス）。 同様に、最後から 2 番目の段階から、前段階に対して特定の量の半製品の要求が行われます。

このように、ある現場での生産規模は、次の生産段階のニーズに応じて形成されます。 近くにある生産プロセスの 2 つの各段階の間に、二重タイプの接続が確立されるのは論理的です。

  1. n ステージから n-1 まで、必要な量の進行中の作業が要求されます (「プル」)。
  2. 第 n-1 段階から第 n 段階まで、必要な量の物的資源が送られます。

情報伝達ツール

カンバンとは何かをよりよく理解するには、このシステムで情報を送信するためのツールが特別なカードであり、次の 2 つのグループに分類されることを理解する必要があります。

  1. 製造オーダーに直接関係するツール。 この種のカードでは、生産プロセスの前段階で生産しなければならない部品の数が最初に示されます。 これらは、生産の n 番目の段階から n-1 段階に送られ、これらのサイトの生産プログラムを開発する主な理由として機能します。
  2. 選択ツールには、前の組み立て段階で取得する必要がある必要な材料リソース (半完成品、材料、部品などが含まれる場合があります) の量に関する情報が含まれています。 この種のカードには、n-1番目からn番目の生産工程までに実際に受け取った資源量が表示されます。

カードは企業の内部インフラストラクチャに関連して循環するだけでなく、協力をサポートする支店や企業間でも循環する可能性があることに注意することが重要です。

カンバンの効果的な使用方法 - カンバンとは何ですか?

トヨタ自動車の大野耐一社長は、かんばんカードを最大限の効率で使用するための多くの原則を開発しました。

  • 生産活動の後続の操作では、カードで示された部品の量が前の操作から削除されます。
  • 手前の生産作業は、特定のカードに示された数量と順序で部品を作成することによって実行されます。
  • カードがないと作成できないパーツはありません。 この規定により、製品の過剰な移動だけでなく、過剰生産の削減も可能になります。 したがって、流通しているカードの量は在庫の最大量に等しくなります。
  • カードは製品の製造の注文です（いずれの場合も、製品は対応するカードに添付されます）。
  • 欠陥のある部品を下流工程に渡すことはできません。 この規定により、可能な限り欠陥のない製品の製造が可能になります。
  • カードの数を減らすと、カードの感度レベルが上がります。 これにより、既存の問題点が明らかになり、効果的な在庫管理が行われます。

カード利用の特徴

実は、カンバン管理は専用のカードを使用するという、ある仕組みに従って行われているのです。 したがって、使用中は、問題のシステムの絶対的な可視性と最大限の安全性を確保するための要件を完全に実装する必要があります。カードの紛失や混合は完全に排除されます。

専門家は、カンバン システムに最大の生産性を提供できる効果的なツールを開発しました。 従業員は職場で複数の異なるツールを使用することが多いため、この方法のボードはアクティブなカードの収集ポイントとして機能します。 したがって、メーカーに送られるカードは制御基板上に置かれます。 そして、新しく受け取ったカードツールが「開始」フィールドに到達すると、対応する部品番号のカードのセット全体が転送され、さらなる生産プロセスが実行されます。

カンバン方式を使用する利点 - それは何ですか?

これを使用する企業は、物的リソースの供給を毎日 (多くの場合、1 日に数回) 受け取ります。 これにより、年間約 100 ～ 300 回の生産在庫を完全に更新することが可能になります。 カンバンを MRP や MAP などのシステムと比較すると、この場合、更新頻度は約 10 倍になります。

他の生産性の低いカンバン方式に対する絶対的な利点を明らかにする例を用いて、カンバン方式を評価することをお勧めします。 したがって、トヨタ自動車株式会社は、1976 年には 1 日 3 回、1983 年には 10 分ごとに、多くの生産拠点の 1 つにリソースを供給しました。

カンバンは、スーパーマーケットでの作業によく使用されます (この目的のために特別に形成された在庫)。 したがって、消費者は、上で述べたように製品の量を示す選択カンバンをスーパーマーケットに送り、スーパーマーケットは指定された数の製品を消費者に転送する。 同時に、スーパーマーケットはサプライヤーに補充カンバンを送り、その後サプライヤーはスーパーマーケットに商品を転送します。

メソッドの基本的な要素

カンバン システムの最も重要なコンポーネントは次のとおりです。

  1. カードだけでなく、生産、輸送、供給スケジュール、技術地図などを構造に含む情報複合体。
  2. ニーズのコントロールと専門的なことに直接関係する複合体。
  3. 製品の総合的（TQM）および選択的（Jidoka）品質管理を可能にする複合体です。
  4. 生産の絶対的な平準化を保証する複合施設。

提示された要素を組み合わせて使用​​すると、最短の生産サイクル、高レベルの資産回転率 (在庫を含む) を達成できるだけでなく、両方の生産にかかる保管コストを排除または最小限に抑え、もちろん最高の品質を実現することができます。生産プロセスの各段階で製品を製造します。

このシステムの欠点とその使用結果

他の開発と同様に、ジャストインタイム システムにはいくつかの欠点があります。 まず、特定の製品の生産段階間で高いレベルの一貫性を組織することが難しいということです。

第二に、生産プロセスが中断され、それに応じて製品の販売が中断される重大なリスクがあります。 それにもかかわらず、問題の方法の適用に関連した世界の慣行を詳細に分析したところ、提示されたシステムにより生産在庫を半分に、在庫を8％削減でき、運転資本と在庫の回転率が大幅に加速することが示されました。当然、完成品の品質も向上します。

カンバンの使用は生産プロセスにとどまらないことに注意することが重要です。 したがって、このシステムは、オフィスやプロジェクトの活動、プログラミング (かんばん開発の複合体全体があります)、さらには個人的な成果 (個人タイプのかんばん) を達成する際にも積極的に使用されています。

カンバン システムは 1950 年代にトヨタ自動車の生産ラインで始まり、その後オフィスに移行し、プロジェクト マネージャーにとって重要なツールになりました。

実践の無限の柔軟性とスタッフの自己組織化の機会により、他のアプローチでは機能しない効率を達成することが可能になりました。 これは、カード自体がシステムの名刺となった場合に当てはまります。カンバンを導入した組織の内部通貨としての地位を確立しました。

起源

無駄のない製造コンセプトと同様に、カンバン システムもトヨタのマネージャーによって開発されました。 このシステムの作者である日本人エンジニアの小野耐一氏は、買い手自身が必要な商品を選ぶというアメリカのスーパーマーケットの運営原理にインスピレーションを受けました。 トヨタ社内における「スーパーマーケット」の役割は倉庫が担っていた。

そこでは、信号カード (これが「カンバン」を日本語から直訳したものです) があり、労働者は信号カードを交換し、自分たちの手で生産プロセスを規制しました。

カードは部品が入った容器に取り付けられていました。 これらのタグには、部品の数と数量、部品を発送した部門、および部品がどこに到着するかに関する情報が含まれていました。

機械の設置と組み立てに直接関与する下流の作業員は、倉庫への依頼を記した「かんばん」が貼られたコンテナから部品を取り出しました。 カードは抜き取られ、空箱とともに運送業者によって倉庫に移送された。 そこでは、別の従業員がすでにスペアパーツの新しいコンテナを準備していました。そのコンテナには、生産されたスペアパーツに関する情報が記載されたタグである製造「カンバン」が取り付けられていました。

生産カンバンは倉庫用の依頼カンバンに置き換えられ、上流の部品生産ラインに送られました。 したがって、カードに示されている数の部品が正確に生産されました。 新しいスペアパーツが入ったコンテナが組立ラインの輸送業者に運ばれました。

カンバンの原則

トヨタの経営者は、6つの体制形成ルールを策定しました。

  1. 下流の作業員は、カンバンに示されているのと同じ数の部品を倉庫から取り出します。
  2. 上流の代表者もカードに厳密に従ってスペアパーツを供給します
  3. カンバンがなければ何も生産されず、移動もされません。
  4. カンバンは必ず部品に添付する必要があります
  5. 欠陥部品はシステムに使用されていません
  6. かんばんカードの数を減らすと、経営陣の変化への対応力が高まります。 ただし、どうしても必要な場合を除き、設定されたカードの数を変更しないでください。
カンバンは「プル」システムです。 これにより、待機コストを排除する一定のフローと、過剰生産のリスクを軽減する最小限の仕掛品 (WIP) との間のバランスが生まれます。 RVP はカードを使用して制御されます。カードの番号は固定されており、カード内の指示が下流の実行者をガイドします。

必須タグのルールは、エネルギー保存の法則のように機能します。

RVP 制限は、カンバン カードの枚数に比例して作成され、販売レベルと現在のプロセスの統計的変動に応じて計算されます。 タグの最大数（システム内の同じ「エネルギー」）によって、いつでも RVP の上位レベルが決まります。 RVP はプル原理によっても制限されます。つまり、上流の生産速度は下流の速度に依存します。


グラフは、システムの基本要素の 1 つがカイゼン文化であることを示しています。 自律的なプロセスと標準のバリエーションにより、経営者は継続的な管理から解放され、従業員のパフォーマンスの向上に集中できます。

ITにおけるカンバンの応用

カンバンは生産ラインで価値を提供し続けていますが、ソフトウェアの世界にも進出しています。

期限、説明またはプロセス番号、および演奏者の名前に関する情報を含むカードのみが、スペアパーツの入ったコンテナではなく、列が並んだボードに取り付けられるようになりました。

  • バックログ - 完了する必要があるタスク
  • 現在開発中のタスク
  • 完了したがまだテスターに​​転送されていないタスク
  • テスト部門に転送する準備ができているタスク
  • プロジェクトマネージャー（PM）がレビューするタスク
  • 完了したタスク

通常、列の上に数字が書かれています - 制限、その中のプロセスの最大数を示します。 バックログ制限は、先行時間に応じて計算されます。 システムで 5 つのジョブが進行中で、それぞれのジョブが完了するまでに平均 1 日かかる場合、バックログは 5 に制限できます。


上記の構造は厳密ではありません - プロジェクトの内容に応じて、即興のスピーカーを追加することもできます。多くの場合、タスクの実行前にタスクの準備の基準を決定する必要があるカンバン システムがあります。 次に、英語で次のように呼ばれる 2 つの列が表示されます。 特定(パラメータを指定) および 実行する（働き始める）。

  • もっと 優先キューのある列を追加できます。実行者が暇なときは、この特定のタスクの列を空にし、他のタスクを引き受ける必要があります。
  • 完了していないタスクはバックログに戻されるか、スキームから取り消されます。
  • カンバンはマルチタスクを推奨していないため、 1 つの実行者に対してプロセス制限が設定されます。
  • いくつかの作業を開始するよりも、完了した作業の方が望ましいです。
  • 最初の仕事がブロックされた場合でも、2 番目の仕事を引き受けることができます。
  • タスクを完了するまでの時間のバランスをとる必要があります。期間が短すぎると品質に影響します。 制限が過度に拡張されると、チームのリソースが無駄になり、プロセスのコストが増加します。


たとえば、タブレットや巨大なモニターではなく、カンバン ボードがあらゆる場所で使用されるのはなぜでしょうか? システムのファンがこの質問に答えるように、通常のボードには 2 つの利点があります。それは、シンプルで視覚的な制御が可能であるということです。 変更は簡単で、チームメンバー間での触覚的で社会的な相互作用が得られます。

カンバンのメリットとデメリット

カンバンには次の利点があります。

  1. 計画の柔軟性。 チームは現在の仕事だけに集中し、タスクの優先順位はマネージャーによって設定されます。
  2. 開発プロセスへのチームの関与が高い。 定期的な会議、透明性の高いプロセス、自己組織化の機会を通じて、従業員は団結し、真の関心を示します。
  3. サイクル期間が短くなります。 同じようなスキルを持っている人が複数いる場合は期間は短縮されますが、1人しかいない場合はボトルネックが発生します。 したがって、従業員は知識を共有し、サイクルタイムを最適化する必要があります。 そうすれば、チーム全体が滞っていた作業を解決し、スムーズな流れを取り戻すことができます。
  4. ボトルネックが少なくなります。 RVP 制限を使用すると、注意力、人材、スキルの不足によって発生したボトルネックや問題領域をすぐに見つけることができます。
  5. 視認性。 すべてのワーカーがデータにアクセスできると、ボトルネックを特定しやすくなります。 カンバン チームは、カード自体に加えて、通常、制御フロー グラフと累積フロー グラフという 2 つの一般レポートを使用します。

実際、システムは非中核生産領域で良好にパフォーマンスを発揮します。

  • ソフトウェア サポートまたはヘルプ デスク チーム。
  • カンバンは、明確な計画がなくても、開発が積極的に進められているスタートアップを管理する場合に効果的です。

カンバンには次のような欠点もあります。

  1. このシステムは 5 人を超えるチームではうまく機能しません
  2. 長期的な計画を立てることを目的としたものではありません。

スクラムとの違い

スクラムは、アジャイルかんばんと同様に柔軟な方法論であり、IT 分野でもよく使用されます。 それらの違いは一見しただけではわかりません。 どちらのアプローチにもバックログが存在するなど、多くの類似点があります。

スクラム

カンバン

ペース

固定期間の反復可能なスプリント

連続プロセス

リリースリリース

プロジェクトマネージャー (プロダクトオーナー) による承認後の各スプリントの終了時

フローは中断されることなく、またはチームの裁量によって継続されます。

役割

プロダクトオーナー、スクラムマスター、開発チーム

PM が率いるチーム、場合によってはアジャイル カンバン トレーナーが関与する

主な指標

チームスピード

リードタイム

変更の受け入れ可能性

スプリント中の変更は、タスクの見積もりが不正確になる可能性があるため、望ましくありません。

変化はいつでも起こり得る

IT分野での応用例

Microsoft から直接: カンバンがソフトウェア開発にデビュー

情報技術業界におけるカンバン原則の使用は、わずか 10 年ほど前に始まりました。 ソフトウェア開発者にカンバンを普及させた主要人物の 1 人である David Anderson は、2005 年に Microsoft のコンサルティングを行いました。 彼らは、内部アプリケーションのエラーを排除する自分たちの部門である XIT Sustained Engineering の仕事に不満を抱いていました。 報告年度の初め、この部門は部門の中で最悪の成績でした。 バックログが許容サイズを 5 倍超過し、1 つのリクエストを処理するのに時間がかかりました。 リードタイム- 通常は 5 か月かかりました。

新しい PM は、アンダーソン氏の相談に乗って、問題のある部門の生産性を 9 か月間で 155% 向上させました。 リードタイム 5 週間になり、バックログは通常のサイズに戻り、タスクは予定どおりに 90% 完了しました。 これらすべての結果は、新入社員の関与を最小限に抑えて達成されました。スタッフは同じ方法を使用してソフトウェアのエラーを修正し続けました。 仕事を組織するためのアプローチが変わっただけです。

興味深い事実: XIT の流れを変えることに尽力したプログラム マネージャーのドラゴス ドゥミトリウは、アンダーソンの本に魅了されました。 驚いたことに、彼は前日に就職したマイクロソフト社でソフトウェア カンバンの思想家に会いました。 ドゥミトリウはアンダーソンに自分の仕事を手伝ってくれるように頼み、アンダーソンは彼の本の原則を実践することに同意した。

Dumitriu は、バックログに 80 件のリクエストが蓄積されている 3 人の開発者と 3 人のテスターで構成される部門を発見しました。 この役職の要件には、ASP テクノロジを使用する能力、SQL Server を使用した管理、および MS Project Server の知識が含まれていたため、PM 自身が一時的に任命されました。 上司たちは、このポジションを、プログラミング方法を知っており、レポートを作成し、バックログの負荷を予測する必要がある「技術者」であると考えていました。 当時は、膨大な量のデータが収集されれば、その部門の問題が特定されるだろうと信じられていました。 ドゥミトリウはそれほど「技術者」ではありませんでした。

しかし、彼とアンダーソンは XIT のパフォーマンスの分析を開始すると、部門のスピードに悪影響を及ぼしている主な要因をすぐに特定しました。

  • リクエストの実行による結果 (ROM) を予測するのに時間がかかりすぎました。 開発者とテスターは両方とも、必要な計算、コード レビュー、完全なドキュメントの実行に丸 1 日を費やす必要がありました。 平均して、1 日に 1 件のリクエストが受信されました。 PM の推定によると、部門の生産性の 40% が ROM に費やされていました。
  • より高い価値のリクエストが優先されました。 XIT は注文の費用から資金を受け取りました。 要求の優先順位は毎月、顧客である他の部門のマネージャーと部門マネージャーの会議で議論されました。 現在の速度でバックログが急増し、月あたり 6 ～ 7 件のリクエストしか処理されなかったとき、他のリクエストの優先順位は時間の経過により常に変化していました。 それらの多くは、翌月にすら及ばない大幅な「後」に延期されました。
  • ROM 段階では、リクエストの半分が排除されました。 プロジェクトの中には、大きすぎて他の部門に移管するプロジェクトとして再認定されたものもあれば、費用がかかりすぎて単純にキャンセルされたものもあります。 一部のリクエストは実装に時間がかかりすぎるため、開発に取り入れられませんでした。 したがって、部門の生産性の 40% がリクエストの分析に費やされ、そのうちの 50% は拒否されました。 労働資源の約 15 ～ 20% が無駄になりました。
  • リクエストの準備作業は、実装が始まるまでに何か月もかかる可能性があります。 この間に、ROM 段階での計算が失われたり忘れたりする可能性があります。 特に、分析を開始した開発者と同じ開発者によって実装が実行されたわけではない場合。

問題を抱える Microsoft 部門向けのカンバン ソリューション

  1. ドゥミトリウ氏とアンダーソン氏は、経営陣や顧客マネージャーとの会話の中で、ROM ステージを放棄することを主張しました。 計算は実装の直前に同じ実行者によって行われたため、「新鮮な」ままでした。
  2. 要望の優先順位付けは月例会議ではなく、状況に応じて電話やメールで行った。 バックログにある 80 個のタスクを顧客ごとに分類しました。 後者は、最初に完了する必要がある主なクエリを強調するように求められました。
  3. XIT の資金調達は固定化されました。
  4. リクエストのコストは考慮されなくなりました。
  5. PM はカンバン ボード上のバッファを入力しました。 開発者は、承認されたタスクと完了したタスクという 2 つのゾーンから作業を行いました。 バッファーには 6 つのリクエストがあり、5 つが処理されました。 「テスト待ち」バッファから選択されたテスター。 コードの変更を必要としない一部のタスクは、開発者を迂回してそこで終了しました。 リクエストを単一タスクのプロセスに分割することで、PM は状況をより詳細に制御できるようになり、顧客に透明性を提供できるようになります。 バッファの導入によりリードタイムが短縮されました。 予測可能なシステムの下では、顧客は次に誰のリクエストをバッファリングするかをより適切に決定できます。
  6. リクエストが大きすぎる場合や費用がかかる場合は、即座に決定が下されました。 開発者が 15 日以内にタスクを完了する準備ができていること、または変更に価値があることを確認した場合、サイズやコストに関係なくリクエストが受け入れられました。
  7. 部門内の流れを観察した結果、PM は、より多くの仕事を抱えている開発者を優先してスタッフ構成を変更する必要があるという結論に達しました。 変更は 2:1 の比率で実行され、4 人の開発者と 2 人のテスターが XIT で作業を開始しました。



2005 年末には、この部門の生産性は 155% 向上しました。 XIT の作業をさらに改善するために、開発者 1 名とテスター 1 名の 2 名の従業員が XIT に雇用されました。 バックログ内のリクエストの数は 10 に減少し、ある開発者は四半期ごとに 11 リクエストを一貫して処理し始めました。 平均すると、四半期あたり 56 件のリクエストが完了しましたが、以前は 11 件でした。 リクエストのコストは 7,500 ドルから 2,900 ドルに下がりました。

コービスでのお申し込み

Microsoft で成功を収めた Anderson は、2006 年に新たな課題の解決を開始しました。 現在、彼はまだ MS を辞めていないビル・ゲイツの別の会社であるコービスで働いていました。 コービスの活動の 1 つは写真のライセンス供与でした。 当時、約 3.5 千枚の画像のデータベースを備えた、世界で 2 番目に大きな写真ストックでした。

アンダーソンの仕事は、会社のメジャー リリースをスピードアップすることでした。 退職までの間隔は 3 か月で、さらに長くなる可能性があります。 リリース計画について話し合うだけでも、経営陣は 2 週間かかりました。 マイナー リリースまたはアップデートを 2 週間ごとにリリースするように手配する必要がありました。 同時に、主要なリソースを主要プロジェクトの作業に振り向ける必要がありました。

コービスのオフィスにはカンバンボードが設置され、アンダーソンはそこで毎日チームとコミュニケーションをとりました。 PM の目的は、プロセスの視覚的な制御を改善し、自己組織化を促進し、実行者の個人的責任を高めることでした。 カンバン システムは、管理の監視を軽減し、生産性を向上させることも目的としていました。


色とりどりのカードやグラフに加えて、「ゴミ箱」がボード上に表示され、大きすぎるタスクはそこに送られました。


写真は公式より
ソフトウェア システムのエンジニアリングを継続するためのカンバン システム (David J Anderson 著)

カンバン方式により、どこで流れがスムーズにならなくなり、どこで遅延が発生するか、いわゆるボトルネックが明確になりました。 チームとの素早いディスカッションにより、現在の問題を特定することができました。 たとえば、テストは 3 日間続き、リリース日に悪影響を及ぼしました。 3 人の従業員がチームを組んで、時間を 1 日まで短縮する方法を見つけました。

ボトルネックとは、リソースの制限や人々の生産性によってタスクの流れが大幅に低下する、企業の運用スキームまたはアルゴリズムのセクションです。 労働者不足、インターネットの状態が悪い、ディレクターの休暇中などにより、タスクの完了が妨げられたり遅れたりします。

カンバン カードの制限は経験的に 2 回設定されました。 「開発準備完了」列の制限が引き上げられました。 新しい列「テストの準備完了」もあります。 ダウンストリームへのリクエストの多くは誤って作成されており、不必要な時間の無駄が発生していました。 したがって、PM は上部フローの動作を検査し、エラーを発見しました。

リクエストの処理には 100 日かかる場合がありますが、それでも計画どおり、リリースは 2 週間ごとに公開され始めました。 号の内容については発行の5日前に決定しました。 Microsoft の XIT 部門の場合のように、生産性を優先してカウントの慣行が放棄されました。 タスクは「遅延コスト」またはリソースの可用性に基づいて優先順位が付けられました。

カンバン システムは、アンダーソンの目標達成に貢献しただけでなく、チーム内の雰囲気も改善しました。 共同で議論し、プロセスを可視化したおかげで、従業員はお互いの信頼を築きました。 スタッフもカイゼン、つまり継続的改善の実践に参加しました。

カンバン方式とは何ですか?また、カンバン方式はタスクを時間通りに完了するのにどのように役立ちますか?

継続的なマルチタスクと多数の顧客の状況では、遅かれ早かれ、どのシステムも過負荷になります。 締め切りは守られなくなり、期待は満たされなくなり、システムは混乱に陥ります。 今日は、カンバンなどの方法論について知っていこうと提案します。 このアプローチは、リソースを効果的に割り当て、すべての問題を解決することを約束します。 確認しよう。

カンバンの歴史の瞬間

かばんのアイデアの基礎はトヨタ自動車によって発明されました。 ある自動車メーカーは、生産ラインの在庫と生産能力の不適切な割り当てにより、多額の損失を被っていました。 一部の運用ステージはアイドル状態になる可能性があり、一部は過負荷になっている可能性があります。

1959 年に、ラインのすべてのセクションのバランスを可能にする生産管理システムが提案されました。 基本原則は、各段階で作業員が必要な部品数を記載したカードを掲示し、それがラインに渡されるというものでした。 生産ラインに沿って続く各作業員は、カードに割り当てられているのと同じだけ前の作業員から部品を取り出しました。

このように、すべての部分にカードがあり、余分なものはありませんでした。 その結果、その地域の在庫は増加せず、後続の各作業員は必要な数の部品を正確に受け取ることができました。

カンバンとは何かを定式化して、インターネット製品の開発に適用してみましょう。

カンバンは、情報カードを使用して生産のすべての段階で注文を伝達する無駄のない製造管理システム (日本語: 「シグナル」/「カード」) です。 簡単に言うと、私たちは製品のアイデアから店頭に並ぶまでの全経路を追跡します。

上はカンバンボードです。 これはタスクのステータスを表示するための主要なツールです。 主な原則: 特定のタスクが生産プロセスのどの段階にあるかを確認します。 さらに、時間はすべての領域で追跡されるため、いつでもシステム内で「 」を見つけて操作できます。

プロジェクトの特性に基づいて列の数を自分で決定します。 これらが製品が通過する主な段階であることが重要です。 上の例は、オンライン製品が通過する主な段階をプラスまたはマイナスしたものです。

この方法論の応用範囲は非常に広いです。 カンバンは、プロジェクトの実施、販売管理、生産ライン、IT 開発、さらには自分自身の生活を整理するためにも使用されます。

読書を中断して申し訳ありません。 私の電報チャンネルに参加してください。 記事の新鮮な発表、デジタル製品の開発、グロースハックなど、すべてがそこにあります。 あなたを待っています！ 続けましょう...

カンバンの原則

  • タスクの視覚的な表示。 すべてのタスクはカードの形式で提示され、ボードに反映される必要があります。 タスクのステータスを更新することは非常に重要です。 たとえば、開発者がコードを準備してテスト用に送信した場合、タスク カードは適切な列に移動する必要があります。 したがって、チームメンバーはいつでも、タスクがどの段階にあるかを確認できます。
  • 生産の各段階における WIP (進行中の作業または同時に実行される作業) 列の制限。 遅かれ早かれシステムがタスクの流れから「窒息」しないようにするには、制限を設定する必要があります。 たとえば、上記の Analisis 列 (分析) のカンバン ボードでは、2 人が作業していますが、彼らが処理できるタスクは 2 つまでです。システムの後続のステージがアイドル状態になるため、それ以上ロードしても意味がありません。 列の制限は経験的に選択されます。
  • 達成されていないタスクに焦点を当てます。 タスクが記載されたボードを見るときは、まず、いずれかの列に「ハングアップ」しているタスクに注意を払います。 いずれかのステージに最も時間がかかる場合は、可能であればリソースを再配分するか人を追加してください。
  • 継続的改善。 システム内の負荷のバランスをとれば、プロセス全体の監視が容易になります。 サイクル タイム (タスクが別の列に滞留している時間、および To do に入った瞬間から Done が解放されるまでの時間) を測定します。 システムの負荷を変更し、すべての段階を完了するのにかかる時間を短縮します。
  • 細部にまで気を配ってください。 たとえば、開発者が定期的に作成したコードがテストに合格せず、改訂のために返却された場合、より高品質の製品がテストされるように開発の品質を向上させるオプションがあるのではないでしょうか?

カンバンのアプローチは理想主義的に見えるかもしれませんが、その原則が結果を生み出すことを私は保証します。 まず第一に、方法論を状況に適応させてから、システムを磨き上げる必要があります。

カンバンツール

または、カンバンボードを管理する場所。

  • Excel テーブル
  • ステッカー付きボード
  • またまた妄想…

実際には、たくさんのオプションがあるので、Google で検索してインスピレーションを得ることができます。 重要なことは、このボードがあり、プロセスの参加者全員が現在タスクで何が起こっているかを確認できることです。

カンバンボードの例

こちらは壁に貼られたボードで、各タスクが付箋に反映されています。

あるいは、Trello のようなクラウド サービスである可能性もあります。

作業にどのようなツールやオプションを使用するかについてはさまざまな意見がありますが、これは主に好みの問題です。 さまざまな解決策を試して、最も気に入った解決策を見つけてください。 重要なのは、カンバンの使用を開始することであり、可能な限り美しいボードを使用することに固執しないことです。

私の意見は次のとおりです。ブレインストーミングやオフラインでのケースの作業には、ステッカーを貼った通常のボードが適しています。 ただし、日常の作業では、もちろん、Jira、Kanbantool、Trello などのクラウド ソリューションを使用する必要があります。 このタスクでは、チーム全体がタスクにコメントを追加したり、列ごとにタスクを移動したりすることができます。

ニュアンス・感想

インターネット製品について話す場合、カンバンは機能し、役立ち、改善されますが、考慮する必要がある懸念事項やニュアンスがいくつかあります。

  • おそらく、列に WIP 制限が導入されると、プロジェクト管理チームは少し不安になるかもしれません。 結局のところ、開発者やテスターなどが並行して解決できるタスクの数をどうやって判断できるのでしょうか? 制限を導入しても、ただ落ち着くだけだったらどうなるでしょうか?

ほら、人が完全に負荷をかけられていないとしても、これは悪いことではありません。 彼は行われた作業を研究および分析し、欠点を見つけて修正し、さらには休むことさえできます。 さらに、プロセスの他の部分 (列) から仲間を助けることができます。詳細は以下で説明します。

  • カナバンの専門家によると、このシステムは部門を越えたチームで理想的に機能します。 まあ、そんな感じで、何もすることがないなら、同僚を助けに行きましょう。 確かに、開発者がテスターに​​、またはその逆に、システムアーキテクトがデザイナーを支援できるチームを編成するには、多額の資金を投じる必要がありますが、それだけの価値があるのでしょうか?

もちろん、チームメンバーが互いに学び合い、何かが起こったときに何らかの形で助けられるのは素晴らしいことです。 しかし、この条件を満たすためには、できれば近くのどこかに座って常にコミュニケーションをとる小規模なチームが必要です。 大規模なプロジェクトでは、このような経験の交換を再現するのは困難です。

したがって、静かな時間があれば、より自分のスキルを磨く傾向があります。 自分がやったことを振り返り、どうすれば改善できるかを考え、役立つ記事を読みましょう。 人間は生き物であり、ベルトコンベアの歯車ではありません。

合計

カンバン方式について見てきましたが、プロジェクトにカンバン方式を適用する方法が理解できたと思います。 プロセスを主要な段階に分割し、得られた知識に基づいてシステムを最適化するようにしてください。