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