モデルベース要件定義テクニック(RDRA)

技術顧問先のエンジニアからの薦めで、神崎善司さんの『モデルベース要件定義テクニック』を読んだ。この書籍では神崎さんの要件分析手法であるRDRA(Relationship Driven Requirement Analysis:ラドラ)の実践方法が解説されている。

モデルベース要件定義テクニック

モデルベース要件定義テクニック

 

k-method.jp

RDRAの手法自体の特徴などを、自分のメモとしてまとめておく。

※ 手法の具体的な内容について知りたい方は、書籍やWebを参照されたい。

RDRAについて

RDRAは一言で言えば「要件分析・定義のフレームワーク」だ。つまり、次の事柄が提供されている。

  • 要件分析〜定義の活動において必要な事項の全体像が示されている
  • 事項間の関係性が示されている
  • 個々の事項の目的(それが必要な理由)が示されている

長年の実務経験のノウハウから抽出されたフレームワークだと思う。要件分析〜定義の活動を効率よく進めるために必要なことがうまくまとめられている。

RDRAは特に、以下の点にフォーカスしたフレームワークだ。

  • 網羅性
  • 整合性
  • 表現力

(書籍やWebにも、RDRAの背景としてこの3つが挙げられている)

RDRAでは、要件分析〜定義活動によって以下の4つをクリアにしていく。

  • システムを使って生み出す価値
  • システムを取り巻く環境
  • システムとの接点
  • システムそのもの

この4つのすべてに対応する図の表記方法が用意されており、活動の広範囲をサポートしていると言える。また、ある図に記載する内容と、別の図に記載する内容との関係性が定義されており、整合性のフィードバックが働くようになっている。

RDRAによって得られるもの

  • 要件分析〜定義工程の進行をスムーズにできる
  • 要件分析〜定義工程の成果物のクオリティを一定以上にできる
  • 上記を、KKD(勘と経験と度胸)に頼らずに、非属人的なノウハウとして利用できる
  • 要件分析〜定義工程の全体像を伝えやすくなる

  

現場で試して学んでいきたい。

2018 retrospective

サクッと振り返る2018年。そして来年のチャレンジ。

アウトプット

カンファレンストーク:3

ブログ記事:16 (このブログ) + 1 (メルカリ)

仕事

  • 株式会社メルカリへ転職
  • 技術顧問開始(アジアクエスト株式会社)

趣味・生活

  • カンファレンスアフターツアー(6月大分、7月京都)
  • ジム復帰&食生活改善開始
  • 東京で生活開始(10月中旬〜)
  • 東京でもジム契約

来年のチャレンジ

  • カンファレンスまたは勉強会でのトーク: ソフトウェア設計 (1)、Microservices (1)、Go(1)、マネジメント (1)
  • ブログ記事:ペース維持(月1以上)、マネジメント、Microservices、Goについての記事を書く。英語で記事を書く。
  • ジム:週3回以上
  • 仕事:Go Bold、All for One、Be Professional

 

DIPの定義を考える

ソフトウェアの設計原則には分かりづらいものが多い。主な原因は、以下だと考える。

  • 原則が生まれた当時の内容のまま、現代に伝わっている
  • 原則の説明が十分に抽象化、本質化されていない

最近TwitterでDIPに触れているtweetを目にした。DIPを十分に理解している方も多くなってきていると思うが、それでもやはりこの「原則」は、依然分かりづらいままになっているのだと思う。これを機にDIPの整理に着手してみることにする。 

DIPの定義

DIP:Dependency Inversion Principle(依存関係逆転の原則)は、Robert C. Martinの1996年の論文によると次のように定義されている。

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.(上位レベルのモジュールは下位レベルのモジュールに依存すべきではない。両方とも抽象(abstractions)に依存すべきである。)
B. Abstractions should not depend on details. Details should depend on abstractions.(抽象は詳細に依存してはならない。詳細が抽象に依存すべきである。)

Dependency inversion principle - Wikipedia

これが定義だと言われても分かりづらい(分かりづらいからなのか、書籍Clean Architectureではこの定義は使われておらず、サラッとした説明のみとなっている)。この定義から、言わんとしていることをフワッと理解できても、本質的に何のことを言っているのか捉えづらいだろう。違和感を生む単語も混ざっている。論文が提出された時代には、プログラマたちに共通する教養として「構造化分析・設計」があった。その時代であれば、上位レベル、下位レベルといった言葉には共通認識があった。しかし現代のソフトウェア構造は複雑になり、その複雑な構造を扱うための新たなアーキテクチャも登場してきている。現代のソフトウェア構造において、上位下位といった形を前提に語ってしまうと、そこで混乱を生む。また、抽象や詳細といった言葉についても、対象を限定しすぎている。

そして何より、この原則の定義方法の弱さが最も大きな問題だろう。定義が「異常状態と正しい状態」を併記する形でしか書かれていない。この書き方ゆえに、DIPを「ソースコードのある種の状態を、良いか悪いか判定するためのルール」だと解釈してしまうのだと思う。

DIPは、状態判定のためのルールではない。悪い状態から良い状態への「変更操作そのもの」を表している、と見た方がしっくりくる。その変更操作を行えば、ソフトウェアの状態を改善できると言っているのだ。整数の加算や乗算に可換則(交換可能)が成り立つというのと同じようなニュアンスになる。つまり、法則なのだ。

まとめると、DIPは、ソフトウェアのモジュールが別のモジュールに依存している時、依存の特徴だけを抽出したより安定度の高いモジュールに両者を依存させるように書き換えることができる、という法則だ。

この「書き換え可能性」がDIPの本質だと考える。そして、この書き換え可能性は、さまざまな目的に利用できる。ソフトウェア構造全体としての安定性を高められるし、OCPが言うようなソフトウェアらしいモジュール性を実現する際にも役立つ。

Robert C. Martinは1996年の論文の結びで、次のように書いている。

The principle of dependency inversion is at the root of many of the benefits claimed for object-oriented technology.

Robert C. Martin "The Dependency Inversion Principle"

DIPは方法である。そしてそれは、ソフトウェア開発における偉大な発明だ。

安定度とは何か

さて、私のDIP定義では「安定度」という言葉を使った。安定度を別の言い方にすると、その要素が「変わらない度合い」だ。プログラミング言語のコア要素であるほど、一般的には安定度が高い。プログラミング言語が提供するユーザー定義要素の場合は、特徴によって高い安定度を持ちやすいものと、そうでないものとがある。また、ユーザー定義要素においては別の視点として、そこに含まれる可変要素の数も安定度に影響する。要素の数が多ければ、客観的可能性として変更が発生する確率が高くなり、安定度は低いといえる。

昨今のクラス指向プログラミング言語であれば、おおよそ次のような順に安定度が高いといえる。

  1. プログラミング言語に内蔵された言語要素
  2. プログラミング言語に内蔵された標準ライブラリ
  3. ユーザー定義のインターフェイス
  4. ユーザー定義のクラス、ユーザー定義の関数、ユーザー定義の抽象クラス

「ユーザー定義の抽象クラス」はよく議論の俎上にあがる。抽象クラスは、高い安定度が求められる位置づけにあるにも関わらず、サブクラスの要件を一手に引き受けてしまい、結果として変更頻度が高くなることがある。これでは、低い安定度しか持ちえない。これは下手な事例だとしても、一般的に抽象クラスの安定度を高く保つのは難しい。だから基本方針として抽象クラスを使うことを避け、interfaceといった、制約が強く、高い安定度を保証しやすい要素を使う方向へ時代は進んだ。

DIPは、「具象ではなく、抽象へ依存するように書き換えること」というルールだと理解されていることが多い。具象クラスへ依存している箇所を、interfaceを介する形に書き換えるということだ。もちろん、この書き換えは可能で、それによってソフトウェア構造の安定度を高めることはできる。しかし、一律にinterfaceを使って書き換えればよいという理解では、本質を見失ってしまう。肝要なのはあくまで「ソフトウェア構造全体としての安定性」を達成することだ。

おわりに

DIPについては、緻密に考えれば他にもいくつか議論になるポイントがある。特に、2つのモジュールを仲介する安定度の高い存在を、どのように定義するのか、どこに所属させるべきなのかといったあたりだ。 このような議論も緻密に検討していくことで、設計原則の働きを具体的に捉えることができる。引き続き検討してみたい。

ところで、今回行ったDIPの定義の改善では、もともとの定義文にあった「具象要素」を、DIPの表現により適切と思われる抽象要素に置き換えた。これは、日本語の文章に対して「具象ではなく抽象に依存せよ」というルールを適用したことに相当する。DIPはこの操作のソフトウェア版に相当するとも言える。安定した構造を生み出す普遍的な法則の共通性として興味深い。

 

参考

at-grandpa.hatenablog.jp

ajitofm 33でしゃべってきた

ご縁があってVOYAGE GROUPさんのajitofmに呼んで頂き、喋って(飲んで)きた。

ajito.fm

 

似たようなことを仕事にしている方々、いろいろ経験は違えど、似たような問題意識、そして似たような問題の認識など、奇妙なほど類似性の高い方々と、ストレートに質問しあったり、時にはカーブを投げ合ったりしながらも、思考を深掘っていくような会話ができるのは、本当に楽しい経験だ。

こういう会話のできる方々との付き合いは大事にしていきたいのと同時に、徐々に他の方々へ輪を広げてもいきたい。

ソフトウェア設計談義その他、懇親会や飲みのお誘いなどあれば、是非twitterでご連絡を。

ありがとう、カルテット

3年と7ヶ月勤めた株式会社カルテットコミュニケーションズを、10月31日をもって退職します。本日が最終出社日でした。

カルテットコミュニケーションズでは、システム開発部のエンジニア兼マネージャーとして、コードを書くことはもちろん、プロダクトのソリューション設計、利用部門との調整、および開発したプロダクトの運用など、プロダクトにおける上から下まで幅広く携わりました。加えて、チーム/組織としての動きの改善や、メンバーの教育、採用向けの試験問題の作成から評価といったことにも携わりました。システム開発部は10人に満たない小さなチームですが、本当に良いメンバーに恵まれ、さまざまな困難にぶつかっても乗り越えてきた、個々のメンバーのいろいろな個性が活きていながら団結力もある凄いチームだと、自信を持って言えます。私がこのチーム、この会社で仕事をした経験は、確実に私の自信を強く支えるものになっています。カルテットコミュニケーションズで一緒に仕事をしてくれたみなさん、本当にありがとうございました。

私がカルテットコミュニケーションズで働く以前、自分が設立した、社員が自分しかいない小さな会社で受託開発をメインにやっていました。そこでは、自分の技術力を上げて、効率よく品質の高いシステムを作り上げて納品するということが興味の中心であり、我ながらかなり上手くやれていたと思います。しかし、うまく仕事をこなしながらも、「なぜこんなシステムが必要なんだろう?」と疑問に感じる開発、「これをやる前に、別の所の仕組みを作ればもっとよくなるはず」という思いを押さえ込みながらの開発がポツポツと出てもいました。その度に、本当に解くべき問題が、自分の立ち位置からは手の届かない距離の場所にあるということに、ある種の絶望のような感覚すら抱くようになっていました。根本にアプローチできる立ち位置にいなければ、自分が納得できる仕事ができない。いつしかそのようなもやもやとした感覚がなんらかの閾値を超えて溢れ、ついには転職を決意しました。次に働く会社では、自分たちでビジネスをしていて、自分たちのビジネスのためのシステムを作っている、そんな会社で仕事をしたい。そこでなら絶望せず、有意義に仕事ができるはずだ。そう考え、カルテットコミュニケーションズに入社しました。そして最初に書いたように、素晴らしく有意義な仕事をさせていただきました。

このような恵まれた状況下で働けていたにも関わらず、なぜ転職するのか。それは、私自身が「タイミングをつかんだ」からという、理由にならないような理由です。私は今43歳です。本当の意味で大きなチャレンジを今しなければ、自分の人生はその類のチャレンジをしないまま終わるのではないか。そんな危機感が年々強くなっていました。私にとっての本当の意味での大きなチャレンジとは、より大きな組織での役割、グローバルな環境、大きなうねりの中での自分の価値の発揮、そして組織と自分のより大きな成功、これらのチャレンジに値すると自分が納得できるだけの報酬。これらすべてです。そのチャレンジにあてはまる「タイミング」を感じ取ったら、動くしかありません!

 

転職先は、株式会社メルカリです。

メルカリのバックエンドチームのマネージャー(エンジニアリングマネージャー)という立場で仕事をします。

この立場での私の個人的な夢は、チームメンバーの技術、チームメンバーの幸福、チームメンバーのアウトプットを、いずれも世界に誇れるレベルだと言えるようにすること。そしてそのようになった時に、自分もそのチームの一人のエンジニアとして技術に携わっていること。これを実現したいと思っています。

東京で開催されるいろいろな勉強会などにも、積極的に顔を出したいと思っていますし、いろいろな方とお会いしてお話したりもしたいと思っています。お気軽にお誘いなどお声がけください!