「非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで 」の記事が素晴らしい

「非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで 」の記事が素晴らしいのでメモ。
Webサービス業界でRedmineをプロジェクト管理に使った場合の事例や注意点が記載されていて、とても参考になる。

【参考】
非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人

akipiiさんのツイート: "これは良い記事。編集部の原稿管理の事例、チケットの粒度はすごく参考になる。RT @chitoseweb: 非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用までのポイントについて書きました。https://t.co/zQJ5LF2qd0"

岡崎 良徳 @中野のSEOコンサルタントさんのツイート: "記事の入稿管理とかにも使えるかな…／非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人 https://t.co/sKm4bZfcq6"

akipiiさんのツイート: "名前がカッコイイのか。 @okachan_man: 関係ないけど「Redmine」って名前がかっこいい。 / “非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人” https://t.co/3xHeixlFLE"

akipiiさんのツイート: "@chitoseweb 非エンジニアのRedmine 運用事例はすごく参考になります。1チームと1プロジェクトの対応は、プロジェクト型組織は当たり前なのですか、最近はサポートデスクや製造業のような機能別組織でも有効と思います。"

【1】たとえば、「Redmineの設定の柔軟さが、非開発部門の業務に適用できる最大の理由」として、下記が挙げられている。

(引用開始)
(1)現状と予定が可視化される
(2)業務プロセスが体系化される（ワークフローが設計できる）
(3)作業履歴が残るため、担当者が変わった際のタスク移行や、あとからの振り返りがしやすい

これは開発部門に限らず、どんな組織にも求められるものではないでしょうか。
Redmineは設定が非常に柔軟にできて、また様々な拡張機能も提供されているため色々な状況に対応できます。
僕が知っている限りでも、Webサービスのカスタマーサポートや、編集部の原稿管理などで活用している例があります。
裏を返せば、自由にできる設定をうまく活かしきれないと無用の産物になってしまうということです。
(引用終了)

換言すれば、下記に相当するだろう。

(1)作業の予実管理、そこからボトルネックや進捗状況をリアルタイムに把握できる(見える化)
(2)業務プロセスが状態遷移図として可視化される(いわゆるビジネス・プロセス・リエンジニアリング(BPR))
(3)チケットやWikiに履歴が残るので、担当者がいなくなっても、作業の発生理由や仕様変更の経緯などを追跡できる(トレーサビリティ)

つまり、RedmineをSI業界における受託開発案件の進捗管理だけでなく、非IT業界におけるデザイナー・事務担当者・サポートデスクのオペレーターなど、一般ユーザのタスク管理にも上記の利点を実現できるのだ。

【2】「Redmineを適切に設定するために、まずは構造を理解しよう」では、Redmineの機能と運用プロセスの対応について説明がある。

(引用開始)
・作業はとにかくチケットに起票。起票されていないものはやらない
・必ず、ボールを持っている人を担当者に設定する
・完了基準を決める
・その他細かい設定は最初からしない
(引用終了)

いずれもチケット駆動開発のプラクティスである「No Ticket, No Work」「Doneの基準」「ペア作業」に相当するだろう。

特に参考になる点は、「プロジェクトの粒度、チケットの粒度はどうする？」の部分だ。
記事では、「プロジェクト＝チーム」「タスク＝確認者が確認する単位」を推奨している。

【2-1】前者のメリットは、「現実世界とRedmineの世界がおおよそ一致することになり、適切なプロジェクト粒度で運用しやくなることが多いです」。
つまり、Redmineプロジェクトが一つのチームのタスク管理に対応付ければ、一つのチームの世界は一つのRedmineプロジェクト内に閉じているので、そのプロジェクトだけ見ればいい。

個人的に最近思うのは、非IT業界では、機能別組織になっている組織が多く、ソフトウェア開発チームのようなプロジェクト型チームではない場合が多い。
例えば、受注する担当者は営業部、資材や原材料を効率的に発注する購買部門、ユーザからの問合せに対応するサポートデスク、などのように、一つの役割だけを担当している組織に属する人は、自分の組織以外で流れている業務の流れまで意識していない。
すると、組織をまたがる作業や情報連携は、自分の責任でないから知らない、責任は取れない、と言うディフェンシブな姿勢になりがちで、業務の流れが凄く悪くなる。

しかし、Redmineでチケット管理するようになると、チケットを通じて、他部署の依頼を受け付けたり、他部署に対応を依頼するエスカレーションの業務フローが明確になるメリットがある。
つまり、チケットの背後にあるワークフローによって、誰がその作業を承認して責任を取っているのか、が明確になるし、情報連携も自然に行えるようになる。

SI業界はプロジェクト型チームや事業部制が多く、一つの案件は期間限定で、案件が終われば解散してしまう場合が多い。
そんな場合にRedmineは履歴が残るので有効なのだが、機能別組織のように、組織が分断されているために担当者の意識もタコツボになっている状態であっても、Redmineがその雰囲気を打ち破り、情報連携しやすくなるような仕掛けを用意している事例を見かけるようになってきた。

【2-2】「タスク＝確認者が確認する単位」は、Doneの基準を「完了ステータスに決断できる範囲にとどめる」ということだろう。
特に、作業者の観点ではなく「確認者」の観点にすべき、という点はとても参考になる。

(引用開始)
この考え方はあまり言及している人がいないようなのですが、作業者の視点ではなく確認者の視点でチケットの粒度を考えると、自然に適切なチケット粒度になると考えています。
完了条件を明確にしようという内容を先ほど書きましたが、多くの場合は誰かが最終確認をすることでチケットが完了します。
確認者の確認単位でチケットを起票しておけば、完了条件とチケットの粒度が合致して上手に運用できます。
(引用終了)

チケットの粒度は、僕もいつも判断に迷うテーマだ。
どの会社でも、どの部署でも、どのチームでも、チケットの粒度は個性豊かで、一つの基準には定まらない。
たとえば、僕がアジャイル開発をやっていた時は、タスクカード単位だった。
一方、ソフトウェア保守の時は顧客の要望や障害などのストーリーカードの単位、事務処理のワークフローでは1個の申請書の単位だった。
つまり、それぞれの業務、開発の状況に応じて、チケットの粒度は観点が全く異なる。

但し、チケットの粒度は完了基準と大きく連動する。
チケットを完了する人が誰であるか、完了にする基準は何か、という点を明確にする必要がある。
それは作業者の観点ではなく、その作業を承認する人の立場で決めるべきなのだろう。

【3】最近は、RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらないの記事や今回の記事のように、Redmineのチケット管理の運用事例で、他の業界でも参考になる話が多い。
次回の東京Redmine勉強会は既に満員御礼なのだが、次々回で話してくれないかな、とか思ったりする。

WindowsOS上でbash環境を使うためのツールのリンク

WindowsOS上でbash環境を使うためのツールのリンクをメモ。

【参考1】
【レビュー】Windows OS上で超気軽にbash環境を楽しめる「clink」 (1) コマンドプロンプトとの互換性も十分 | マイナビニュース

Clink

clink/clink.md at master ・ mridgers/clink

mridgers/clink: Bash's powerful command line editing in cmd.exe

コマンドプロンプト派なら入れておくべき機能改善ツール『Clink』 ｜ ライフハッカー［日本版］

【参考2】
Windows用のお手軽なUNIXシェル環境としておすすめなGit For Windows (Git Bash)

Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

GitHub for Windowsの導入について（追記あり） - 鎌玉のよしなしごと

ちょっとした些細な作業をルーチン化したい時、Windows上でシェルスクリプトを書きたくなる。
bashのスクリプトをWindows上でそのまま動かしたくなる。

以前はCygwinを使うのが普通だったが、たくさんのライブラリをダウンロードする必要があるし、設定が結構面倒なイメージがある。

ネットで探してみたら、clinkというツールがあるらしい。
他には、Git For Windowsがいいらしい。
以前は日本語のパス名だとうまくcdできなかったが、GitHub for Windowsの導入について（追記あり） - 鎌玉のよしなしごとによれば、幾つかの設定を追加すれば使えるみたい。
実際、フォルダ上で右クリックして、GitBashを開くと、Unixコマンドも普通に使えて便利。
過去のシェルスクリプトをWindows上で動かしたりして試してみる。

消費税の端数処理ではまった

久しぶりに、端数のまるめ処理ではまったのでメモ。
ラフなメモ書き。

【参考】
切り上げた数値を元に戻すには - 数学 | 【OKWAVE】

消費税の端数処理は影響が大きい？！総額表示と積み上げ計算の復習を！

消費税の端数処理は影響が大きい。
よくある例は、税込価格から消費税を抜いた税抜きの販売価格を計算した後、税抜きの販売価格から消費税を加味した税込価格に戻す処理で、四捨五入で単純に計算すると、端数が合わなくなってしまう。
上記の記事のように、元に戻す時は、切り捨てにする。

たかが1円程度の違いと言っても、大規模店舗で商品を大量仕入したり、工場で原材料を大量仕入したりする時は、数十万円の違いが出たりする。
小売業や製造業では、購買部門の担当者が別途いて、彼らは仕入先と、大量購入するから単価は値引きさせるように交渉しているから、金額にはとてもうるさい。
発注処理は大量仕入れで安く仕入れることで、規模の経済を生かすから、ちょっとしたシステムのバグがユーザ企業のビジネスに大きな影響を与えてしまう。

消費税の計算方法は、実は商品ごとに異なったりする。
普通は、税込価格で表示するように法律で決められているから、税抜価格で安い価格で不当に表示するのは、不正競争防止法などにも引っかかるだろう。

しかし、たとえば、書籍では再販制度があるために、税抜価格で表示していい。
他に、委託販売、試用販売でも似たような事例があるだろう。
つまり、商品の種類ごとに、価格表示の仕様は異なる。

設計SEはその辺の事情も考える必要があるので、普通は別途、計算仕様書なる補足資料を作り、価格表示や消費税の計算に関する仕様をまとめている。
その計算仕様書には、どの場面では、どんな計算式で、四捨五入・切り上げ・切り捨てにするか、という仕様がまとめられている。
開発者は、その計算仕様書を参照しながらシステムを実装していく。
これが、ドメイン知識と呼ばれるものなのだろう。

一方、注意すべき点は、価格計算の要件は法律で決まっているため、システムの仕様も法律の要件に引きずられてしまうことだ。
つまり、消費税に関する法律とか、景品表示法、不正競争防止法などの法律があり、法律がシステムの仕様を決めているし、その仕様は絶対だから変更することもできない。

そして、法律はその時々の政治的事情でコロコロ変わる。
消費税が5％から8％に上がっただけで、たくさんのシステム改修が発生して、ちょっとしたスポット景気になった。
ユーザから見れば、消費税は変わるのだから動的に作っていて当然で、なぜ改修料金を支払わないといけないの、と思ったりする。
だが、古いシステムほどロジックは魑魅魍魎なので、法律がフレキシブルに変わるたびに、システムをいじる手間がかかってくる。
法律の変更に対応できるようなシステム設計、アーキテクチャ設計が必要であるわけだ。

この辺りの業務知識も一度まとめてみたいと思う。

「昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ」の記事が役に立つ

「昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ」の記事が役に立つのでメモ。

【参考】
昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ - Qiita

個人的には、CobolやVBの案件に放り込まれるのは嫌い。
でも、仕方ない場合もあったりする。
特に、ExcelのVBAは開発案件でなくても、保守運用で使う報告書や作業指示書や集計表などで、ルーチン作業を自動化するために使われているので、使わざるを得ない場面が多い。

一番嫌なのは、今までのJava、C#のやり方がCobolやVBAでは通用しないことだ。
つまり、開発環境の使いにくさ、言語仕様の未熟さ、API不足などで、普通は考えなくて良い所まで考えさせられるのが苦痛。

上記の記事は、Java経験者がVBAを初めて書く時にはまりがちな内容を記載してくれていて、とても役立つ。
VBAはオブジェクト指向言語っぽく見せかけていながら、言語仕様が未熟なので正直使いづらい。
でも、使いにくい部分を知っておけば、多少は苦痛を減らせる。

個人的には、RubyやJRubyでWin32OLE経由でExcel操作した方が便利で速いのではないか、と思う。

RubyでExcelを操作(OLE)する

Rubyist Magazine - Win32OLE 活用法 【第 1 回】 Win32OLE ことはじめ

RubyでWin32oleを使ったExcelサンプルプログラム - Qiita

Ruby から Excel を操作する方法 | TipsZone

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしいのでリンクをメモ。

【参考】
RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

はてなブックマーク - RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

【1】IoT企業特有の問題点を読むと、ハード業務はWF型開発、ソフトウェア業務はアジャイル開発なんだよなあ、と改めて思う。

(引用開始)
IoT企業特有の問題

1. タスクが複数の開発レイヤーにまたがりまくる
2. お問い合わせ対応も横断的
3. ハードとソフトで開発サイクルが違い過ぎる
(引用終了)

ハード業務は文字通り、硬くて融通が利かない。
出荷してしまうと、元に戻せないしリセットも出来ないから、前工程で品質を100％くらいの気持ちで作らざるを得なくなる。

また、IoT企業でなくても、最近のメーカーはどこもソフトウェア開発部隊を持っている。
すると、今までの製造業の文化とソフトウェア開発の文化は全く違うので、製造業の成功体験をソフトウェア開発に持って行って、だいたい失敗する。
最近の日本で、人工知能やデータマイニングが弱いからソフトウェア開発を強くしよう、という話が多いのは、たぶん製造業の成功体験に引きずられすぎて、ソフトウェア開発はアジャイルな開発スタイルが向いている、という発想に持ち込めないからだと思う。

【2】色んなツールを試した結果、Redmineを選択して成功したらしいが、そのメリットが下記に書かれている。

(引用開始)
1. 気軽に横断的なプロジェクトがつくれる、そこに小さいプロジェクトをネストできる
2. ガントチャートが標準でついている
3. カンバンのプラグインも充実している
4. 当然ソースをいじって自分たちなりのカスタマイズができる
(引用終了)

ハード部隊やソフト部隊、カスタマーサポートのように、業務の内容も業務に携わる従業員の気質も全く違う場合、ただでさえ作業の連携は悪い。

ハード部隊の人はとにかく真面目で、軍隊のような組織に近く、チーム連携を重視する。
ソフト部隊の人はとにかく自由で、自己主張が激しい部分がある。
カスタマーサポートの人は対人関係のやり取りが強く、営業マンに近い。

そんな多様な気質のチームの間で、一つのツールで作業のやり取りや情報共有を一元管理したくなる。

Redmineのメリットを読むと、複数プロジェクト機能・ガントチャート機能がデフォルトであること、カンバンはプラグインで機能追加できることがあげられている。
確かに、全く気質の違う人種のチームが複数ある場合、一つのプロジェクトにまとめてチケット管理するよりも、別々に管理する方が、チケットを起票する人達もやりやすいと思う。
つまり、機能別組織に複数プロジェクト機能を対応付けて、それぞれのレイヤーで作業をチケット化して、管理する方がチケットの粒度もまとめやすいし、プロジェクトごとにチケット管理の特徴を出しやすい。

【3】但し、「導入にはRedmineエバンジェリストみたいな人が必要」という指摘がすごく心に残る。

(引用開始)
ただここで大事なことを言っておくと、やはり導入にはRedmineエバンジェリストみたいな人が必要がだと思います。
正直いなかったらやってなかったですね。
今は調整しつつめざせSpreadSheet撲滅という感じです。
(引用終了)

「導入にはRedmineエバンジェリストみたいな人が必要」の意味は、IoT企業の業務とRedmineの機能をどのように対応付けて、自分たちがやりたい開発プロセスをRedmineで実現するか、というフィットギャップ分析が重要であり、それが出来る人がRedmineエバンジェリストなのだ、と僕は理解している。

Redmineはオープンソースでありながら、機能も豊富でUIも使いやすいし、WF型開発でもアジャイル開発でもサポートデスク管理にも使えるという柔軟性を持つ。

しかし、多様な業務を、唯一つのRedmine運用ルールに当てはめることは当然無理であり、破綻する。
それぞれの場面で、Redmineの優れた機能をどのように使い分けて、運用の効果を引き出すか、というノウハウが必要なのだろう。
この辺りのノウハウも、色んな事例から抽出してプラクティスないしパターンとしてまとめてみたい。

Redmineでガントチャートの幅を広げるパッチ

Redmineでガントチャートの幅を広げるパッチをメモ。

【参考】
Redmine 3.0.0で ガントチャートの幅を変更してトラッカーを非表示にする | yamamanx

Redmine-2.3.2、ガントチャートに日付を表示、左の幅を広げる（担当者名表示するため）

【参考1】
RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索

Redmineのガントチャート改善part2: プログラマの思索

Redmineのガントチャート機能改善の要望チケット: プログラマの思索

Redmineのガントチャートに担当者を表示するプラグイン: プログラマの思索

Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date: プログラマの思索

Redmineチケットの担当者を固定にする手法はWBS駆動に凝り固まり過ぎ: プログラマの思索

Lock wait timeout exceeded を再現させる条件 - Google グループ

ガントチャートの光と影: プログラマの思索

(引用開始)
(Redmine 3.0.0で ガントチャートの)幅を変更する

//app/views/gantts/show.html.erb を編集する。

87行目の330を任意の値に変更する

subject_width = 350
(引用終了)

Redmineを導入して、複数チームに運用が拡大していくと、ガントチャートをMSProjectみたいに階層構造で見ていくリーダーが多い。
例えば、彼らの運用を見ると、発生源となる要望を親チケットとして、それを起点として、作業やQAや障害を子チケットで階層化するように運用している。
Redmineのガントチャート画面では、親チケットが作業の発生源となるチケットであり、作業予定が記載されていて、その子チケットにどんどん作業実績が追加されるイメージで運用している。
多分そのやり方が以前から慣れているからだろう。

すると、チケットの階層構造が深くなると、ガントチャート画面のチケットのタイトルが途中で切れてしまい、読みにくくなる。
すると、ガントチャートの幅を広くできないか、という要望をよく受ける。

Redmineのガントチャートの幅を広くするには、Redmine 3.0.0で ガントチャートの幅を変更してトラッカーを非表示にする | yamamanxに記載されているように、ガントチャート画面のソース1行を修正するだけ。
実際にパッチを当てて、ガントチャートのチケットの幅を広げると、プロジェクトリーダーはすごく満足したみたい。

この辺りのUIも、Redmineの設定画面で動的に変更できるといいなと思う。

個人的には、Redmineのガントチャート機能はもっと改善できる余地があると思う。
既に、チケットの階層表示、先行・後続関係の表示、イナズマ線の表示、週と日の表示などが機能改善されていて、Webでお手軽にガントチャートを作りたいならば、Redmineで十分な気はする。
しかし、ガントチャート画面上でチケットを編集したり、クリティカルパスを表示できれば、MSProjectの代替品になるだろう。

Redmineのガントチャート機能を強化する有償製品は既に数多く販売されているようなので、お金があるなら試した方がいいと思う。

【参考3】
Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2～RedmineでEVMを実現 Lychee EVM: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3～Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

Redmineの要員管理のプラグインLychee Resource Managementの感想: プログラマの思索

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

豆蔵ソフト工学ラボのモデリング記事のリンク

豆蔵ソフト工学ラボのモデリング記事がいつも参考になるので、リンクをメモ。
自分が考えていることをラフなメモ書き。

【参考1】
誤解しがちなモデリングの技：目次 | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第1回：コンポジションにまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第2回：隠れた曖昧さ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第3回：ステートマシン図（Ｉ） | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第4回：ステートマシン図 (II) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第5回：ユースケース図にまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第6回：初心者にありがちな間違い | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第7回：モデルの意味的な誤り(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第8回：モデルの意味的な誤り(II) | 豆蔵ソフト工学ラボ

【参考2】
組込み開発のためのモデリングワンポイントレッスン：目次 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第1回：対象を明確に | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第2回：デバイスのモデリング | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第3回：クラスとインスタンスの区別 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第4回：ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第5回：ドメインと制御の区別(後編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第6回：状態って何？ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第7回：イベントいろいろ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第8回：状態遷移 | 豆蔵ソフト工学ラボ

【1】一つのシステム、一つの業務を分析する時、複数の観点でモデルを描いて、重要な箇所やキーとなる部分を把握したい時にUMLは役立つと思う。
但し、いくつかの注意点があると思う。

業務システム、業務の設計では、UMLの観点の分析は役立つが、ER図とDFDがやはり必要。
ER図で帳票の項目がどのように配置されるか分かるし、DFDで業務フローとデータの関連が一瞥できる。

個人的に注意している点は、エンティティがイベント・リソースだけでなく、サマリテーブルとして保持すべき部分はどこであるか、という所。
リアルタイムに表示したい時に時間がかかるならば、バッチ処理で集計したデータをサマリテーブルに生成し、そのデータを表示させるように設計する。
すると、その表示のタイミングによって、データは最新でないから、ユーザが戸惑う時がある。

また、業務システムのモデリングでも、組込システムと同様に、データのライフサイクルという観点で状態遷移図を考えたい時があるが、ER図・DFDではそれを表現しにくい。
いつもしっくりこない。

【2】組込システムのモデリングでは、UMLの観点の分析はすごく役立つと思う。
クラス図で必要な処理がオブジェクトに集約されるし、シーケンス図やアクティビティ図でオブジェクトの動的な処理をプログラムとほぼ一致させることもできる。

個人的に注意している点は、組込みシステムを状態遷移図として表現する時に、複雑な要件や仕様をどこまで状態遷移図で表現できるか、という所。
システムを状態遷移図に表現できれば、事実上、プログラムに自動生成することは可能。
だが、実際のシステムでは、イベントを待っていて発火する、とか、イベントの履歴を保持してどの状態に遷移させるべきか使用が決まっている、とか、色んなパターンがあって、状態遷移図に全ての仕様を盛り込むのも難しい。

UML2.xの状態遷移図の仕様を調べると、かなり複雑な仕様を表現する事はできる。
「H」のような履歴というモデル要素などを考えてみると、過去の人達が苦労して編み出した概念なんだな、とか分かる。

また、組込み開発のためのモデリングワンポイントレッスン：第4回：ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボの記事のように、ドメインと制御の部分を区別して設計するのもかなりに熟練の業を必要とすると思う。
ユーザ側の観点ではドメインの要素しか見ないが、実際のシステム内部では、たくさんの制御装置があって、それら装置が連動して整合性が取れて初めて、システムが正常動作する。
ドメインと制御装置の依存関係、制御装置同士の関係を表現するのが難しいと思う。
どうしても、Controller部分が肥大化してしまうので、Mediatorパターンのように表現したくなるが、何となくいつもうまくいかない気がする。

【3】豆蔵さんの上記の記事はどれもとてもよく考えられている記事なので、astahでUMLをモデリングしていて、何となくしっくり来ない時に読み直している。
自分も、モデリングのパターンを整理してみたいと思う。

機会費用、機会損失、機会原価の考え方

簿記が扱う会計上の原価だけが、原価と呼ばれているわけではない。
機会原価と呼ばれるものがあるが、機会原価とはそもそも何だろうか？
機会費用、機会損失とは何か？
以下は、自分の理解のためのメモなので、間違っていたら後で直す。
主張は特に無し。

【参考】
N's spirit　機会原価とは　機会費用とは　機会損失とは

「機会損失」と「機会原価」の違いについて : 杉本公認会計士事務所　公式ブログ

機会損失とは｜金融経済用語集

機会費用とは｜金融経済用語集

機会費用 - オポチュニティーコスト - sawacom.net

機会原価 - HamaLog

機会費用 - Wikipedia

N's spirit　機会原価とは　機会費用とは　機会損失とは

逸失利益 - Wikipedia

【1】機会費用、機会原価、機会損失は紛らわしく、間違えやすい。
「機会費用＝機会原価＝opportunity cost」、「機会損失＝逸失利益」と覚えれば理解しやすく成る。

【2】 機会原価（opportunity cost）と機会損失の違い

(引用開始)
今回は、「機会損失」と「機会原価」の違いについてです。
両者は経済学や管理会計の分野でよく耳にする言葉ですよね。
これらの言葉はよく混同されがちでよく似てる言葉ですが違いがあります。
機会損失とは、最善の意思決定をしなかったために、失った利益額であり、
機会費用とは、ある意思決定をしたために行えなかった投資機会のうち、最大の利益を得ることができなかった利益額になります。
具体的には、投資額が一定で、得ることができる利益が200、100投資案Ａ、Ｂがあったとします。
投資案Ａを選択した場合には、機会損失は０、機会原価は100となり、投資案Ｂを選択した場合には、機会損失は100、機会原価は、200となります。
つまり、機会損失は最適な意思決定を行いえば０になりますが、機会原価は、代替的な投資案がある場合は必ず発生するためゼロにすることはできません。
(引用終了)

例：
投資案A　利益＝200
投資案B　利益＝100

→投資案Aを採用した場合、機会損失＝0、機会原価＝100
→投資案Bを採用した場合、機会損失＝100、機会原価＝200

「機会原価」とは、諸代替案のうち一つを受け入れ、他を断念した結果、失われる最大の利益。
逃がした利益が原価（機会原価）になる。

「機会損失」とは、最善の意思決定をしなかったために、失った利益。
法学では、「逸失利益」とも呼ばれるらしい。

(引用開始)
機会原価は埋没原価と異なり、意思決定に影響を与えるものです。投資の判断の際に、何が機会原価になっているのか正確に見極めないと、本来は投資すべきものでないものに投資をしてしまう、逆に投資の必要なものに投資を止めてしまうということが起こり得ます。
この機会原価をキャッシュフローの中で用いているのが、割引率になります。
(引用終了)

【3】機会費用（opportunity cost）は機会原価と同じ概念

(引用開始)
機会費用は、「オポチュニティーコスト」とも呼ばれ、ある行動を選択することによって失われる、他の選択可能な行動のうちの最大利益を指す経済学上の概念をいいます。
(引用終了)

【4】機会原価が何となく難しく感じるのは、未来の原価であり、会計上の原価と異なるから。
会計上の原価は、過去に発生した費用の履歴であり、簿記で記述される。
原価は、過去に発生した費用を記録して集計しただけだから、数値ははっきりしている。

機会原価が難しいもう一つの理由は、2つの選択肢(オプション)の利益の差額で計算されるから。
つまり、差額原価。

しかし、機会原価は、その機会を逃すことで失った利益なので、その数値が明確で絶対正しいとは言えない。
でも、普通の人は機会原価の基準で、買い物したり、就職を決めたりしている。
「時間をお金で買う」行為は、機会原価を最小限に抑えようとする発想。
大学院に進むよりも2年早く就職してお金を稼いだ方が得だ、という行為も、機会原価の基準に基づく。

つまり、普通の人は、機会原価を最小化しようとして、機会損失＝0に近づけようと、意思決定を選択する。
まさに、人間は経済的合理性に基づいて行動する、みたいな考え方。

【5】でも、逸失利益(機会損失)は、自ら選択した行動で発生するだけではない。
交通事故、震災、火事のような突然の災害や人災が原因で降りかかる時もある。
その場合、逸失利益を推定計算して、加害者に損害賠償請求する権利が被害者にある。
しかし、逸失利益の計算は推定なので、本当に正しいか、という問題もつきまとう。

また、逸失利益に基づく損害賠償請求には、法律に基づく要件がある。
不法行為、債務不履行など。

オープンソースERP iDempiereの日本語版ディストリビューションJPiere説明書のリンク

オープンソースERP iDempiereの日本語版ディストリビューションJPiere説明書のリンクをメモ。

iDempiereは、最終的にはSAPのオープンソース版を狙っているのではないかと思う。
iDempiereは、Java＋PostgresSQL＋Tomcatなので、フリーな開発環境でも本番環境でも自由に気軽に構築できる。
テーブル数も900個以上もあり、それなりに大規模なオープンソースのツールになっている。

但し、海外で作られたせいもあって、正直使いづらい面があると思う。
また、日本独自の商習慣や法律に対応できていない部分もあると思う。
そんな部分は、オープンソースなので、どんどんフィードバックして改良していけばいいと思う。
荻原さんが頑張っている日本語ディストリビューションJPiereにもすごく期待している。

【参考】

JPiere概要 from Hideaki Hagiwara

JPiere説明書-発注編 from Hideaki Hagiwara

JPiere説明書-受注編 from Hideaki Hagiwara

JPiere説明書-出荷納品編 from Hideaki Hagiwara

JPiere説明書-売上／請求編 from Hideaki Hagiwara

JPiere説明書-期末在庫評価編 from Hideaki Hagiwara

JPiere説明書 消費税-間接税編 from Hideaki Hagiwara

話題の時計「フランク三浦」から考える商標権の考え方

@hatsanhatのつぶやきで知財裁判の事件を知ったのでメモ。

【参考】
話題の時計「フランク三浦」 パロディはどこまで許される？ - 弁護士ドットコム

佐野　初夫さんはTwitterを使っています: "フランク三浦(笑) https://t.co/ElgsMGWr5P 欲しいかも Amazonにたくさん売ってます"

商標登録 メッセージサイト - 商標登録に必要な要件

商標権の要件はいくつかある。
すぐに思いつく要件は下記かな。

一つ目は、自他識別能力があるか否か。
「フランク三浦」と「フランク・ミューラー」は発音は紛らわしいけど、日本語にすれば識別できる、と判断したのかな。
この辺りの事例はとても煩雑で、ブランド名の「・」や「/」が空白になるだけで差止請求や損害賠償請求が来る場合もあるみたい。

もう一つは、混同惹起がないか。
「需要者の間に広く認識されている」(つまり周知性)ように、ブランド名が全国的な周知性があれば、問題ない。
例えば、携帯のAUは、短い単語で紛らわしいのに、全国的な周知性があるから認められた。

この考えは、不正競争防止法の周知表示混同惹起行為、著名表示冒用行為、商品形態模倣行為の要件にもつながる。

他には、先使用権が認められるか。
その場合、都道府県レベルまたは全国レベルで周知性がなければ、認められない。
逆に、それだけ広い範囲で既に知名度があるならば、同じブランド名だが先に使っているということで、保護される。

商標権や著作権で最近話題になったのは、東京五輪のエンブレムの件だろうか。
最近は、特許や商標だけでなく、著作人格権(同一性保持権とか)・著作隣接権(複製権・演奏権とか)などの知的財産権の知識を知っておかないと、第三者から訴えられる時があるので、注意すべきかもしれない。

組織成長モデル「グライナー・モデル」のメモ

組織成長モデル「グライナー・モデル」のリンクをメモ。

【参考】
ビジネスの世界、いろいろ（６）　“利益の追求って、組織のルールって？（６）”

ﾏﾈｼﾞﾒﾝﾄ・ｷｬﾘｱ・人事　～ﾌﾞﾛｸﾞJ-center～ 組織成長の５段階（グライナーモデル）

MBA流　大人の学ぶ力 |【組織の法則】プロローグ：ハッピーな組織を作るための必須知識　グレイナーの５段階企業成長モデル

グレイナーの企業成長モデル - すべてが学びと思えたら

製品ライフサイクルと同じように、組織成長にもライフサイクルがあるらしい。
「グレイナーの企業成長モデル」と呼ぶらしい。
グレイナーの企業成長モデル - すべてが学びと思えたらがの記事分かりやすい。

(引用開始)
ベンチャー企業の授業で、グレイナーの企業成長モデルの説明がありました。
1972年にハーバード・ビジネス・レヴューに掲載された理論です。
グレイナー教授は日本ではあまり知られていないようですが、この論文の引用は経営学の大御所であるドラッガーと並んでとても多いそうです。

最初、授業で説明を受けた時は、理解ができなかったこともあって、いまひとつピンと来ませんでした。
しかし、後で、テキストを復習したり、書籍や文献に当たっていくにつれて、非常によく考えられていて、納得感のある理論だということを感じることになりました。

グレイナーの企業成長モデルを簡単に説明すると、
・ 企業は５つの顕著な発展段階を経て成長する。
・ 組織は危機を乗り切るために、一定の変革と革命を行わなければならない。
・ 危機を乗り越えて新たな成長段階へと進む。
というものです。さらに５つの発展段階をくわしく説明すると、
・ 発展段階には成長するためのモデルがある。
・ 同時に、危機も発生する。危機を乗り越えるモデルがある。
としています。
(引用終了)

僕が理解した内容は次になる。
数人で立ち上げたベンチャー企業があったとしよう。
最初は、製品ライフサイクルの「死の谷」「ダーウィンの海」で試練が訪れる。
アイデアだけでは製品を安定して大量生産できないし、会社内部の組織化が必要になってくる。

次に、会社の組織化として、普通は機能別組織にして、業務が専門化されて回り出す。
すると、蛸壺のような組織構造になってしまうために、もっと権限をくれ、と現場が不満を持ち、自主性を促さざるを得なくなる。
つまり、事業部組織は、会社の規模が大きくなると必要になるわけだ。

さらに、事業別組織で各事業部に権限を移譲すると、自由にビジネスを始めるようになり、統制が取れない。
そこで業績連動させる仕組みを取り入れて、事業部に制約を課す。
すると、各事業部は目先の売上や利益に局所最適化された行動を取るようになり、イノベーションある行動を取りにくくなり、業績重視の行動が社会的な悪影響を及ぼす。
まるで、最近の日本企業の不祥事を連想させる。

最後に、事業部別組織(または社内カンパニー制)に対し、全社の調整機能が上手く統制されると、部分最適の組織は全体最適の方向へ動き出す。
しかし、全社の調整機能は形式的な官僚主義になりがちで、ミンツバーグの「機械的官僚制」という症状に陥る。
「機械的官僚制」は標準化された業務、大量生産の組織に向くが、大企業病に陥りがち。
まるで、公務員組織や老舗の大企業を連想させる。

組織は常に、その成長に応じて、乗り越えるべき段階がある。
例えば、ある程度大きな組織になると、組織慣性が大きく、経営トップでさえ組織の方針変更が難しくなる。
そうなると、組織変革の動きを起こすために、組織内の優秀なリーダーを選んだチェンジリーダーを組織横断で作り、エバンジェリストとして組織をかき回す、みたいな対策を取る時もある。
この動きも、グレイナーの企業成長モデルで当てはめることもできるだろう。

ベンチャー企業の経営者は、このような組織成長モデルを知っておくと、自分たちが今どの立ち位置にあり、今後どのような危機が現れるのか、を予測しやすくなるだろうと思う。

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク

Redmineの全文検索を高速化するプラグインfull_text_searchが公開されていたのでメモ。
読んでみると、すごくワクワクする。

【参考】
Full text search - Plugins - Redmine

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

okkez/redmine_full_text_search: Full text search for Redmine

PostgreSQLで日本語全文検索 - LIKEとpg_bigmとPGroonga - ククログ(2015-05-25)

Ruby on RailsでMySQLとMroongaを使って日本語全文検索を実現する方法 - ククログ(2015-11-10)

Ruby on RailsでPostgreSQLとPGroongaを使って日本語全文検索を実現する方法 - ククログ(2015-11-09)

【1】Redmineはオープンソースでありながら、機能もUIも優れたチケット管理システムだと思うが、おそらく唯一の弱点は、Git連携と全文検索の高速化だと思う。

@akahane92さんは以前から、Redmineの弱点の一つとして、Redmineの画面の右上にある検索ボックスから全文検索する時にチケット数が20万件を超えると応答時間がすごく遅くなる、と指摘されていた。
Redmineは当初は小規模チームのタスク管理に使われていたから、そんなレベルまで大規模に使われる事例は想定していなかったに違いない。
だから、チケット枚数が20万件以上、数百万件を超える場合に全文検索が遅くなるのは仕方ないと思う。

だが、チケットやWikiの履歴を調べたい時に欲しい情報がすぐに検索できなければ、チケット管理システムにナレッジを蓄積するメリットが薄れてしまう。

この全文検索の高速化の問題については、JPLはたぶん知っていて、デフォルト検索が全件検索にならないように、絞り込み機能を追加したり、検索条件を増やしたりして対応してきた。

その問題点や自分が考えていることは既に書いた。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

【2】上記の問題に対し、full_text_searchプラグインのメリットは、MySQLとPostgresSQLの2つのDBに対応していて、全文検索エンジンの別サーバーを配置する必要もなく、特に日本語の全文検索に強い点だろう。
「日付ではなくスコア順に並ぶので関連性が高いものが上に表示されやすい」機能があるのも、全文検索の使い勝手が上がるだろう。
また、インデックスをCronで作り直すことも特に記載されていないので、保守も簡単であるように思われる。
リリースノートを見る限り、たぶん、日本語だけでなく他の言語でも同様に高速化しているだろうと思われる。

他に、上記の記事に記載されているように、全文検索を強化するプラグインは既にいくつか公開されている。
だが、日本語の全文検索の高速化に特化したプラグインはありがたい。

Redmineの全文検索にPostgresSQLを使ってLike検索を高速化するRedmine PostgreSQL Search plugin: プログラマの思索

Postgresql Full Text Search - Plugins - Redmine

Full text searching plugin for Redmine (Elasticsearch) - Plugins - Redmine

Redmineがこのようにどんどん機能強化されていく様子は、興味深い。
Redmineも、既に成功したオープンソースの事例の一つになればいいなと思う。

【追記】
@akahane92 さんが200万チケットで全文検索を検証した所、1秒以内で検索結果が表示されたらしい。
おそらくこの機能を使えば、Redmineの全文検索の高速化の問題は解決できるだろう。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。／Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

経済学の根本問題～貯蓄投資バランスとセイの法則

電子書籍「現代経済学の直感的方法」と森嶋通夫氏の『思想としての近代経済学』を読んで、石川経済学(マクロ、ミクロ)を読んだら、経済学の根本問題が何となく分かったような気がした。
経済学の根本問題は、貯蓄投資バランスとセイの法則の２つではないか、というアイデアをメモ。

以下、ラフなメモ書き。
自分は経済学の専門家でないので、間違っていたら後で直す。

【参考】
貯蓄投資バランス - Wikipedia

高校生からのマクロ・ミクロ経済学入門　政治経済　現代社会　　3 貯蓄・投資/ISバランス

三面等価の原則 - Wikipedia

セイの法則 - Wikipedia

高校生からのマクロ・ミクロ経済学入門　政治経済　現代社会　　セー（セイ）の法則

おちゃらけミクロ経済学: ミクロ経済学とマクロ経済学の違い その2

合成の誤謬 - Wikipedia

耐久財のディレンマ - Wikipedia

過大な生産力のディレンマについて: 21世紀の風

現代経済学の直感的方法　電子出版のお知らせ

現代経済学の直観的方法 - 小人さんの妄想

【1】三面等価の原則、倹約のパラドックス、そして貯蓄投資バランス

【1－1】すごく小さい頃、母親や祖母が銀行に行って、銀行にお金を預けたり、引き出していたりしていたが、僕はゴム風船やお菓子などがもらえて楽しい場所だった。

でも、素朴な疑問があった。
銀行は、預金者からお金を預かり、しかも預金利息を付けて多めに支払っているが、どうやって儲けているのか？
銀行はそんなお人好しで、赤字にならないのかな？と。

小学校の先生に聞いたら、銀行は集めたお金を会社に貸し出して、利息をつけて返してもらっているのよ、と言われたが、ピンと来なかった。
小学生の世界では、銀行が会社にお金を貸し出す場面なんて、直接見ることなんて無いから。

【1-2】倹約のパラドックスは、考えるほど謎のパラドックスだ。

不況になれば、人は消費せず、倹約して貯蓄に回す。
その行為を国民全員が行うとどうなるか？
倹約のパラドックスでは、もし全ての人がもっと貯蓄しようとすると、すぐさま起こる事は、総需要の低下と国民所得の低下が起きる。そして、所得の低下により、最終的には誰も貯蓄するお金すらなくなる。
つまり、倹約が不況を更に悪化させる。
だから、不況になれば、貯蓄を促すのではなく、皆に浪費するように政府は行動すべきだ、と。

直観としては、個人が借金しないないように貯蓄するのは健全な行為だ。
でも、世の中の市場経済は、皆が浪費することを前提としなければ、正常に動作しないらしい。

【1-3】マクロ経済学では、最初に三面等価の原則を習う。
Y＝C+I+G＋NXの公式はまだ分かる。

しかし、貯蓄と投資がバランスするという「ISバランス」が理解しにくい。
貯蓄と投資の金額は本当に均衡するのか？

普通の個人が銀行に預金するような「貯蓄」という行為と、半導体企業が高価な半導体製造装置を大金を支払って「投資」する行為が、つながっているように見えなくて、とてもバランスしているように思えないからだ。
個人の貯金額なんてせいぜい数万～数千万円くらいなのに、工場の設備投資額は数億～数千億円がざらで、差が大きすぎる。

でも、実際、日本にせよ、欧米にせよ、普通に成功している市場経済の国では、GNPの20％が貯蓄であり投資である、と言われている。
それぐらい莫大な金額が社会の背後で動いているらしい。

【1-4】上記の疑問に対し、僕の理解では、貯蓄を投資に回すようなサイクルを市場経済は意図的に作り出して、常に経済成長するような仕組みを強いられているから、と思う。
この考え方は、「現代経済学の直観的方法」を読んでようやく分かった。

貯蓄されたお金は、タンス預金で貯めるのは個人の自由だが、マクロの観点では、タンス預金になったお金は死んでいるのと同じ。
お金は循環すること(流動性)がなければ、経済はどんどん縮小していく。

だから、ケインズ経済学では、不況の時は、政府が代わりに公共投資をして、貯蓄で死蔵されたお金を強引に浪費して、お金を循環させる。
つまり、ケインズ派の考えは、市場経済には価格の自動調整機能は不十分で、人間の手で時々はお金をつぎ込まないと市場経済はしぼんでしまう、というものになる。
例えば、銀行を通じて貯蓄を投資に回すのが間接金融、個人の貯蓄を株式市場に直接投資するのが直接金融。
それが上手く回らないならば、政府が強制的に個人から貯蓄を税金として奪い取り、公共事業という名の元にお金をばらまく。

この考えは、古典派の「神の見えざる手」の思想とは異なる。
古典派は、市場は価格の自動調整機能が働いて、あるべき均衡点に自動で到達する。
人間の恣意的な市場介入は、崩壊したソ連のように、無駄な投資による無駄な生産、無駄な浪費を招き、社会を停滞させる、という発想。

経済学では、ケインズ派と古典派の対立がずっと根底にある。

【2】もう一つの経済学の根本問題は、市場経済の価格の自動調整機能は有効なのか、という点。
これは、セイの法則「供給は需要を生み出す」から導かれる十分条件。

セイの法則が成り立つ、と暗黙的に仮定しているのが古典派でありマルクス経済学。
セイの法則は成り立たない、と明示的に仮定するのがケインズ派。
『思想としての近代経済学』がとても分かりやすい。

【2-1】現代でも、セイの法則が成り立つ市場はある。
例えば、ハイテクベンチャーなどのいわゆる新興市場。
あるいは、待機児童の多さで問題となっている保育所の人手不足、保育所の供給不足も当てはまるだろう。

しかし、現代ではほとんどの市場は供給過剰であり、セイの法則は成り立たないと思われる。
農業もそうだし、工業製品のほとんどがその状態。
供給するほど、価格は下落するが、労働組合や政府が、労働賃金の下方硬直性を実現するために、それ以上に価格調整が効かず、供給過剰が解消されず、どんどん状況は悪化する。

完全市場経済なんて、たぶん、現代では妄想に近いのだろうと思う。
むしろ、不完全競争市場がほとんどであり、独占・寡占した企業が牛耳っているのだろう。

【2-2】セイの法則が成り立たない背景には、耐久財のディレンマがある。
市場に出回っている製品は消耗品とは限らず、むしろ高品質な物が多く、何度も使い回しができる耐久財が多くなっている。
過大な生産力のディレンマについて: 21世紀の風では、自動車のレンタル市場を例に説明している。

(引用開始)
「この式は、利子率iが与えられるならば、レンタル価格ｐは自動車の価格Pに比例しなければならないことを示している」。
　ここから、レンタル市場の需給を均衡させる価格と自動車そのものの需給を均衡させる価格は必ずしも一致しないことがわかる。「このように耐久財市場の場合には、特別の場合の他は、二つの市場が同時に均衡することはありえない。こうして耐久財がが生じると共に、価格の市場調節機構は重大な障害を蒙ることになる」。
　途中の議論を省けば、こうした場合の需給調整は、価格ではなく、数量的に生産量を調整することで行われることになる。重要なのは、自由経済の下で、価格機構は全均衡条件が成立するように機能はしないということである。それは、「供給はそれ自身の需要をつくる」というセーの法則が成立しないことを意味している。
　これは、「耐久財の持つ比重が、近代社会では大きくなったことと、生産力が増大したために耐久財について容易に生産過剰が起こりうるようになったから、生じた」のである。したがって、この問題は、市場を自由化して価格機構がスムーズに働くようにしても解決しない。こういう生産過剰ゆえに起こる諸問題を解決するためには、政府の介入が必要である。それがケインズの提唱した有効需要送出策である。しかし、「この道ですら、雇用を充分拡大するには、政府事業の経済的効率はよくないという批判に甘んじなければならない。すべては過大な生産力がもたらしたディレンマである」
　このディレンマは、社会主義と資本主義に共通するというのが森嶋氏の結論である。氏は、社会主義経済ではセーの法則が働いて、貯蓄がすべて効率を無視して投資されたために、無駄な生産が膨大に行われ、ケインズ型失業が起きなかったが、過去の投資の失敗のツケがたまり、行き詰まったというのである。
(引用終了)

【2-3】供給過剰が普通になった成熟市場では、セイの法則は成り立たず、価格調整機能が自動で動作しなくなる場合がある。
すると、すべての市場が供給過剰になってしまったら、最終的にどうなるのか？

たぶん、ベーシックインカムのように、世の中の人間全員に政府が「負の所得税」を支払って、自由に浪費してもらい、市場経済を回すしかないのだろう。
最近の日銀のマイナス金利も、そんな方向を予感させる。
皆に借金してもらって良いから、浪費してもらいたいのだ。

「現代経済学の直観的方法」では、過去にそのような事例があるという。
古代ローマも同様に供給過剰の世界であり、ローマ市民は政府からパンとサーカスを無償で与えられて生活していた。
彼らは、既に、ベーシックインカムを先取りしていたわけだ。
そして、古代ローマ人は労働倫理だけでなく、倫理そのものもなくしてしまいそうになり、そんな心の空洞をキリスト教が埋めた、という歴史があるわけだ。
では、現代ではこの問題をどう解決するのだろうか？

【3】市場経済が安定している前提として、経済成長率が永遠に増え続ける、という仮定も、何となくおかしいと思っている。
地球という星の資源は有限であるからには、いつか必ず、浪費する市場経済は地球の資源を全て使い果たして、壁にぶつかり、それ以上の発展がのぞめなくなる。
おそらくそうなる前に、おかしな予兆が現れて、マルサスの人口原理のように、自然が介入して均衡を保とうとするのだろう。

経済学は、その最終的な問題をどのように解決しようとしているのか？
僕はまだ回答を知らない。

Enterprise Architectの使い方のリンクとメモ

古い記事だが、Enterprise Architectの使い方のリンクがあったのでメモ。

IT設計で使っているツール：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その１：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その２：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その３：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その４：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その５：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)をこのように使ってます。その６：気になっていることのメモ：So-netブログ

Enterprise Architect(EA)はこんな事もできる：気になっていることのメモ：So-netブログ

ドキュメントを作成する時に：気になっていることのメモ：So-netブログ

スパークスシステムズジャパン フォーラム - ユーザー掲示板　CRUD図の表の中身の逆生成は可能ですか？

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

日本でモデリングツールが使われない背景: プログラマの思索

EnterpriseArchitectはとても多機能なモデリングツール。
僕はまだ使いこなせてない。

上記の記事では、EAの使い方としてUMLにこだわらず、要求→ユースケース→機能→テストケースまでのラフな絵を描いて想像を膨らませたり、要求→ユースケース→機能→テストケースまでのラフな絵を階層化した構造ツリーを表示することで変更要求の影響箇所を一瞥できるのが便利だ、と述べている。
その点は、EAに限らず同感だ。

モデリングツールはastahをずっと使い続けているが、モデリングツールに期待する機能はたくさんある。
ステートマシン図から状態遷移表を自動生成したり、機能(ユースケース、プロセス)とテーブル(ER図)を組合せたCRUD表の自動生成、とか。
状態遷移表は組込みシステムのイベントフロー設計で使えるし、デシジョンテーブルのテストケースとしても流用できる。
CRUD表は、サブシステムの分割基準に使えたり、FP法による簡易見積りにも使えるだろう。

また、クラス図、アクティビティ図、ステートマシン図、ER図、DFDなどあらゆるダイアグラム間で、整合性を担保したり、トレーサビリティを維持する仕組みは、モデリングツールで自動チェックしてくれなければ実現は不可能。
最終的にはモデリングツールでモデルのトレーサビリティを保証することで、要件や仕様の漏れをなくしたいのだ。

つまり、モデリングツールを使いこなせれば、見積り・設計・テストの作業効率化に適用できるはず。

設計ツール | system-enablers日記にはこんな文章がある。

(引用開始)
また、有用なツールは、開発手法も教えてくれます。
例えば、今現在、注目しているICONIXプロセスではEAを使うことを推奨していて、EA用のアドインを提供しています。
(中略)
「プロは腕も持っているが、道具も持っている」ものです。
わたしたちもプロの道具を上手に使って、いい仕事をしたいものです。
(引用終了)

個人的には、関西でastahを使ったモデリングの勉強会を開いて、情報共有したいなあと思ったりする。

キャッシュフロー計算書はエクセルで簡単に作れる

中小企業庁のExcelマクロを使えば、キャッシュフロー計算書はエクセルで簡単に作れると分かったのでメモ。

【リンク】
中小企業庁:「中小企業の会計」ツール集（平成23年度指針改正対応版）

実践！キャッシュフロー計算書はエクセルで簡単に作れます！

実際の会計処理ではCF計算書は非常に重要だ。
資金繰りが悪いかどうか、社長も気になるし、銀行などの金融機関も真っ先にCF計算書を作って、融資すべきかどうか判断するからだ。

しかし、簿記2級までで、会社のBSやPLは自作できるはずだし、製造業の原価管理もできるようになるのに、CF計算書は簿記1級レベルなので、普通はきちんと勉強できていないのが普通だろう。
CF計算書は慣れれば計算するだけだが、理解するのが難しい気がする。

そんな時は、上記のExcelマクロを使って、2期分のBSに数値を入れて、CF計算書を自動出力してみればいい。
営業CF、投資CF、財務CFがBSのどこの値を参照して計算されているか、理解しやすくなるからだ。

実務では、前年度と今年度、または今年度と来年度の損益計算書と貸借対照表を作成した後、CF計算書を作り、営業CFを計算する場合が多い。
更に、1～5年分の営業CFを求めて、フリーキャッシュフローを計算した後、5年後のNPV(正味現在価値)を求める場合が多い。
例えば、製造業で大規模な設備投資を行う場合、投資して元が取れるか、という判断に使いたいからだ。

特に、新規設備だけを導入する新規投資、旧設備と新設備を比較してどちらの投資の方が機会原価として元が取れるかという取替投資などのパターンが色々あるので注意が必要。

金融系に勤務している人ならば当たり前に知っているだろうが、SE全員が知っているとは限らない。
でも、CF計算書を出力したり、設備投資のROIを計算するアルゴリズムは、既に仕様が決まっているので、仕様さえ理解すれば実装は簡単なはずだ。