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

更新日

投稿日

 
  カンバン
 
 前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点を洗い出しました。そしてその問題点を解決するために、新しい価値の流れ図を作りました。今回は、その新しい価値の流れ図を実装するために、カンバン・ボードを使ったことについて書いてみようと思います。
 

4. カンバンの実装

 
 標準化した製品開発工程と価値(物と情報)の流れ図がすでにあったので、あとは力ずくでカンバンに実装するだけでした。これまでの作業に比べればあまり深く考える必要のない分、作業はスムーズで、気持ち的には楽でした。
 

(1) ソフトウェア

 
 ソフトウェアはすでに部長が導入していた leankit というウェブベースのカンバン・ソフトウェアを使いました。ウェブ・ソフトウェアの良いところは、インターネットに繋がってさえいれば、何時でも、どこからでも、コンピュータからでも、スマートフォンからでもカンバンにアクセスできる、というところでした。これにより、地理的にも場所的にも離れている開発メンバーが、カンバンを中心としてコミュニケーションが諮れるようになりました。
 
 ウェブベースのソフトウェアなので、カンバン・カードが次のフェーズに移動したり、内容が変更された時は、自動的にメールを使って関係者に通知を行うこともできるようになりました。またカンバン・カードからネットワーク上の関係資料にリンクを張ったりすることもできるので、カンバン・カードを入り口として、必要な資料を簡単に見つけることもできるようになりました。
 

(2) カンバン・ボード

 
 leankit 上にカンバンを実装していきました。標準化した製品開発工程をもとに、フェーズ(縦欄)を設定し、開発タイプに応じてスイムレーン(横欄)を配置していきました。また leankit の機能を活かせるように、それぞれのフェーズやスイムレーンに必要な情報を埋め込んで行きました。
 
 カンバンは一つではなく、実際には開発する製品(商品)ごとにいくつか作るため、カンバン・ボード自体の標準化も図る必要がありました。開発エンジニアが、すべてのカンバン・ボードで同じような操作ができるようにするためです。
 

(3) カンバン・テンプレート・カード

 
 標準化した製品開発工程をもとに、いくつかのカンバン・テンプレート・カードを作りました。
 
  • PCBA 設計開発テンプレート
  • 機械設計開発テンプレート
  • 総合テストテンプレート
  • 開発ドキュメント管理テンプレート
 
 どのテンプレートも内部にサブ・タスクカードを定義しました。これは開発作業チェックリストとして、標準化された製品開発フェーズと工程を確実に遂行するためです。
 
 カンバン・カードは開発アイテムごとにいくつも発行されるのですが、これら実際のカンバン・カードはこのテンプレートからコピーして作れるようにしました。
 

(4) プロジェクト・マネジメント

 
 プロジェクトの日程はプロジェクト・マネージャが管理しています。これまでプロジェクト・マネージャは自分のやり方でプロジェクトを管理していましたが、製品開発工程のテンプレートが出来てからは、この標準化された工程に従って日程も管理できるようになりました。
 
 しかし、リーンを使った開発がまだ完全に確立していない現段階では、カンバンを使うことには弱点がありました。それは開発工程のクリティカル・パスが見えないということです。開発工程の中で、現在どのエンジニアのどの作業がクリティカル・パスになっていて、全開発工程にどれくらいの影響を与えているのか、カンバンを眺めただけではなかなか分かりません。
 
 そこでプロジェクト・マネージャには Microsoft Project を併用してもらって、クリティカル・パスを管理してもらうことにしました。また日程に応じて、製品開発カンバンをテンプレートから作って、カンバン上に配置してもらうことにしました。その際、カンバン・カードには最低限以下のような情報を記載してもらうようにしました。
 
  • 開発担当者
  • 開発スタート日
  • 開発終了日
  • カンバン・カードサイズ(ポイント)
 
 開発エンジニアには開発状況を随時カンバン・カードに記載報告してもらうようにしました。そのためプロジェクト・マネージャはカンバン・カードを見るだけで開発状況が把握できるようになりました。
 
 確実に開発を進めるために、カンバン・カードを次のフェースに移動する際は、開発エンジニアとマネージャがそのフェーズが完了したかどうかを生成物によって確かめてもらうようにしました(トールゲート・レビュー)。そのためのチェックリストも用意しました。
 

5. データ収集とグラフ化

 
 カンバンからは以下のようなデータを収集し、製品開発プロセスの向上につなげるようにしました。
 
...
 
  カンバン
 
 前回からの続きです。前回ではまず製品開発工程の価値(物と情報)の流れ図を作り、工程上の問題点を洗い出しました。そしてその問題点を解決するために、新しい価値の流れ図を作りました。今回は、その新しい価値の流れ図を実装するために、カンバン・ボードを使ったことについて書いてみようと思います。
 

4. カンバンの実装

 
 標準化した製品開発工程と価値(物と情報)の流れ図がすでにあったので、あとは力ずくでカンバンに実装するだけでした。これまでの作業に比べればあまり深く考える必要のない分、作業はスムーズで、気持ち的には楽でした。
 

(1) ソフトウェア

 
 ソフトウェアはすでに部長が導入していた leankit というウェブベースのカンバン・ソフトウェアを使いました。ウェブ・ソフトウェアの良いところは、インターネットに繋がってさえいれば、何時でも、どこからでも、コンピュータからでも、スマートフォンからでもカンバンにアクセスできる、というところでした。これにより、地理的にも場所的にも離れている開発メンバーが、カンバンを中心としてコミュニケーションが諮れるようになりました。
 
 ウェブベースのソフトウェアなので、カンバン・カードが次のフェーズに移動したり、内容が変更された時は、自動的にメールを使って関係者に通知を行うこともできるようになりました。またカンバン・カードからネットワーク上の関係資料にリンクを張ったりすることもできるので、カンバン・カードを入り口として、必要な資料を簡単に見つけることもできるようになりました。
 

(2) カンバン・ボード

 
 leankit 上にカンバンを実装していきました。標準化した製品開発工程をもとに、フェーズ(縦欄)を設定し、開発タイプに応じてスイムレーン(横欄)を配置していきました。また leankit の機能を活かせるように、それぞれのフェーズやスイムレーンに必要な情報を埋め込んで行きました。
 
 カンバンは一つではなく、実際には開発する製品(商品)ごとにいくつか作るため、カンバン・ボード自体の標準化も図る必要がありました。開発エンジニアが、すべてのカンバン・ボードで同じような操作ができるようにするためです。
 

(3) カンバン・テンプレート・カード

 
 標準化した製品開発工程をもとに、いくつかのカンバン・テンプレート・カードを作りました。
 
  • PCBA 設計開発テンプレート
  • 機械設計開発テンプレート
  • 総合テストテンプレート
  • 開発ドキュメント管理テンプレート
 
 どのテンプレートも内部にサブ・タスクカードを定義しました。これは開発作業チェックリストとして、標準化された製品開発フェーズと工程を確実に遂行するためです。
 
 カンバン・カードは開発アイテムごとにいくつも発行されるのですが、これら実際のカンバン・カードはこのテンプレートからコピーして作れるようにしました。
 

(4) プロジェクト・マネジメント

 
 プロジェクトの日程はプロジェクト・マネージャが管理しています。これまでプロジェクト・マネージャは自分のやり方でプロジェクトを管理していましたが、製品開発工程のテンプレートが出来てからは、この標準化された工程に従って日程も管理できるようになりました。
 
 しかし、リーンを使った開発がまだ完全に確立していない現段階では、カンバンを使うことには弱点がありました。それは開発工程のクリティカル・パスが見えないということです。開発工程の中で、現在どのエンジニアのどの作業がクリティカル・パスになっていて、全開発工程にどれくらいの影響を与えているのか、カンバンを眺めただけではなかなか分かりません。
 
 そこでプロジェクト・マネージャには Microsoft Project を併用してもらって、クリティカル・パスを管理してもらうことにしました。また日程に応じて、製品開発カンバンをテンプレートから作って、カンバン上に配置してもらうことにしました。その際、カンバン・カードには最低限以下のような情報を記載してもらうようにしました。
 
  • 開発担当者
  • 開発スタート日
  • 開発終了日
  • カンバン・カードサイズ(ポイント)
 
 開発エンジニアには開発状況を随時カンバン・カードに記載報告してもらうようにしました。そのためプロジェクト・マネージャはカンバン・カードを見るだけで開発状況が把握できるようになりました。
 
 確実に開発を進めるために、カンバン・カードを次のフェースに移動する際は、開発エンジニアとマネージャがそのフェーズが完了したかどうかを生成物によって確かめてもらうようにしました(トールゲート・レビュー)。そのためのチェックリストも用意しました。
 

5. データ収集とグラフ化

 
 カンバンからは以下のようなデータを収集し、製品開発プロセスの向上につなげるようにしました。
 

◆開発スピードに関するデータ

 
  • バーンダウン(アップ)チャート
  • 開発スピード
  • カンバン・リードタイムとその推移
  • タスク・サイクルタイムとその推移
  • オンタイム完了の割合
 

◆エンジニアに関するデータ

 
  • エンジニアの作業負荷
  • エンジニアの開発貢献度
 

◆開発プロセスの質に関するデータ

 
  • カンバン・カードの分布状況とその推移
  • First-time Through Rate
  • カンバン・カードのオーナーシップ状況
  • カンバンの5S(整理・整頓・清掃・清潔・しつけ)
 
 カンバンを使うことによって、多くのデータを収集できるようになりました。あとはこれらのデータを使って、製品開発プロセスを改善させていくだけです。
 

   続きを読むには・・・


この記事の著者

津吉 政広

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

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


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

もっと見る
体感で思考する 普通の組織をイノベーティブにする処方箋 (その163)

    これまで五感を一つ一つとりあげ、それぞれの感覚のイノベーション創出における意義と、そこに向けての強化の方法について解説してきました。...

    これまで五感を一つ一つとりあげ、それぞれの感覚のイノベーション創出における意義と、そこに向けての強化の方法について解説してきました。...


普通の組織をイノベーティブにする処方箋 (その166) 体感を活用して思考の扉を増やす

  【目次】 【この連載の前回:普通の組織をイノベーティブにする処方箋 (その165)へのリンク】 ◆連載記事紹介...

  【目次】 【この連載の前回:普通の組織をイノベーティブにする処方箋 (その165)へのリンク】 ◆連載記事紹介...


設計部門の課題と原因分析 【連載記事紹介】おすすめセミナーのご紹介

       設計部門の課題と原因分析の連載記事が無料でお読みいただけます!   ◆設計部門の...

       設計部門の課題と原因分析の連載記事が無料でお読みいただけます!   ◆設計部門の...


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

もっと見る
仕組みの見直しに成功する組織2 プロジェクト管理の仕組み (その26)

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...

 前回の仕組みの見直しに成功する組織1に続いて解説します。    仕組みの見直しに成功する組織の考察ですが、今回は、マネジメントのコミットメ...


QFD-TRIZを活用した革新的製品開発への挑戦

♦ 限られた人員、予算で効率的にヒット製品を 1. QFD-TRIZ導入の背景  今回は創業当初から電磁バルブなどの「機器事業」と、198...

♦ 限られた人員、予算で効率的にヒット製品を 1. QFD-TRIZ導入の背景  今回は創業当初から電磁バルブなどの「機器事業」と、198...


プロジェクトの計画策定 プロジェクト管理の仕組み (その3)

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...

 前回のその2:CMMIの要件管理に続いて、プロジェクトの計画策定について解説します。CMMIでは次のことができている必要があります。   ...