便利なツールが誰でも簡単に手に入り使える時代になりました。しかしいくら便利なツールが増えたからといって、リーンシックスシグマのフレームワークが変わってしまうことはありません。むしろリーンシックスシグマのプロジェクトの実行が便利なツールを使うことで変わってきている気がします。
DOE（Design of Experience: 実験計画法）は最たるものかもしれません。今や 実物を使った DOE よりも、コンピュータ・シミュレーションを使ってやる DOE の方が多くなっています。他の事例として、今回は SharePoint、R／RStudio、Shiny など、便利なツールを使ったリーンシックスシグマのプロジェクトを紹介したいと思います。
プロジェクトの背景
このプロジェクトは、プロジェクトマネジャー達が抱える問題を発端として始まりました。問題というのは、
- プリント基板（電子回路）の設計期間が長すぎる
- プリント基板（電子回路）の設計期間が不確定過ぎる
- プリント基板（電子回路）の設計スケジュールが見積もれない
- そのため、全体として製品開発期間が正確に見積もれない
- だから、せめてプリント基板（電子回路）の設計期間がある程度見積もれるようにしてほしい
というものでした。
Define フェーズ
まずは Project Charter を使ってプロジェクトの枠組みを定めました。プロジェクトマネジャー達が抱える問題が初めからはっきりしていたので、リーンシックスシグマのプロジェクトの達成目標もこの段階である程度絞り込むことができました。
次に SIPOC を使って現在のプリント基板（電子回路）の開発プロセスや、開発過程での生成物を大まかに把握しました。それと同時に RASCI を使って、 開発プロセスやこのプロジェクト携わる関係者をすべて洗い出しました。
洗い出した関係者を一同に集め、KJ を使いながら問題点を一つ一つ丁寧に拾っていくと同時に、期待されるであろうプロジェクトの達成目標を列挙していきました（VOC: Voice Of Customer）。さらにいくつか挙がったプロジェクトの達成目標には AHP （Analytic Hierarchy Process）を使って優先順位をつけておきました。
この Define フェーズで見えてきたことは、プリント基板（電子回路）の設計は大規模かつ複雑であるにも関わらず、分業ではなく、会社に所属する各地に散らばった 25 人もの電子回路の開発エンジニア達が製品ごとに個別に担当していたため、開発スケジュールは個々のエンジニアの大まかな見積もりに委ねられていた、ということでした。また個々のエンジニアは複数のプリント基板設計を同時に抱えていたため、それらが開発スケジュールの見積もりをより一層難しいものにしていました。
Measure フェーズ
Measure フェーズでは、「開発スケジュールを正確に見積もることができない原因」を深く探りました。Fish-bone（Ishikawa）Diagram を使って、原因とその影響を理解したり、Cause & Effect Matrix を使って、どのプロセスがもっとも見積もりに影響を与えているのか、などを理解しようと試みました。また現在のスケジュール見積もりプロセスが抱える潜在的なリスクを理解するために、Process FMEA も使いました。
この Measure フェーズで見えてきたことは、プリント基板の開発スケジュールは「プリント基板」の一括りでは見積もれないということでした。基板の機能やサイズ、開発ロケーションなど色々な要素によって、開発スケジュールの見積もりは大きく左右されます。エンジニアにとっては当然と言えば当然のことなのですが、お金と時間がすべてであるビジネス側（上級管理職など）にとっては、そのようなことは大したことではありません。しかしビジネス側に問題の本質を的確に説明するためには、言葉だけの説明よりも、Measure フェーズの結論をデータやグラフにして提示した方が効果的なのです。
Analyze フェーズ
Analyze フェーズでは、まず QFD（Quality Function Deployment: House of Quality）を使って、プリント基板の開発スケジュールに影響を与えるであろう項目を洗い出しました。QFD が最終的に抽出した設計項目は 60 にも及びました。
この部署はここ数年の間で、大小 150 種類以上のプリント基板を開発してきました。現在も進行形で 30 種類以上の開発が進んでいます。過去、そして現在のプリント基板それぞれから 60 にも及ぶ設計項目（データ）をどのように集めるのか、その方法とプロセスについて、いくつかのアイデアを出し、さらに Pugh Matrix を使って、もっと適切なアイデアを一つ選びました。そのアイデアに従ってデータを集める方法やプロセスを設計し、また集めたデータをどのように分析し、共有するのかを検討しました。
Analyze フェーズの最後には、新しいプロセスが潜在的に抱えるリスクを把握し、それを低減するための方策を打つために、再度 Process FMEA を使いました。後は設計した新しいプロセスを次の Improve フェーズで構築し、実施するだけです。
Improve フェーズ
Improve フェーズでは、新たな費用を一切かけずに、現在使える便利なツールを使ってプロセスを構築しました。プロセスの前半はマイクロソフト・オフィス 365 を中心に、そして後半は R を中心に構えました。
- エンジニア達にとって設計項目データの入力がしやすいよう、InfoPath を使ってデータ入力フォームを作り、その入力フォーム使って SharePoint 上にフォームライブラリを構築しました。SharePoint を使った理由は、各地に点在するエンジニアがいつでもどこでもデータを入力できるためです。
- SharePoint サイトと Team を連携させ、データ入力に関する質問や問い合わせなど、コミュニケーションは Team 上で行うと同時に、その情報を共有しました。Team を使った理由は、メールと違い、コミュニケーションとそれ履歴が一箇所に集約できるためです。
- SharePoint 上に蓄積されたデータを、クエリーを使って一括ダウンロードできるようにしました。クエリーを使えば、いつでも最新のデータが得られるからです。
- 一括ダウンロードしたデータを R を使って分析しました。回帰分析を用いたプリント基板の開発期間の予測を中心に、クラスター分析や主要素の分析なども行いました。R を使った理由は、非同期に更新されるデータを何度も繰り返しダウンロードし、自動的に分析処理することに適しているためです。またレポート機能にも優れているためです。
- プリント基板の開発期間予測モデルをつくり、モンテカルロ・シミュレーションを行いました。モンテカルロ・シミュレーションを使った理由は、60 項目にも及ぶデータにバラツキがあったり、過去のデータが曖昧であったためです。
- プリント基板の開発期間予測モデルを Shiny を使ってウェブ・アプリケーションに変換し、プロジェクトマネジャーに提供しました。Shiny を使った理由は、R から直接ウェブ・アプリケーションが作れることや、専門的な統計ソフトウェアをプロジェクトマネジャーやエンジニア達が使わなくてもよいためです。
Shiny を使ったウェブ・アプリケーションでは、パラメータを変えることによってプリント基板の開発期間がどのように影響を受けるのかを、即座にモンテカルロ・シミュレーションの結果としてヒストグラムに表示できるようにしました。
Control フェーズ
せっかく仕組みを作っても、データが集まらなければ、分析すら始めることができません。ウェブ・アプリケーションを作っても、それをプロジェクト計画に使ってもらわなくては無駄に終わってしまいます。そこで Control フェーズでは、いかに継続的にデータを集め、いかにそこから導き出したプリント基板の開発期間予測を使ってもらうか、ということに焦点を合わせました。
幸い、部署では SAFe （Scaled Agile Framework）を使っていたので、データの入力と更新作業を定期な作業として組み入れることができました。また開発期間の予測値は、カンバン・カードのポイント値として使えるようになりました。
そして期待していたように、データが集まってくるに従って、予測精度が上がってきました。というのも、このプロジェクトが始まったとき、エンジニア達は例外なく「過去の設計については思い出せない」と言っていたので、常々「正確なデータは必要ないので、プロのエンジニアとしての経験と知識に基づいてデータを入力してくれればそれで十分。今は個々のデータの正確性よりも、より多くのデータが欲しい」と答えていたからです。多くのデータが集まれば、個々のデータが多少不正確でも、全体として多くを語ってくれるからです。