製品開発部へのカンバン導入記(その1)

更新日

投稿日

 
  技術マネジメント
 
 最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようです。もともとはカンバンは製造現場で使われるのが一般的でしたが、最近はソフトウェア開発やビジネス業務でも使われ始めています。ソフトウェア開発に限って言えば、スクラム(アジャイル)においてスプリント・バックログで管理していたものが、特に大きなソフトウェア開発プロジェクトはカンバンに移行しているようです。
 
 僕が所属するハードウェアを主体とする製品開発部でも、カンバンを導入してから一年以上が経ちました。この一年間は苦労続きだったのですが、いまだに軌道に乗ったとは言えない状態です。今回は、製品開発部へカンバンを導入する際の苦労話しについてです。
 
 もともとは部長の鶴の一声で製品開発部へのカンバン導入が決まりました。誰が、どの製品のどの段階に現在携わっているのか、それをウェブベースのソフトウェアを使ってビジュアルに見た目良く表示してくれる、というソフトウェア商品の売り文句を信じての導入でした。と言うのも、これまでの製品開発は、たとえ同様の製品であっても担当するプロジェクト・マネジャーやエンジニアが異なり、それぞれのチームがそれぞれのやり方で、何千行にも達するタスクをマイクロソフト・プロジェクトで管理していたために、誰が現在何をやっているのか、チーム以外の人にはさっぱり分からなかったからです。
 
 カンバンを導入すると聞いて、僕は”時期尚早”という理由で反対しました。というのは、ハードウェア製品開発は多くの工程が複雑に入り混じっており、ソフトウェア開発のように同質のものや同質の工程の集合体ではないこと、複雑であるが故に、ハードウェア・エンジニア達はそれぞれ自分のやり方で製品を開発していたこと、などが理由でした。そして製品開発工程が標準化していないのに、カンバンを導入するなど早すぎるし、到底無理だと思ったからです。
 
 幸いにも、この時点では僕はまだこのプロジェクトに参加していなかったので、自由に反対意見を言うことができました。もしこのカンバン・プロジェクトに始めから参加していたら、なかなか反対意見は言えなかったと思います。リーンでは以下の順序で、カンバンを使った『価値の流れ』を作ります。
 
(1) 価値の定義
(2) 価値(物と情報)の流れ図を作る
(3) ムダを無くし価値が流れるようにする
(4) 価値を引き出す(プル)
(5) 完全を目指して改善を繰り返す
 
 カンバンを使うのは四番目の『価値を引っ張る(プル)』の段階です。製品開発部の場合、一番目の『価値の定義』ができていないのに、途中を抜かしていきなり四番目のカンバンに手を出すなんて、そもそも無謀なことでした。案の定、最初のカンバンはエンジニアを管理するように作られました。それはまるでエンジニアに割り当てられた仕事をチェックリストで管理するようなものでした。「チェックリストを作るなら、何も高額なカンバン・ソフトウェアなど使う必要なんてどこにも無い」と思ったものです。
 

1. 価値の定義

 

(1) 製品開発の価値

 
 最初のカンバンは大失敗でした。色鮮やかな数百枚というカンバン・カードが、所狭しとカンバン・ボードに散らばったKaだけで、だれも仕事を管理することができなかったからです。最初のカンバンが混乱を極めた頃、僕もこのプロジェクトに参加することになりました。
 
 僕はまず、価値の定義から始めました。価値とは”顧客がお金を払っても良いと思う物やサービス”のことです。製品開発部の場合、設計する PCBA 基板や機械装置が顧客にとっての価値となります。顧客はそのような製品に”お金を払っても良い”と思うのであって、どのエンジニアがどんな仕事をしたかなど、まったく興味はありません。
 
 そこで最初のカンバンを破棄して、新たに顧客にとっての価値をもとにした新しいカンバンを作り直し始めました。
 

(2) カンバンの目的

 
 なにもカンバンだけが価値の流れを管理するためのツールではありません。他にもプロジェクト・マネジメント・ツールは数多くあります。しかし部長の鶴の一声でカンバンを使うことに決まってしまったため、カンバンを使う以上はカンバンの長所を活かして、カンバンの短所を補足する必要がありました。
 
 このウェブベース・ソフトウェアであるこのカンバン・ツールは、何時でも何処でも誰でも、コンピュータやスマートフォンを使って、カンバンにアクセスできることが最大の長所でした。その長所を活かして、カンバンを部員同士のコミュニケーション場、ミーティングの場として使うことにしました。特に部員が地理的に散らばっている製品開発部では、部員同士がカンバンを通じて、情報のやり取りやプロジェクトの管理ができることは魅力でした。
 
 管理職が複雑なプロジェクトの進行具合を一目で把握できるようにすることも、このカンバンの大きな目的でした。そのためカンバンのレイアウトやカンバン・カードの数など、ビジュアルな側面も十分に検討しました。
 
 一方、カンバンが苦手としたものは、製品開発という目に見えない長期に渡る...
 
  技術マネジメント
 
 最近ビジネスの世界では、カンバンを使ってプロジェクトを管理しようとする動きがとても強いようです。もともとはカンバンは製造現場で使われるのが一般的でしたが、最近はソフトウェア開発やビジネス業務でも使われ始めています。ソフトウェア開発に限って言えば、スクラム(アジャイル)においてスプリント・バックログで管理していたものが、特に大きなソフトウェア開発プロジェクトはカンバンに移行しているようです。
 
 僕が所属するハードウェアを主体とする製品開発部でも、カンバンを導入してから一年以上が経ちました。この一年間は苦労続きだったのですが、いまだに軌道に乗ったとは言えない状態です。今回は、製品開発部へカンバンを導入する際の苦労話しについてです。
 
 もともとは部長の鶴の一声で製品開発部へのカンバン導入が決まりました。誰が、どの製品のどの段階に現在携わっているのか、それをウェブベースのソフトウェアを使ってビジュアルに見た目良く表示してくれる、というソフトウェア商品の売り文句を信じての導入でした。と言うのも、これまでの製品開発は、たとえ同様の製品であっても担当するプロジェクト・マネジャーやエンジニアが異なり、それぞれのチームがそれぞれのやり方で、何千行にも達するタスクをマイクロソフト・プロジェクトで管理していたために、誰が現在何をやっているのか、チーム以外の人にはさっぱり分からなかったからです。
 
 カンバンを導入すると聞いて、僕は”時期尚早”という理由で反対しました。というのは、ハードウェア製品開発は多くの工程が複雑に入り混じっており、ソフトウェア開発のように同質のものや同質の工程の集合体ではないこと、複雑であるが故に、ハードウェア・エンジニア達はそれぞれ自分のやり方で製品を開発していたこと、などが理由でした。そして製品開発工程が標準化していないのに、カンバンを導入するなど早すぎるし、到底無理だと思ったからです。
 
 幸いにも、この時点では僕はまだこのプロジェクトに参加していなかったので、自由に反対意見を言うことができました。もしこのカンバン・プロジェクトに始めから参加していたら、なかなか反対意見は言えなかったと思います。リーンでは以下の順序で、カンバンを使った『価値の流れ』を作ります。
 
(1) 価値の定義
(2) 価値(物と情報)の流れ図を作る
(3) ムダを無くし価値が流れるようにする
(4) 価値を引き出す(プル)
(5) 完全を目指して改善を繰り返す
 
 カンバンを使うのは四番目の『価値を引っ張る(プル)』の段階です。製品開発部の場合、一番目の『価値の定義』ができていないのに、途中を抜かしていきなり四番目のカンバンに手を出すなんて、そもそも無謀なことでした。案の定、最初のカンバンはエンジニアを管理するように作られました。それはまるでエンジニアに割り当てられた仕事をチェックリストで管理するようなものでした。「チェックリストを作るなら、何も高額なカンバン・ソフトウェアなど使う必要なんてどこにも無い」と思ったものです。
 

1. 価値の定義

 

(1) 製品開発の価値

 
 最初のカンバンは大失敗でした。色鮮やかな数百枚というカンバン・カードが、所狭しとカンバン・ボードに散らばったKaだけで、だれも仕事を管理することができなかったからです。最初のカンバンが混乱を極めた頃、僕もこのプロジェクトに参加することになりました。
 
 僕はまず、価値の定義から始めました。価値とは”顧客がお金を払っても良いと思う物やサービス”のことです。製品開発部の場合、設計する PCBA 基板や機械装置が顧客にとっての価値となります。顧客はそのような製品に”お金を払っても良い”と思うのであって、どのエンジニアがどんな仕事をしたかなど、まったく興味はありません。
 
 そこで最初のカンバンを破棄して、新たに顧客にとっての価値をもとにした新しいカンバンを作り直し始めました。
 

(2) カンバンの目的

 
 なにもカンバンだけが価値の流れを管理するためのツールではありません。他にもプロジェクト・マネジメント・ツールは数多くあります。しかし部長の鶴の一声でカンバンを使うことに決まってしまったため、カンバンを使う以上はカンバンの長所を活かして、カンバンの短所を補足する必要がありました。
 
 このウェブベース・ソフトウェアであるこのカンバン・ツールは、何時でも何処でも誰でも、コンピュータやスマートフォンを使って、カンバンにアクセスできることが最大の長所でした。その長所を活かして、カンバンを部員同士のコミュニケーション場、ミーティングの場として使うことにしました。特に部員が地理的に散らばっている製品開発部では、部員同士がカンバンを通じて、情報のやり取りやプロジェクトの管理ができることは魅力でした。
 
 管理職が複雑なプロジェクトの進行具合を一目で把握できるようにすることも、このカンバンの大きな目的でした。そのためカンバンのレイアウトやカンバン・カードの数など、ビジュアルな側面も十分に検討しました。
 
 一方、カンバンが苦手としたものは、製品開発という目に見えない長期に渡る複雑な工程の順序や優先順位を管理することでした。クリティカルパスも分かりません。その短所を補足するため、カンバンと一緒にマイクロソフト・プロジェクトを併用して、そちらで工程の順序や優先順位を管理するようにしました。
 
 これまでのプロジェクト管理はマイクロソフト・プロジェクトを使っていたので、マイクロソフト・プロジェクトを併用することは、管理職達の心理的抵抗を減らすことにも役立ったと思います。もしいきなりマイクロソフト・プロジェクトを廃止して、いきなりカンバンに移行したら、管理職たちはかなり戸惑ったことでしょう。
 
 しかし、マイクロソフト・プロジェクトを併用するのは一時的なことです。もしカンバンが軌道に乗り、開発工程の標準化が完成すれば、自然とマイクロソフト・プロジェクトの必要性は無くなって来るからです。
 
 次回に続きます。
 

   続きを読むには・・・


この記事の著者

津吉 政広

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関する問題を一緒に解決してみませんか?

リーンやシックスシグマ、DFSSなど、問題解決のためのフレームワークを使った新製品の開発や品質の向上、プロセスの改善を得意としています。「ものづくり」に関...


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
イノベーションの創出 普通の組織をイノベーティブにする処方箋 (その122)

  前回に引き続き、今回も「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々の活動の中...

  前回に引き続き、今回も「切り取った知識の重要部分を発想するフレームワークを使って、イノベーションを発想する」にもとづき、日々の活動の中...


第4回 2025年ものづくり白書から~最終回 日本の製造業はどこへ向かうのか、設計中心産業への転換と次世代人材

【目次】 本連載では、2025年版ものづくり白書を起点に、2026年以降の日本の製造業の構造変化を読み解いてきた。 第1回:環...

【目次】 本連載では、2025年版ものづくり白書を起点に、2026年以降の日本の製造業の構造変化を読み解いてきた。 第1回:環...


思い付くには何が必要か 普通の組織をイノベーティブにする処方箋 (その60)

   前回は思考の構成要素として、「その1:思い付く」と「その2:思い付いたことの発展」があるという話をしました。今回からは「その1:思い...

   前回は思考の構成要素として、「その1:思い付く」と「その2:思い付いたことの発展」があるという話をしました。今回からは「その1:思い...


「技術マネジメント総合」の活用事例

もっと見る
擦り合わせ能力を活かすマネジメントとは(その1)

  前回は、「擦り合わせ型開発」と「組み合わせ型開発」のモデルを使って、開発体制について考察しました。擦り合わせ型開発と組み合わせ型開発それぞれ...

  前回は、「擦り合わせ型開発」と「組み合わせ型開発」のモデルを使って、開発体制について考察しました。擦り合わせ型開発と組み合わせ型開発それぞれ...


トレーサビリティの保証 プロジェクト管理の仕組み (その43)

 前回までシステム設計について、その基本の考え方や実施方法について解説してきました。多くの組織で、システム設計は、できる人だけの作業になっており、設計の最...

 前回までシステム設計について、その基本の考え方や実施方法について解説してきました。多くの組織で、システム設計は、できる人だけの作業になっており、設計の最...


プロジェクトの問題を見極める1 プロジェクト管理の仕組み (その23)

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...

 進捗管理のための基本メトリクスセットのひとつである開発工数メトリクスについて解説していますが、前回は、プロジェクト構造(WBS)軸とアクティビティ軸のそ...