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

更新日

投稿日

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

1. 価値の定義

 

(1) 製品開発の価値

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

(2) カンバンの目的

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

1. 価値の定義

 

(1) 製品開発の価値

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

(2) カンバンの目的

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

   続きを読むには・・・


この記事の著者

津吉 政広

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

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


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

もっと見る
ムーンショット目標4とは 新規事業・新商品を生み出す技術戦略(その64)

 「ムーンショット型研究開発事業」※の関連で、今回はムーンショット目標4の解説です。※(ムーンショットとは)  同目標4では「2050年までに、地球...

 「ムーンショット型研究開発事業」※の関連で、今回はムーンショット目標4の解説です。※(ムーンショットとは)  同目標4では「2050年までに、地球...


技術戦略 研究テーマの多様な情報源(その33)

  前回の『価値づくり』に向けての三位一体の技術戦略 第3回では、個人単位でテーマ創出のためのスパーク(革新的アイデアの創出)を起こす重要...

  前回の『価値づくり』に向けての三位一体の技術戦略 第3回では、個人単位でテーマ創出のためのスパーク(革新的アイデアの創出)を起こす重要...


関係性の種類、包含とは 普通の組織をイノベーティブにする処方箋(その94)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回も前回に引き続き、下記の「関係性の種類」の中の「(...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」を解説しています。今回も前回に引き続き、下記の「関係性の種類」の中の「(...


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

もっと見る
イノベーション戦略のキーツールとは

  1. 現代のワークショップ    ワークショップは元々、職人が集まって共同で何かを作るための「工房」「作業場」といった意味の...

  1. 現代のワークショップ    ワークショップは元々、職人が集まって共同で何かを作るための「工房」「作業場」といった意味の...


ソフトウェア開発の成果物による進捗管理 プロジェクト管理の仕組み (その16)

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...

 前回は、計画時の見積もり精度を上げるための基準モデルと、進捗を見える化するための基本ツールである基本メトリクスセットのひとつ、作業成果物メトリクスについ...


設計部門の課題と原因分析(その1)

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...

【設計部門の課題と原因分析 連載目次】 1. 設計部門の現状を正確に特定する 2. 課題分析と課題の根本原因除去 3. 設計部門用に用意したコン...