モデリング

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)

2015/08/25

「ビヨンド ソフトウェア アーキテクチャ」は買い?

ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ(LukeHohmann 岡澤裕二 和智右桂) | 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか! これはとても良い本でした。 - t-wada のコメント / はてなブックマーク


(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス(マーキテクチャ)と技術(ターキテクチャ)をつなぐ架け橋として、情報システム部の方全員に読んでほしい本(情シス必読書)です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか?」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A:リリースチェックリスト
補遺B:戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな?

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

| | コメント (0)

2015/08/20

CSV形式のデータをSQLを使って解析する方法

CSV形式のデータをSQLを使って解析する方法があったのでメモ。

【参考】
Download and Install

Linux - CSV形式のデータをSQLを使って解析する - Qiita

Text as Data - q によるテキスト(CSV, TSV など)データの SQL クエリー操作

WindowsでもLinuxでも、qコマンドを入れると使える。
但し、UTF-8のCSVがデフォルトなので、MacやLinuxの方が使いやすいだろう。

実際に試してみたら、CSVをあたかもRDBのように見なして、SQLでいくらでもデータを抽出したり、整形できる。
これは便利だ。

データ解析をR言語で試すアイデアもあるが、SQLの方が慣れているので、使いやすい。
上記の記事では、日毎の売上集計、商品売上ランキングなどをSQLで出力する例がある。
簡単なSQLだけど、経営分析とか、プロジェクト管理におけるちょっとした実績集計処理に使えそう。

色々試してみる。

| | コメント (0)

2015/08/18

ユースケース駆動ではなくロバストネス駆動開発?

「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。

【参考1】
天使やカイザーと呼ばれて ≫ ロバストネス駆動開発?

天使やカイザーと呼ばれて ≫ ロバストネス図113枚!!

OOAD講座:第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking

ロバストネス図の使い道: プログラマの思索

ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。
この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。
確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。

ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。
単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バッチ処理があったりすると、ラフな設計がいるのだろう。

【参考2】
ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (2/3) - @IT

ソフトウェア開発の匠(1):「ITエンジニアは職人気質を取り戻すべき」 (3/3) - @IT

ユースケースの疑問: プログラマの思索

UML再考: プログラマの思索

ユースケースの善し悪し: プログラマの思索

でも、萩本さんの記事によれば、「ロバストネス分析に多大な工数をかけたが成果が出ない」という問題もある。

(引用開始)
ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。
しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

(1)ユーザーも開発者も理解しづらい産物を作りかねない
(2)分析モデルを作るまでに多くの工数を要する
(引用終了)

オブジェクト指向分析(OOA)の弱点は、分析モデルと実装モデルの乖離があるために、実装モデルに辿り着くまでの工数が大きくかかることだろう。
分析麻痺症候群に陥りやすい弱点があるのではないか。

概念モデル→論理モデル→物理モデルみたいな流れだと、中間成果物がやたらと増える。
しかもその成果物の保守も大変。

ロバストネス図がユースケースとクラス図の間を結ぶミッシングリンクであることは分かるが、仕様変更やソース修正と同じタイミングでロバストネス図も保守していくのは結構大変だ。
つまり、ロバストネス図も設計書やソースと同じく、構成管理の配下に置くべきである。
しかし、構成管理と連動したモデリングツールは結構使いづらい。

但し、astahは個人的には設計のスケッチツールとして使いやすいし、Subversionと連携して構成管理も可能だ。

【3】ロバストネス駆動開発は、個人的には結構イケているのではないか、と思ったりする。
簡単に書けるし、書いていくうちに、処理の粒度に気づいたり、他の人とのコミュニケーションにすぐに使えるからだ。

もう少し考えてみる。

| | コメント (0)

2015/08/14

ユースケースの善し悪し

ユースケースの善し悪しについて、良い記事があったのでメモ。

【参考】
良いユースケースを書くための発想法

ユースケースの疑問: プログラマの思索

ロバストネス図の使い道: プログラマの思索

ユースケース駆動開発実践ガイド: プログラマの思索

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき

最近、ユースケース記述を読む機会があり、システム要件がシンプルに上手く書かれていた。
その理由を考えている時、良いユースケースを書くための発想法を読んで、なるほどと思った。

僕もよく間違えるけれど、ユースケースを機能仕様としてシステム観点で細かく書いしまいがち。
本来のユースケースは、利用者の観点で、システムスコープを明確にすることだ。
また、ユースケースは、利用者とシステムの相互作用の観点として書かれるべきなので、シーケンス図でシステムと応答するような形で書くイメージになるべき。

| | コメント (0)

2015/07/15

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う

Conwayの法則の拡張版として、「運用は組織に従う」「ワークフローは組織に従う」という経験則があるように感じた。
ラフなメモ書き。

【参考】
システム設計よりも業務プロセスの設計をやっている: プログラマの思索

業務システム設計の隠れた要件~会計監査やシステム監査: プログラマの思索

Conwayの法則~組織はアーキテクチャにしたがう: プログラマの思索

「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索

パターン14:Conwayの法則 

(引用開始)
別名:
アーキテクチャは組織にしたがう
組織はアーキテクチャにしたがう

問題:
組織とアーキテクチャの整合

コンテキスト:
アーキテクチャ設計者と開発者チームが集まった。アーキテクチャは結構うまく設計されている。

影響する事柄:
アーキテクチャは組織の中での情報交換の経路を形作る。
デファクトな組織構成は、形式的な組織構成を形作る。
形式的な組織構成がアーキテクチャを形作る。
初期段階におけるアーキテクチャにしたがった定型化は、単に近似であり不安定である。

解決策:
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。

結果として生じるコンテキスト:
組織と製品アーキテクチャが整合する。

論理的根拠:
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。
(引用終了)

【1】端的に言えば、Conwayの法則とは「どんなソフトウェアであれ、それを作った組織の構造を反映する」という経験則。
ソフトウェアのアーキテクチャ、ソフトウェアの複雑さは、それを作った開発した組織、利用する組織の組織構造がそのまま反映されてしまう。

よく言われる例として、コンパイラを作る開発者が4つのチームに分かれていたために、4パスコンパイラという無駄なアーキテクチャになってしまった、という事例がある。

「組織構造がソフトウェアの複雑さに反映されてしまう」というConwayの法則は、他の場面にも拡張できると思う。

【2】「ワークフローは組織に従う」経験則を感じる場面は、Redmineをいろんな現場に導入する際に、現場特有の事情からワークフローが複雑になっていく状況で痛感する。

本来は、ワークフローはシンプルでいい。
「タスク」「バグ」などのトラッカーのワークフローは、本来はそんなに複雑にすべきではない。

しかし、開発現場によっては、開発チーム以外に、品質保証部や他部署の開発チーム、オフショアの開発チームとやり取りする状況があり、複雑になりがち。

例えば、国内の開発チームが設計した設計書に従って、オフショアの開発チームがコーディングし、そのプログラムを国内の開発チームが受入する場合がある。
すると、国内の開発チームの作業のワークフローはシンプルで良いが、オフショアへ開発作業を依頼してから受入するまでの作業を進捗管理したい場合、ステータスが増えてしまい、ワークフローも複雑にならざるを得ない。

例えば、受入担当者も、仕様レビューもあれば、開発標準のレビューもあるから、担当者が変わるし、その状態に対応するようにステータスも増える。
関連する組織が増えるほど、作業の状態を表すステータスが必要になり、ワークフローも長くなっていく。

僕もステータスが10個以上あるようなワークフローを実際に見たことがある。
それは「スタンプラリー」というアンチパターンにつながると思う。

でも、関連する組織構造があれば、ワークフローに反映せざるを得ないのだ。
そうでなければ、Redmineの運用が回らないから。

【3】「運用は組織に従う」経験則を感じる場面は、システム設計ではなく運用設計を考えている時に痛感する。

ERPを導入したら、そのERPを現場でどのように使うべきか、担当者ごとに業務ごとに役割や作業内容を決めていく。
しかし、システム設計の観点でトップダウンで決めると、現場の業務担当者から総スカンを食らう。
「その作業は私の業務ではありません」と言われてしまうのだ。
大企業ほど、組織がサイロ型になっているので、自分の担当範囲以外の作業を押し付けられるのを嫌う。

すると、現場の意見を聞きながら、ERPの運用を導入すると、こんなメリットがあるから、むしろ作業した方がいい、とか、この作業は年数回しかないからマニュアルを見てやれば問題ありません、などのように、運用フローの同意を得ていく必要がある。

こんなまどろっこしい作業が必要な理由は、現状の運用フローは組織構造に従った職務分掌で決まっており、それを修正することは、組織構造を変更することにつながると直感的に感じているからだろう。

運用フローが変更されることで、作業が増えるのは拒否されるのは当たり前。
だが、現状の運用フローが変更されると、現場は混乱してしまいがちなので、拒否反応を起こしがち。

最悪なのは、ERP導入によって、担当の業務がなくなると分かったとしても、以前の部署が残り続けることで、ERP導入の反対者になってしまう状況だろう。

そんなことを思うと、現場の運用フローをシステム設計の観点で変更するのは、あちこちの部署に同意を取る根回しが必要になり、非常に面倒だ。
運用フローは組織構造を反映しているから、そう簡単に変更できないのだ。

この辺りのノウハウや経験則もプロジェクトマネージャには必要なのだろう、と今更ながら感じる。


| | コメント (0)

2015/07/04

ブルーオーシャン戦略は機能をそぎ落として必要最低限の製品を作り出す戦略の一つ

先日、関西IT勉強会でブリビオバトルがあった。
その時に、ブルーオーシャン戦略の本の感想を聞いて、ようやくその意味を理解できたのでメモ。
以下は疲れた頭で、ラフなメモ書き。

【参考】
N's spirit ブルーオーシャン戦略とは 戦略キャンバス

【1】アイデアに基づく製品をどのマーケットに売り出すべきか、あるいは、こんな商品があるがどう売り出したらいいか、その戦略を考える時に、ブルーオーシャン戦略が役立ちそうな気がする。

【2】「ブルー・オーシャン戦略」のツールは、アクション・マトリックスと戦略キャンパス。
アクション・マトリックスでは、製品の原型に対し、「取り除く」「減らす」「付け加える」「増やす」ことによって、新たな価値を生み出す。

つまり。、アクション・マトリクスは、アイデアから生み出された製品の原型に対し、まずは機能やデザインのうち不要なものを取り除き減らす。
そこから、新たな機能やデザインを付け加えて増やす。

この考え方は、MVP(minimum viable product)に似ている。
リーンスタートアップに出てくるMVPは、製品の機能は必要最低限として、市場のフィードバックを得ながら仮説検証していく。
最初から機能てんてこもりではないのだ。

【3】戦略キャンパスは、横軸に顧客に提供する価値、縦軸に顧客が享受するメリットのグラフを描くこと。
ポイントは、横軸に、アクション・マトリックスで見出した新たな価値観を追加することで、他のライバル企業の差別化を図る。
まだ誰も販売していない未知のマーケットに売り出せれば、それがブルーオーシャン。

ブルー・オーシャン戦略」では、サウスウエスト航空やイエローテイル(アメリカ産ワイン)等の例があり、非常にわかりやすい。

戦略キャンパスの考え方は、ポジショニングマップの描画に使えるのではないか、と思う。
ポジショニングマップは、実際は結構書きにくい。
肝心の縦軸・横軸の評価項目をなかなか洗い出しにくい。
でも、戦略キャンパスは、数多くの評価項目を抽出してくれるので、効果的に使えそうな項目を選んで、プロットする内容が散らばるようにできればいい。

ポジショニングマップを描けば、ブルーオーシャンのマーケットは、必ずどこかのエリアに存在し、そこはまだ手つかずの領域でもあることが如実に表現される。

【4】「ブルー・オーシャン戦略」には「市場の境界を引き直す6つの視点」という戦術が紹介されているが、これはファイブ・フォース(5F)の考え方に近い気がする。

ファイブフォース分析の概要とやり方 | カイロスのマーケティングブログ

5フォース分析(5つの競争要因)[ITCサンシャイン・ブレインズ]

ファイブ・フォース分析は、特定業界の外部環境を分析するのに使われるが、「市場の境界を引き直す6つの視点」と被っているような気がする。
その理由は、双方ともに、外部環境の分析に使われるからだろう。

1.代替産業に学ぶ→代替品の脅威
2.業界内の他の戦略グループから学ぶ→既存企業同士の競争、新規参入者の脅威
3.買い手グループに目を向ける→買い手の交渉力
4.補完財や補完サービスを見渡す→サプライヤーの交渉力
5.機能志向と感性志向を切り替える
6.将来を見通す

| | コメント (0)

より以前の記事一覧