「設計・開発の課題にマネジメント視点で取り組む」
生産現場を支えるITの領域に長年従事した後、コンサルティングファームで経営者に近い立場で企業の業務プロセス改革やIT企画支援などの経験を経て、製造業をお客様に持つIT企業の経営に携わるようになった。再びエンジニアの方々に接する機会が増えたことを嬉しく感じるとともに、あれ？大丈夫？という感覚をもってしまうことがしばしばある。というのも、担当する仕事の情報だけが見えれば良い、他の部門のことにはあんまり興味ない。そんな風におっしゃる方々にちょくちょく出会うことがあるからだ。日々の仕事に追われて余裕がないのはわかるのだが、部門横断のマネジメントはどうなっているのだろうか？
製造業の上流工程である設計や開発、さらに個別受注型の製品や生産準備の領域では、設計図面や技術情報、工法といった作られるモノそのものに関連する情報を対象にしたマネジメントに重きが置かれてきた歴史がある。しかしながら現代のモノづくりは、製品ライフサイクルの短命化、また世界の地域別マーケットに合わせた開発件数が増えている。さらにBtoBではほとんどが個別受注生産の形態をとる。これらは複数の組織や企業、拠点を横断して行われておりプロジェクト型の業務である。業務を俯瞰する上位プロセスのマネジメント－メタ・マネジメントがより重要になってきていると考える。とかく“モノ”の管理に偏りがちでかつ属人化の課題が言われている上流工程を対象に、組織を横断したプロセスマネジメントの方法やアプローチを、事例を挙げながら考えてみようと思う。
設計開発のマネジメント
モノづくり、中でも設計開発のような上流工程のマネジメントに取り組み始めたのは、弊社がAras Innovatorと出会った時期と同期する。それは、ある自動車の部品会社の技術企画 －いわゆる製品の設計開発領域のITを担当している方から一通のメールをいただいたのがきっかけであった。
『技術部門の開発業務の効率化、“人・カネ”を管理できるようなテーマが与えられているが、現在の技術部門のシステムは、部分最適化を狙って構築したものばかりであり、部門をつないでいるのは、ほとんど人や紙（ドキュメント）で連絡（連携）しているのが実態です。開発が主業務であるにもかかわらず、営業・製造部門・需給(物流)まで幅広く関わっており、そのため設計者は手配者となり、本来の開発で考える仕事ができていないようになっていると推測しています。』
この後、実際の業務に関わっている複数の部署の代表の方々にヒアリングをして、その実態を探ってみることになった。何を規範にどんな手順で仕事をしているのか、その中で課題と感じていることはないのか。すると、部署によって製品シリーズの違いこそあれゴールは同じはずなのだがプロセスもやり方も異なる。個別の工夫をしているために利用しているITのツールが複数あり、後工程への連携もうまくいっていない。「数年前に比べると開発件数が圧倒的に増えているのにエンジニアの数は増えていないんです。いつもすごく忙しくて残業ばかりです」 そして設計開発から試作までの間には金型設計、製造など異なる部門が関わっているが、後工程の部門では、前工程から最初に来たスケジュールが守られず、それなのに納期は変わらないのでいつも負荷が高いという。
ではこれらの部署、部門を横断して調整する役割はないのか。全体の計画は共有されていないのか？もちろん開発調整会議はやっているが、2週間に1回程度、気が付いた時には手遅れになっている。計画は個別のExcelで作成して配布しているが変更は共有されていない。エンジニア一人ひとりは優秀である。従来であれば個人が“頑張って”仕事をすれば遅れも取り戻せるし、品質問題も抑えられた。しかしながら、開発案件が増えているうえに、工程の一部のプロセスが外注に替わったり離れた拠点になったりしている。もはやエンジニアが工程間の調整や手配に時間を取られている場合ではない。
そこで、弊社が提案したのが、まずは部署横断で仕事の状態が視えてそれらが共有できるようなプラットフォームを持つことであった。元々、量産以降の工場のスケジューラや拠点間のサプライチェーンマネジメントを手掛けていたので、プロセスの連携、視える化、効率化のテーマに同様のアプローチができるのではないかと考えたのである。
設計開発のプラットフォーム
具体的な手段を決める前に、計画を共有するプラットフォームとはどんなイメージなのか、何を狙いとするのかを議論しながらコンセプトを描くことにした。その際の青写真が図１で示す「エンジニアリングプラットフォーム」である。現在の弊社の提供するDynamic Task Manager（ＤＴＭ）の元となる考え方である。
図１エンジニアリングプラットフォームのコンセプト
材料開発、形状設計、金型製作などそれぞれ特化した仕事の内容をすべて把握しているようなスーパーマンは存在しない。細かな業務の内容でなく工程間の重要なタスクやマイルストンの計画と進捗を共有できること、そして開発者であるエンジニアは「管理」されることを嫌うので日常業務の中で必然的に利用する機能を組み込むこと。これらを前提として、計画時点で複数の案件のコンフリクトを調整できること、また“管理のため”でなく“関係者の利便性のため”を、目指す姿として設定した。工程の日程計画に対して進捗がわかる、計画に際しては担当する人の負荷が見える、さらに設計開発の成果物も共有できる、後工程への依頼の発行や最終的には予算管理も可能とする。こうした最終的な姿を描いたうえで、それに向かってどのようなステップで進むべきかのロードマップを描いた。
これまで全く実施していなかったプロセスを導入するのは、組織にとっては非常に難しい。特に日本企業はトップダウンで物事が進まないので、最初から多くのことに取り組むのでなく、できるところから手を付けて一つ一つ成果を上げていくしかない。各ステップで達成目標を設定し段階的な拡張を行っていくことが重要である。
この仕組みを構築するにあたって、市販のパッケージの利用、スクラッチ開発など、具体的な手段を、複数の視点からの評価軸を決めて利用するソフトウエアを選定することにした。（図２）
図２プラットフォーム選定表
「プロジェクトマネジメント」が最初に必要とされるソフトウエア機能であったのでいくつかのパッケージソフトを比較した。当時でもそれなりに良いものもありどれも教科書通りのプロジェクトマネジメントには適合していたが、モノづくりという企業ごとの個性を持ったプロセスにはそのまま使えない。その時Aras Innovatorが日本で提供を始めたことを知り調査してみた。Aras Innovatorであれば、PLMソフトウエアであるため技術領域全般を支援する機能が一通りそろっているうえにデータベースやソースが公開されているので追加開発も可能で拡張性が高い。かつサブスクリプションという価格体系なので初期費用が抑えられる。結果、Aras Innovatorを利用した追加開発を行うことに決定した。
共創の“場”としてのDTM
さて、このような経緯で生まれた弊社のＤＴＭであるが、その後、Aras Innovatorのプロジェクトマネジメントソリューションのアドオンパッケージとして数回のバージョンアップを行い、利用していただく企業も増えてきた。ただし、日本では、上記で挙げた企業の例と同様に、量産前までのプロセスを横断してマネジメントする仕組みをもっていなかったので、設計開発の日程計画の策定と実績登録、さらに一歩進んで成果物管理から始めているケースが大部分である。
そういう意味では、まだ有用性の検証は途上ではあるのだが、はじめの一歩としても以下のような有用性を挙げていただいている。
- 開発からリリースまでの日程計画と進捗が手に取るようにわかるようなって仕事がやりやすくなった（プロジェクトマネージャ）
- 自分の担当する仕事とその期限が通知されるので漏れがなくなった（担当者）
- 前工程が完了するとすぐに前工程の成果物や依頼書が確認できる。以前はメールに埋もれてしまっていたが文書ファイルを探す手間が省ける（担当者）
- 出張先からも進捗や課題がわかるのでフォローができる（業務リーダー）
- 全体の日程と進捗がわかるので段取りを立てやすくなった（業務リーダー）
- 計画策定時に担当者の忙しさを確認して仕事が割り当てられるので、特定担当者への偏りが少なくなった（事業部リーダー）
これらを見ると、DTMによるプロジェクト管理が決して、管理者のためだけでなく、実際の業務を行う担当者の方々にも役に立っていることがわかる。これまで個別に行っていた業務が一つのデータベース上で繋がって、お互いがお互いの仕事を確認しながら協働で仕事をしているという実感をもっていただいているようである。
さらに、Aras InnovatorのVisual Collaborationを利用すれば、途中成果物に対してマークアップをつけると共にお互いのコメントをスレッドとして残しながら開発を進めるということも可能になる（図３）
図３ Aras InnovatorによるVisual Collaboration（Aras社のサイトより転載）
また、弊社もソフトウエアを開発する企業であるのだが、自社がリードする顧客プロジェクトでDTMを利用している。顧客のユーザ部門、情報システム部門とで、プロジェクトのタスクとそのスケジュールと実績を共有することで毎週の出張を伴う進捗会議に縛られることがなくなった。課題がある場合はそのタスクに対して、従来から利用していたWebの課題管理ツールをリンクして登録する。登録された課題はプロジェクトメンバーで共有し、解決するまでコメントや対策を記入していく。進捗や課題の管理は特定のマネジャーにお任せでなく、各人がマネジメント意識をもって取り組むことができるようになった(図4) メンバーにとってはプロジェクトのもう一つの“場”となっている。
図4 DTM課題からリンクされたScrum Boardの例 (Atrassianのサイトより転載）
個別受注生産のコストマネジメント
プラント設備などの個別受注生産型の事業では、案件の引き合い・見積から設計生産・設置まで、プロジェクト型で業務が進められる。社内だけでなく社外のパートナー企業から設備やリソースを調達しながら、これらの工程計画を周知徹底し遅延なく進行することが必須である。そして受注金額に対する原価管理、そして黒字化はいかなる場合においても死守すべきミッションでもある。
こうした厳しい条件を背景にして、韓国の太陽光発電設備を製造設置する企業では、DTMを利用してプロジェクトの進捗に応じた予算・原価管理まで拡張して利用しているケースがある。（図5）
図5 個別受注生産プロジェクト管理システムの主な機能、ERP連携
受注契約単位で①DTMを利用した日程/原価の管理 ② ERPシステムの連携による原価管理 ③ PJ計画から終了までのプロジェクト全体の進捗モニタリング機能がシステムの主要なスコープである。WBS（アクティビティの集約単位）の管理レベルを定義し、その4レベル目を“Work Package”と明確に位置づけ、その単位で調達、製造、原価の管理を行っている（図６）。
図６ WBS Work Package単位の日程と原価管理
そしてそのWBSの Work Package単位に受注原価、目標原価、予定原価を設定し、 ERPで管理するTaskと連携する。ERPの原価管理では部門別、費目別に実績が入ってくるのでこれを集計し、目標原価と突き合わせて予定原価を修正する（図7）。プロジェクトマネージャは、日程計画の進捗状況とコストのリスクもモニタリングする仕組みとなっている（図8）。EVMチャートの提供により原価超過について早期に認識し対応するような意思決定支援を可能とした。
図7 ERPと連携したプロジェクト原価管理
図8 プロジェクト全体のゲート管理、モニタリング
さて、ここまでプロジェクトという概念で、設計生産及び個別受注生産形態の事業におけるマネジメントを見てきた。最後に紹介した事例は、プロジェクトの計画や進捗だけでなく原価まで踏み込んだしくみを構築した本格的なケースであるが、まずは現在進行中の業務プロセスを共有し可視化することから初めてみることをお勧めする。共通のプラットフォームを利用することで、プロジェクトマネージャだけでなく技術者個人が全体のマネジメントに気配りするきっかけができるのではないだろうか。
最後に、紹介した個別受注生産の進捗と原価の管理の例は、システムの開始から約10か月で全体のリリースを達成していること付け加えておく。韓国企業の意思決定のスピードと勢いには圧倒される。