ERP・財務会計・経済学

2019/06/16

業務系エンジニアが生き抜くのは難しい時代になった

業務系エンジニアが生き抜くのは難しい時代になったという記事をリンク。
以下、脈絡のないポエム。

【参考】
業務系エンジニアはどうしていくべきか? - 急がば回れ、選ぶなら近道

【1】日本のSIなら、プログラマからマネージャになるにつれて、実装技術から離れてしまい、どんどん技術から離れていく。
すると、一番怖いのは、技術の目利きが落ちることだと思う。
最新技術のメリット、デメリットをいち早く見抜き、どの場面で適用すると上手くいくのか、逆に失敗するのか、という目利きができなくなると、正直怖くなる。

結局、技術の全部を抑えておかないと難しい。

【2】「最終的にはシステムはIOに行き着く」という指摘は秀逸。
アプリ、ミドルウェア、インフラなどの層別アーキテクチャ(N-Tier)はいつの時代も基本。
最近は、インフラが熱い。
インフラを押さえれば、最近の技術の動向はいち早く把握できる。

【3】イノベーションを常に強いられる業界は、そこで働く人にとっては苦痛に思える人も多いだろう、と思ったりもする。

実際、若かった人も年を取ればどうしても、過去の経験値に縛られたり、集中力や瞬発力が落ちるので、新しい文化を取り入れるのが難しくなる。
広岡達朗の著書の中で「人間は常に保守的な存在だ」という文言を以前読んだことがあったが、たぶんその言葉は真実なのだろう。
人間は、従来成功したやり方を明日からいきなり変える、ということに抵抗感があるのだろう。

経験値がゼロで、獲得した資産や家族がなければ何も怖くはない。
しかし、長年蓄積してきた資産、経験、家族が増えてくれば、それを全て捨て去り、一から作り出すのは心理的に難しくなる。
一方、イノベーションのジレンマでは、過去の資産を活用できるプロセス・イノベーションを前提にしていない。
むしろ、イノベーションを阻害するような過去の経験は無い方が、イノベーションを生み出しやすい。

イノベーションを常に強いられるIT業界は、脱落するエンジニアが多く、経験豊富な人よりも若者の方が有利、という特徴が出てくるのだろう、と思う。
そして、「IT業界はイノベーションが激しい」ということと「IT技術は後方優位性が強い」ということは同じ意味なのだろうと思う。


| | コメント (0)

2019/05/31

IOTは組立加工工場を中央制御型工場へ変える

ラフなメモ。
IOTはなぜ流行るのか?
下記の記事を読んでようやく分かった。

【参考】
お知らせ:「化学工学」誌に論文『ディスクリート・ケミカル工場の生産システムを考える 』が掲載されました : タイム・コンサルタントの日誌から

90年代までに日本の製造業の工場は、FA、FMS、CIMなどで既に、生産工程はほぼ自動化されている。
しかし、上記の記事から推測すると、組立加工の製造業のほとんどはたぶん、中央制御型工場ではなく、現場や各工程に分権化されている。
一方、化学プラントなどのプロセス系工場では、中央制御室による中央制御型工場が既に実現されていた。

では、なぜ、組立て加工の工場は、化学プラント工場のように、中央制御型にできないのか?
上記の記事では、工場設計の「アーキテクチャーの差異が、じつは扱うマテリアルが流体か固体かという、単純な違いに起因する」と主張する。

しかし、昨今のIOT技術を用いると、「従来モジュラー型でしか設計し得なかった組立加工系の工場を、インテグラルなシステムに変える潜在的可能性を持っています。この可能性に早くから着目したのが、ドイツの「インダストリー4.0」構想でした」。

つまり、IOT技術を駆使すれば、工場は完全無人化、完全自動化を実現できる可能性があるわけだ。
実際、Amazonの物流倉庫は完全自動化を目指しているわけだから、工場でも可能なはずなわけだ。

一方、日本の製造業の現状として、バブル崩壊後ずっと、過剰生産による設備投資に悩まされてきたので、生産設備の改善が停滞していた。
しかし、昨今のIOT技術の隆盛によって、ドイツがこの可能性にいち早く着目して政府主導で行った結果、実は日本は遅れていたのではないか、という見方が日本のメーカーでも強まってきた、というストーリーなのだろう。

| | コメント (0)

規模の経済と経験曲線効果のメモ

規模の経済と経験曲線効果は、どんな事業を起こすにしても、必ず使うビジネス上の経験則と思う。
以下は自分が理解したラフなメモ書き。
間違っていたら後で直す。

【1】規模の経済と経験曲線効果の違いは何か?

「規模の経済」とは、生産規模の拡大により、単位当たりの生産コストが低くなる事。
「経験曲線効果」とは、製品の累積生産量が増加するに従い、製品1単位当たりの生産コストが一定割合で減少すること。
つまり、規模の経済はハード面、経験曲線効果はソフト面に相当する。

規模の経済は、大企業なら大規模な資金を設備投資に振り向けることで実現できるが、中小企業には難しい。
しかし、経験曲線効果なら、中小企業でも、同一の製品の生産を繰り返し行うことで、作業員の経験値が上がることで、コストを下げることができる。

【2】規模の経済は、どんな業界に使われているのか?

たとえば、製造業のように、工場の設備投資と生産工程の標準化活動で成果を出しやすい。
また、規模の経済と経験曲線効果は製造業だけでなく、他の業界でも通用する場合が多い。
たとえば、コンビニや外食チェーンのようなフランチャイズ系列でも、大量仕入れによる原価低減と多店舗展開における販売サービスの標準化にも見られる。
つまり、小売・卸売業などでも、規模の経済の発想は使われている。
労働集約型の業界でも、経験曲線効果をいかに引き出すか、という視点の改善活動は必要らしい。

【3】規模の経済は、資本主義にとってどんな意義を持つのか?

おそらく資本主義というシステムは、設備投資効率を向上させてきた歴史がある。
その要因の一つには、規模の経済によるコスト低減効果があったからではないか。
実際、20世紀の歴史を振り返ると、銀行が全国民から貯蓄を収集し、そのお金で製造業へ大規模な設備投資を行い、大量生産してきた。
その結果、企業も政府もどんどん大規模になり、最終的にはとてつもない大規模な官僚制組織になった。

資本装備率(しほんそうびりつ)とは - コトバンク

(引用開始)
労働量に対する資本量の比率。正しくは労働の資本装備率,あるいは資本集約度という。
資本装備率は個別企業としても,また産業別にも,あるいは国民経済全体としても計測されるが,いずれにせよ雇用労働者数を L ,資本設備額を Kとすれば,この比率は K/Lとして表わされる。
資本装備率の上昇は生産力の増大を意味し,資本主義的経済発展は絶えずこの比率を上昇させる傾向にある。
(引用終了)

よって、規模の経済は資本主義の要となる重要な考え方ではないか?

【4】規模の経済に限界はあるのか?

ある一定規模までは、設備投資や経験曲線効果は有効に作用するが、いずれ壁にぶち当たる。
その壁にぶち当たるまでは、企業は価値連鎖となる工程や活動だけでなく、付随する活動も自社で内製化・内部保持する事で、規模の経済を活かそうとする。
たとえば、以前の日本の製造業では、本業の自動車・電気製品の事業だけでなく、従業員の出張サービスや娯楽サービスなどに至るまで事業として内製化してきた。
そういう事業として内製化した理由はおそらく、規模の経済のメリットを活かすためだったのだろう。

しかし、『プラットフォーム革命』によれば、人員や有形固定資産に縛られること、組織が大規模化することで複雑化する為に、規模の経済の効果は限界にぶち当たる。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

【5】規模の経済が活用できない業界はあるのか?

労働集約的な業種では、規模の経済・経験曲線の効き目は小さいだろう。
サービス業や、会計事務所・病院などのようなプロフェッショナル官僚制組織では、組織の大規模化による規模の経済のメリットが薄いかもしれない。

特に、ソフトウェア開発では、人月の経験則のように、大量の人員による開発は生産性のさらなる低下を生み出すことは既に知られている。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

一方、IT業界では、限界費用がゼロに近くなり、収穫逓増の法則になる。
たとえば、『プラットフォーム革命』のストーリーでは、IT業界におけるGAFAやBATのようなプラットフォーム企業では、人員や設備などの有形固定資産が無い為、限界費用はゼロとほぼ同じくなるので、規模の経済の限界がないと考えられる。
よって、プラットフォーム企業による自由競争の結果、唯一の企業による自然独占になり、市場と同規模になるまで成長することで、小国のGDPに相当するくらいの独占企業が生まれることになる。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

【6】規模の経済は経済学の考え方と矛盾するのか?

マクロ経済学のどこがヤバいのか

ミクロ経済学の基本的な考え方の一つに、「需要と供給の均衡」がある。
一般に、消費者の需要と生産者の供給量は、交差する1点、均衡価格に必ず落ち着く。

その考え方の前提には、「限界効用の逓減」「限界費用の逓増」の2つがある。
「限界効用の逓減」は分かりやすい。
たとえば、消費者にとって、生ビールの1杯目は美味いが、5杯、10杯と飲み続けると限界効用は低減する。

「限界費用の逓増」は「収穫逓減」と同じ。
たとえば、農業のように、肥料や労働者を増やしても、土地の面積は限界があるので、費用の増加分よりも産出量は少なくなる。

一方、規模の経済の概念はまさにその真逆で、たくさん作るほど「限界費用は低減」していく。
生産者にとって、同一製品を大量生産・同一原材料を大量仕入れすることは、規模の経済により限界費用は低減し、コスト削減につながる。
つまり、「限界費用の逓増」は規模の経済と矛盾する。
この部分はどうつじつまを合わせるように考えたら良いのか?

おそらく、平均費用のグラフを使って、ある一定規模までは「限界費用は低減する」が、上限を超えると「限界費用は逓増」する、と考えることで折り合いを付ける。

| | コメント (0)

2019/04/22

IT企業が経済学者を雇い始めた理由が面白い

最近、IT企業が経済学者を雇い始めた理由を解説する記事をちらほら見かける。
記事が面白いのでリンクしておく。
以下は、自分の理解のラフなメモ書き。
間違っていたら後で直す。

【参考】
IT企業はなぜ経済学者を積極的に雇い始めたのか | HBR.ORG翻訳マネジメント記事|DIAMOND ハーバード・ビジネス・レビュー

米アマゾンらが経済学者を雇う理由~デジタル経済学者のシェアエコ化(石角 友愛) | マネー現代 | 講談社(1/3)

IT企業による経済学の活用 : 遠い呼び声の彼方へ!

(引用開始)
第一に、最先端の経済学の理論は、IT企業が必要とするサービスの要素技術になり得るからです。
例えば、日経ビジネスに掲載されたハル・ヴァリアン教授のインタビューによれば、ヴァリアン教授が主導し、広告オークションの設計にオークション理論を取り入れ、AdWordsの設計を行ったそうです。
(中略)
第二に、最先端の経済学者はIT業界が必要とする統計のエキスパートであるという点です。
最先端の研究では、経済学者は統計理論を活用し、事象をモデル化することが要求されます。
結果、経済学者は統計によるデータ処理のエキスパートとなっています。
一方でIT業界も、データを活用するためのは統計処理が不可欠です。そしてビッグデータの時代になるほど、高度な統計処理が要求されます。
結果、ITサービスの開発やグロースに必要なデータ処理やそのモデル化に、統計学者の知見が活かされているのです。
(引用終了)

【1】昨今のAIや機械学習の隆盛を見ると、心理学や経済学のような文系の学問とIT技術の組合せが非常に相性がいいのだろう、と感じる。
その理由は2つある。

【2】一つは、心理学や経済学が過去数百年に渡って蓄積してきた理論や知見は、「市場や社会集団に対し、どのような社会制度や経済政策を整備すれば、人にインセンティブで動機づけさせて、あるべき正しい方向に人の行動を律することができるか」という問題をずっと考えてきたからだ。

その手法は、政治、経済の分野だけでなく、ショッピングサイトやオークションサイト、Uberやエアーアンドビーなどのマッチングサイト、などの多数のWebシステムに簡単に適用できる。
特に、マッチングサイトでは、情報やサービスを提供する生産者とそれを購入する消費者の間で、お互いに最大の利益を得るようなマッチングを計算する必要があるが、まさにそのアルゴリズムは、どのような仕組みをWebサイトに導入すれば取引が全体最適化されるか、という問題に置き換えられるからだ。

あるいは、SNSや広告エンジンのマーケティングでは、どのようなターゲット層にどんな広告内容を表示すればマーケティング効果が得られるか、という問題に対し、心理学の知見を活かすことで、ターゲット層に具体的なペルソナを作り出して、ABテストでマーケティング手法を実験する、ということも簡単に実行できるからだ。

つまり、既存のIT技術を使った結果に、心理学や経済学の過去の知見を適用すれば、そのデータに価値観を与えることができる。

まあ、振り返ってみれば、経済学はマンキューによれば「インセンティブの学問」でもあるし、一方、心理学も人間の性格に関する理論を数多く生み出してきたので、その内容を昨今のWebシステムに適用できるのは当たり前ではある。

【3】もう一つは、心理学者や経済学者は統計のスペシャリストであること。
実際、心理学や経済学の学部の卒論、修士論文は、アンケートから統計的有意性を評価したり、膨大な行動・経済データから因果関係を導いて理論化するなどの内容ばかりだ。
つまり、彼らは、統計学を自分達の学問で理論化するときの手段として普通に使っている。
その作業はまさに、最近もてはやされるデータ・サイエンティストの作業と全く同じだ。

昨今のコンピューティングパワーのおかげで、統計処理という煩雑な計算は全てプログラムで代用できる。
それにより、心理学や経済学が本来やりたかった「人にどんなインセンティブを与えると、あるべき方向へ行動を誘導できるか」という問題を簡単に実験できるようになった。

実際、Uberでは、ミクロ経済学の授業の最初に出てくる需要曲線や消費者行動曲線をリアルに導き出すことに成功した事例があった。
需要曲線が分かれば、供給曲線は生産者自身が制御できるので、均衡する価格を生産者自身が誘導する事ができる。

他に、たとえば、税金をどのように表示すれば、消費者の需要を損なわずに購買意欲を引き立てることができるか、という行動経済学の実験もあった。
この実験で得られた内容は、まさに政府の経済政策に取り入れれば、消費税率が上がったとしても景気の腰折れをさせないような効果を生み出す可能性があるだろう。

【4】他方、個人的には、機械学習やニューラルネットワークなどのAI分野において、昨今のIT技術で、過学習の問題をどう解決しているのか、に興味がある。

いくらコンピューティングパワーが上がったとしても、間違った方向で計算して過学習の状態、つまり鞍点に陥れば、本来の全体最適された結果が得られない。
この問題は古くから知られていて、解決方法も色々あげられているが、まだしっくりと来るものは感じない。

【5】「心理学や行済学のような文系の学問とIT技術の組合せが非常に相性が良い」事が分かれば、今後、IT技術者には、心理学や経済学の学習も必要にされてくるかもしれない。

IT技術者はプログラミングという道具には詳しいが、ビジネス上の問題を解決する手法は知らない。
たとえば、「eショッピングやマッチングサイトでどんな設計にすれば売上が増大するのか」「生産者や消費者にどんなインセンティブを与えれば、売上向上につながるような行動を誘発できるか」という問題を解決するには、心理学や経済学の知見を使って、ユーザを誘導するシステム設計を実現することが求められるからだ。

一方、心理学や経済学は膨大な理論を蓄積してきたので、彼らの手法をIT技術で実現するだけで、簡単にその有効性を評価できるはず。
手当たり次第、彼らの手法をIT技術で試してみてもいいわけだ。

そんな事を考えると、面白い時代だな、と思う。
文系の学問は役に立たないと昨今言われるけれど、実は、こういう場面で非常に有効と分かるからだ。

【6】でも、心理学や経済学の理論によって「人のインセンティブで行動を誘発させる」手法を悪用すれば、甚大な影響も起きるだろう。

たとえば、アメリカのトランプ現象、英国のEU離脱などの政治現象を見ると、FacebookのようなSNSを使って民衆の政治行動を悪い方向へ誘導させることも実現可能になったのかな、とも思う。
また、炎上マーケティングのように、過激な発言に数多くの人が「いいね」「リツイート」させられることで、莫大な広告収入が得られるなら、そういう方向へどんどん過激化させていく方向に進んでしまう。
つまり、売上向上の最適化を図るアルゴリズムが暴走すれば、「人のインセンティブに故意にエネルギーを注ぎ込むことで、過激な行動へ走らせる」方向へ進んでしまうわけだ。

実際、一人の人間として知性があったとしても、集団心理学の観点では、リスキーシフトのように、より過激な意思決定に進んでしまう事例は、過去の日本の敗戦や米国のベトナム戦争のように、既にある。

今は、ビジネスに限らず、政治経済の分野で、心理学や経済学とIT技術の組み合わせによる壮大な実験が平行で行われている時代のように思える。

| | コメント (0)

2018/11/16

ポーターの競争戦略の考え方

ポーターの競争戦略の考え方がようやく分かったのでメモしておく。
自分だけのメモ書き。

【参考】
外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 1ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 2ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 3ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 4ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 5ページ

戦略論の復習②…ポジショニングアプローチ | 田舎者の受験日記

【1】ポーターの競争戦略の基本構想はこんな感じ。

経済学の分野の中で、産業組織論がある。
産業組織論では、ある業界(市場)の制約条件が企業行動を制約し、結果として企業の収益率を決定する。
いわゆるSCPモデルでは、売上と収益率の分布図を書くと、V字モデルで表現される。
つまり、高収益企業は、売上は小さいがニッチ市場に特化した中小企業か、売上が大きく規模の経済を活かした大企業のいずれかになる。

V字カーブ

この考え方を逆手に取って、企業は、業界内で収益率の高いポジションへ移動すべき、というポジショニングアプローチを取る。
つまり、ポジショニングアプローチとは、①外部環境を分析して機会のある産業を発見し、②当該産業へ進出して参入障壁を築き持続的競争優位を確立する、という考え方で、産業分析→基本戦略の決定の順に行う。

すると、課題は「収益率の高い産業をどのように発見するのか」になる。

一般的な手順としては、
①PPM分析や5フォース分析を行い、収益率の高い産業を探す
②進出すべき産業が見つかったら、ポーターの基本戦略に基づき、業界のターゲットの幅と競争優位の源泉の2軸による分析で、コストリーダーシップ・差別化・集中戦略のいずれかを採用する
③基本戦略が決まったら、最後にその実施による参入障壁の形成と、持続的競争優位を確立し維持する
④さらに、自社の経営資源をバリューチェーン分析し、強みである経営資源の差別化を図る

価値連鎖(バリュー・チェーン)と活用方法

【2】ポーターの競争戦略で面白い、と思った点は2つ。

一つは、産業組織論という経済学の理論を背景にしているので、実証データがあり、経営学という曖昧な学問にも論理的な枠組みを提供して、思想を整理できること。

もう一つは、「プラットフォーム革命」を読んでみて、ポーターの競争戦略やコースの定理という経済学の基本思想を元にGAFAのような大手プラットフォーム・ビジネスを分析してみると、非常に分かりやすい、と思ったこと。
ゼロ・トゥ・ワン」を読んで、プラットフォーム企業は独占利潤を得るから安定している、みたいな主張がよく分からなかったけれど、「プラットフォーム革命」を読んで何となく分かった気がした。
the four GAFA 四騎士が創り変えた世界」の内容も、ポーターの競争戦略の基本思想「ポジショニング」「バリューチェーン」から考えると分かりやすくなると思う。

経営理論は、経営者という人に依存した理論と思っていたけれど、経済学の発想を適用すれば、政治的力を持つ人の恣意的な意思決定に無関係に決定する内容が多い、ということが分かった。
また、大手プラットフォーム・ビジネスも、従来の製造業の仕組みとは異なるビジネスモデルであったとしても、経済学の理論や制約条件に依存しているし、そこから離れられない。

【3】僕の理解では、プラットフォームビジネスとは、経済学の言う「貿易利益」で儲けている。

そのプラットフォームは、自由競争のない計画経済の基盤から成り立っているので、事実上の独占状態であるから、独占利潤を独り占めできる故に、史上最大の企業価値を持つに至った。

たとえば、GAFAやアリババは、何もない所から貿易利益によって莫大な独占利潤を得ていて、その利潤は、小国のGDPをはるかに凌駕するくらいの価値を生み出す。
しかし、Facebookの影響力が大きすぎるがゆえにトランプ大統領を生み出したように、プラットフォーム企業は民主主義制度を破壊するくらいの政治的影響力を持つという側面も出てきた。
この辺りの理論と現実は、現在進行中みたいな感じなのだろう。

この辺りの理解した内容も後でまとめる。

| | コメント (0)

2018/11/06

ネット小説「悪の組織の原価計算」のリンク

商工会議所がネット小説「悪の組織の原価計算」を公開しているのでリンク。

【参考】
ネット小説「悪の組織の原価計算」の連載を開始しました | 商工会議所の検定試験

簿記でもこういう小説が公開されるとは、時代の流れを感じる笑。

| | コメント (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)

2017/08/10

法律の背後には経済学の理論があるという仮説

法律の背後には経済学の理論があるという仮説についてメモ。
以下は主張がまとまっていないが、素人によるラフなメモ書き。

【1】とある会合に出た時、そこでは、参加者やスタッフが中小企業への施策を色々議論して、アイデアをまとめていた。
最終的には、それらのアイデアを施策としてまとめて、中小企業庁へ持参して、提案書として渡したらしい。
そして、今年度の中小企業への施策に、提案の内容が盛り込まれており、やった意義があった、という報告があった。
その時に、こういう施策が実行されると、我々士業にもお仕事が舞い込むんですよ、という話があった。

その話を聞いて、すごいな、と思うと同時に、別の考えが浮かんだ。
政治では、基本は法律を策定して、企業や人間の行動を規制したり、補助金のようなインセンティブを与えてある方向へ誘導したりする。
つまり、法律は、世の中の社会において、みんなの不利益となるような企業行動は規制し、将来の産業育成や弱者保護のような方向へ企業行動が向くようにインセンティブを与える。

法律の暗黙の前提には、人間は全てが善人とは限らず、悪人もいるので、そういう人たちを規制しなくてはいけない、という考えがあるような気がする。
すると、個人一人の思いや行動というミクロではなく、集団や企業、国家のように人間を集団というマクロで見て、その全体を規制したり、ある方向へ誘導するように制御したくなる。
実際、すべてを自由に任せていたら、悪い行動は誰も規制できなくなる。
そのために法律があるのではないか。

つまり、法律という制度によって、企業行動や人間の行動を規制して、ある方向にインセンティブを持たせるように仕向けているわけだ。
この考え方は、経済学における「制度経済学派」の考え方に近いのではないか。

【2】マンキュー経済学の本でも、「経済学の10の原理」で、「人々は様々なインセンティブに反応する」「通常、市場は経済活動を組織する良策である」「政府が市場のもたらす成果を改善できることもある」という原理があるが、それらを連想する。

経済学の十大原理

経済学の十大原理(マンキュー入門経済学) | 経済を10分だけ学ぶ

普通は、市場経済で自由に任せた方がいい。
企業も人間も、自由にアイデアを作り出し、事業を生み出して、自由に経済活動をすればいい。
でも、自由な市場経済原理で上手く行かない場合も多い。
そこで、法律という制度で、大企業が独占しないように規制したり、補助金を新産業で活動している中小企業に与えたりして、その方向へ他の企業が向くようにインセンティブを与えたりする。

【3】他に、独占禁止法が存在する理由がまさにそう。
独占・寡占市場に対しては、独占禁止法が対処法の一つ。

「市場の機能がうまくはたらけば、資源が効率的に配分される」というのが基本的な経済学の考え方だが、独占・寡占によりそれがうまく機能しない場合が「市場の失敗」。
そうならないように、自由な競争を生み出すように独占禁止法が存在し、公正取引委員会もある。

独占禁止法の存在意義には、経済学の理論が根底にある。

【4】他に、SCPパラダイムという言葉を知って、何となく関係があるような気がした。

SCPモデル/パラダイム - techdmba

SCPパラダイム - 人材開発・組織開発コンサルタント「ZOFFY」の日記

戦略論の復習②…ポジショニングアプローチ|田舎者の受験日記

SCPパラダイムは、ある業界の構造を分析する際の枠組み。
市場構造(Structure)が市場行動(Conduct)を規定し、市場行動が市場成果(Performance)を規定する(つまりS→C→P)という考え方で、外部環境が企業の行動を規定し、企業の利潤を規定する、という考え方。

この発想を展開すると、ある業界で独占利潤を得ている大企業がいて、消費者が不利益を被っているならば、余剰利益を得ている企業(P)に対し、その企業の行動を法律などで規制し(C)、とどめに法が無くても企業が余剰利潤を得られないような市場構造にする(S)というロジックも成り立つ。
つまり、法律によって、企業行動を規制することで、独占利潤を得られないようして、自由競争になるような方向へ誘導する。

おそらく、独占禁止法だけでなく、下請代金支払遅延等防止法など数多くの中小企業向けの法律も、そういうロジックがあるのだろう。
つまり、本来は、弱者である中小企業を守るという政治的事情として法律が作られているのだろうが、大企業が独占利潤を得にくいように、経済学の理論で補強できるように法律を構成しているのではないか。

換言すれば、そういう理論を背後に法律を作っているならば、現実を規定する法則に即しているので、その法律はすぐには廃れないだろう。

| | コメント (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)

より以前の記事一覧