J-MDMは、ビジネスの基盤になるマスターデータ管理ソリューションの純国産MDMパッケージです。
業界・業種問わず、さまざまな導入実績を誇る「J-MDM」の裏側について迫る連載企画の第2回は「設計書自動出力機能」。
機能開発に至った背景や具体的な利用イメージについて、株式会社JSOLの小野智士、都久井達哉に話を聞きました。
開発者の作業補助や業務効率化を図る「設計書自動出力機能」
── まずは「設計書自動出力」の機能について教えてください。
小野：J-MDMには、画面の項目情報やパラメーター設定などをノーコードで開発可能な標準機能を用意しています。
設計書自動出力の機能というのは、自由レイアウト機能*で定義した内容を画面項目定義書として出力する機能で、主に開発担当者向けに自動で設計書を出力する機能になっています。
*「連載企画 第一回 参照」（公開後リンク挿入）
J-MDMをリリースした当初は、ウォーターフォール型で画面設計を行い、その後に開発していくのが主流でした。要は、設計書を自分たちでプロジェクトごとに作り、決定した内容をもとに画面を作っていく形だったわけです。
直近では、お客さまと認識合わせをする段階で、先に画面だけ作ってから開発に入っていくケースも増えてきている一方、お客さまの要望に合わせて作った成果物からリバースして、「設計書を手起こししていく作業」がかなり労力を要する背景がありました。その手間をシステムで自動出力できるようになれば、開発者の作業補助や業務効率化につながるのではと思い、設計書自動出力の機能を開発したのです。
都久井：開発者目線で言うと、基幹システムの一部を担う開発ゆえに、昨今に見るようなアジャイル型ではなくウォーターフォール型でマスター管理システムの構築を行うのが一般的となっています。
ですが、ウォーターフォール型では工程ごとにレビュー（設計書の確認）を行うため、仕様が正しく反映されているか確認するのが工程の終盤となってしまい、認識や理解のズレがあると手戻りが発生する場合もあります。当然のことながら作成していた設計書の変更も余儀なくされます。
J-MDMでは自由レイアウト機能でプロトタイプ画面（モックアップ）を確認することで、お客さまからフィードバックをいただき、意見や要望を吸収することで、精度を高めていくことが可能です。
ウォーターフォール型の開発でありながら、アジャイル的な部分の要件を詰め、設計書の作成には極力手間をかけない。そうすることで効率的にプロジェクトを進めることができると考えております。
利用者の立場に立った「汎用的な共通フォーマット」の具現化
── 機能開発する上で苦労したこと、工夫した点はどのようなことでしょうか？
小野：機能を開発していくなかで、最も苦労したことは「汎用的なフォーマットを作ること」でした。というのも従来は、個々のプロジェクトごとに開発者が作成していたので、設計書のフォーマットが、それぞれで全く異なっていたからです。いかに使いやすく、かつ広く汎用的に利用可能な共通フォーマットを作れるかが、大きな肝になっていました。
我々の開発チーム内部でも、議論を重ねていきながら共通フォーマットの具現化を行ってきましたが、「実際にこんな機能を作っています」という進捗を、J-MDMを使った導入経験のあるメンバーに都度共有していくことを意識していました。共有することで、改善点のフィードバックをもらえるので、そこからさらにブラッシュアップし、正式な機能としてリリースしたのです。
都久井：機能開発で議論した部分としては、どうしても機能を作ることだけに固執すると、お客様によっては理解できない表現のままリリースしてしまうことになるので、その部分は開発チーム同士でよく議論しましたね。
やはり、一度機能として提供してしまうと、そう簡単には変更しづらくなるので、設計書上の表現の仕方は慎重に考えながら、どういう風にすればお客さまの利便性が高まるのか。というのを念頭に置きつつ、開発を行ってきました。
また、実際にプロジェクトを経験している方に意見をもらうと、どうしてもその案件で苦しんだり、はまったりしている課題にフォーカスしがちになります。ですので、一つひとつの要望に対して、それを拾うべきか否かは、しっかりと検討することを心がけていしました。
また、プロジェクト側から挙がってこないけれども、今後出てきそうなニーズの見通しや、設計書を出力した後の運用面など、製品の汎用化を意識しながら、設計書自動出力機能の要件を固めていきました。
── 機能開発にはどのくらいの期間を要したのでしょうか。
小野：設計書自動出力機能については、2023年6月にJ-MDM Ver2.5.1をリリースした際に実装された機能です。
J-MDMのバージョンアップは、半年から1年のスパンで行われるものなので、その期間に収まる程度の開発ボリュームになっています。
機能を作ること自体、技術的な部分さえ解決してしまえば、そこまで長期間に渡るシステム開発ではない分、「MDM製品を作る開発者」と「プロジェクトの経験者」の両方の目線合わせをとても大切にしています。双方の意見や要望を短期間で拾い集めて、そのアウトプットを取捨選択し、機能開発を行っています。
設計の段階から自動生成できる顧客主導型のMDM構築へ
── 特に使ってほしい場面や利用イメージはありますか？
小野：利用イメージは主に2パターンを想定しております。まずひとつ目は、要件フェーズでお客さまと認識合わせをするために作成したプロトタイプ画面の設定内容を、手動で設計書に起こしていくのではなく、自動で出力することで設計フェーズも簡略化していく使い方です。
もうひとつは、先に画面などのプロトタイプを作らず、設計から開発という正規の手順を踏んでいくケースです。この場合の利用イメージとしては、作った画面から設計書を自動出力し、要件定義フェーズで作った「手動の設計書」と設計・開発フェーズで出力した「自動の設計書」を突き合わせ、設計内容を正しく設定に落とし込めているかの確認作業で機能を活用するやり方です。
都久井：お客さまからも、QCD（品質、コスト、納期の3要素）の観点から設計書自動出力機能に対して、一定のご評価をいただいております。
どうしても、さまざまなニーズに応えられるように機能に汎用性を持たせていくと、画面を動かすために必要な設定が増えるため、テストの工数も増大してしまう状況があります。そこの工数を削減していかないと、QCDの向上にはつながっていかないので、次のテーマはそこにもフォーカスしながら機能改善をしていければと思っています。
さらに、ある程度要件が固まったら、自動的に設計書が作れるようにしていく構想も考えています。もっと上流のインプットから、設計書を自動で作成し、それを実際の設定に反映させることで要件通りに動く。いわば設計も含めた自動生成のところまで踏み込んでいければ 、受注案件型から顧客主導型でMDMをインストールしていけるのが、最終的に目指していきたいゴールです。
また、設計書を自動でアウトプットした際の利用イメージはありますが、もう少しお客さまの実運用を踏まえた形で交通整理していくことが大事だと思っています。
要件定義からプロトタイプの作成、開発からテストに至るまでの道標を作ることができれば、MDM導入に際しての解像度も高められるので、この部分も実現できるように尽力していきたいですね。
── 今後のバージョンアップを見据えての改善予定があれば教えてください。
小野：現状の機能としては、あくまで設計書を自動出力する機能のみなのですが、今度は設計書の内容をシステム側にインプットして、画面に出力できるような機能も追加していきたいと考えています。それができてくると、プロトタイプを作らない完全なウォーターフォール型の場合に、設計書の内容から画面を作成できるようになり、設計・開発の幅も広がることで、よりお客様に合わせたプロジェクトを推進することが出来るでしょう。