GSN の記述例〜RAMS(IEC62278)

「モデリングしてますか?」 今日は、産総研 (AIST: 産業技術総合研究所)の相馬さん、本日2回目になりますが、今回は、GSNの具体的な記述例を、ご紹介いただけるという事です。では、よろしくお願いします。  鉄道の機能安全規格 IEC62278 – RAMSのドキュメントをGSNで描いた例 産総研の相馬です。 本日は、鉄道の機能安全規格であるIEC62278、RAMSと呼ばれる規格のGSNによる記述について、ご紹介したいと思います。 まず簡単に、RAMSのご説明をさせていただきたいと思いますが、鉄道分野の機能安全規格の最上位のものになります。 ソフトウェア、ハードウェア、それから通信といった規格もありますが、それら全ての上位の規格となります。 RAMSは、全部で14の段階からなっており、コンセプト、それから実装等を経て最終的に廃棄の段階まであります。 この各14段階、それぞれを段階ごとに、今回はGSNによる記述を行いました。 今日ご紹介するのは、第3段階のリスク分析に関する部分です。それともう1つ、RAMSに関してですが、各段階で5つの構成要素からなっています。目的であるObjective、その段階へのInput、要求事項Requirementその段階で作成される成果物Deliverableと呼ばれるものです。そして最後にVerification、検証、といった5つの項目から必ず成り立っております。 では、どのように記述していくのか、まずは第3段階リスク分析のフェーズになりますが、このリスク分析のフェーズが十分行われている、実施されているという事をトップのゴールとしておいて議論を展開していきます。左側に関しては、RAMSの目的Objectivesがきちんと達成されている事に関する議論、右側は、入力が適切なものを持ってきているという議論になります。 このようにアーキテクチャーをまず決定してから、GSNを構成していきます。今日は、この上位概念部分のGSNの記述と、ある1つの目的に関する議論の部分を紹介します。 こちらが、IEC6788 RAMSの実際の記述内容になります。一部抜粋してきております。 まずはじめに、トップゴールを置いて、先ほど述べたように「目的が達成されているという議論」、それと「入力が適切であるという議論」に分解していきます。 更に、目的は、このように4つあります。全ての目的が達成されている、各目的に対して議論を展開すると。ただ、全ての目的とかいても、いくつあるのか、というのが分からないので、それをコンテキストで補うようにします。 実際に、4つの各目的が達成されているゴールを配置していきます。このように上位概念を構成していきます。 それでは、1つの目的である「十分なハザードが特定されている」というゴールに対する議論になります。 目的を達成するためにしなくてはならないこと、要求事項、それから、検証といった部分に記述されています。 例えば、要求事項、検証等から「どのような事を達成すれば十分なハザードが特定できているのか」、ここでは体系的な手法によるハザード特定が行われていること、さらにハザードの原因となる所に関して、全て網羅的に考慮されていること、そして実際にハザード特定を行う方の力量が示されている、ちゃんと力量を持った方が、ハザード特定を行っているということがサブゴールとして配置されます。 さらに、ハザード特定の方法に関しては、セーフティプランという計画で考えられていた方法通りのものが用いられていること、もしくは、ハザード特定の範囲がきちんと定義され、その範囲内で行われている事などが、コンテキストとして配置されております。 実際に行われたハザード特定であったり、力量を示す資料などが、Deliverable(成果物)として作成されておりますので、これらが、最終的なソリューションとして配置されるという事になります。 IEC 62788 RAMSをGSNで描くと、このような形になります。 […]

「アシュアランス・セーフティーケース概論」〜歴史的背景と制度〜

モデリングしてますか? 今日は産総研(AIST:産業技術研究所)から田口研治さんに来ていただいて、セーフティケースの歴史的背景やGSNについてお話しをいただきたいと思います。 では、田口さん、よろしくお願いします。 産業技術研究所の田口と申します。 本日はセーフティケースの背景から始まって、どのようにGSNという表記法が使われているかについて簡単に説明させていただきたいと思います。    セーフティケースの歴史的背景 まずですね、セーフティケースについて歴史的な背景を説明する際に重要な用語として「セイフティケースレジーム」という言葉があります。これは、セーフティケースというのは単にドキュメントではなくて、やはりその法規的な問題から始まって社会制度としてどのように安全性を保証するかという、相対的なものとして捉える必要があるということです。 セーフティケース自身は有名な話として、パイパー・アルファ(Piper Alpha)という北海の油田の事故から始まりました。 実際に北海の油田の事故においては、その結果ですね、Offshore Installations Regulationという実際に法制度として確立されたという歴史的背景があります。  セーフティケースの定義 セーフティケースの定義ですけれども、英国の防衛規格であるDefence Standard 00-56という定義においては、 「与えられた運用環境におけるシステムの適用に関して、安全であることを、強制的かつ理解可能、妥当な事例として提供する、根拠資料の集まりにより支援された構造化された議論」という定義になっています。 ここでやはり重要なのは「根拠資料の集まりにより支援された構造化された議論である」という、この点だと思います。  セーフティケースが義務付けられている産業分野、規格 実際にセーフティケースが義務づけられている産業分野、規格等は様々あります。 航空機関係では、EUROCONTROLというヨーロッパの航空機管制システムに関する安全性の保証に関するガイドラインがあります。鉄道関係では、Rail Yellow Book(レール・イエロー・ブック)というものや Railway Safety Case Regulations(レールウェイ・セーフティケース・レギュレーションズ)というような英国の規格があります。 国際規格としては IEC62425、ヨーロッパの規格ではEN50129という鉄道システムに関するセーフティケースの規格があります。また車載関係では、ISO26262というものがあります。 […]

GSN記法チュートリアル〜書き方のコツ〜

「モデリングしてますか?」 今日は産総研(AIST:産業技術総合研究所)の相馬大輔さんをお招きして、GSN記法のチュートリアルをお願いしたいと思います。では相馬さん、よろしくお願いします。   ありがとうございます。産総研の相馬です。 本日は、GSNの基本についてご説明をさせていただきたいと思います。    ゴール志向分析と似たようなトップダウンの手法 GSN、Goal Structuring Notationと呼ばれるセーフティケースを記述するための記法なんですが、York大学のTim Kelly等(Tim Kellyの対談ビデオはこちらから)によって開発され、FTAなどのゴール志向分析と似たようなトップダウンの手法になります。      GSNの要素 ノードとしては、基本的には、Goal、Strategy、Solution、Contextといったノードと、それらを繋ぐSupported by、In context ofといった矢印で、それらを繋いで形作ります。主張をStrategyやSub goalに分解し、最終的に、その根拠資料となるSolutionを配置して、その議論を構成するというものです。  専門的な知識を持たない人にも理解できるように明瞭に記述する GSNを描くときの注意点がいくつかございます。 Goal、Context、Solutionなど1つの要素に、複数の要素を含めない、内容をかかない、という事が注意点になります。 次に、明確に記述するという事ですね。 曖昧な2つ以上の意味に捉えられるような文章を書かない、きちんと定義されていない分に関しては、Contextなどをつけて、その意味を明確にするという事が必要になります。 GSNは、もちろん、システムや作ったものに関して専門的な知識を持った方が作りますので、議論の飛躍が起こりやすくなります。 ですので、読む方は、専門的な知識を持たない可能性もあるので、きちんとワンステップずつ議論を構成していかないといけない、というよう注意点もございます。    できるだけシンプルな議論構造に また、GSNの描き方、議論の構造に関してですが、よくコミュニティスタンダードの方でも出てくる「各ハザードに対して、それが対抗されている」といったような議論をかく事が多いのですが、実際には、それらは根拠資料の中に入っている事になりますので、それよりは、もう少しシンプルに、「こういう考えで全部に対して対抗されている」、ということであれば、その根拠資料だけを配置する、といったシンプルな書き方の方が良いと思います。 […]

技術レビューの現場におけるGSNの活用法(2)〜相手と自分の共通理解をつくるには

「モデリングしてますか?」 DENSOクリエイトの小林さんを再度お招きして、GSNを使ってレビューをする際に問題となる「共通の合意の作り方」についてお話ししていただきたいと思います。では小林さん、よろしくお願いします。   前回「議論においては、前提を相手と合わせる事が大切だ」とお話させていただきましたが、今回は、そこについて簡単に紹介させていただきたいと思います。 まずはじめに、相手と自分の、議論の前提の認識が合っているかどうか、という状況を図示すると、おそらくこういう4ディションになるのではないかと思います。  自分と相手が共に知っている状態 1つ目については「自分と相手が共に知っている状態」。ここは、実際の開発現場で考えると、相手がずっと仕事をやってきて、自分も一緒に仕事をやってきた、というのが、このディションになるのではないかと思います。  相手は知らず、自分のみ知っている状態 – しっかり教える 「相手が知らなくて、自分が知っている」所というのは、自分たちの技術に、お客様が非常に関心を持ってくれている、「新しく仕事を始めよう」という状態、あるいは、お客さんの方の窓口が変わった、という場合は、こういう所になります。 ここでは、自分の知っていることを相手にしっかり説明しておかなければ、相手が、いつまで経っても「自分のこととして仕事に取り組んでくれない」とか「中を見てくれない」といったことになるのではないかと思います。  相手のみ知って、自分が知らない状態 – しっかり教えてもらい明文化する 「相手が知っていて、自分が知らない」という領域については、お客さんが長らくやってきた製品開発の中で、自分たちが参入する、という場合になると思うのですが、ここの前提もしっかり合わせておかないと、後になって「なぜこんな事も分からないのか?」というような話があがるかもしれません。 そういうリスクがあるので、ここの領域については、相手にしっかり教えてもらって、明文化するという事が必要になると思います。 前後しますが、ここ (相手が知らず、自分のみ知っている領域)は「教えてあげる」という事がいりますね。  自分も相手も知らない状態 – 一緒に前提を作り上げる 最後に「自分も知らずに、相手も知らない」という領域については、相手と自分が一緒になってまずは前提を作っていくという作業があって、それに基づいて仕事を始めるとうまくいくのではないかと思います。 ここは「一緒に作り上げる」ということが大切ではないかと思います。 議論自体は、こういう形になると思ってます。  議論の周囲にある「相手と合意しているもの」を明らかにしてから議論を形作る 議論の対象がこのスコープだとします。その時に、先ほどのモデル(相手と自分の状態)を念頭に置きながら、どういった前提文書があるか、相手と合意形成されている前提文書や証拠文書、こういったものをしっかりと洗い出すことが、まず大事だと思います。 その上で、議論の対象となるもの、「何を主張したいか」ということ、例えばこの主張が妥当であることを証明したいのであれば、前提文書等を用いて、この主張を分解していき、相手と合意形成をできる証拠文書に基づいて、ここを証明する、と、こんな形で先ほどの議論モデルを念頭においてまとめてくると、GSNでこういった形で伝わるのではないかと。 そこが合ってることによって、共通理解をもったGSNを書いて、相手に納得してもらえるのではないかと、そういうことを考えています。 はい、ありがとうございました。 […]

技術レビューにおけるGSN, D-Caseの現場活用法(1)〜レビューの前提となる基準を作る

モデリングしてますか? 今日は、DENSOクリエイトの小林さんをお招きしてGSNを現場のレビューで活用する、という例についてお話をしていただきます。 では、小林さん、よろしくお願いします。   クリエイトの小林です。今日は、平鍋さんに機会をいただきましてGSN(Goal Structuring Notation)の現場活用についてお話させていただきます。    GSN(Goal Structuring Notation)の記述ルール 先ずはじめに、GSNの簡単な記述ルールですが、GSNとは、トップに自分の主張したいものの状態を置きまして、それを、相手と合意形成している前提に基づいてサブの主張に分解していく、と、最終的に、そのサブの主張が、証拠に基づいて証明される、といった記法になっております。  GSNを使って解決したいこと 実際これを開発現場で、どう活用していこうかという事なんですが、現状は、現場が抱えている問題としまして、皆様もよく感じられる事があると思うのですが、上位の方が、部下の成果を見た時に「この内容って、何でこういう形になってるの?」という事が分からない、とか、そういった話がよくあると思います。又は「僕の思った通りに作ってくれないじゃないか」といったような事もあるんじゃないかと思います。また部下の視点からいくと、上司の人に見てもらったんだけど何回見てもらってもOKがでない、といった事もあるように思います。 それを簡単に図示した絵が、こちらの絵になるのですが、この絵の中では、作成者の方が、成果物を、自分の考えに基づいて作成し、上位の方も、自分の経験に基づいて確認する、といったことになっています。 当然ここで、上位の方と部下の方、作成者の方ですね。ここの考え方というのが合ってるはずがないので、その結果、度重なるやり直しとか、手戻りといったことが発生しているのではないかと考えております。 そうしたものを解決するために、一番簡単なのが「上司の方と部下の方の認識を合わせる」「考え方を共通化する」という事が大事だろうと。 ですので、こちらの図に書かれていますように、色んな基準というものレベルがあると思うのですが、それを上位と会議の担当者の方と合わせることによって、作成者の方はその基準に基づいてものを作り、上位の方は、その基準に基づいて成果物をレビューする、と、そうすることによって、手戻りなく、うまく仕事ができるんじゃないかなという風に考えて、こういった活動を現場に投入していこうと、いま考えております。 GSNを使って解決する方法としましては、こちらの図に示しましたように、相手と自分の考え方を共通化する、という上司と部下の認識を合わせることによって、部下の方は、成果物をそれに基づいて作成し、上司の方は、それに基づいて部下の成果を確認する、という仕組みを作ることで、うまく仕事が回るようになるのではないかと思っております。 ということは、このコンテキストの所に、「基準」というものを書いていく、ということによって全体の考え方が、上司と部下、あるいはレビュイーとレビューワーの間で合意を先に作っておく、ということで、このGSNが、よりレビューしやすくなるという風に考えればいいですね。 この続きについては、次のビデオでご紹介します。

【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x 平鍋対談

 最近のGSN(Goal Structuring Notation)の動向 では、先生、最近のGSNの動向について、少しお話をいただけませんか?     最近、我々がまとめたのが… お、これは!     DEOSの本ですね。所さん(所眞理雄氏)が中心になって、7年間のプロジェクトの成果がまとまったんですね。それが、このDEOSという本です。この中に「ディペンダビリティ工学」というのがあるんですけど…   これは、新しい名前ですか?「ディペンダビリティ工学」?     そうですね。「Dependability Engineering for Open Systems」という事で、変化し続けるシステムのためのディペンダビリティ工学。その変化し続けるシステムのディペンダビリティ、信頼性を保証するために、ここに図があるんですけど(右下画像)、D-Caseが使われています。D-Caseは、GSNを拡張した表記法ですね。   これは日本で書かれた本ですか?     はい、日本で書かれた本です。この取り組みを、オープングループというエンタープライズアーキテクチャの標準化をやっている組織があるんですけど、そこに我々が一緒になって提案しています。それは、エンタープライズアーキテクチャを高信頼化するための手法で、GSNが、本格的に採用されています。そういう動きがあります。    ISO26262の機能安全の中で、GSNは標準的な表記法として採用されている 先生は、GSNに着目された、”D-case“として、DEOSの中に持ち込もうとされた着目の動機みたいなものはありますか?   それは、「受け身」で始まったんですけど。笑。 […]

GSNとD-Case、パターンとモジュール化、日本流の差分・派生開発への適応

「モデリングしてますか?」 今日は、電通大(電気通信大学)に来ています。ここに、松野先生がいらっしゃいます。   みなさん、こんにちは。電気通信大学の松野と申します。 今日は、わざわざ平鍋さんに調布まで起こしいただきまして、今撮影しています。    GSNのおさらい 今日はですね、山本さんが前回話したGSN、アシュアランスケースの話の続きです。 GSNというのは、アシュアランスケースの記法の一つで、システムの安全性とかディペンダリティを、色んな人にきちんと説明するためのドキュメントです。 例えば「システムが安全ですよ」など、色んな人に説明しないといけないんですけど、いろんな説明の仕方があります。GSNは、それを、議論構造を明確にした上で説明できるようにしたものです。 この場合「システムが安全である」というゴールがあるんですが、いろいろ言い方があります。ここでは、システムが持っている機能ごとに分解して説明する、としています。 システムが機能1と2を持っていた場合、システムが安全であるためには、機能1が安全、機能2も安全、という風に分けて考えていきます。 最後にどんどん詳細化していくんですが、最後にテスト結果とか、皆さんが普段やられておられるテスト等の結果を基に、最終的に議論を支えるものを書きます。  パターン機能 さて、こういのをどんどん描いていくわけで、astah* GSNなどを使ってかいていくわけですけども、こういのをバーとかいていくと、どんどん量も多くなっていくし、しかも、これを形自体をどう形作っていけばいいか、ということが問題になってきます。 プログラミング言語、みなさん詳しいと思うんですけど、そうした問題にどう対処していくかというのは、GSNでも一緒です。 1つは「パターンにしてしまう」ということ。要するに、すごく頭いい人が作ったGSNのパターンをそのまま使って、皆さんのGSNもかいてしまえばいい、という話があります。 例えば、簡単な図なんですけど、このシステムを変数として扱うことができます。 例えば、ここに、皆さんの作っている自動車、飛行機、ご自身のシステムの名前をいれるということがあります。また、機能毎といってますが、当然皆さんのシステム毎に、機能の種類や数が全然違いますよね。ここら辺もパターン化して、汎用化するという仕組みも挙げられます。 たとえば、このパターンにありますが、このシステムという所自体を変数化してしまう、という考えがあります。安全と書きます。このシステムというものをプログラミング言語のように変数宣言してしまいます。 システムはストリング型であると、そうすると、ここで定義したシステムというものは、サブゴール、つまり下の構造で、システムというものの変数を自由に使えるようになります。たとえば、システムの機能ごとに議論する、といった事ができるようになります。 ここでもし皆さんが「自分のシステムの名前にしたい」と、車など入れたとしますね。 そうすると、ここでシステムとなっていた所が、自動車、という風に置き換えられます。 こうすると、皆さんがいちいち自動車、自動車、自動車、、と書かなくても、一気に全部変わるわけですね。これが、パターンを実現するための機能になります。 もう一つ、例えば、自動車だったとしたら、機能1、2、3があって、「自動車の機能毎に安全である」というゴールを作らなければいけないんのですが、ここで、機能が100個あったとします。ここで100と指定すると、パターンとすると、ここに100個のサブゴールが作られる、こういうことを実現すると、非常に汎用性の高いパターンを作ることができます。 これがパターン機能です。  GSNの巨大化を防ぐ為のモジュール化 もう1つ、GSNに対しての拡張として「モジュール化」という考えがあります。 モジュールは、みなさん普段プログラム作る時にやられてると思いますが、例えば「機能1は安全である」ということを展開するとします。すると、これだけでもサブがどんどんと果てしなく大きくなっていって、巨大なGSNになってしまいます。 […]

介護補助システムの設計(2) ブロック定義図編

チェンジビジョン astah* SysML製品プロダクトオーナーが「介護移乗補助装置」を題材に、SysMLモデリングを紹介するコンテンツの2回目です。 前回のSysML要求図に続き、今回はブロック定義図およびブロックと要求間の関係の描き方、ブロックや満足(satisfy)などのモデルを解説します。 ■SysML動画シリーズ (1) 要求図 (2) ブロック定義図 (3) 内部ブロック図 (4) パラメトリック図

GSN解説(2) – GSNの基礎とその構成要素

こんにちは。名古屋大学の山本修一郎です。 GSNは「あるシステムやプロセスが、基準を満たす」ということを説明するための手段です。 ですので、まず「主張」というものがあります。 この主張は、システムや基準、原則がありまして「こういうシステムや基準を対象にして、システムが、ある基準や原則を満たす」ということを説明するための手段です。 これを説明するためには、例えば「システムの構成で説明する」という事になります。 そうすると、システムの構成というのは、例えばこのシステムには構成要素があるので、 「構成要素がこの基準や原則を満たすこと」と 「構成要素の関係が原則を満たす」 この2つを説明する必要が有ります。 それぞれについて、確かに関係が原則を満たす客観的な「証拠」があります。要素についての証拠もあります。 そうすると、今度はこの要素に基づいて、確かにシステムが、こういった原則を満たしているということを、第三者に対して論理的、合理的に説明することができます。 これが、GSNの最も基本的な考え方なんです。 [関連記事] – GSN解説(1) – GSN (Goal Structuring Notation)とは何か? – 【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x 平鍋対談

介護補助システムの設計(1) 要求図編

チェンジビジョン astah* SysML製品プロダクトオーナーが、「介護移乗補助装置」を題材に、SysML要求­図の描き方を解説します。 [スクリプト] このシリーズでは、介護現場における移乗補助システムの設計を想定して、V字プロセスに沿ってSysMLモデリングの図を描いていきたいと思います。 移乗介助システムにおいて、この二つの要求があると考えられます。 各要求においてIDがあります。 そして、各要求において概要もあります。今回は概要の内容を省略します。 腰痛リスクを軽減するために、腰の負担を軽減しないといけないため、この二つの要求の­間に導出関係があります。 V字プロセスにおいて、要求段階で洗い出した要求に対して、検証段階において、必ずそ­の要求の妥当性を検証しないといけないため、非介護者の体重を反映したアシストが可能­というテストケースが登場します。 このテストケースによって腰痛リスクを軽減する要求が検証されます。 この一連の要求とテストケースを実際に要求図で描いていきましょう。 要求図を描いていきましょう。 ここに要求のアイコンがあります。 ここをクリックして要求を作成します。 astahでは、図面をダブルクリックしても要求を作成できます。 さて、要求の名前を編集しましょう。要求のIDと要求の概要も編集しましょう。 さて、もう一つの要求を作ります。 今度はプロパティビューから要求名などを編集しましょう。 この二つの要求の間に、導出関係があるため、導出関係を作成します。 ここに導出のアイコンがあります。 astahでは要求をホバーして、ドロー・サジェストから導出関係も作成できます。 要求を検証するためにテストケースを作成します。 ここにテストケースのアイコンがあります。クリックしてテストケースを作成します。 テスト名、テストケースの名前を入力しましょう。 テストケースと検証する要求の間に、検証関係があるため、この検証関係を作成します。 ここに検証関係のアイコンがあります。クリックして検証関係を作ります。 ここに色を設定するためのアイコンがあります。クリックして色を設定します。 要求図で作成した一連の要求を要求テーブルで表示することができます。 さらにこの要求テーブルをExcelのファイルに出力することもできます。 […]

GSN解説(1) – GSN (Goal Structuring Notation)とは何か?

みなさん、こんにちは。これからお話するのは、説明責任とGSN(Goal Structuring Notation)の関係についてでございます。  「システムや活動プロセスといったものが、ある一定の基準や原則に基づいてることを第三者に説明する」、これが説明責任の遂行 説明責任て、皆さん、何だかご存知ですか? 「システムや活動プロセスといったものが、ある一定の基準や原則に基づいていることを第三者に説明する」というのが、説明責任の遂行という考え方ですね。 ということは、我々が開発しているシステムがあるとします。 すると「このシステムが、ある原則に従って開発されている」という事を説明する手段が必要になります。 その説明手段がGSNである、と言うことができると思います。 ということは、GSNで説明することは「システムが原則に従っていること」、これを説明する必要があります。  GSNの4つの基本的な構成要素 そのために、GSNでは、4つの要素を用意しています。 1つは「主張」ですね。「システムが原則に従って振舞う」といったことです。 それから、その主張を直接説明することは、なかなか難しいので、更に細かな主張に分解する必要がでてきます。その時に使われるのが「戦略ノード」と呼ばれるような、分解するノードです。 それから、更に、「システムが原則に従う」ということを説明するために、どのような前提条件に基づいてこの議論が展開されているのかを示すための「前提ノード」というものがあります。 それから最後に「確かにシステムがこの原則に従って振舞う」ということを説明するための、もっとも単純な主張を説明する「証拠」がでてきます。 そういう意味で、GSNには、この4つの基本的な構成要素を使って、こういう主張を説明することができます。 これが、GSNを使って説明責任を遂行する方法です。 [関連記事] – GSN解説(2) – GSNの基礎とその構成要素 – 【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x […]

【対談】「これだけ」モデリング – Part 1/2

「これだけモデリング」は、なぜうまれたか - 対談その1。 UMLの仕様を全部使ってモデリングするなんて、無理。モデリングという「活動」を通して参加者に「残像」を残すことが重要。

「これだけ」モデリング – Part 2/2

「モデリングしてますか?」 今回は、前回の続き「これだけモデリング」ですが、アジャイル開発の中で、もっとモデリングを使おうという話をしていただきます。「これだけモデリングは、アジャイルを加速する」という事で、山岸さん、よろしくお願いします。   皆さん、こんにちは。メソドロジックの山岸です。 今日は、「これだけモデリングは、アジャイルを更に加速する」というテーマで、お話をさせていただきます。  アジャイルとモデリング 最近、アジャイルが非常に盛んになっておりますが、そうした中で「アジャイルは、ドキュメント削減するんでしょ、だからモデリングやりません」という混乱が散見されており、そこが随分違うなと、私は思っています。 アジャイルといっても、最近のアジャイルの話題は、エンタープライズにどう適用するか、です。アジャイルというと、スプリントのサイクルのところに話がフォーカスされる、つまりプロダクトバックログを作ってから以降の話、という事です。 ただ、エンタープライズというのは、色んなシステムが複雑系を成しているというか絡み合ったもので、且つデータの移行などの複雑なもので、対象も複雑な業務なわけです。  スプリント以前のモデリング ですから、一定のリズムでアウトプットを出していくというようなスプリントのサイクルに入るまでの所、つまり、バックログを積むまで、にやっておかなければいけないことが、沢山あるんです。 実際に、1番重要なのは「業務を正確に把握する」というところですね。そこで、モデリングは非常に有効に働くと私は思います。 スプリントに入ると、非常に高速になるわけですが、そこに至るプロセスをできるだけ素早くやっていくという部分は同じだと思うのですが、業務を更に素早く把握しようとするとモデリングの力を借りざるを得ない訳ですね。 モデリングによって、先ずちゃんと地図を描いておくこと、それからエンタープライズの場合、システムを長期に渡ってメンテナンスしていくという意味では、やはりアーキテクチャを、きちんと設計した上でスプリントのリズムに入っていかなければいけない。 という事で、この辺りは、モデリング無しで素手でやれるような領域ではないと考えています。 更に業務を正確に手早く把握するためには、モデリングの力を十分に活かさないと、まず難しいでしょう。  スプリント中のモデリング 実際のスプリントに入ると、設計者と実装者は変わりませんから、同じメンバー間のコミュニケーションを高める、という意味では、わざわざUMLで設計書を描いて、それをベースにコーディングする、というような情緒なサイクルではなく、「素早くやる」という事であれば、全体の構造をちゃんと理解した上で、それを時々見る、ということで、最初の段階でモデル化したものを参照しながらという事になります。 また「コミュニケーションを活性化する」という事は、アジャイルの中で非常に重要なわけですが、言葉より伝わる、というモデリングは、スケッチとしてあるわけですよね。いくら言葉で言うよりも、お互いが共通理解しているノーテーションで描いた方が、よっぽど早く伝わる。その方がよっぽどアジャイルだ、という話が、1つあります。 そういうところで、モデリングを使うと、更にスピードが加速する事ができます。  リリース後、運用準備のモデリング それから、リリース後、エンタープライズというものは、ずっと使い続けて進化し続けますから、次の開発者に委ねていかなければいけないくらい寿命が長いものですね。ですから、その所では、設計の重要な情報というのをモデルのようなものを使って、保守していかなければならない。 「エンタープライズアジャイル」という領域でも、アジャイルをより加速するというポイントで、モデリングを設計する必要があると考えています。  要求獲得のためのダイアグラム それで、実際に何を使うのかというと、業務の要求獲得というか要求開発のためのモデリングというのは、簡単に言うと、この3つですね。 つまり、そもそもその業務で何をするのか、それが、どういうもので構成されて、それがどう動くのかを、表現するという事が、ここで必要となるいう事ですね。 そして、実際には、何をするのかっていうと、ユースケース図で表現しますし、誰がどうやって、という部分は業務フローで表現します。何で構成されているかは、概念クラス図で描くという事が基本になります。その場合も、ここに挙げましたような限られたノーテーションを出来るだけシンプルに使って表現する事が非常に重要です。  関わる人に「残像」として残るモデリング、これがベスト という事で、ここで重要なところは、あくまでも「業務理解のためのモデリング」という事で、抽象度を上げすぎて、”そもそも”みたいな話をしても、業務の特徴を表すことはできませんので、やはり、一定の業務イメージとか具体イメージを表現できるレベルにしておかなければいけないという事です。 それから、概念モデルを、そのまま設計モデルや、トレーサビリティを維持したままデータモデルやクラスの実装言語の設計モデルに持っていこうという考え方は、あまり考えない方がいいと思っています。 […]

「これだけ」モデリング – Part 1/2

モデリングしてますか? 今日は、メソドロジックさんにお伺いして、山岸さんが提唱されている新しいコンセプトである、「これだけモデリング」について、お話をしていただきたいと思います。 それでは山岸さん、どうぞよろしくお願いいたします。 こんにちは、メソドロジックの山岸です。今日は「これだけモデリング」という話を、短い時間ですが簡単にご説明させていただきます。    モデリングの威力はすごい。しかし,これだけ役立つのに、なぜ使われていないのか? 私は、20年前にブーチ法というものに出会って、モデリングを知ったのですが、それから今まで自分が関わったプロジェクトでは、大体モデリングをやってきたという経験があります。今となっては、モデリングせずにプロジェクトをやるのは、素手で戦っているというような感じで、非常に違和感があり、凄く野蛮な気がします。 UMLが出てきて既に15年以上経っていますが、これだけ役に立つものなのに、なぜか意外に使われていない、という事に驚きを感じています。 というのは、モデリングが、どれくらい役に立つものか、という事が、あまり分かってないんじゃないのかというのも1つですし、あとは、導入のハードルが高いと思ってる人が多い。あるいは、使い方が間違ってるんじゃないかと思われる時もあります。 要は、かけてるコストに対して、ちゃんとしたリターンを得てないのではないかと思います。コストパフォーマンスを十分取れてないから使わない。今まで(モデリング)無しでも、物が作れているかどうかは、ともかくとして、無しで作っちゃってる、という技術があります。あえてここでモデリングを勉強して、更に、今までやってない作業を加えてプロジェクトを回す事に対して、皆さんは、あまりメリットを感じないかもしれませんね。加えて、最近のアジャイルブームで「ドキュメントを書かない」という流れの中でモデリングもやらないみたいな混乱、もあると思います。 私が思うに、「場に合わせて、適切なレベルでモデリングをする」というのは、非常に効果が高いと思います。 それを、皆さんは、今日この場でお勧めしたいと思います。  モデリングが根付かない理由 悪い例からお話しますと、そもそも皆、生真面目にやりすぎている。UMLは13種類のダイアグラムがあるんですけど、それに対して、それぞれの図の表記に困ってしまっていて、「それを逐一勉強した上で、プロジェクトに取り掛かろう」とか、どのレベルの詳細度まで描くか、をあまり考えないで“やたら”描いてるという事が、多々見られるわけですね。 やはり「小難しくし過ぎてる」というのは、一つあると思います。 非常に細かいレベルまで表記方法にこだわって描いていくことや、抽象度をすごく上げて、”そもそも”というレベルのモデルを描いても、描いたモデルは、返って伝わらなくなりますね。 私は、よく英語に例えるのですが、”一番通じるレベル”があって、例えば国際語としての英語というのは、必ずしもネイティブのような英語を喋ってても、他の国の人には伝わらないわけですね。なので、“このレベルで使うと、1番よく伝わる“というレベルがあるんですよね。そして、モデリングしてきた人は、誰が取り決めたわけではないけれど、一様に”このレベル”という感覚が、共有できてると思っています。 ですから、そのレベルのものを習得して、逆にそれ以上のものは使わない、というような、そういう“ほどいい使い方”を、皆さんにお勧めしたいと思っています。 そもそも、そういう風に生真面目にやったり、難しくしすぎちゃうのは、何のためのモデリングをしているのか、という所を見失っているケースが多いですね。  モデリングの目的を明確にして、自分たちの「ほどよい」レベルを見つけよう モデリングの目的は、大きく幾つかあると思っています。 1つはやはり、「物を理解するため」にモデリングするという事ですね。 理解についても「全部を理解する」と「複雑な詳細を理解する」という、理解のためのモデリング。それから「伝達するため」、「記録するため」そういった目的もあります。 他の言い方をすると、スケッチとしてのモデル、設計書としてのモデル、プログラム言語としてのモデルなど、色々なレベルの使い方もあります。 それから、扱い方にしても、描き捨てるのか、中間生成物として使っていくのか、最終成果物として残すのか、あるいは保守資料としてメンテナンスまでするのか、そういったものが分類としてありますね。 ですので、今、モデリングをしようとする時に、どういう目的で、何のために、どの程度描いて、この先どう扱うのかというところを決めると、おのずと”ほどよいレベル”というのが定まってきます。  UML13種図のうち、4図だけ使えばいい 図としては大体このくらい知っていればいいでしょう。13種類あるうちの4つを知ってればいい。 ただし、図を使うシーンがあります。他えばクラス図だと、概念クラス、設計クラス、データ設計図など。クラス図だけれど、使うシーンによって使い方が違います。こういう所を意識して、黄色く塗ったあたりを、特に皆さんには必ず習得して欲しいですし、ここに挙げたところが標準的に使っていただければいいんじゃないかと思っています。 あとは、各ダイアグラムにしても、細かく色んなノーテーションがあるので、ダイアグラムごとに「この程度のノーテーションを使いましょう」というお勧めなレベルもあります。 […]

パターン編(3) 分析・設計パターンの重要さと書籍紹介

当「モデリングしてますか」チャンネルの”パターン編”の意味、なぜパターンを知っておくことがよい­モデリングにつながるのかについて解説します。世の中には、ソフトウェア開発活動に役­立ついろんなカテゴリのパターンが存在します。分析パターン、設計パターン、実装パタ­ーン、アーキテクチャパターン、などなど。お薦めの書籍とともに紹介します。 [スクリプト] モデリングしてますか? 今日は、パターン編という事で、ソフトウェアのパターンの重要性について、最初にお話ししたいと思います。 パターンとは? パターンとは、歴史を話すと凄く長くなるので、今日は話しませんが、ソフトウェアの色々な開発活動の中で、よく行われている例(パターン)が、いくつもあって1つのパターンを形成します。こういう風にやるとうまくいくんだ、というものに名前をつけて、集めてくる手法です。 例えば、実装のコードレベルのパターンもあれば、設計レベルや、分析レベル、ビジネスレベルのパターンもあり、非常に広範囲に使われる言葉です。 パターンとは、「名前」と、「名前が使われる文脈」と、「解こうとしてる問題」があって、「解決」があります。 だから、「文脈」、「問題」、「解決」をセットにして名前を付けたもの、という言われ方をしますが、基本的にはコードのように、固い再利用ではなく、考え方や知識を再利用するフォーマットになります。 デザイン/設計/ビジネスで使用されるパターン 1番良く知られているのが、この「オブジェクト指向における再利用のためのデザインパターン」という、95年に書かれた本です。ソフトウェアの中で、パターンが非常に花開くきっかけとなった本です。この本が書かれる前に、James o. Coplienが「Advanced C++ Programming Styles and Idioms」という本の中で「イディオム」として、実装のパターンを解説しております。 それから、Kent Beckの「Smalltalk Best Practice Patterns」ですが、これも実装レベルのパターンとして、非常に有名です。後にKent Beckは、Java版に書き直して、「Implementation Patterns」という本に変えています。これは実装のパターンです。 それから、分析に入ると、1番有名な本としては、「アナリシスパターン―再利用可能なオブジェクトモデル」で、Martin Fowlerが書いた本です。この本は、分析レベルで現れるパターンについて、書かれており非常に分厚い本です。 おそらく、これが書かれるおおもとになったのは、インフォメーションエンジニアリングという言葉を作った、James Martinの「オブジェクト指向方法序説〈基盤編〉」です。James J. […]

パターン編(2) 顧客、注文、商品をつなぐ「モノ – コト – モノ」パターン

チェンジビジョン平鍋が「リソース系の顧客および商品、とイベント系の注文をつなぐパ­ターン」を易しく紹介します。 前回の「パターン編(1) 注文書を表現するヘッダー明細パターン 」の続きです。 モデリングしてますか? 前回は、ヘッダー明細パターンという事で、「注文」と、「注文明細」、もう少し詳しくいうと、このような「注文書」の中で、この「注文明細」と、全体の「注文」の関係について解説をしました。今回は、前回登場しなかった「商品」という概念について、今回は詳しくお話ししたいと思います。 「商品」という概念とは? ここには「注文明細」とありますが、注文の1行は、1つの商品と紐付いています。 そのため、「商品」という概念を登場させます。 このように注文明細の中にある「タオル」という注文に対して、「単価」「数量」「金額」がありますが、この「商品」をモデリングすると、このようになります。「商品名」と「定価」という風に、データ構造しておきます。 ここで、「単価」と「定価」は重なるのですが、場合によっては「定価」から値引きをする場合があるので、このような形にしておきます。「注文明細」から見ると、「商品」は1つと決まっていて「商品」から見ると、「注文」は複数対応する事があるというパターンになります。 「モノ – コト – モノ」パターン ここからが面白いんですが、両脇にある「顧客」と「商品」は割と長く存在しているものです。 「注文」とは、一時のものです。 このような「顧客」や「商品」の事を、「リソース」という言葉で表す事があります。 それから、「注文」は、寿命が長い2つのオブジェクト(リソース)の間にあって、一時のトランザクションを示すものを、「イベント」と呼ぶ事があります。このように2つのリソースを、結びつけて1つのイベントが起こるというパターンは、非常によく起こる事ですね。 ここをヘッダー明細パターンといいましたが、色々よび方がありますが、この事を、児玉さんは、「モノ – コト – モノ」パターンという非常に良い名前をつけています。 また、企業の情報システム構築のデータ構造では、このパターンは非常によく出てきます。 リソース2つがあって、真ん中にイベントがある。特徴は、イベントには必ず「日付」があるという事ですね。 それから、前回お話しできなかったのですが、この「注文明細」の合計が「注文」になります。そのため、「注文金額」というのは、実際には「注文明細」から掛け算して、足し合わせたものになるので、自動的に決まりますね。これを、「派生属性」と呼んで、斜線で表します。 応用がきくパターン まとめると、よく見る「注文書」とは、1つの注文の明細になっています。「件名」と「金額」が、1つの注文になっています。 […]