モデリング

2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

| | コメント (0)

2018/05/25

「大学生・社会人のための言語技術トレーニング」の感想

「大学生・社会人のための言語技術トレーニング」の本がとても良かったので、感じたこと、考えたことをラフなメモ書き。
自分の考えと感想を混ぜて書いているので、ロジカルでない。

大学生・社会人のための言語技術トレーニング - 発声練習

医学書院/週刊医学界新聞(第3054号 2013年12月02日)

7月の言語技術教室: タイガ日記

言語技術の有効性 三森ゆりかさん | 女王様のブログ

【0】書店に行くと、ロジカルシンキングや論理的思考の書籍がたくさん並んでいるし、たくさん売れている。
なぜ、そんな本が売れるのだろうか?

「大学生・社会人のための言語技術トレーニング」を読んだ後、たぶん、日本人は小学校から大学まで論理的思考の訓練を習得しないまま就職して、実際のビジネスで数多くの論理的思考を使う場面に遭遇するので、慌てて勉強し直す必要があると感じているから、と思った。

【1】ロジカルシンキングとかクリティカルシンキングとか、色んな本を読んできたけれど、「大学生・社会人のための言語技術トレーニング」を読んで、ようやく、日本語での思考と英語での思考では方法が違うのだ、という事がよく分かった。
もちろん、英語でも日本語でも、言語を使うのだから、論理的な思考を行う方法は双方とも適用できるし、同じ結果も得られる。

しかし、日本語というツールは、その内包する弱点を特に意識しなければ、たぶん、論理的に思考する時に数多くの落とし穴にはまってしまいがちなのだろう、と感じた。

【2】日本語の最大の弱点は、主語なしでも書けること。

【2-1】「私は」「あなたは」「彼が」という言葉を使わなくても、自分の主張を公表できる。
むしろ、日本語では、「私は~と考えます」といつも使っていたら、自己主張が強すぎ、のように思われて、引いてしまう雰囲気になる。

しかし、英語だろうが他の言語では「I think~, because~」という表現は普通だ。
そういう構造が言語に埋め込まれていれば、自然な発言が自己主張につながるし、自分の立場を明確に公表する、という言動につながっていく。

日本の小学校・中学校の国語の試験問題を見ると、「この文章の主語は誰でしょう?」みたいな問題があったりする。
こういう主語探しの問題は、英語ではありえない。

日本の文学では、主語なしの文章で、故意に複数の解釈を埋め込む技法もある。
例えば、川端康成の「雪国」の最初では、トンネルを抜けたら雪だった、という文章の主語を故意に省略し、後で、主人公の発言であったかのようにストーリーが進む。
しかし、こういう文学的技法は、政治やビジネスのように交渉する場面では全く不要。

日本人は自己主張が弱い、という理由は、たぶん、「私は~と思います。理由は~だからです」という文章が日本語の構造として形式的すぎて、日常会話で話すと不自然に感じてしまう、という弱点があるからだろう。
よって、「主張→根拠→結論」という一般の3段階論法を、日本語で自然に話すのが、上手くフィットしない雰囲気を感じてしまうからだろう。

【2-2】「大学生・社会人のための言語技術トレーニング」で興味を惹いた点は、中学生向けのドイツ語の小説で、文章の主語が3人称→1人称→3人称に変遷する時に、読者である中学生がその文章の主人公に意識を挿入しやすいことがある、という指摘。

実は、その小説で男の心理を3人称で語っている文章は、第三者的視点で客観的に語っているのだが、1人称で語っている場面では、男の心の中の動きであり、主観的であり、実は狂気な言動、という仕掛けになっている。
つまり、中学生は、日常生活ではありえない狂気の男性の心の中に入り込むことで、小説内で疑似体験しているわけだ。
そういうテクニックもあるらしい。

【2-3】他の日本語の弱点として、時制がないという点もある。

「大学生・社会人のための言語技術トレーニング」の一節では、ドイツの小説には過去形の文章が続いた後で、現在形の文章に急に変わった場面がある。
実は、過去形の文章は他人事だが、現在形になることで読者がその状況に入り込むことで、小説内で疑似体験するように仕向けている、と言う。

しかし、そういう技法を日本語で翻訳しようとすると、変な日本語になってしまって読みづらい、という事もあるのだろう。

【3】「大学生・社会人のための言語技術トレーニング」で「説明の黄金律」というものが紹介されている。
空間配列、時系列、重要度(度合い)の3つだ。
この考え方をドイツでは小学生低学年から叩き込まれるのに、日本の小学生は国語でも習わない。

【3-1】特に、空間配列(Spacial Order)という考え方を日本人は意識していない。
これは構造の順序そのもの。
説明の順序は、外から内へ、大から小へ流れる。

しかし、日本人のよくある説明は、空間配列の順序で整理して話さないために、あちこちの論点に散在する説明になってしまい、主張や結論が曖昧に聞こえてしまう。

「大学生・社会人のための言語技術トレーニング」では、フランスの国旗の説明で空間配列を説明せよ、という問題があり、良い回答と悪い解答の比較が非常に面白い。

また、「大学生・社会人のための言語技術トレーニング」によれば、絵の分析は、空間配列の考え方の強化に最適らしい。
絵の分析は、事実と意見の違いを明確に区別する訓練にもなるらしい。

たとえば「偉大な物理学者アインシュタイン」という文章では、どこまでが事実で、どれが意見解釈なのか?
それを即座に読み取れるか?

【3-2】空間配列=構造の順序、時系列=時間の順序、重要度=比較の順序。
実はこの考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」にも記載されていた。
彼女の本には、この考え方は小学生頃から知っているから、という一節が書かれているが、実は、日本の小学校の国語ではこんな考え方を僕は習って来なかった。
だから、論理的に思考する、論理的に話す、という手法に苦労してきたのかもしれない。

【3-3】「大学生・社会人のための言語技術トレーニング」では、物語の構造についても詳しく説明してくれている。
簡単な具体例は、桃太郎。
物語の構造は、英語であれ日本語であれ、古今東西同じ。

物語の構造は、状況→複雑化→疑問→答え、という流れになる。
しかし、英語圏ではこの物語の構造という考え方を明確に小学生の頃から教わっているのに、日本の小学校では明確に教えられていない。
実は「状況→複雑化→疑問→答え」という考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」の最初に記載されている。

「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」では、プレゼンのイントロ部分では、古典的な技術であるストーリー形式(物語形式)で始めると聴衆を引き込みやすい、という一節がある。
その一節で、「状況→複雑化→疑問→答え」という考え方が紹介されていた。

僕が、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」を最初に読んだ時、とても堅苦しくて読みにくい本だ、どこが名著なのか分からない、と感じていたが、「大学生・社会人のための言語技術トレーニング」を読んで理解した後で読み直すと、なるほど、そういう背景があったのか、とようやく理解することができた。

【4】パラグラフ・ライティングという技法も、日本の国語の授業で習わない。

トピック・センテンス→サポーティング・センテンス→コンクルーディング・センテンスという流れ。
トピックセンテンスには、コントローリングアイデアが必要。

パラグラフ・ライティングには5つのルールがある。
・各段落に話題(テーマ)は一つ。
 →日本語なら、意味段落に相当する。
  「意味段落◆----形式段落」のような構造。
  日本語の文章は、形式段落がむやみに多すぎるので、意味段落にまとめる作業が別途発生する。
  「形式段落を意味段落にまとめよ」という国語の試験問題もあるらしい。

・話題文(トピックセンテンス)は段落の先頭に置く。
・話題文だけで話を成立させる
 →コントローリングアイデアに相当。

・不用意に接続詞を置かない。
・論理を整理しておく。

パラグラフ・ライティングを発展させると、「序論→本論→結論」という学術論文の基本構成になる。
つまり、小学生が習うパラグラフ・ライティングを起点として、10年かけて論理的思考を徹底的に訓練した後、大学生の卒業論文という結果になる。

【4-1】日本人の文書が分かりにくい、と言われる原因のうち、最大の原因は、起承転結のスタイルで書いているからだろう。

起承転結のスタイルでは、前置きが長く、結論が一番最後になるので、すぐに結論を判別できない。
だから、エレベータートークで話すように訓練しろ、と、新人社員はよく言われるわけだ。
日本語の文章は、結論が後回しになりやすい。

他にも原因がある。
一つは、空間配列の技法を習得できていないために、情報を構造として整理できていないこと。
情報を外から内へ、大から小へ、という構造で整理していないので、情報の粒度がバラバラで、論点が分かりづらい。
ちょうど、外部設計から内部設計へ、というソフトウェア設計の考え方と同じ。
いきなり、プログラムの詳細設計レベルの話をされても、そのシステムは結局何ができるのか分からない、という問題と同じ。

もう一つは、日本語特有の論理スタイルが悪いこと。
たとえば、主語なし文章のようなゾンビ文。
時制が曖昧。
形式段落が多すぎて、意味段落としてまとめられていない。

【4-2】日本でオブジェクト指向が普及しなかった、という理由の一つは、オブジェクト指向の日本語の文章が感覚的に変、という事もあるだろう。

「オブジェクトが~する」という文章は、まるでモノが人のように振る舞う点が日本語として感覚的でない。
むしろ日本語としては、「オブジェクトは~される」という受動態で表現する方が感覚的に読みやすい。
つまり、逐次実行的な受動態の文章スタイルの方が、詳細設計の文章は肌感覚で合う。

【4-3】「空間配列・時系列・重要度」という考え方は、チケット管理にも即座に適用できる。

空間配列は、チケットの粒度そのもの。
WBSのように、工程→作業→成果物のように粒度を詳細化していく考え方と同じ。

時系列は、チケット登録日、更新日の順序と同じ。
重要度は、チケットの優先度、チケットの並び順、リリース順、と同じ。

【5】「大学生・社会人のための言語技術トレーニング」では、自分の意見を立証するための構造として「トゥールミンモデル」が紹介されている。
たとえば、絵の分析で、こういう人物が描かれているので、私はこう考えた、と主張する時、その証拠とその論拠を明確にして、主張を支える技法だ。

この技法を発展させると、クリティカルシンキング、クリティカルリーディング、批判的思考につながっていく。

トゥールミンモデルの考え方は、ゴール思考モデル(GSN)につながるし、昨今の自動車業界における機能安全規格の要件適合やシステム適合性にもつながる。
つまり、なぜこの自動運転システムは機能安全といえるのか、という主張を支えるための証拠や論拠を揃えて、論理的に組み立てる必要性があるわけだ。

【6】「大学生・社会人のための言語技術トレーニング」に書かれている素材は、小学生の国語の内容と同じ。
しかし、ロジカルに読む・書く・考えるという技法は、実は日本人は意識していないのかもしれない。
僕自身も明確に意識していなかったので、改めて、理解できた部分は書き残してみた。

| | コメント (0)

2018/04/28

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談

昨夜の関西IT宴会「2人の方法論者によるデータモデリング激レア対談」が開催された。
自分が後で読み直すために、殴り書きのメモ。
自分の感想も入れておく。
DOA屋さんから見れば、理解してないな、と思われるかもしれないが、気にせずに公開しておく。

2人の方法論者によるデータモデリング激レア対談 - connpass

2人の方法論者によるデータモデリング激レア対談<第62回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】By 佐野さん
オブジェクト指向は、ゲームや組込みシステムには向いているだろう。
しかし、業務システムのように、帳簿組織を起源に持つシステムには、オブジェクト指向は向かない。
帳簿組織の業務はデータモデリングすべき。

【2】By 佐藤さん
昔はT字形ERだったが、今はTMと呼んでいる。
中身は別物。
(注:その意味は、後述)
(注:僕はT字形ERの本しか持っていないので、以後は、T字形ERと書く)

TM手法はOOAみたい、と言われる。
理由は、astahで描けるから。

注:たぶん、下記の記事のことかな?
「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

T字形ERの対照表は、OOAの関連クラスと同じ。

【3】By 渡辺さん
AS400の頃に、RDBを本格的に触り始めた。
私は理系なので、「テーブルA:カラムa, b, c・・・」とモデルを書いていたが、周りのSEが全く理解してもらえない。
しかし、具体的にモデルを書くと、SEも理解してくれる。
仕方なく(?)、今の渡辺式ER図のようなデータモデルを書いている。

その頃に流行した4CLでモデルのテンプレートを作り、システムを自動生成するような仕組みを作っていた。
そして、自分で、Delphiでモデルのテンプレートを作り、システムを自動生成するようなモデリング支援ツールを自作していた。
それが、今の三要素分析手法のきっかけ。

感想:
DOA屋さんがOOA屋さんと同じくモデル駆動開発に行き着くのは、モデリング支援ツールを作りたかったという動機があるんだろうな、とふと思った。

【4】By 佐藤さん

Coddの論文を元に、商用ベンダーは商用RDBMSを実装した。
しかし、実際にRDBをそのまま使うとパフォーマンスが出ない。
DBMSには、性能が悪化しないように工夫している。
だから、DBMSの仕組みを理解しないと、パフォーマンスが出ない。

T字形ERは、Coddの弱点に気づいて理論として構築した。
でも、まだ欠陥が残っていた。
TM手法を構築して、佐藤さんの中では完全に解決した。

【5】By 佐野さん

OOAを毛嫌いする理由は、関数従属性を前提にしないこと。
モデルでは、単なる関連で書いている。

【6】By 渡辺さん

三要素分析法は、ER図、DFD、アクションツリーから成る。
データの形はER図、仕事の連携はDFDやアクションツリーで表現される。

データの形が決まれば、画面UIはほぼ確定してしまう。
また、データの形が決まれば、バッチ処理も決まってしまう。
仕事の連携が決まれば、システムの機能(仕様)も決まる。

そういう発想から、三要素分析法は生まれた。

XEAD Tools and Resources - 設計方法論 三要素分析法(TEA Method)

【7】By 佐藤さん

インデックス設計でアクセスパスが自然に決まる。
T字形ERでは、アクセスパスは自然に実装される。

なぜモデルは普及しないのか?という質問に対し、
モデルはあって当然。
それをユーザの環境に合わせて、どのように導入するか?をモデラーは考えるべき。

【8】By 渡辺さん

経理マンの専門知識をデータモデルで表現すると、システムの知識を知らない経理マンも、そのデータモデルを理解できる、という経験をした。
そして、経理マンは勝手に自分達でモデルを描き始める。
そういう経験を経て、モデルの重要性を感じている。

注:懇親会で佐藤さんに、T字形ERでは、顧客のビジネスをデータモデルで表現した時、イベントとリソースのテーブルの個数を数えて比較する。
その時、イベントの個数がリソースの個数よりも少なければ、顧客の潜在的なビジネスモデルを構築できる可能性がある、という話を読んで、すごく納得した、と僕は話した。
つまり、イベントとリソースの組合せで新たなイベントを作り出せる可能性があること、それは顧客の新たなビジネスモデルを構築することにつながることと同じ。

すると、佐藤さんから、ああ、その話では続きがあって、そのデータモデルを顧客に見せたら、顧客自身が自分達でビジネスモデルを作り始めたんだよ、と言われた。
その話と同じかな。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

【9】By 佐野さん

情報系の大学の学生は、学校でデータモデルを習わない。
UMLは習うのに。
彼らも、Postgresは知っているし、使える。
でも、中身のテーブルは全てサロゲートキーになっている。
関数従属性を気にしていない。
そもそも関数従属性を考える、という行為すらしていない。
テーブルは単にデータを格納するだけ、にすぎない。

【10】By 佐藤さん

元々RADを目指していた。
T字形ERで設計すると、当時100万ステップのプログラムのうち、7割は不要になる。

でも、いつも背中から撃たれた。
同業者から嫌われる。

たとえば、大手SIのSEから、T字形ERみたいなこんなに正規化しすぎるとパフォーマンスが悪くなりますよ。
だから、パフォーマンス向上のために、あえて非正規化を施し、森羅万象テーブルみたいに1個のテーブルに300個以上のカラムを設計する、みたいなデータモデルを作ってくる。

「大規模集積回路モデル」と「板チョコモデル」: 設計者の発言

SIでは、生産性を上げたくない。
人月商売なので、開発者の人数が減ると売上が減ってしまうから。
SIは、高価格で、バグ込みのソフトウェアを納品しているんですよ、と。

【11】By 佐野さん

T字形ERはモノありき、のように感じている。
(注:たぶん、業務システムのリプレース案件では、DOAが最強だからだろう、と思った)

他のDOAの流派でも、AsIsベースが多い。
例えば、請求書をデータモデルにする、とか。

渡辺式DOAの凄い所は、いきなりToBeを描く所。
何もない所から作る。

注:懇親会で佐藤さんから、T字形ERは他のDOAと違う。
他のDOAの流派は具体論ばかり話す。
T字形ERは理論から始める。
だから、数学基礎論から勉強し直した、と言われたのが印象に残った。

Oracleを初めて触り始めた頃、OracleでSQLを書くと、テーブルをJoinした時、小さなテーブルを先に読むとパフォーマンスが遅くなる。
Oracleの中身を知らないと、なぜSQLのパフォーマンスが悪化するのか分からない。

真因は、DB設計できていないから、SQLのパフォーマンスが出ないことにある。
だから、SQLは重視しない。
むしろ、真の問題はデータモデリングにある。

X-TEA Driverの面白い所は、複数のDBも扱える。
例えば、マスタはOracle、トランザクションはPostgres、とかでもOK。
しかも、複数のDBのテーブルもJoinできる。

また、データモデルと業務の整合性も事前にチェックしてくれる。

【12】By 佐藤さん

SQLを何も考えずに書くのは信じられない。

モデルはアトリビュート、インデックス定義が含まれる。
実は、アルゴリズム指示書もある。

その中身は、Input=モデル、Process=アルゴリズム、Output=インデックスのような詳細設計書。
すると、アルゴリズムの部分は、ほとんどプログラム自動生成に近い。
プログラマは不要で、コーダーさんに近い。
SIは不要だね。

【13】By 佐野さん

ORマッパーが普及したので、SQLを書けない人も多い。

一方、SQLマッパーというモノもある。
SQLで書いたモノがオブジェクトになる。
たとえば、下地さんのRMenuではjson形式でSQLを表現でき、そのままパースできるので便利。

注:懇親会で下地さんに聞いたら、RMenuで業務システムを実装したら、最初はあえてインデックスを貼らない。
システムの運用後、データが蓄積されて、遅くなった、と言われたら、該当の画面からjson形式のSQLを抽出し、それをパースしてインデックスを生成して、組み込んでいる。
jsonだからすごく使い勝手がいいよ、と。

【14】By 下地さん

プログラムは使い捨てであるべきだ。
なぜなら、プログラムは資産ではない。
その時限りの費用で計上すべきものだ。

注:その意図は、データモデリングを極めると、テーブル設計さえ確定すれば画面UIはほぼ確定されてしまうので、プログラムはほとんど自動生成できてしまう。
つまり、プログラムで書くべき部分はすごく少なくなる。
すると、プログラムは資産というよりも、データモデルに付随したモノに過ぎない、という考え。

佐藤正美さんも、ソフトウェアを資産と考える考え方は嫌いだ、と言っていた。

但し、会計の理論上では、ソフトウェアは無形固定資産に含まれる。
だから、業務システムは保守フェーズで減価償却費が発生するし、システムの改善は、価値が目減りした資産を増やす行為になるので、会計処理も複雑になるデメリットもある。

注:
アジャイル開発では、ソフトウェア(=プログラム)は、最初は負債であり(なぜなら何もないところに投資するから)、その後、キャッシュを生み出して売上を上げていき、損益分岐点を超えたら初めて黒字になるイメージだ。
そういうアジャイル開発の考え方と整合性は取れるか?

プロエンジニアになるための「アジャイル開発」再入門

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

| | コメント (0)

2018/03/09

PlantUMLを使ってExcel設計書をテキスト化するアイデア

以前、Excel設計書をテキスト化できないか、考えたことがあった。
ネットしながら、PlantUMLや他ツールを使ってExcel設計書をテキスト化するアイデアをメモ。
以下は、後で自分が参考にしたい記事をリンクしておく。

仕様書にもExcel脱却が求められている: プログラマの思索

【参考1】
PlantUML 埋め込み AsciiDoc の Gradle を用いた HTML 一括変換 ・ Yutaka ?? Kato

【参考2】
AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ

【参考3】
PlantUML を導入するのに適したケースとは - kkeisuke blog

(引用開始)
以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。

一人で利用する場合
少数精鋭、もしくは統制(教育)されたチームで共有したい場合
情報共有ツールがすでに浸透している場合

PlantUML が解決している課題
UML を理解していなくてもそれっぽい図が書ける
誰が書いても体裁が揃う
検索が可能
バージョン管理システムと合わせると履歴管理の生産性が向上する

PlantUML は「書く」こと、また適切なツールと併用することで「調べる」ことの生産性を向上させます。
(引用終了)

【参考4】
現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる - Qiita

(引用開始)
システム設計が大好きで大嫌いな皆さん、こんにちは。
突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか?
ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。

解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理することで、(レビューフローなどを適切に設定した上で)コードとの乖離を防ぐ、といったことが一案としてあるかと思います。
(引用終了)

【参考5】
PlantUML言語リファレンスガイドのPDFが素晴らしい。
100ページ以上もあり、丁寧。

PlantUML言語リファレンスガイド PDF

akipiiさんのツイート: "@ogomr さんの記事がすごく役立つ。PlantUML Cheat Sheet https://t.co/xoa9xeeVhj"

PlantUML Cheat Sheet - Qiita

(引用開始)
PlantUML は DSL(ドメイン特化言語) で UML の図を描きます。
テキストで記述するので Git で差分を確認したり GitHub Flow で
関係者とコラボレーションをして図が描けるので便利です。

PlantUML は多くの UML に対応していますが、よく使うものを チートシート にまとめました。
(引用終了)

【参考6】
PlantUMLでMySQLやPostgresSQLのER図を生成できるようになったらしい。

Database to PlantUML - データベースの内容からER図を生成 MOONGIFT

Hywan/Database-to-PlantUML: Compile PostgreSQL and MySQL table information into a PlantUML description.

achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

はてなブックマーク - GitHub - achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

【参考7】
??...さんのツイート: "PlantUMLで境界づけられたコンテキストとアプリケーション層の設計してみてるんだけどコーディング感覚で書けるしパッケージ設計までできるので実装イメージしながら書けて楽しい"

akipiiさんのツイート: "面白いな。RT @c6h4clch3: シナリオ製作者よ...PlantUMLを使うのです...関係性や時系列などを表すのに便利なテキスト->図の変換ツールです...添付画像はあるシティシナリオにおける探索者と警察、一般人、神話生物との関係性を例にしたものになります...是非ご確認ください... https://t.co/wDfgVTBZNo"

akipiiさんのツイート: "いいね!RT @morimasa1970: @gogotea3 最近、RedmineにPlantUMLのプラグインを導入したんで、フロー図はその辺でがんばろうと勉強中です。"

choroyonさんのツイート: "PlantUMLいいな これなら方眼Excelからおさらば出来る???… "

yojikさんのツイート: "VSCodeのPlantUMLエクステンションがめちゃくちゃ良い。リアリタイムでプレビューしながら書けるだけでこんなに気持ちよく使えるとは。今までつかったモデリングツールの中でもトップクラスの使用感!これこそ顧客(俺)が本当に欲しかったものだ。。"

N.Cさんのツイート: "PlantUMLの導入終わったー! これでコード書いてキャラ相関図作れる! 必要なやつダウンロードしてPC再起動したら使えるよ!?( 'ω' )? やりかたはこちらです https://t.co/Sbl72dGjEd なお、試しに作った画像がこちらです… https://t.co/qPHL28ko8u"

なべや まいこさんのツイート: "数日前にシナリオ書くのに便利!と話題になってた『PlantUML』をWordで動かしてみたので、記事を書いてみた。日本語記事見当たらなかったので、もしかしたら書けば誰かが助かるかな、と。 WordでPlantUMLを動かしてみた(その1)|note(ノート) https://t.co/QGB0FWzgEd"

WordでPlantUMLを動かしてみた(その1)|なべや まいこ|note

【参考6】
PlantUMLは惹かれているのだが、astahで描く方が今は手に馴染んでいる。
下記の意見も同意している。

u6k_yu1さんのツイート: "ちょっと思い返したけど、書き散らすときは紙かホワイトボードでグリグリやって、整理するときにastah使ってる。PlantUMLはテキスト管理のしやすさから何度か試用しているけど、うーんという感じだった。"

岡本卓也さんのツイート: "自分もその感じです。astahはホワイトボードの延長で、思考を直感的に書き出すのに向いてる。『あ、この箱とこの箱は会話しそうだから線で繋ぐか』みたいな。 PlantUMLはここで『線で繋ぐなら文法はこうか?』みたいなワンステップ入るのが辛い。確かにテキストなのでgitとの相性は良いんですがね。… https://t.co/uLQFaWD8uv"

astahとPlantUMLが同期できるといいのだが。

【追記】
akipiiさんのツイート: "これはいいね!確認してみたい。RT @htomine: パフォーマンス見て問題無さそうだったらQiitaにも実装します :+1: / “PlantUML対応、記事のコピー機能を追加しました - 生産性を向上させる情報共有ツール - キータチーム(Qiita:Team)” https://t.co/neyBNqB620"


| | コメント (0)

2018/01/01

アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。
内容がとても奥深い。

僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。
以下、ロジカルでないラフなメモ書き。

【参考】
@yusuke_arclampさんのまとめ記事が公開されました。

アジャイルにおける事前合意について - arclamp

【1】エンタープライズアジャイル勉強会 2017年12月セミナー開催のお知らせ

アジャイルを機能させる外枠について - arclamp

(引用開始)
アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。
チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アシ?ャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。
ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp)

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。
(引用終了)

つまり、見積りできないモノ、ステークホルダーとの調整をアジャイルチームに持ち込まない。

isopさんのツイート: "kent beckや平鍋さんが偉大なアーキテクトだから、という文脈は激しく同意したい"

isopさんのツイート: "@hiranabe 先日のエンタープライズアジャイル勉強会での @yusuke_arclamp さんのQAセッションで開発サイクルを回すことでアーキテクチャは自然と生まれてくるのか?という質問に対する回答でした"

鈴木雄介/Yusuke SUZUKIさんのツイート: "どちらかというと「平鍋さんやkent beckがアジャイルを語るとき、アーキテクチャの重要性が本人達にとって自明すぎるがゆえに語られないのは問題だ」というクレームめいた言い方をしまして... https://t.co/P6Ou6WRkpl"

【2】上記に関する感想をツイート。

akipiiさんのツイート: "名言。ストンと落ちた。RT @yusuke_arclamp: エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM https://t.co/qFNXcROiek"

昌。さんのツイート: "@akipii @yusuke_arclamp 先日のアジャイル勉強会でもその辺り激しく主張されてましたね"

akipiiさんのツイート: "@aj15_aj15 @yusuke_arclamp 立場によっては、当たり前だろ、という意見と、開発を最大に効率化する観点では、この方法しかないので、この方法を洗練化すべきだ、という意見があると思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@akipii @aj15_aj15 特にエンタープライズ業界でアジャイルをスタートする方は強めに意識してもらいたいな、と思います。僕の知る現場で苦労しているのは、この2つということが多いので。"

門屋 浩文さんのツイート: "@yusuke_arclamp @akipii @aj15_aj15 なるほど。エンタープライズアジャイルにはまだ踏み込んでいませんが、納得です。ただ、それができるPOやSMはウォーターフォールでもうまくいく気がします。早く成果物を作る・使うって効果を優先ってことで手法を選択、ですかね"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 いえいえ、もっと深い意味があります。DOAモデラーとの議論では、アジャイル開発では要件定義やアーキテクチャ設計は誰が担当するのか?と言う議論がありました。アジャイル開発の文脈では、開発チームは要件定義やアーキテクチャ設計を担当せず、POに委ねることで解決しようとしてます。多分。"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 よって、DOAモデラーの観点では、そうならば 速く開発できるのは当たり前でしょ、と。でも要件定義やデータモデリングを他人の手に委ねて良いのかと。僕は、アジャイル開発のような特化したやり方は有りと思うし、そういう仕組みがあるから中小SIが市場に食い込めるので日本では人気あると理解し… https://t.co/QO72yG0fhm"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@MadoWindahead @akipii @aj15_aj15 アジャイルでは「要件定義レベルでモデルやアーキテクチャを固くすることに意味がない」とも言えます。なぜなら変化するから。つまり、作りはじめるまでに、いつ、どこまで、誰が固く表現するのか?というのが論点かと。"

【3】スクラムとの関わりについて。

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルで「エンジニアにとって面倒なことをチームに持ち込まない」というのを「効率化のために調整は減らすべき」と考えるか「エンジニアの甘え、仕事の醍醐味は調整だ」とするかで分かれそう。もちろん、両面ある。僕としては「両者を混ぜて曖昧にするな」というだけ。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スクラムマスターってエンジニアの世話役とかおもりみたいな面もあり「そんなの甘え」と思う人もいるだろが、そういう人がいないとエンジニアが機能しないのも事実なんだよね。ウォーターフォールでいう「バッファ」を実体化したのがスクラムマスターともいえるのかな?"

鈴木雄介/Yusuke SUZUKIさんのツイート: "ともかく日本でまともな開発現場、エンジニアがやり甲斐があって、つらくならない開発現場を増やしたい。でも、なんでもできるエンジニアは限られているから組織やチームとしてできる体制を作らないといけない。だから、マネジメントが必要になる。アジャイルは良いツール。"

みぞやんさんのツイート: "@yusuke_arclamp WFでいう(人数によりますが)サブシステムごとのチームリーダーがスクラムマスターを担えるといいのかなと思いました"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@mizoyan432 最新のスクラムガイドでも「スクラムマスターはサーバントなリーダーである」と記載があるので、ある意味ではその通りです。ただしコミュニケーションパスを抑えるようなリーダーではないべきですね。"

HARADA Kiroさんのツイート: "@yusuke_arclamp 有効なら「甘え」でなにか悪いことでも?くらいのノリですかねえ。バッファよりは、もうちょい能動的で、バッファ減らす要因に働きかけに行く感じ。"

【4】アジャイル開発とWF型開発における、プロセスの違い、体制の違い、

鈴木雄介/Yusuke SUZUKIさんのツイート: "企画の決める仕様がゆるい、基幹システム連携がもめる、運用部門に提出するドキュメント作成が大変、といったことはWFからアジャイルになっても変わらない。むしろ、課題として明示化される。作業に落とし込めない調整事を開発チームに持ち込ませないのが大事。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンタープライズ開発だと、WFでもアジャイルでもやるべきことはきちんとやる、のです。ただ、作業にならないものはスプリントに持ち込めなくなるからPOやSMが頑張って作業になるように調整を行うことになる。その代わりチームは機能の実現に全力を尽くす。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スプリント計画で「開発チームが見積もれないものはスプリントバックログにいれない」というのが大事です。それがグダグダになるとうまく回らなくなる。そもそもプロダクトバックログに調整中のものは持ち込まないべき。その手前に解決しておかないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルに比べてWFの方がゲートやプロセスが厳密なんて聞きますが、間違いです。アジャイルはスプリントごとのゲートやプロセスは大変に厳密です。ただWFはゲートの数が少ないので一回でやるべきことが多くなるだけで。"

上記のツイートは、本当に同意。
大規模WF型開発でも、優秀なプロジェクトマネージャは故意にフェーズ分けして段階リリースを踏む、という手段を取る場合が多い。
最後の1回だけの本番リリースは危険すぎる。

鈴木雄介/Yusuke SUZUKIさんのツイート: "WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていた頃が僕にもありましたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM"

そういう文脈で、アジャイル開発では、スクラムマスターやプロダクトオーナーが防波堤になる。
組織パターンにおける防火壁、ファイアウォール。

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラで調整が面倒なのは仕様合意、システム連携、インフラ調整、運用引継。インフラ調整はクラウド化で軽減、システム連携や運用引継はプロセス関係なく事前ネゴ。仕様合意はアジャイルの締切駆動や定期調整に変更。つまり、アジャイルで変化を強く求められるのはビジネス側"

鈴木雄介/Yusuke SUZUKIさんのツイート: "みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。"

【5】@yusuke_arclampさんと@sugimoto_keiさんのやり取りを読んだ後で振り返ると、おそらく、アジャイル開発には要件定義工程はあるのか、という問題の本質を突いているのではないか、と直感した。

杉本啓さんのツイート: "鈴木さんのエントリで一番気になったのは「見積もれないことをチームに持ち込まない」という点です。興味深い要求は、ふつう最初見積もれないですからね。これは「なすり合い」「平行線」とは違うと思うのです。私は鈴木さんの心情を批判しているのではなく書かれた主張を批判している点ご理解下さい。 https://t.co/XE9KG0za2U"

吉田 収さんのツイート: "@yusuke_arclamp @sugimoto_kei いわゆる「ビジネスアナリスト」の領域はチーム外とした方がよいということになるでしょうか。"

杉本啓さんのツイート: "@omuysd @yusuke_arclamp お尋ねの点は、どう仕切りたいかという意思の問題に依るところが大きいように思います。私としては、業務側との関係が宜しければ、業務要件の定義・分析もチームで担当する方が好みですが、それは設計/開発だけチームで受けるのとは少し異なるビジネスかと思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@omuysd @sugimoto_kei フェーズによると思います。初期は完全に外でも良くて、作るものが見えて来たらやり取りを開始し、画面への落とし込みはチームに任せていくという雰囲気でしょうかね。杉本さんが言われるようにチームのスキルや関係性で寄り方は変わるでしょうが。"

@yusuke_arclampさんも違和感を感じられているのかな、と感じた。

akipiiさんのツイート: "DOAモデラーとの議論を読んでたら、そんな感じがする。RT @yusuke_arclamp: なんか自分の主張がRUP的にフェーズによってチームスキルの濃淡を付けろという話になっている気がしてきて微妙な気分。うーむ https://t.co/Vweh4rkrnO"

【6】DOAモデラーからの意見。
モデリングするという行為の立場から言えば、まさに正論。

年忘れLT宴会<第60回IT勉強宴会> | IT勉強宴会blog

ソフトウェア開発と業務システム開発(杉本さん)

(引用開始)
アジャイルとウォーターフォール

・「ソフトウェア開発」に関するアプローチの違いだけではない。
・スコープ(視野に収めている範囲)が違うよね。
・ソフトウェア開発 vs. 業務システム開発
・超高速開発は、スコープの点ではWFと同じ。
・ソフトウェア開発を仕事としているエンジニアに超高速開発を訴えるとき、注意しないとスコープを誤解される。
・超高速開発は、業務システム開発の面を強調した方がよい。超高速開発というとソフト開発が早くできるというメッセージだけ。
(引用終了)

個人的には、関西IT勉強会で、DOAとアジャイル開発におけるモデリングや要件定義の違いについて、@yusuke_arclampさんと@sugimoto_keiさんの対談を聞いてみたい、と思う。

【7】個人的な感想を以下、書いておく。
ラフなメモなので、論理がズレているかもしれない。

【7-1】超高速開発ツールが何故プログラマに嫌われるのか

超高速開発ツールを使うと、DB設計や実装モデルを作れば、プログラミングレスで即座に業務システムを作れる。
つまり、超高速開発はモデル駆動開発の方向性に似ている。

しかし、プログラマの観点では、超高速開発ツールは正直面白くない。

プログラマなら、誰もが自分のプログラムが一番と思っている。
でも、自分が書いた優れたプログラムを見てくれ、という場面をアピールできない。
Githubで互いに書いたプログラムをフォークして、プルリクエストを送る、といったソーシャルコーディングが実現されない。

また、モデルという絵や、モデルを表現するための別のプログラムであるDSL(ドメイン特化言語)を別途覚える手間がかかる。
そんなものを覚える暇があるなら、RubyやPythonをガリガリ書きたいし、そちらの方がはるかに意味があるでしょ、と。

すると、超高速開発ツールは製造業のSE向けがマーケットなんだろうな、と思う。
つまり、プログラミングしないけどシステムを開発したい人達、すなわち発注者、特に日本では製造業のSEがターゲットになるだろう。

彼らはプログラミングは下流工程とみなし、外部へ発注するのが普通と考えているからだ。
外部に発注する工程が超高速開発ツールで代替されて、発注費用がなくなるのが理想だろうから。

akipiiさんのツイート: "同感。良い物なのに肝心のターゲット、つまり発注側のSEに届いてない気がする。RT @sugimoto_kei: 翻って超高速開発ツールを見るに、ターゲットがバクっとし過ぎのような気がする。もちょっとターゲットを定めた方がよいのでは?"

また、超高速開発ツールは多分最終的にはDSL基盤を目指しているんだろうな、と思う。
つまり、超高速開発ツールはプログラミングしない代わりに、モデルを描くために特化したスクリプト言語が必要になり、それがDSL(ドメイン特化言語)になるわけだ。

たとえば、UMLでもOCLみたいなDSLが提唱された時もあった。
DSLの優れた事例は、ExcelのVBAという意見もあったな。

そのDSLの最大の特徴は、プログラマでなくても、ユーザが分かるようなプログラミング言語であり、ユーザが簡単に書けることだろう。
システム化したい業務を一番良く知っているユーザ自身が、モデルをDSLで書いてしまえば、後は超高速開発ツールが即座にシステムを作れる、というストーリー。

そういうストーリーでは、プログラマの出番はないし、業務システムの発注者であるユーザ自身が超高速開発ツールを使いこなせるようにならなければならない。
超高速開発ツールはおそらく、そういう方向へビジネスモデルとして進化するのではないか。

【7-2】アジャイル開発における発注者と開発チームでの設計上の役割分担の誤解

上記のように、アジャイルチームには、外部との調整や要件定義に関わる作業は担当させない。
要件定義やそこから定まるプロダクトバックログはプロダクトオーナーが担当するし、スクラムマスターがスクラムチームの守護神として守る。
つまり、アジャイルチームの外側に、要件定義やモデリングの作業が追いやられているように見える。

モデラーの立場から言えば、そういう分業体制なら、速く開発できるのは当たり前だろう、と。
既に、作るべき機能リストがあり、チームはそれを淡々とこなせばいいのだから、と。

おそらくこの部分で、アジャイル開発とDOAモデラーとの間で、認識の相違が生まれるのだろうと思う。

【7-3】アジャイル開発が何故日本では中小SI企業に人気があるのか

では、なぜ、アジャイル開発が日本でも注目されているのか?
アジャイル開発が注目される理由の中に、日本特有の事情があるのか?

理由として、日本の中小SI企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という@sakaba37さんの意見があって、すごく納得した。

実際、日本のIT業界では、受託開発は請負契約の多段階の下請構造になっている場合がほとんど。
すると、その構造のままでは、中小SI企業自身がIT案件を主導するビジネスはやりにくい。

しかし、アジャイル開発を採用すると、ユーザ企業とシステム企画や要件を直接ヒヤリングしながら、スピーディにシステム開発して納品するビジネスモデルを実現できる。
つまり、今までは、元請けSIの大企業が担当していたシステム企画や要件定義フェーズを、下請けの立場に甘んじていた中小SI企業が直接担当して、ユーザ企業と直接契約できるようになるメリットがある。

特に、Webシステム開発のように、技術力に特化しているならば、要件定義さえ上手くまとめれば、ユーザ企業と直接やり取りしながら、小刻みにリリースしながらシステムを納品していくことができる。
一方、発注者であるユーザ企業も、早い段階でシステムの受入れで確認できるし、途中で細かな改善要望も織り交ぜられるので、双方にメリットが共有できれば、受け入れやすい契約になる。

また、ドメイン駆動設計のような設計手法、ユーザストーリーマッピング等の要件定義手法、リーンキャンパスやリーンスタートアップなどのシステム企画の手法も色々編み出されているので、従来のアジャイル開発の盲点であったフェーズもカバーできるようになってきている。

すなわち、日本におけるアジャイル開発の文脈では、アジャイル開発は、中小SI企業が多段階の下請構造から脱却するためのビジネスモデルとして捉えられる、のではないか。

【7-4】DDD(ドメイン駆動設計)がアジャイル開発におけるモデリング技術の補完的役割を担っている

では、アジャイル開発では要件定義やモデリングは不要なのか?
開発チームの外側で要件定義やモデリングを行うとしても、プロダクトオーナーはアジャイル開発の文脈でどのような要件定義手法やモデリング手法を持つべきなのか?

2018年初頭の日本では、ドメイン駆動設計がアジャイル開発における唯一のモデリング手法として認知されている、という回答になるのではないか。

現場で役立つシステム設計の原則を読んだ | mizoguche.info

Takuto Wadaさんのツイート: "(トッパン|ピアソン)ショック、単に絶版、様々な要因でOOA/OODの書籍がほぼ死滅し、訳書が出るタイミングが遅かったDDD本だけがオーパーツのような存在になった結果、日本ではDDD ≒ OOA/OODになってしまったという奇妙な状況の背景の話をした #teppeis_sushi"

@t_wadaさんの指摘の通り、2000年代はオブジェクト指向分析の観点で色んなモデリング手法が提唱されていたが、それらの本を出版していた出版元が書籍発行を辞めてしまったため、最も遅く出版されたドメイン駆動設計本だけが生き残り、その本しかアジャイル開発者は参考できない、という現状があるからではないか。

つまり、ドメイン駆動設計が日本で注目されている理由の一つは、そういう日本特有の事情があるのではないか。

【7-5】超高速開発ツールには、DOA基盤のツール以外にも、SalesforceやKintone、Ruby on Railsも含まれる

そういう超高速開発ツールはDOA基盤のツールだけでなく、著名なパッケージ製品では、SalesforceやKintoneも含まれるだろう。
たとえば、DOAの発想でデータモデルさえきちんと設計すれば、Salesforceで簡単に実装できる。
また、要件定義できちんと要件さえ確定していれば、KintoneでAPIを駆使して、簡単な業務システムを作り込める。

杉本啓さんのツイート: "kintone というのは複数テーブルのジョインも出来ないと聞いて、全然だめじゃないのと思っていたのだが、使ってみるとそうでもないようだ。簡単な台帳を作るにはよく練られている。ターゲットとする用途をうまく選択することがいかに重要かを示す例かもしれない。"

杉本啓さんのツイート: "@akipii はい。私も超高速開発ツールと同じと思っていましたが、おっしゃるように、想定している利用シーンが異なる(kintone の方が絞り込まれている)のではないかと今は考えています。@iteman さんの方が詳しいですが。"

Atsuhiro Kuboさんのツイート: "@sugimoto_kei @akipii 汎用の CMS と WordPress 等のブログシステムとの違いに近いと感じています。超高速開発ツールは「設計する」というアクティビティがあると思いますが、kintone にはそれがない感じでしょうか。"

そういう観点では、Ruby on Railsも超高速開発ツールの一種とみなすこともできるだろう。
業務のデータモデルをActiveRecordで対応付けることができれば、画面は簡単に自動生成できるから。

さらに、画面の細かなUIは、JavaScriptで作りこめばいい。
たとえば、XEADでも、画面UIの作りこみの部分はJavaScriptで実装できるように作られている。

特に、Ruby on RailsはJavaScriptと大変相性が良いので、画面UIをデスクトップアプリのような操作感で実現できる。

よって、最近は、DOA基盤のツールだけでなく、SalesforceやKintoneのように手軽に操作できる有償のパッケージ製品、さらにはRuby on Railsのような強力なフレームワークが普及したことで、超高速開発ツールを適用したいニーズに当てはまるのだろう、と思う。

【7-6】超高速開発ツールが普及したからこそ、匠Methodのような要件定義手法に価値がある

アジャイル開発やプログラマの視点では、超高速開発ツールに否定的になってしまう。
しかし、超高速開発ツールのおかげで、発注者自身がお手軽にシステム開発できる基盤が整った、という側面もある。
つまり、要件定義できちんとシステム要件さえ確定できれば、超高速開発ツールを使えば、即座にシステム化できるのだ。
よって、萩本さんが提唱する匠Methodを要件定義のための手法として扱って、超高速開発ツールのインプットに連携すれば、スムーズにアジャイルに開発できるだろう、と思う。

そんな話を連想できたのは、先月に関西匠塾に行ってきて、匠メソッドの概要を初めて聞いたから。
詳細はまだ理解しきれていないけれど、ビジネスモデル設計やシステム企画から業務の要件定義まで一通り、設計できる、とのこと。

価値を描き、活動に落とし込む手法を学ぼう! - connpass

では、その後はどうやってシステム開発するのか?
お話を聞くと、たとえば、Salesforceを使って、システム要件を元に素早くシステム開発していく、というストーリーみたい。
つまり、匠メソッドを要件定義のアウトプットを作るフェーズで使って、業務の要件定義書を作り、それをSalesforceやKintoneのインプットとして用いることで、アジャイルに開発できる。

【7-7】kintoneという超高速開発ツールの開発基盤があるからこそ、業務ハックという職業も生まれる

この考え方は、最近、倉貫さんの会社でも提唱されている業務ハックにつながるのではないか、と推測する。

業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

業務ハック勉強会@大阪 ? 働き方改革にも効く!事例で学ぶ業務改善のノウハウ - connpass

つまり、超高速開発ツールのような即座にシステム化できる開発基盤があるからこそ、プログラマの観点では、業務モデリングも実装ツールの一つに組み込んでしまって、アジャイルにシステムを作りながら、業務もシステムも改善してく手法を取っていく、という考え方ではないか。
ユーザから画面UIに関する細かな改善要望があっても、JavaScriptさえ操ることができるなら、画面UIの作りこみにさほど苦労することはないだろうから。

この辺りは聞いてみないと分からないけど。

【8】以上は妄想にすぎない部分もあるけれど、今年も色んな勉強会に行ってみて、上記のアイデアの方向性が合っているのか、確認してみたい。

【追記1】
鈴木雄介/Yusuke SUZUKIさんのツイート: "相変わらずウォーターフォールとアジャイルの話は受けがいいなぁ。最近のエンタープライズ界隈はウォーターフォールからアジャイルへの転向が増えている気がするので、もっと、こういう話はされていいんだろうな。 https://t.co/yR1x9ZUku4"

【追記2】
杉本啓さんのツイート: "読みました。興味深い試みですね。業務の仕組みを作るという志向において超高速開発やDOA界隈と似ていると思います。「業務ハッカー」という呼称は、確かに新味があってプログラマに受けそうですが、顧客サイドからするとどうですかね。現場の人には響くでしょうが、上の方には響きにくいかも。 https://t.co/fbXybQn6vL"

akipiiさんのツイート: "@sugimoto_kei 実現したいものは超高速開発ツールも業務ハッカーも同じ方向性に感じます。但し、モデリングに注力してノンプログラミングにする超高速開発ツールと、プログラミング作業の中に業務設計や運用設計を取り込む業務ハッカーは手法が異なると読み取りました。"

杉本啓さんのツイート: "@akipii まあ、嗜好は違うのだとは思いますが、同じ問題領域を対象にするのであれば、収斂してくるような気がしますね。超高速開発がノンプログラミングというのはセールストークであって実際にはDSLなどでプログラミングするわけだし、業務ハックで使うkintoneもある種のDSL環境ですしね。"

杉本啓さんのツイート: "@akipii 業務ハッカーについては、私は、さほど違和感を感じていません。買う側の意思決定者には響きにくいだろうなと思う程度です。調整をチーム外にという鈴木さんの話については、たぶん問題意識についても不一致があると思います。"

杉本啓さんのツイート: "@akipii とはいえ「超高速開発」よりは「業務ハッカー」の方がセンスありますね。ユーザ視点に立つと、前者では開発が速くなるんだろうなあという印象しか湧きません。後者だと、自分たちの業務に踏み込んで考えてくれるのかも、という期待が持てます。"

| | コメント (0)

2017/06/16

Salesforceのデータモデリング手法の記事のリンク

@hatsanhatさんの記事「データモデリングしてますか?」がとても参考になるのでメモ。
詳しくは下記の記事を参照。

【参考1】
データモデリングしてますか? - TECH BLOG | 株式会社テラスカイ

参考になった箇所は下記の通り。
サロゲートキーだけの開発環境の場合、「複合キーの制約をNotNull制約と更新不可制約で実現する」点が参考になる。

(引用開始)
スキーマビルダーで描画すればそのまま実装も出来るところは大変便利ですが、データモデル構造だけをシンプルに見たいという用途には向きません。
そこで筆者はオープンソースのモデリングツール「X-TEA(エクスティ) Modeler」を使用しています。
モデリングツールは何種類か試しましたが、1:Nの関係を親子関係と参照関係で明示的に表現出来る事と、項目に「更新不可属性」を設定出来る(何故必要かは後述)ためこのツールを重宝しています(作者に感謝)。
(中略)

顧客・顧客担当者・商談だけを関係付けたデータモデルです。
「顧客」と「顧客担当者」の間は鳥の足のような特徴的な線で結ばれています。
これが親子関係を表します。

「顧客担当者」と「商談」の間は先が点々になっています。
これは同じ1:NでもN側にNullを許す参照関係を表しています。

この2つの書き分けが出来るツールは珍しいのでSalesforceに向いています。
(引用終了)

(引用開始)
本当に複雑なデータモデルの時に主キーも正確に表したい時は、外部キー(foreign key)を使います。
複合主キーと外部キーの違いはNotNull制約と更新不可制約だけです。

・主キーはSalesfordeIdの単独主キーとする
・複合主キーとしたい他の項目はNotNULL制約+更新不可制約を付ける
(このためにX-TEA Modelerの「更新不可属性」が必要になります)
(引用終了)

(引用開始)
顧客オブジェクトの先頭の項目「011-id」は顧客オブジェクト(011)のSalesforceIdを示しています。
SalesforceIdとはオブジェクトの各レコードに一意に付けられる番号です。
この値を見れば、会社の中でレコードを1つに特定出来ます。
一般に言う「オブジェクトキー」とほぼ同じです。
Salesforceはこの値をURLに指定するとレコードを検索出来るという奇跡のようなURI設計(笑)になっています。
(引用終了)

【参考2】
あわせて、渡辺さんのBlogとさかばさんのBlogも参考になるのでメモ。
特に、さかばさんの指摘「RDBだから複合キーを使わずに実装できてしまう。モデリングの問題(注:実装と対比して、設計の問題という意味と推測)ではなく実装の問題です」も参考になる。

単独主キーでもDB設計は楽にならない: 設計者の発言

「単独主キー専用環境」と賢くつきあうために: 設計者の発言

複合主キーの扱い方: ソフトウェアさかば

(引用開始)
RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。
(引用終了)

| | コメント (0)

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2017/03/27

第54回関西IT勉強会の感想

第54回関西IT勉強会で、渡辺さんの生産管理データモデルを超高速開発ツールで実装してデモを見せてくれて、面白かった。
以下はラフな感想。
間違っていたら後で直す。

【参考】
データモデルを通して業務を理解しよう <第54回IT勉強宴会> | IT勉強宴会blog

データモデルを通して業務を理解しよう - connpass

【1】渡辺さんの生産管理データモデルは既に公開されている。
書籍では何度も読んでいるけれど、実際に動いた画面は見てないので、ピンときていない部分もあった。
今回、超高速開発ツールで実装してデモを見て、渡辺さんの生産管理データモデルはすごい!と改めて気づいた。
(レベルが低くてスミマセン)

【2】渡辺さんの生産管理データモデルで興味深い点はいくつかある。

【2-1】受注生産と言いながら、汎用部品の見込生産にも対応している

受注生産のシステムなので、製造するときには必ず受注番号が既にある。
受注番号から製造指図書が生成され、それに従って、原材料の発注、設備の作業時間の予約、作業員のスケジュール予約が自動設定される。
つまり、MRPの所要量計算が自動計算されて、必要なリソースが予定として計画される。
そして、次の業務へ移る。

だが、渡辺さんの生産管理データモデルでは、「特殊売上」「特殊仕入」という特殊な業務がある。
これは、汎用部品の売上処理や仕入処理を意味する。
なぜこういう機能が必要なのか、を推測すると、受注番号なしで製造指図書を発行したい、という例外的な業務があるからだろう。
そういう例外的な業務をシステム化しないケースもありうるが、その場合は、例外的な業務は従来の紙による運用になってしまい、生産データや売上データを別で入力する必要が出てしまう。
だから、このような例外的な業務に対応する機能も実装しておくと便利。

その場合、その例外的な業務に対応する機能は、ほとんど全ての例外業務を飲み込んでしまう。
たとえば、本来は、何らかの理由で追加生産する時に使う機能だったのに、汎用部品を事前に見込生産する、とか、サポート保守用の部品を事前に生産して準備する、とか、ありとあらゆる例外業務に対応できてしまう。
つまり、例外的な業務に対応する一機能にすぎないのに、実際は、受注生産以外の全ての生産業務に対応できるような仕組みを故意に作っておけば、中小企業のある程度の生産業務に対応できる、という背景があるのだろう。

そういう意図を読み取りながら、デモ画面を見ると、さほど複雑ではないシンプルな生産システムにも関わらず、このデータモデルを流用すれば、ある程度のシステムを構築できてしまうわけだ。
たぶん、渡辺さんの過去の経験から、こういうデータモデルがないと、現場の業務は回らない、という確信があるのだろう。

【2-2】製造指図書、発注明細などのFatなテーブルの項目には意味がある

公開されたER図をサラッと見ると、業務の中心にFatなテーブルがあり、その周囲に惑星のような小さなテーブルが配置されている。
まるで、太陽系のようなデータモデル。

T字形ERの人達から見れば、正規化しきれていないテーブル構造だと思えてしまうかもしれない。
だが、実際にデモを見ると、Fatなテーブルの項目は、それぞれの業務の画面項目に対応しており、データの生成→更新→終了に至るまでの経緯を保持するデータに対応する。
つまり、導出項目だったり、数量だったり、連番だったりする。

渡辺さんの生産管理データモデルで最も特徴的な在庫推移機能の画面では、業務が変わるたびに、在庫数量がその都度更新され、リフレッシュされる。
実際は、親画面からポップアップされた子画面で、ステータスや数量を更新すると、親画面の在庫数量がリフレッシュされる。

下記の質問はそんなデモを見た時に出た。

(引用開始)
・先ほどから画面を閉じるとひとつ前の画面がリフレッシュしてるように見えます
 最近追加した機能です。画面フォーカスが戻った時に自動リフレッシュ出来ます
 またルールエンジンも組込みましたので簡単な業務ならノンプログラミングになりました。
(引用終了)

在庫推移画面は実際に見たことがなかったので、そんな動きになるのか、とようやくイメージできた。
(レベルが低くてスミマセン)

つまり、Fatなテーブルは、各業務に必要な導出項目や更新する項目を保持するために必要であり、データ保守やデータ移行の手間を考えると、あえて、正規化しすぎないようにしているわけだ。
その分、カスタマイズもしやすいだろう。

【2-3】製造指示工程明細---●製造指示材料明細

製造指図書テーブルから、製造指示工程明細と製造指示材料明細の2つのテーブルが外部キーとして外部参照関係を持つ。
さらに、工程と品目明細のテーブル間で、「製造指示工程明細---●製造指示材料明細」という外部参照関係がある。

この意味は、原材料を「工程の始点から投入」だけでなく、「工程の途中から投入」できるようにするために、そのような関係を持たせている、らしい。
なるほど!

普通は、原材料は「工程の始点から投入」のパターンだが、工程の途中から投入する生産工程もあったりする。
そのような例外的な業務に対応できるように、故意に制約を緩めて汎用化しているわけだ。

工業簿記の総合原価計算では、「工程の始点から投入」のケースと「工程の途中から投入」のケースでは、加工進捗の計算方法が変わるため、加工費の算出が変わってくる。
つまり、この部分に対応することで、多様な原価計算パターンにも対応できるようにデータモデルを設計されているわけだ。

【2-4】発注明細●----入荷見出し

(引用開始)
発注の部分のERがすごく良くできています。
発注見出 -< 発注明細を作ります。
仕入が入ってくると発注明細ごとに仕入番号を更新することで入荷された単位で仕入れを発生させることが出来ます。
(引用終了)

僕の理解では、発注明細が複数個発生すると、そのたびに入荷処理するわけではなく、一括で処理したい。
そこで、一括処理する単位で、発注明細を束ねて、入荷処理する。
つまり、発注明細に、仕入番号という外部キーを挿入して、仕入番号の単位で入荷処理を行うように記録させる。
なるほど!

T字形ERでも、2個のトランザクションに先行・後続の関係を持たせる時、外部キーを持たせる。
また、T字形ERでは、先行のトランザクションを一括処理でまとめて、後続のトランザクションに渡す時は、親子キーの関係を持たせるが、渡辺式データモデルでは、実運用を考えて、外部キーで持たせている。
つまり、発注明細テーブルの仕入番号は最初はNULLであり、仕入という入荷処理を行うと、仕入番号が発行されてセットされる。

懇親会で実装した人に聞いたら、この部分のデータモデルはシンプルで汎用性が高いので、いろんな業務にカスタマイズしやすい。
よく考えられている、という話だった。

【2-5】ストアドプロシージャは、サーバーサイド・JavaScriptで実装する

今時、ストアドプロシージャをプログラミングするのは古いらしい。
サーバーサイド・JavaScriptで実装するが流行らしい。
確かに、サーバーサイド・JavaScriptで実装しておけば、どんなWebシステムでもクライアントアプリでも、公開されたAPI経由で自由に計算処理できる。

性能要件が気になるけれど、そこさえクリアできれば、保守性を考えると、サーバーサイド・JavaScriptで実装した方が良いのだろう。

【3】@sakaba37さんから、渡辺さんのデータモデルのようなモデリング手法に違和感がある、と聞いた。
あれは、論理モデルではない、物理モデルだから。
本来のモデリングではないのでは、と。
たとえば、オブジェクト指向モデリングならば、モデルは論理モデルを指すのであり、物理モデルはいろんな種類があるから、と。

たしかに、モデリングと言うよりも、実際に実装したシステムまで作ってしまった、みたいな感じだ。

この手の話は、以前、議論したことがあった。

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

つまり、普通のモデリングで言われるモデルは「論理モデル」であり、論理モデルだからこそ、実装方法は色々ある。

一方、勉強会の途中で、渡辺さんの質問「業務に対するモデルの正しさはどのように判定していますか?」があがり、皆であれこれ議論して、結局、場面ごとに違うので、正しいモデルは一つとは限らないね、という話になった。
そして、渡辺さんいわく、モデリングはエンジニアリング技法の一つなので、品質やコスト、納期のトレードオフでモデルが決まるから、と言っていた。
その意図は、「モデルの判定は理想論ではなく、QCDやその時代の技術レベルの選択のすり合わせで決まるので、相対的なものである」という意味なのだろうと思う。

以前、@yusuke_arclampさんも似たようなことを言っていた。

akipiiさんのツイート: "アーキテクトは理想論を語る科学者ではなく、コストなど現実的な折り合いを付ける技術者であるわけか。RT @yusuke_arclamp: アーキテクトというのは「個別の技術論」ではなく「技術選択論(要件と技術のすり合わせ)」を語れないといかんのだけどね。"

でも、@sakaba37さんと同じく、何かすっきりしない気持ちもある。
上記の議論は、モデルのレベルを「実装モデル」に落としているために、技術選択論になっているのではないか、と。
この辺りは妄想なので、あとでまとめる。



| | コメント (0)

2017/02/23

データフローダイアグラムではプロセスは一番最後に書く

データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。

【参考1】
データフローダイアグラムの書き方

(引用開始)
プロセス,データの発生源・行き先,データの保管元・保管先全てに名前がついているにもかかわらず,データの流れにだけ名前がついていないDFDを見かけることがあります.
これらはDFDの役割を果たしていません.
DFDが表現しなければならないのは,プロセス,データの発生源・行き先,データの保管元・保管先を行き来するデータなのです.
データの流れに名前をつけないのは,DFDが最も表現しなければならないものを表現していないということです.

図6.プロセス名は最後につける
(引用終了)

(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合,原因はプロセスの機能分割が適切ではないことが多々あります.
プロセスは,例え名前がなくても,入出力データからその内容を容易に推測できるものでなくてはなりません.

データの流れに名前をつける際には,「~情報」や「~データ」と言う名前をつけてはいけません.
抽象的すぎ何を表わしているのかわかりません.
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら,何を表わしているのかわかるでしょうか.
もし,データの流れに具体的な名前がつけられないのなら,DFDの作り方に間違いがあります.再検討しましょう.
(引用終了)

【参考2】
DFD(データフローダイヤグラム)の描き方(1) | ステキな一日

(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が100%完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。

データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)

DFD(データフローダイヤグラム)の描き方(2) | ステキな一日

(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか?

(1)今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。

(2)そして外部要素への入出力を描きます。(これは対象外への最終的な入出力となります。)

(3)データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。(後で入れられるし、変わるかもしれないので)

(4)今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)

DFD(データフローダイヤグラム)の描き方(3) | ステキな一日

(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってDFDの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。

プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。 
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)

DFD(データフローダイヤグラム)の描き方(4) | ステキな一日

(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。

データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)

DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。

「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。

これから気をつけようと思う。

| | コメント (0)

2016/10/10

T字形ER手法の手順書のリンク

T字形 ER手法の手順書のリンクがあったのでメモ。
分かりやすい資料。
自分が理解したことをメモ書き。間違っていたら後で直す。

【参考】
TM の最新 バージョン (TM2.0)

T字形 ER手法 使用上の注意点

僕はSQLをこう学んだ | mah365

(引用開始)
T字形ERというデータモデル設計法

上記のようなテーブル設計とは別に、かなり興味を持って勉強していたのがT字形ERというデータモデル設計法です。

たまたま前にいた会社の自由参加型の研修に応募したときに出会った考え方なのですが、佐藤正美という先生がなかなかヘンクツで面白い人で引きこまれたのでした。

太っ腹なことに、研修で使っているテキストも公開してくれています:
(中略)

T字形ERはRailsでのテーブル設計と相性が良い考え方でもあるので、また折に触れて整理した状態でご紹介したいです。
(引用終了)

T字形 ER手法のテキストのリンクは、TM の最新 バージョン (TM2.0)にある。

手順はこんな感じと理解した。

「受注入力」画面又は帳票を準備
→「受注入力」の勘定科目のT字形勘定を作り、左側に一意となるキー、右側に従属項目、のように仕訳(仕分け)する
→さらに正規化していき、「顧客」「商品」「受注」のような勘定科目のT字形勘定に仕訳する
→エンティティ(勘定科目)をリソース、イベントで分類し、イベントは時系列に左から右、リソースはイベントの上下に配置する。
→リソース、イベントに関連(参照制約・複合制約)を付ける
→さらにサブセットで分解して、NULL値を除去する

興味深い点は、簿記のT字形勘定を真似ていること、RDBに格納されたデータが命題であることから集合論の知識(1階述語論理とか)が使えること、イベントは全順序でリソースは半順序の関係にあること、みなしエンティティは「共存」の継承関係を使ってNULL値を除去していること。
DOAは色んな流派があるけれど、突き詰めると、機械的な設計手順となるT字形ERに落ち着くのかもしれない。

但し、T字形 ER手法 使用上の注意点に記載があるように、T字形ER手法は相当練られているので、自己流に解釈してカスタマイズしないように、と注意書きが書かれているので要注意。

| | コメント (0)

より以前の記事一覧