見出し画像

「要件定義の標準」をゼロから作った話——データ総研との共同開発|SEとして歩んだ30年を振り返る⑪-1

システム開発で、一番厄介な工程はどこか。

長年の経験から、私の答えは決まっていた——要件定義だ

「何を作るか」が曖昧なまま開発が進む。途中で「そういう意味じゃなかった」が出てくる。手戻りが起きて、コストと納期が崩れる。多くのプロジェクトの失敗は、要件定義の段階で既に始まっている。

IRM研究会でデータ中心アプローチ(DOA)を学び、ダスキンのプロジェクトで実践した。そこで確信した。「要件定義にDOAを組み込めば、この厄介さをねじ伏せられる」と。

ならば次は、それを会社全体の標準にする番だった。

そのために異動したのが、技術部だ。会社全体の開発手法・技術標準を管理する部署。現場でシステムを作ることから、エンジニアが使う「道具と方法」を作ることへの転換だった。


データ総研とPLANDB

データ総研は、データ中心アプローチ(DOA)を前提としたデータモデリング手法を既に体系化し、企業向けに提供していた。そのブランド名がPLANDB(Plan DB)だ。

技術部での標準化は、このPLANDBを軸に据えることから始まった。DOAの思想に基づき、「データの構造から業務を整理する」という要件定義の進め方を、社内の公式な手法として定義する。方向性は明確だった。


PLANDBだけでは足りなかった

ただし、PLANDBをそのまま使うだけでは標準化にならなかった。

データ総研が提供していたのは、あくまでデータモデリングの部分だ。「エンティティとリレーションシップをどう整理するか」——そこは精緻に定義されていた。

だが要件定義の工程全体を見渡すと、カバーされていない領域が残っていた。

  • 機能要件の整理——業務がシステムに何を求めるか

  • ユーザーインターフェースの定義——画面・帳票の設計仕様

  • 論理DB・物理DBの定義——データモデルをDB設計へ落とし込む工程

  • 後工程へのつなぎ方——要件定義の成果物を、設計・開発工程にどう引き渡すか

さらに、要件定義では「何を作るか」の前に「何が問題か」を正確に定義する作業が欠かせない。問題解決の方向性を整理する工程だ。

ここにはMIND-SAという手法を取り入れた。株式会社日本システミックス(Nix)が1984年に体系化した問題解決メソッドで、顧客の業務課題を構造的に整理し、「だからこのシステムが必要だ」という論理の骨格を作る。この工程があってこそ、データモデリングが的外れにならない。MIND-SAについては、また別途詳しく書きたいと思っている。


ツールの共同開発

手法の整備と並行して、作業を支援するツールの共同開発にも取り組んだ。

要件定義で作成する成果物——データモデル、機能一覧、画面定義——を出力できること。後工程の設計へつなぐためのドキュメントや定義情報を一元管理できること。

「手法」と「ツール」をセットで整備することで、現場のエンジニアが迷わず使える環境を作る。データ総研との協業は、コンサルティング会社と自社開発部門が共同でプロダクトを作り上げるような性格を帯びていた。

ツール化まで含めると、想定を超える工数がかかった。手法を定義することと、それをツールとして動く形にすることの間には、大きな壁がある。その壁を越えるたびに、「標準を作る」仕事の重さを実感した。


教育プログラムという難題

手法もツールも揃った。だがそれだけでは、現場は動かない。

要件定義の新しいやり方を、社内のエンジニア全員に広める——これが次の、そして最も時間のかかった仕事だった。

私自身は実際のプロジェクトでデータモデリングを行いながら、並行して教育プログラムの設計に取り組んだ。「知識を教える」だけでなく、「現場で使える」レベルまで引き上げる研修をどう設計するか。

それは試行錯誤の連続だった。

一度研修をやってみれば、「ここの説明では伝わらない」「この演習では腹落ちしない」という発見が必ず出てくる。修正して、また試す。受講者の反応を見ながら、少しずつ精度を上げていく。

手法を作ることより、人に根付かせることの方が何倍も難しい——この実感が、この時期に刻み込まれた。


まとめ

  • 要件定義を会社全体の標準にするため、技術部に異動

  • データ総研のPLANDBを軸に、不足していた機能要件・UI・DB定義・後工程連携を補完する形で標準化

  • 問題解決の方向性整理にはMIND-SAを導入(詳細は次回)

  • 作業支援ツールをデータ総研と共同開発。ツール化は想定以上の工数を要した

  • 手法・ツールの整備と並行して、社内への普及のための教育プログラムを設計。試行錯誤の連続だった


あなたに聞いてみたい

「仕事のやり方を標準化した」「チームのルールやマニュアルを一から作った」経験はありますか?

社内手順書の整備でも、チームの開発ルール策定でも。「みんなが使える共通のやり方を作った」経験があれば、ぜひコメントで教えてください。


関連記事:
→ SEとして歩んだ30年を振り返る⑧-1|100社のシステム部長が「手弁当」で集まったIRM研究会
→ SEとして歩んだ30年を振り返る⑧-2|ダスキンで「データ設計が先、システムは後」を実践した話
→ Claude Codeの「Skill Graphs」を実際にインストールしてみた話


元大手SIerのSE。50代で退職後、両親の認知症介護に5年間専念。現在は在宅でのAIエージェントビジネス構築に取り組み中。

#SE #システムエンジニア #データモデリング #プランDB #データ総研 #DOA #要件定義 #開発標準 #技術部 #1990年代 #50代 #キャリア #ライフシフト

いいなと思ったら応援しよう!