モデルベースの要件定義手法「RDRA」。導入後、BIGLOBEで起きた変化と効果とは

こんにちは。BIGLOBE Style編集部です。

企画したプロダクトの機能や性能を決める要件定義は、サービス開発プロセスの中でも重要な工程の一つです。数多くいるステークホルダーが要件に合意することは、とても難しいことだと知られています。そこで、BIGLOBEでは「RDRA（ラドラ）」というモデルベースの要件定義手法を導入しています。

今回の記事では、「プロダクト全体像を把握」し「社内ステークホルダーとの合意形成」を実現したRDRA導入の効果を、DX推進部サービス戦略グループ主任の勝田 隆弘が紹介します。

ステークホルダーには、もちろん社内のエンジニアも含まれます。基盤系システム部 基盤横断システムグループ グループリーダーの西 秀和も加わり、エンジニア目線での「これまでの課題」「RDRA導入の現場における効果」「さらに良くしていくために取り組むこと」について、対談形式でまとめました。ぜひご覧ください。

※撮影時のみマスクを外しています。

• 要件定義を、早く・漏れなく・誤解なく関係者と合意する
• 業務設計の属人性を無くし、議論するベースを作る
• RDRAができれば、どの領域に行っても活躍できる人材になれる
• RDRAを組織文化として根付かせていく

要件定義を、早く・漏れなく・誤解なく関係者と合意する

—— 勝田さんは昨年10月に「BIGLOBE RDRA導入後の要件定義の変化」というテーマでセミナーに登壇されています。まずは、その内容も踏まえRDRAについて教えてください。

勝田：RDRA（Relationship Driven Requirement Analysis）とは、株式会社バリューソースの神崎善司さんが提唱されている柔軟で精度の高いモデルベースの要件定義手法です。詳しくは神崎さんのサイト（http://rdra.jp/）をご覧ください。

BIGLOBEのプロジェクトの多くは、自社が提供しているプロダクトの成長・維持を目的とした改修案件です。その要件定義フェーズにおいて「プロダクトの変更点をいかに早く・漏れなく・誤解なく関係者と合意できるか」は重要なテーマの1つでした。

それを解決する手法として最適だと思い導入したのが、RDRAです。

勝田：導入の狙いやその後の効果としては、大きく2点挙げられます

■プロダクトの全体像を把握

私が担っていた業務設計のチームでは、5年くらい前までプロダクトの要件定義のプロセスやノウハウはメンバーによって異なっていました。さらにはプロダクト全体像を管理するためのドキュメントが確立されていない状態で進められ、いわゆる属人化が進んでいました。組織が大きくなり人事異動などが発生するとブラックボックス的にわからない部分ができてしまい、プロダクトの全体像を把握するのが困難という課題が発生していたのです。そこで、プロダクト毎にRDRAモデルによる仕様マスタを作成することで、効果的な業務管理を実現しました。

■要件定義を取り巻く社内のステークホルダーとの合意形成

プロダクトの要件定義は、関わる他部門のメンバーと協議することが大切です。その点、先ほども触れた通り、過去には属人的な課題があり、確認資料や合意形成ツールがバラバラで悪循環を生むこともありました。RDRAモデルにしてからは、記法を統一することで「業務プロセスの中のこの部分が今回変わるんですよ」など、変更や改善点を指差しで示して確認できるため理解が早くスムーズになりました。

—— ありがとうございます。それを踏まえ、エンジニア目線で何が今まで課題だったのか、何が良くなったかなどを基盤系システム部の西さんにも入っていただき聞いてみたいと思います。

西：まず、勝田さんが担っていた業務設計チームについて知りたいです。他社さんではあまりない部門なのかなと思うんです。

勝田：私も入社してから配属された部署だったので、最初は何なんだろうと思いました。しかし、今となって感じるのは、ここがBIGLOBEの強みのひとつなのではということ。本来この領域はSIerなどの外部エンジニアが要件をヒアリングして開発するというパターンが多いのですが、それだと何かを変えるたびにSIerにお願いする必要があります。その結果、自社サービスプロダクトなのに私たちの中にノウハウや知識がたまらないという課題ができてしまいます。本来は自社のプロダクト企画側で、このフェーズができれば望ましいのですが、そうはいかないケースも多いですよね。

西：システムも業務も全部任してしまうとベンダーロックインですね。自分たちの会社のプロダクトなのに、自分たちが知らない状態になってしまう。

勝田：そこで、今は自分たち業務設計チームが要件を作って開発しているので、何か改善しようと思った時にすぐに対応できるのです。組織内に、この部門がある価値はそこかなと思います。

業務設計の属人性を無くし、議論するベースを作る

西：RDRAを導入したのは、その業務設計部門をより機能させるためですか。

勝田：そうですね。昔の業務設計フェーズはその道のベテランの頭の中だけに「こうすればいい」というのがありました。だから、その人たちの見解を聞いたり、過去に行った案件のことを思い出したりといった方法に頼っていると、管理するサービスが増えたときに大変な状態になってしまいます。

また、BIGLOBEは業務フローを重視する会社ではあったので、RDRA導入前から業務フローを中心にどうプロダクトを管理していくべきかという課題意識もありました。

西：業務フローさえしっかりあれば「ここは何をやりたいんですか」と質問ができますよね。勝田さんは実際にRDRAの導入をどう感じていますか？

勝田：自分たちのやりたいと思っていることがしっかり要求通りに実現できているのかどうかは、今までは見えにくいところがありました。それをリリースする前に確認して意識を合わせられること自体に価値があると感じています。

西：エンジニアサイドからすると、今までの経験上、要件が矛盾した資料が出てくることが一番の困りごとでした。最後の最後で「すみません、この仕様だと実現できません」みたいな話で。その点、RDRAだと全体の関係性がわかるので、とてもいいなぁと思っています。

勝田：おっしゃるとおり、要件の関係性についての表現力は強みですね。

RDRAができれば、どの領域に行っても活躍できる人材になれる

西：RDRAを導入してから、新しい人が来たときの対応の仕方などは変化がありましたか？

勝田：昔に比べると、話を進めやすくなりましたね。以前は、新人が入ってこの仕事をしますとなったときに、担当するプロダクトのことを伝えるベースになるものがなかったので教えるのが大変でした。そのため、初期導入の勉強も現場で案件を進めるのも、過去の事例を出して参考にしながら要件定義を進めていました。しかし、それでは人が育ちません。RDRAがあることで要件を理解する基礎ができ、その後の進め方もある程度システマチックに説明できる状況になったことは成果なのかなと思います。

西：その点、ベテラン社員への影響はいかがですか？

勝田：課題やリスクの洗い出しを経験だけに頼る、といった場面が減りましたね。結局、RDRAは頭の中にあることを都度アウトプットさせられるので、個々人の本能的な危機察知能力みたいなものだけに頼らず、論理的かつ網羅性を持ってまとめられるからです。結果、上司や案件を遂行する人への説明がとてもしやすくなり、納得感も得られやすい共有ツールとして効果的に機能するようになりました。

西：業務フローでマスター化されたものがあるのは、いいですよね。昔はホワイトボードを使って説明していて、その人の好みによって書く記号や説明の仕方が変わったりしましたから。でもその点、RDRAの表記方法も独特ですよね。最初、抵抗感はありませんでしたか？

勝田：最初は抵抗感だらけでしたよ（笑）。情報量も、やるべきことも急に増えたので。ただ、そのフェーズを乗り越えられたのは、RDRAを使うことでメリットがあるとわかったからです。こういうふうに書けば自分たちの言いたいことをうまく伝えられる、議論が深まるということを根底で理解できました。だから、新しく入ってくる方も最初は“やるべきことの壁”にぶつかるかもしれないので勉強は必須です。

西：何でも直感でできればいいのですが、基礎が理解できれば要件定義をより正確に進められるようになりますよね。

勝田：そうなんです。あとは、RDRAができると自身のキャリアにとっても有効だと思っています。例えば、私はDX推進部に異動になって「DXって何をするの？」となって調べていく過程で、要件定義や要求分析などの進め方やまとめ方の知見が活かせると感じました。対象領域の専門知識を入れ換えさえすれば、要件を整理するところのプロセスはあまり変わらないからです。

また、自分がこういうことをできるんですよということを、自信を持って言う根拠にもなります。例えば転職するときに「私、業務設計できます」と言ったとしても何ができるんだろうってなりますが、「RDRAができます」と言えばわかりやすいですよね。

西：エンジニアは「こんな言語ができます」「こんなプロジェクトをやりました」と、わかりやすいのと同様に、業務設計もRDRAがわかると言えることで自信になりますね。

勝田：RDRAを実践することは、どの領域に行っても活躍できる人材になる可能性があるという道筋を示していると思います。

RDRAを組織文化として根付かせていく

西：勝田さんご自身が今後やりたいことはありますか？

勝田：要件定義のさらに上流領域の、何が目的で何をやりたいんだっけといったことを考える機会を増やしたいと思っています。要求分析を整理してアウトプットし、RDRAモデルを繋げて、私たちがやりたいことはこういうことですと話せるようなイメージです。今ある強みを発揮し組織の力になれればいいですね。

西：本来やりたかった企画と開発の橋渡しの部分にもさらに集中できそうですね。その他に個人的に「これは本当はもう少しやりたいんだけど、できていない」といったことはありますか？

勝田：業務設計チーム内でRDRAを通じてさらに理解を深め、同じ目線で会話できるようになることです。結局、良い結論を下せるか否かは最終的にその人のスキルに依存してしまうところがまだあります。そのため、同じレベルで議論ができる人を増やすことが重要で、社内でそのような環境を作っていくことはずっと気にかけているところです。

西：議論のベースができてしまえば、理解するのに使った時間を「考えること」に使えるので、頑張ってRDRAを広めていきたいですね。組織文化として根付いていくまで。現在、サービス開発の”Agility”にこだわっていくために、企画・推進・設計・開発を一体化できるよう組織体制を見直しているところなので、私もRDRAの普及活動をしていきたいと思います。

—— 組織文化として根付くと、より良いプロダクト作りにも活かせそうですね。本日は素敵なお話、ありがとうございました。

BIGLOBEでは、共に挑戦し成長してくれる仲間を募集しています。
ご興味のある方はこちらの採用情報をご覧ください。

hrmos.co

※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。