モデリングによる製品開発プロセスの高度化

製品開発がいつもスムーズに進まないんだよね。ようやく完成した製品に満足いかないことも多い。開発プロセスの中で何度もテストを行って検証しているんだけどね。

製品開発において力を入れるべきポイントを誤っているのかもしれませんね。製品づくりはV字プロセスで進めることが多いです。テストはV字の右側の「製品検証」のほうになりますが、実は左側の「製品設計」のプロセスで品質を作りこむことが非常に大切でそちらに注力すべきなのです。

このV字プロセスは3回くらい回すことが多く、各フェーズで重視すべきリスクは異なるのですが、そこもあまり理解されていません。技術検証のフェーズはとっくに終わっているのに、ずっとそこを頑張っているといった具合です。

まさにうちの話だな（苦笑）。そもそも「正しい製品開発プロセス」を誰も理解していない。会社からは「製品開発のやり方がなっていないからどうにかしろ」と言われ、「MBSE」とか「アジャイル」といかいろいろなキーワードをもらっているけれど、それらを自分たちで調べたところでどう進めていいかはわからない。仕方なく大手コンサル会社に相談してソリューションの提供を受けたりしたけど、効果が出た実感はないんだよね。

「製品開発のやり方がなっていない」というのは、例えばどういうところですか？

スクラッチで一から作ることがほとんどなくて、既存のソフトをマイナーチェンジしながら使い続けている。おかげでソースコードがぐちゃぐちゃで、いわゆる「スパゲッティ状態」なんだ。誰も中味に触れたくないから、バグだけやっつけで直してどうにかしのいでいるような状況。これってマズいよね？

製品をもっと「メンテナンスしやすい」「変更しやすい」「再利用しやすい」ものにするためのプロセスが必要そうですね。そのために、まずは既存の設計を「見える化」し、そこから見える課題を解決するためにプロセスも「見える化」することをオススメします。

「見える化」か...。確かに、うちの会社の場合、組織が複雑で横連携もうまくいっていないから、どんなふうに製品開発が進んでいるのか全体像が見えていないなあ。

そういう状況を打破する手法が、モデリングによってシステムの全体像を可視化しながら製品作りを進める「MBSE」（モデルベースシステムエンジニアリング）です。「最終的に何を作るのか」という基本コンセプトを関係者全員でシェアし、「心」を一つにして開発を進めるのがその目的です。

関係部署の全員が同じ部屋でひざを突き合わせて開発すれば、そんな状況は解消できるのにね。うちの会社はやっていないけど。

そうした「すり合わせ開発」を復活させることに、オージス総研は取り組んでいます。モデルを活用してすり合わせができる土壌を作っていきましょうというわけです。

厄介なのは、今までは自分たちが作る装置の技術要素だけで十分だったんだけど、最近はそれにつながる装置が増えて、それらにも対応しないといけない。余計に時間がかかってしまう。

そういう時こそ、モデルを活用して「これとこれをこうつなぐ」という関係性を矛盾なく設計することで、新しい装置をつなげることも容易になるのです。

さらに、「モデリング」に加えて、既存プロセスの良い所を残しながらその会社に合った作業の「プロセス」を検討し、プロセスに沿った開発を進める上での効果的な「ツール」の導入・使い方を提案するなど、様々な部署が関与し合って開発を進めていく環境づくりを支援します。また、既成概念や技術の詳細に捉われない客観的な視点で、議論が円滑に進むように「ファシリテート」します。

それなら、当社の実態に合った製品開発プロセスが出来そうだな。

まずはお客様がどのように開発をされているかをじっくりヒアリングし、導入すれば効率が上がると思われるモデルをお客様と協働で作っては検証し改善していくというサイクルを回します。

大手コンサル会社のソリューションは何がよくなかったのかな？

ありがちなのは、教科書通りのプロセスを導入しただけであたかもMBSEの導入が完了したように思わせるケース。それによって実現されるのは、お客様の実態に合わないお仕着せの製品開発プロセスでしかありません。「このモデルを活用してリスクを早めに解消する」という「心」がないので、しっくりこないプロセスになってしまうんですね。私どもは「日本型システムエンジニアリング」という言い方をしていますが、お客様が今まで行ってきたやり方に合わせ、言ってみれば日本の開発現場が抱える課題を把握し、お客様と一緒に対応していくのが大きな特徴です。

「心」もキーワードだったとはなあ。自分たちを理解してくれるパートナーがそばにいるのは心強いね。もちろん自分たちもノウハウを身に付けていかないと。

そんなお客様に向けたトレーニングも実施しています。技術要素ごとに、スタートアップの研修からステップアップの研修までご用意しているので、社内のレベルアップにもご活用いただければと思います。

もう一つ、小規模の環境で実装と検証を繰り返して開発を進める「アジャイル開発」もミッションになっている。これもネットで調べながら自分たちはアジャイルに開発しているつもりなんだけど、はっきり言って効果が出た実感はないんだよね。

何をアジャイルに検討しなければならないかを、見誤っているのではないでしょうか？そもそも近年、製品づくりの考え方は「モノ」から「コト」へと変化しています。

どういうこと？製品は「モノ」でしかないよね？

モノとしての製品ではなく、その製品が提供する「体験（=コト）」を意識した考え方ですね。モノであれば仕様通りにカタチにしていけば良いので、工程管理に力を入れることでしょう。しかし、コトは未知の領域を多分に含むので、工程管理をすればできるというわけではありません。開発初期のシステム設計段階では、アジャイルで管理すべき観点は工程ではなくリスクなのです。

開発の妨げになるリスクを管理するということ？

そうです。早めにリスクを潰してプロジェクトを回していかないと、全体的な開発スケジュールにも支障が出ます。「すり合わせ開発」をしなくなっている状況では、リスクを見つけて分析することも難しいのです。

アジャイル開発については、ノウハウをしっかり習得しないといけないね。

私どもがコーチングさせていただくことも可能です。お客様にはモデリングで問題をしっかり分析・可視化していただきながら、アジャイル開発をどのように進めていけばよいかマスターしていただくという形です。ぜひご活用ください。