かんばん (ソフトウェア開発)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/10/10 01:59 UTC 版)
| ソフトウェア開発工程 |
|---|
| 中心となる活動 |
| パラダイムとモデル |
| ソフトウェア開発方法論とフレームワーク |
|
| 開発支援 |
| プラクティス |
| プログラミングツール |
| 標準と機関 |
|
| 用語集 |
|
かんばんはソフトウェア製品を開発するための方法である。さらに、かんばんは、ソフトウェア開発者に過剰な負荷をかけずに、ジャスト・イン・タイムでのソフトウェアリリースを強調したプロセスでもある。このアプローチでは、顧客へのデリバリーに必要なタスクの定義を行い、そのタスクをソフトウェア開発プロジェクトの関係者が理解するために、プロセスを視覚化する。そして、タスクの作業者は、作業をキューから引っ張って（プル）していく。
かんばん
ソフトウェア開発におけるかんばんは、大きく2つの部分に分けられる。
- 方法論としてのかんばん - ソフトウェア開発におけるかんばんシステムのこと。インクリメンタルなアプローチであり、組織に合わせてプロセスを進化する方法。
- ツールとしてのかんばん - 視覚化したプロセス管理システムのこと。これにより、何を開発するか、いつ開発するか、どれぐらいのコストで開発するかを発信する。
方法論としてのかんばんは、英語圏において「Kanban」と大文字から始まる言葉で説明されている。そして、シグナルとなるカードは「kanban」、シグナルカードによって実現したプル型システムは「kanban system」と呼ばれ、小文字から始まる言葉で区別して表記されている[1]。
方法論としてのかんばん
方法論としてのかんばんは、デイヴィッド・アンダーソン（David J. Anderson）によってまとめられた理論である[1][2]。かんばんは、作業進捗とともに変わるものであり、プロセスを進化するアプローチであり、組織に合わせてシステム（仕組み）を変化する。かんばんでは、Work-in-progress（WIP：まだ完成していない作業を指し、日本語だと製造業で使われる仕掛品に該当する）を制限したプル型システムを実現する。プル型システムの核となるメカニズムによって、システムの運用やプロセスの問題を明らかにし、システムの継続的な改善に必要な協力作業を促す。このプル型システムの一つの例が、かんばんシステムであり、WIP制限されたプル型システムという一般的な形を経て、かんばんシステムとなった。
基本原則
以下の基本原則が、かんばんの根底にある。
- 現在、何をしているかを理解することから始める
- かんばんは、特別な役割やプロセスの形を規定していない。よって、かんばんソフトウェア開発プロセスや、かんばんプロジェクトマネジメントメソッドといったものは存在しない。かんばんでは、開発現場に存在する役割やプロセスの発見から始め、継続的かつインクリメンタルにそれらを刺激する。そして、現場のシステムを進化させ、変化を起こしていく。
- インクリメンタルに進化させ、変化を追求していく
- 組織（またはチーム）は、継続的、かつインクリメンタルにかんばんを進化をさせ、変化を起こしていくことに同意しなければならない。この同意が、システムの改善につながり、改善を支える存在になっていく。広範囲にわたる改善から発生する変化は、より効果的に見える。しかし、組織には抵抗勢力や、変化に対する恐怖が存在する場合があるため、失敗する可能性も高くなる。かんばんは継続的に、小さくインクリメンタルな進化を促進し、現場のシステムを変化していく。
- 現状のプロセス、役割、責務、職位を尊重する
- 現在の組織には、容認されている必要な作業や、維持すべき価値といったいくつかの要素を含んでいる。組織に所属する者は、将来の変化に対応するために、変化への恐怖を排除する方法を探し求めなければならない。現在の役割、責務、職位に同意することによって、変化が起き始めた時に発生する恐怖を除外する。これによって、かんばんを率先するための、幅広い理解が獲得可能になるだろう。恐らく、広範囲にわたる別のアプローチとかんばんを比べると、かんばんは役割や職位や責務の変更を促していく。さらに、一般職の大規模な棚卸しによって、個人がかんばんの価値に気がつくのを手助けする。
- すべての地位でのリーダーシップを求める
- 個々の貢献者から地位の高いマネジメントまで、組織内の全地位においてリーダーシップを発揮し、促進されるべきである。
6つのコアプラクティス
デイヴィッド・アンダーソンは、方法論としてのかんばんの成功例について観察を続けてきた結果、5つの核となる特性を定義した。その後、関係するプラクティスやその拡張として、6番目の特性が追加された。
- 可視化する
- 知識労働のワークフローは、目に見えないが内在するものだ。よって、ワークフローを可視化（視覚化、可視化）することが、どのように作業が進んでいるかを理解するための核となる。ワークフローの理解なしで、正しい変化を起こすのはとても難しい。
- ワークフローの可視化を行う場合、壁をステージ（縦の列）に分けて、そこにカードを貼りつければよい。この方法が一般的な可視化手段となる。壁を区切って表現して作ったステージは、ワークフロー内の異なった状態や段階を表している。
- WIPを制限する
- 流れを管理する
- ワークフロー内にあるそれぞれの状態を通した作業の流れは監視、測定、レポートされるべきだ。継続的でインクリメンタルな進化から生まれる変化を、既存の仕組みに対して積極的に流れを管理することによって、仕組み上の良い面や悪い面が評価される。
- 明確なポリシーを作る
- プロセスの機能が明確になるまでは、プロセスについて議論を続けるのは難しく、不可能だとも言える。物事の仕組みや、作業が実際どのように完了しているかについて明確な理解がないと、どんな問題の議論でも、感情的になったり、信頼できない情報や主観に偏る傾向があるからだ。よって、明確な理解を持つことで、より合理的に、実験に基づいた、目的のある課題の議論が可能になる。これは、改善提案の合意を導くような形になるだろう。
- フィードバックループを実現する
- 作業の流れをレビューするためのコラボレーションや、需要と供給能力の測定、注目すべき出来事を説明している話に関連付けられたメトリクスや指針は、進化から生まれる変化を可能にするために必要不可欠だ。一般的に、運用レビューといったフィードバックを実現していない組織だと、局所的でチームレベルのプロセス改善を超えることができない。結果的に、かんばんの生み出す価値に気がつけなくなり、どこか別の機会に知ることになる。
- コラボレーティブに改善し、実験的に進化する（モデルや科学的な方法を利用する）
- かんばんメソッドは小さく継続的でインクリメンタルな進化を促進し、それによって発生する変化を支える。チームが作業、ワークフロー、プロセスやリスクについて、理論を共通理解したときに、チームは問題に対する共通の理解力を構築し、合意した改善案の提案を可能にするだろう。
- かんばんメソッドが提案する科学的なアプローチは、継続的でインクリメンタルな進化から生まれる変化を実装するために使われる。かんばんメソッドは、明確な科学的手段を提供しない。
以下の様な共通のモデルがある：
- 制約理論（TOC） (ボトルネックの研究)
- 深遠なる知識（Profound Knowledge™）(変化と変化がプロセスに与える影響についての研究)
- リーンソフトウェア開発
ツールとしてのかんばん
ツールとしてのかんばんは、方法論としてのかんばんによって、組織（システム）を変化させ、変化を促進させるためにツールとして使われる。ジャストインタイム生産システムで使われるカンバンは、前工程へのシグナルとして使われるため、物理的なシグナルカードを意味している。しかし、ソフトウェア開発におけるかんばんの場合、目に見えない作業（ワークアイテム）をカードにして運用するため、仮想的なかんばんシステム（Virtual kanban system）とも呼ばれる[1]。
ツールにおけるかんばんは、海外だと「サインボード（signboard）」と訳されることが多い[3]。しかし、国内では以下のように様々な名前で呼ばれている。かんばん、かんばんボード[4]、タスクかんばん、タスクボード[5]、カードウォール[1]、アジャイルかんばん[6]。
ソフトウェア開発において、ツールとしてのかんばんには、いくつかのバリエーションが存在する。
タスクの状態を可視化したかんばん
タスクの状態を「TODO」「DOING」「DONE」という3つのステージに分割し、タスクを情報カードや付箋紙に書いて貼り付けたかんばん[5]。これは、単純にタスクやタスクの状態を見えるようにしたものなので、かんばんシステムではない[1]。
かんばんシステムのかんばん
[6] かんばんという方法論で使われるかんばんは、以下の点に注目をしたツールになっている。
- WIP制限によって、それぞれのステージの量をコントロールしている
- 作業をプル（引き取る、引っ張る）仕組みが存在する
- 開発によって生み出そうとしているユーザにとっての価値（機能など）が、流れとして見える
関連項目
- アジャイルソフトウェア開発
- リーンソフトウェア開発
- トヨタ生産方式
- ジャストインタイム生産システム
- カンバン
- リーン生産方式
- WIP
参照
- ^ a b c d e Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 0-9845214-0-2
- ^ Anderson, David (September 2003). Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall. ISBN 0-13-142460-2
- ^ Kanban (development), Wikipedia
- ^ “かんばんボードによるプロジェクトの見える化”. オブラブ (2012年). 2013年1月10日閲覧。
- ^ a b “プロジェクトファシリテーション実践編：見える化ガイド”. infoq.com (2010年). 2010年5月9日閲覧。
- ^ a b “「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ”. infoq.com (2010年). 2010年5月9日閲覧。
参考文献
- David Anderson(著)「Kanban: Successful Evolutionary Change for Your Technology Business」Blue Hole Press、2010。ISBN 0984521402
- Henrik Kniberg(著)「Kanban and Scrum - making the most of both」lulu.com、2010。ISBN 0557138329
- Henrik Kniberg(著)「Lean from the Trenches: Managing Large-Scale Projects With Kanban」Pragmatic Bookshelf、2011。 ISBN 1934356859
- Henrik Kniberg(著)「リーン開発の現場 カンバンによる大規模プロジェクトの運営」オーム社、2013。 ISBN 427406932X
外部リンク
| 典拠管理データベース: 国立図書館 |
|---|
「かんばん (ソフトウェア開発)」の例文・使い方・用例・文例
- かんばん_(ソフトウェア開発)のページへのリンク
