モデリング

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)

2016/08/17

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ

「マイクロサービスアーキテクチャ」を読んだら、すごく面白かった。
ThoughtWorksの開発者が書いた本は、どれも随筆っぽく、個人的にはどれも面白い。
マイクロサービスに関するラフなメモ書き。

【参考】
akipiiさんのツイート: "「たぶんマイクロサービスは本当に組織論」という言葉がすごくイイ!ソフトウェア工学の理論で整理できないかな?マイクロにしすぎた結果がこれだよ! #architecture #golang https://t.co/3w5pY6aedt"

Yoshihito Kuranukiさんのツイート: "プログラミング、それも優れたソフトウェア設計で学んできたことは、経営をする助けになっている。組織とソフトウェアの構造は似るという「コンウェイの法則」を逆に考えれば、良いソフトウェアの設計を応用すれば、良い組織の設計ができる、とも考えられる。そもそも会社とはソフトウェアなのだから。"

akipiiさんのツイート: "逆コンウェイの法則。組織構造はアーキテクチャに合わせる。経営者の観点では、組織は経営戦略に従うのだから、アーキテクチャの下で組織構造を従わせる感覚は普通なのかもしれない。 https://t.co/8FYPiEDyjh"

マイクロサービスアーキテクチャとは何か - arclamp

マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita

マイクロサービスを設計するときはエンジニアの発想を捨てる

今話題のマイクロサービス・アーキテクチャについて、本格的に実践中のビズリーチさんに聞いてみた! | HTML5Experts.jp

マイクロサービスの実際: 第 1 回 マイクロサービス入門

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【1】マイクロサービスアーキテクチャはなぜ今頃、流行しているのだろうか?
@sakaba37さんにに、「マイクロサービスアーキテクチャ」の本が面白かったんですよ、とちょっと興奮気味に話したら、怪訝な顔をされた。

マイクロサービスというアーキテクチャの発想は既に知られているし、分割するのは当たり前だ。
でも、どの粒度まで分割すべきなのか、分からない。
従来のソフトウェアの分割統治の設計手法と何が違うのか?

マイクロサービスで、仮想環境や継続的デリバリーや自動テストの最新技術を取り入れて、早くリリースできるのは理解できるが、それら技術を使えば早くリリースできるのは他の設計でも同じ。
組織構造とマイクロサービスが密接に関連していて、マイクロサービス単位のチームを構成すべき、という観点も、従来のConwayの法則からして、当たり前ではないか、と。

確かに、そうだな、と思う。
では、従来の設計思想と何が違うのだろうか?

【2】マイクロサービスが今頃になって注目される理由は、「外部システム連携」「プラットフォーム」「組織構造」の3つの観点があるから、と思う。

【2-1】僕がマイクロサービスに興味を持つのは、社内の数多くの業務システムを開発したり保守していると、「外部システム連携の設計手法の一つ」としてマイクロサービスアーキテクチャが必要になってくる場面が多くなっているからだ。
以前は、外部システム連携と言えば、無数のバッチをフローでまとめたバッチ処理が主流で、ジョブフローのどこかが止まればバッチ処理が止まってしまう。
バッチ処理で設計すると、リランや運用フォローで必ず手作業の運用手順が入り込んで、更に作業が複雑になる。

そこで、外部システム連携をマイクロサービスでオンラインでリアルタイムにやり取りできるようにすれば、運用もかなり楽になる。
機能追加もやりやすい側面がある。

従来はバッチ処理でしか設計できない場面が多かったが、最近はサーバーの高性能化やクラウドのおかげで、マイクロサービスで作りやすくなった経緯もあるだろう。

【2-2】外部システム連携をマイクロサービスで作るようになると、元のシステムは、外部システムと連携しやすいようなAPIを多数作りこむ必要が出てくる。
そのAPIがマイクロサービスに相当するように作る場面が多い。

すると、元のシステムは「プラットフォーム化」してくる。
つまり、外部のシステムから見れば、マイクロサービスのAPIを提供するシステムは、重要なデータが蓄積されたデータ基盤である。
そのデータを取得したいために、マイクロサービスというAPIが必要になってくる。
その外部接続用APIは、リアルタイムに取得できるI/Fが良い。
たとえば、REST APIがその一つだろう。

そんな事を思うと、Redmineは一つのプラットフォームであるように思えてくる。
なぜなら、Redmineはソフトウェア開発案件の作業情報が蓄積された一つの情報系システムであり、そのデータはREST APIで好きなように外部システムから取得できるからだ。
たぶん、Redmineが日本で普及した理由の一つは、データが蓄積されるほど有用なシステムであり、そのデータをREST APIでいつでも取得できて、外部システム内でデータを加工できる点にあると思う。

【2-3】システム機能をマイクロサービスで設計してみると、システムは複数のサブシステム(マイクロサービス)に分割され、それらサブシステムが連携して一つのシステムとなるような設計になってくる。
つまり、システム構造はより複雑になる。
すると、それぞれのサブシステム毎に開発チームが作られて、システム単位の並行開発になってくる。

そういう側面を見ると、マイクロサービスごとに開発チームという組織構造が現れる。
Conwayの法則は「アーキテクチャは組織構造に従う」であるが、マイクロサービスの設計思想が浸透すると、「アーキテクチャ(マイクロサービス)に合わせて組織(開発チーム)が従う」という逆コンウェイ戦略の思想が自然に出てくる。
この部分がすごく面白いと個人的に思っている。

なぜなら、開発者主導で組織構造が変化する場面に遭遇することができて面白いからだ。
普通は、経営者が自分の戦略に基づいて、トップダウンで組織構造を定める。
開発者は、その組織構造に従って作業するしか無い。

でも、マイクロサービスアーキテクチャでは、マイクロサービスに合わせたチーム構成が自然であり、そのような組織構造を作ることが推奨される雰囲気になる。
マイクロにしすぎた結果がこれだよ!の中で「たぶんマイクロサービスは本当に組織論」という言葉が出てくるけれど、おそらくそんな感触なのだろうと推測する。

【2-4】アーキテクチャと組織の密接な関係は、知っている人は当たり前の概念みたいだが、僕にとっては、そんなに当たり前の概念でもない。
現代の日本のソフトウェア工学、ソフトウェアプロセスの問題の真因を探ると、結局、組織論の問題になってしまう場合が多いのではないか、と思ったりする。

組織構造は一度定めると、組織慣性が働いて、組織内部のメンバーはもちろん、経営者ですらも組織を変更できなくなる場合が多い。
たとえば、官僚制組織が最たる例だ。
つまり、組織構造は一旦作られると、それを変更するのは難しく、人々は組織に嫌々ながら従わざるをえない。

【2-5】一方、作られたシステムの設計に従って作られたチームがどんどん肥大化して大規模組織となり、その組織設計が経営戦略の障害になる事例もある。

たとえば、「マイクロサービスアーキテクチャ」の本では、こんな話があった。

大規模インターネットが出現する前の時代に、Webサイトを持つ大手印刷会社はCMSを作った。
そのCMSは、料金を支払った第三者がコンテンツを入力するシステム、そのデータを加工する中央システム、一般大衆が閲覧できるフロントシステムの3つに分割されていた。
当時は、入力・中核・出力の3つのシステムと密接に連携した組織が、小規模ではあるが、部門として作られた。

当初は、オンデマンドのビジネスは小さかったが、じきにCMSを中核としたオンデマンドのビジネスが従来の印刷事業を上回るようになった。
すると、組織構造が事業の成長に合わなくなってきて、不都合になってきたのだ。

つまり、事業のIT側の3つの部門はそれぞれ、入力・中核・出力の3つのシステムに一致しており、それぞれの部門で別々のデリバリーチームがあった。
この組織構造がシステム設計よりも前に存在しておらず、実際にシステムを中心に組織が形成されていった、ということを誰も自覚していなかったのだ。

しかし、組織構造をすぐに変えることは難しい。
上記の事例で組織変革が難しい理由は、組織の元になる入力・中核・出力の3つのシステムを変えなければ、組織をいくらいじっても、逆に業務に支障が生じてしまうためだ。

一般には、組織変革が失敗する理由は、組織慣性が働くために、経営者ですらも組織構造やそれに基づく組織文化を変えることが出来ないからだ。

上記の事例では、システム設計の欠点に気付き、組織構造を変更するためにシステム移行を行なっているらしい。
しかもその移行プロセスは、何年も経ったのに、今も進行中らしい。

そんな話を読むと、頑固な組織構造や組織文化の背後には、時流に合わないシステム設計がその根本原因である場合もある、ということに気づく。

【3】マイクロサービスが今頃になって出てきたのは、上記だけでなく、技術がようやく揃ってきたこともあるのだろうと思う。
開発環境や本番環境の仮想化がやりやすくなり、AWSのようなクラウドにすぐに乗せることができて、コミットできれば即リリースできるような仕組みが整ってきた。
つまり、継続的インテグレーション、継続的デプロイ、継続的デリバリーのような技術とマイクロサービスはすごく親和性が高い。

そのおかげで、マイクロサービスアーキテクチャというボトムアップの設計手法が注目されるようになったのだろう。

【4】でも、マイクロサービスが全ての問題を解決するようなバラ色の手法ではない。
たまたま設計してみたら、マイクロサービスという共通の設計手法が作れるのでは、という感じだ。

「マイクロサービスアーキテクチャ」の本でも、最初からマイクロサービスで分割する設計をするよりも、ある程度システムの機能が揃ってきた後に、マイクロサービスに分割するようにリファクタリングすることを勧めている。
つまり、最初からマイクロサービスで設計できる場面はそう多くないらしい。
実際、たとえば、Redmineもある程度チケット管理の機能が揃ってきた後で、REST APIが次々に作られて公開された歴史がある。
最初からマイクロサービスで作ろう、という発想はなかったのだろう。

一方、SOAはトップダウンの設計手法であり、最初から外部接続できるようなAPI設計をすべき、という思想が貫かれている。
SOAとマイクロサービスは共通点もあるが、相違点も多い。

個人的には、マイクロサービスを再利用可能なコンポーネントとみなして、デザインパターンのような設計パターン集が作れるといいなあ、と思っている。
Webシステム、Webサービスのより良い設計手法は発展途上であり、その手法はぐちゃぐちゃで整理されていないからだ。

【5】個人的には下記2つの資料がすごく分かりやすい。

| | コメント (0)

2016/01/03

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ

2015年になって、ITの地殻変動がどこに起こっているのか?を考えてみる。
自分の理解が浅いのは承知のうえで、以下は、妄想を含めたラフなメモ書き。
間違っていたら後で直す。

【参考】
機械学習をこれから始める人に押さえておいてほしいこと - Qiita

Pythonでデータの分析を出来るようになりたい(その1) - Qiita

Pythonでデータの分析を出来るようになりたい(その2) - Qiita

Pythonでデータの分析を出来るようになりたい(その3) - Qiita

Pythonでデータの分析を出来るようになりたい(その4) - Qiita

「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

Google、脳のシミュレーションで成果……猫を認識 | RBB TODAY

データサイエンティストを目指すというかデータ分析を生業にするなら読んでおきたい初級者向け5冊&中級者向け12冊(2015年冬版) - 東京で働くデータサイエンティストのブログ

クリスマスイブに「さくらの聖夜」というイベントに行ったら、とんでもない発表が行われていたw #さくらの聖夜 - Blog::koyhoge::Tech

「統計学が最強の学問である」の感想: プログラマの思索

機械学習に関するメモ: プログラマの思索

「データサイエンティスト」の感想~データマイニングが自然科学を再定義し直す: プログラマの思索

教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索

【1】最近思うのは、オープン化、Web2.0、スマフォ・タブレットと進化し続けたWebの進化よりも、データマイニングの技術革新の方がすごく勢いがあるように感じることだ。
今や、スマフォは手のひらサイズのPCであり、Unixであり、これ以上の究極の進化形はないのではないか。

【2】一方、データマイニングの技術は、ようやく必要な機能が一通り揃ってきたように見える。

1)HadoopやStackなどのMapReduceの技術がこなれてきた。
これらの技術によって、データ解析の技術基盤が揃ってきた。

2)データマイニングの開発環境は、クラウドですぐに作れる。データ容量が増えても、スケールしやすい。

3)IoTの概念によって、HWのセンサー機器から大量のデータを収集できるようになった。
他にも、皆が持っているスマフォから、位置情報やSNS情報を収集できる。
あるいは、ドローンやRaspberry Piなど、数多くの機器からも、大量のデータをリアルタイムに収集できる。

4)R言語のような統計学に特化したプログラミング言語が普及してきた。
今なら、R言語よりもPythonの方がもっと手軽に書けるだろう。

5)他にAIの復活。機械学習がAIを復活させたように見える。

【3】機械学習やデータマイニングが今のトレンドになっている理由は、R言語やPythonなどでプログラミングしやすくなり、クラウドで大量データをスケールしやすくなったことだけではないと思う。
機械学習やデータマイニングの背後には、統計学という理論でそれら成果の裏付けが保証できる、という点が最大の理由だろうと思う。

つまり、IoTでセンサー機器から大量のログを収集できた後、それら大量データを帰納法を使って見出した因果関係は、その正当性を統計学が保証できる仕組みがあるからだ。
すなわち、統計学が機械学習から得られた知見の確からしさ、正当性を保証してくれるわけだ。
その因果関係の真の意味は後回しで良く、理論づけはその後で良い。

統計学が最強の学問である」に書いてあるように、昔の統計学は退屈な学問だった。
つい最近まで、せいぜい電卓を使うぐらいで、コンピュータの性能も低く、大量データを手計算で処理するには限界があった。
だから、限られたデータ量から、いかに少ない手数で計算して、因果関係を推測するか、という手法ばかり発達していた。
つまり、統計学の本来のメリットが生かせていなかったわけだ。

しかし、プログラミング言語やMapReduceなどの技術、クラウドなどの開発基盤、センサー機器やドローンやスマフォなどのデータ収集機器が揃ってきて、ようやく大量データから帰納的な理論を打ち立てることが可能になってきた。
そして、誰もが手軽に、センサー機器を組み立てたり、ドローンを飛ばしたり、PythonやRでデータマイニングのプログラムを書くことができるようになってきた。
それらから得られた知見は、統計学を上手く利用すれば、その正しさを保証できるはずだ。

【3】「機械学習やデータマイニングで得られた知見は統計学で保証できるはず」という考え方は、僕にとって既視感を感じる。
つまり、「既存の理論をバックにして、新しい技術を使って試す」というやり方がすごく既視感。

例えば、チケット駆動開発というアイデアは、既に枯れたツールであるBTSやITSをアジャイル開発に適用するという発想から生まれた。
そこから更に発展させて、汎用的な機能を持つBTSをアジャイル開発だけでなく、PMBOKやソフトウェア工学に適用させて、既に知られているプラクティスや理論上の概念を実際に試して評価することもできた。

理論を完全に理解できていなくても、既知の理論にあるプラクティスや概念を片っ端から試してみれば、ノウハウがたまるし、理論のメリットやデメリット、適用の限界なども見えてくる。

同様に、統計学で既に知られている概念やメソッドを実際のプログラムで実現し、実際に機械学習で試してみれば、色んなノウハウが得られるだろうし、理論を使えばもっと良い方法が見つかる可能性もあるだろう。

例えば、「統計学が最強の学問である」では、POSデータ解析でよく使われるバスケット分析は、統計学におけるカイ二乗検定の方が優れている、という指摘がある。
実際、グーグルの共同設立者も「バスケット分析よりも統計学的な相関分析の方がいい」という論文を書いているらしい。

つまり、システム開発で試行錯誤して相関関係を見出したアルゴリズムよりも、統計学にある既存の概念を使った方がはるかに効率的に因果関係を見いだせる場合があるわけだ。

その理論を知っている人なら当たり前のことでも、現場の人はそういう理論は知らない。
逆に、理論を知っている人は、ビジネス経験や実際の応用事例が不足しているから、世間に向けて効果のある知見を披露できない。
だからこそ、プログラミングという強力な武器を持っているプログラマは、理論を少しかじってみるだけでも、新しい知見を見出し、社会に貢献することが可能なはずだ。

【4】とは言え、統計学の手法を実際の応用事例に生かす、という手法は、IT業界以外でも既に幾つか知られている。
例えば、製造業の品質管理技法では、統計学を応用する手法は既に行われている。
実際、製造業では、出荷時に全数検査はできないので、一部の標本を抜き取って品質をチェックする抜き取り検査を行わざるをえない。
その時に、抜き取り検査で得られた品質評価の結果が、他の残りの全ての製品でもほぼ同じで問題ない、という箇所で統計学の推定・検定を使っているわけだ。

品質管理技法は、日本では昔から、QC検定で既に資格化されている。

QC検定 | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

また、最近ならば、マーケティングにも統計学を応用する動きが見られる。
レコメンドエンジン、バスケット分析、CRMなど、購買分析や顧客分析にも使えるし、ビジネスにより直結する。

統計学検定という資格もあるらしく、3級は高校卒業程度らしいので、理論を習得するのに丁度良いかもしれない。

統計検定:Japan Statistical Society Certificate

日本統計学会認定「統計検定2級」に合格しました - akiyoko blog

【5】機械学習やデータマイニングで気になることは、Pythonの隆盛であり、Rubyがやや遅れているように見える点だ。

例えば、Rubyは、Railsという強力なWebフレームワークのおかげで、Webの世界では大きな影響力を持つ。
また、Chefなどクラウドに関するインフラ技術においても、Rubyという技術は必須であるように見える。
しかし、今のトレンドである機械学習やデータマイニングの世界では、Rubyの影が薄いように見える。

個人的には、Rubyはたくさんのポテンシャルが秘められていると思うので、この方面にも拡張して欲しいと思う。

| | コメント (0)

2015/09/22

ドメイン駆動設計はアジャイル開発の弱点を補完する技法ではないか

増田さんのドメイン駆動設計の公開資料が素晴らしいのでリンクしておく。
ドメイン駆動設計はアジャイル開発の弱点を補完する技法ではないか、というアイデアをメモ。
ラフなメモなので、ロジカルでない。

【参考】

(引用開始)
エヴァンスが取り組んだ技術 「オブジェクト指向」と「XPスタイル」の設計 に、現場で取り組んだ成功と失敗の物語。
そこから学んだ教訓をまとめたものが 「ドメイン駆動設計」
オブジェクト指向分析設計の参考にすべき文献は多いが、現場で使える実践的なガイドが 意外と少ない
現在、DDDコミュニティの一部は、「クラウド時代のドメイン駆動設計」への挑戦と実験を盛 んに行っている
(引用終了)

「XPやScrumの母体であるアジャイルコミュニティでは、オブジェクト指向の分析設計は当たり前の手法であり、スキルだった」のに、いつの間にか、その設計技法が忘れ去られて、設計技法そのものが軽視されてしまった。
しかし、それでよいのか?

ファウラーなど、アジャイルコミュニティを引っ張ってきた人達を見ると、ビジネスモデリングもシステムの設計能力もすごく高い。
その前提が忘れられている。
実は、ドメイン駆動設計は、アジャイル開発コミュニティが忘れてきた設計技法の教訓やノウハウを集大成したもの、という指摘はすごく分かりやすい。

ドメイン駆動設計はアジャイル開発の弱点である設計技法を補完する技法と見なせば、最近すごく注目されている背景も分かるような気がする。
マイクロサービス、イベントソーシングなどの概念が次々に現れているのは、昨今のような「多産多死のWebサービス開発」で必要な技法だからだろう。

興味深いのは、昨今のドメイン駆動設計のスコープは、エヴァンズが語ってきた従来のドメイン駆動設計ではなく、クラウドに合わせたドメイン駆動設計へ進化しようと盛んに研究されている点だ。

確かに、エヴァンズのドメイン駆動設計の本の内容は、2004年頃までの内容の集大成であり、昨今のクラウド・モバイル・ビッグデータ・IoTなどの技術を前提とした設計技法ではない。
以前のノウハウや文脈では、実際の現場ではなかなか使えないのが現実だろうと思う。

個人的な直観としては、マイクロサービスのような機能の再利用性、イベントとメッセージングのようなUIの再設計が重要になるのでは、と思う。

前者は、SOAが思想として優れていてもなかなか普及しにくかった問題は、RESTやJsonの普及によって、いかに既存のWebAPIを再利用して、変更に耐えうるように、素早く開発するか、という観点に変わった。

後者は、PC時代のUIではなく、圧倒的に普及したスマートフォンに合わせたUIはアジャイルUXみたいな考え方に発展している。
そして、多数のスマートフォンが操作している背後では、Webサーバーがそれらのデータをやり取りし、プッシュ通知の仕組みを持っていたりする。

しかし、例えば、プッシュ通知の仕組みを実現するには、各スマートフォンの個人情報を保持する必要があり、状態に応じてプッシュ配信しなくてはいけない。
つまり、大量の個人情報を保持するセキュリティの仕組み、いかに大量のメッセージをさばくか、というサーバー上の仕組みが必要なのでそう簡単な設計ではないはずだ。
大手企業のように、大量のサーバーをデータセンターに持つか、クラウド環境でサーバーをスケールしやすいように設計するなどの技法が必要になってくるのだろう。

もちろん、これ以外にもドメイン駆動設計が今後深掘りすべきテーマや分野はたくさんある。
実践ドメイン駆動設計」でもその内容は少しは触れられているので、読んでみたい。
どこかで勉強会をやっていないだろうか?

| | コメント (0)

より以前の記事一覧