WEB銭の読書やグラベルロードのメモなど

マンガ「グラゼニ」が大好きな、ウェブ系の何でも屋さんが綴る、仕事とか、読んだ本のこととか、日常とか、世の中に関する忘備録。

ハイパーインフレの悪夢―ドイツ「国家破綻の歴史」は警告する

著者:アダム・ファーガソン
発売元:新潮社

 

目次

金を鉄に
喜びなき街
突きつけられた請求書
10億呆け
ハイパーインフレへの突入
1922年夏
ハプスブルクの遺産
秋の紙幣乱発
ルール紛争
1923年夏
ハーフェンシュタイン
奈落の底
シャハト
失業率の増大
あらわになった傷跡

 

感想

すごいいい本だわ。

 

歴史の教科書に必ず出てくる、ドイツのハイパーインフレ

 

それがどのように発生し

 

ドイツ国民にどのような影響を与えたのかということが、よく分かる。

 

「で、ヒトラーがだてきたんでしょ?」なんて短絡思考じゃダメよ。

 

最初、インフレはいいものだと迎え入れられていた。

 

途中まで、インフレはいいものだと迎え入れられていた。

 

少し変かな?と思っていたけれど、インフレはいいものだと迎え入れられていた。

 

気がついたら、どーにもこーにもできなくなっていた。

 

このへんの状況を一言で言い表しているのが317ページ

 

正しいと信じて行っていたことが、実は自分の身の破滅を招いていたことに、もうどうしようもない状況に陥ってから、ようやく気がつく。

 

ってやつですな。

 

あと307ページ

 

ハイパーインフレの最中には、家族の銀器よりも1キロのじゃがいものほうが、グランドピアノより豚の脇腹肉のほうが一部の人にとっては価値があった。家族の中に売春婦がいるほうが、赤ん坊の亡骸があるよりもよかった。餓死するより盗む方がましだった。名誉より暖房のほうが心地よく、民主主義より衣類のほうが不可欠で、自由よりも食べ物のほうが必要とされていたのだ。


ってフレーズですな。

 

まさに貧すれば鈍するですわ。

 

ハイパーインフレになってもいいように、農地を手にしていよう。

 

しかし、ドイツがどーやってハイパーインフレを克服したのか?それがもう少し細かく描いてあったら嬉しかったわ。

 

これからはインフレ、大変だ!!って本だけでなく、古今東西ハイパーインフレに襲われた国家がどのように復活したのか?復活しない間でも、どうやって押さえ込んだのか?を調べていこう。

 

ハイパーインフレの悪夢

ハイパーインフレの悪夢

 

 

21世紀の資本

 

 

目次

第 I 部 所得と資本

■第1章 所得と産出

■第2章 経済成長──幻想と現実

第 II 部 資本/所得比率の動学

■第3章 資本の変化
■第4章 古いヨーロッパから新世界へ

■第5章 長期的に見た資本/所得比率
■第6章 21世紀における資本と労働の分配
第 III 部 格差の構造

■第7章 格差と集中──予備的な見通し
■第8章 二つの世界
■第9章 労働所得の格差
■第10章 資本所有の格差
■第11章 長期的に見た能力と相続
■第12章 21世紀における世界的な富の格差
第 IV 部 21世紀の資本規制

■第13章 21世紀の社会国家
■第14章 累進所得税再考
■第15章 世界的な資本税
■第16章 公的債務の問題

 

感想

今一番売れている経済書

 

ってか、こんな分厚い経済の専門書が10万部以上も売れているってびっくりだわ。

 

で、民主党や、社民党など「労働者が国の基本です。でも、その労働者は正社員だけですが、何か。そんな労働者を代表する労組の幹部が資本家な見に報酬をもらっていて何が悪いんですか?( ー`дー´)キリッ」という方々のバイブルになっているらしいですが

 

どっちも、「ほんとか?」と思ってしまう。

 

格差発生のメカニズムと、格差が引き起こす問題点には触れているが、格差は絶対悪で、格差を生み出してしまう仕組み自体が間違いなのだという、ポルポト的な主張はどこにも見当たらなかったと思ふ。

 

そもそも、なんで格差というか、経済的問題が発生してしまうのか?というそもそも論に対して、ピケティは歴史的アプローチを見せるのですけれど

 

それは人口の爆発的増加によるもので、近代(中世?)ヨーロッパではそれが問題にあっていたということが書かれているのですよ。

 

それは5ページ

 

フランスの人口は更に18世紀を通じて、ルイ14世時代の終わりからルイ16世の処刑までずっと安定して増加し、1780年には3000万人近くになった。1789年の爆発に先立つ数十年で農業賃金が停滞し、地代が上昇したのは、どう考えてもこの空前の急激な人口増のおかげだ。

 

に記載されているわけですなわ。

 

これが、この本の柱になる考え方ですわな。

 

財政政策も、金融政策もへったくれもなかった時代にあって、人口の増加=需要の増加が神の見えざる手であって、人口が増えれば増えれほど、商品の希少性が上がり、インフレ的状況になるってわけなんですわな、と。

 

で、この辺の話や疑問に答えたのがリカードや、マルクスであった、と。

 

で、この辺の話を含めて資本収益率が、経済の成長率を大幅に上回ると云々かんぬんという話、この本の柱ですな、底に行くわけですよ。

 

で、

r>g

という不等式が出てくるのですな。

 

しかし、29ページに

 

私の結論は、マルクスの無限蓄積の原理と永続的格差拡大の含意ほど悲惨ではない(というのもマルクスの理論は暗黙のうちに、長期的な生産性増大がゼロだという厳密な想定に依存しているからだ)。私が提案するモデルでは、格差拡大は永続的ではないし、富の分配も将来の方向性としてあり得るいくつかの可能性のひとつでしかない。だが考えられる可能性はあまり心やすまるものではない。

 

で、

資本市場が完全になればなるほど、rがgを上回る可能性も高まる。

と、話を続けるわけだ。

 

で、累進課税とか重要だけれど、これは国際協調が必要なんだよねぇ・・・と話を続ける。

 

これ、30ページくらいまでの話なんだけれど、菅直人とか、ここまでも読んでいないんじゃないのかしら?なんて思ってしまうわw

あと

r>g

という式以外に、これも重要だと思ふ。56ページ。

 

資本主義の第一基本法則 α=r✕g

 

これで資本主義の第一基本法則を提示できる。これは資本ストックを、資本からの所得フローと結びつけるものだ。資本/所得比率βは、国民所得の中で資本からの所得の占める割合(αで表す)と単純な関係を持っており、以下の式で表される。

 

α=r✕β

ここでrは資本収益率だ。

 

例えばβ=600%でt=5%なら、α=r✕β=30%となる。
言い換えると、国富が国民所得の6年分で、資本収益率が5%なら、国民所得における資本のシェアは30%ということだ。

 

なにげに、個人的にこの本の肝はここな気がするんだよな。

で、この第一法則を受けて、第二法則に話が移るわけですわな。

 

資本主義の第二基本法則は

β=s/g

βは資本/所得比率、sは所得率、gは成長率

となるのですな。

 

で、これは何を意味しているかというと

 

175ページ

 

ほとんど停滞した社会では、過去に蓄積された富が、異様なほどの重要性を確実に持つようになる。

 

って、ことを証明している式なわけですわな。

 

で、繰り返しになるけれど、この本は「格差、ダメ!ゼッタイ」的なことを説いている本ではなく、経済学の本なわけですわな。

 

クメール・ルージュマンセーじゃないんだからさ。

 

ただ、発生してしまう格差はなんとかしなければならない。

 

そして、その格差解消方法が書かれているのですよ。

 

それは、まず教育と技能への投資(325ページ)

 

労働者の質を上げて、賃金をたくさんもらえるようにしましょうって話だな。

で、次は戦争(412ページ)

 

すべてがガラガラポンされるので、格差どころの騒ぎでなくなる。

 

世界の経済誌において、格差が採用化されるのって戦争が起きた時なんだよな。

 

きっちり、それはこの本に書いてある。

 

なので、「格差、ダメ!ゼッタイ」は戦争賛成派なのかしら?と思ってしまふ。

 

で、次はインフレ(色んな所で書かれているけれど、472ページには「インフレの主な影響は、資本の平均収益を減らすことではなく、それを再分配することなのだ」という記述あるのでね)。

 

で、次は累進所得税も含まれるであろう、資本税(514ページ以降のもろもろ)。

 

金持っているやつから金を奪えば、そりゃ格差はなくなりますね、と。

 

みんな揃って貧乏になりましょうということに近い気がすんだな。

 

ちなみに強制的に格差をなくした国がある。

それがソヴィエト連邦

 

ソヴィエト連邦が何をやってどうなったかという話も、この本に書かれている(557ページから)。

なもんで、繰り返すのですが

 

民主党や、社民党など「労働者が国の基本です。でも、その労働者は正社員だけですが、何か。そんな労働者を代表する労組の幹部が資本家な見に報酬をもらっていて何が悪いんですか?( ー`дー´)キリッ」という方々のバイブルになっているらしいですが

どっちも、「ほんとか?」と思ってしまう。

 

ちなみに本としては非常に面白い本。

 

そして、この本を読んでいたら

 

貧乏人の経済学――もういちど貧困問題を根っこから考える

貧乏人の経済学――もういちど貧困問題を根っこから考える

 

 

 

殺人ザルはいかにして経済に目覚めたか?―― ヒトの進化からみた経済学

殺人ザルはいかにして経済に目覚めたか?―― ヒトの進化からみた経済学

 

 

 

善意で貧困はなくせるのか?―― 貧乏人の行動経済学

善意で貧困はなくせるのか?―― 貧乏人の行動経済学

 

 

 

 

最底辺のポートフォリオ

最底辺のポートフォリオ

  • 作者: ジョナサン・モーダック,スチュアート・ラザフォード,ダリル・コリンズ,オーランダ・ラトフェン,野上裕生,大川修二
  • 出版社/メーカー: みすず書房
  • 発売日: 2011/12/23
  • メディア: 単行本
  • 購入: 2人 クリック: 18回
  • この商品を含むブログ (9件) を見る
 

 
を読みたくなりましたわ。

 

 

21世紀の資本

21世紀の資本

 

 

はじめよう! 要件定義 ~ビギナーからベテランまで

著者:羽生章洋
発売元:技術評論社

 

目次

第1部 要件定義って何だろう?

Chapter-01 要件定義=要件を定義すること
Chapter-02 要件定義の基本的な流れ
Chapter-03 定義すべき要件の内訳
Chapter-04 3つの要素の定め方
第2部 要件定義の詳細

Chapter-05 要件定義,その前に
Chapter-06 企画を確認する
Chapter-07 全体像を描こう
Chapter-08 大まかに区分けしよう
Chapter-09 実装技術を決めよう
Chapter-10 実現したいことを整理整頓しよう
[助走編]
Chapter-11 利用者の行動シナリオを書こう
Chapter-12 概念データモデルを作る
[離陸編]
Chapter-13 UIを考えよう
Chapter-14 機能について考えよう
Chapter-15 データについて考えよう
Chapter-16 要件定義の仕上げ
Chapter-17 要件定義,その後に

感想

いやはや、要件定義に関して、しっかり勉強できる本ですわ。

 

まぁ、若者にとっては勉強でして、年行った方々にとっては再確認というか、整理ですな。

 

そもそも要件てなんだか知ってますか?

 

これ、辞書引いても出てきませんわ。

 

それは作って欲しい人が一方的に要求をならべるだけでは要件とは言えないということです。どういうことかというと、創る側の人が「これなら作れます」と言える注文でなければ、実現不可能な依頼だということです。

 

そうなんだよね。

 

要求確認は夢を語る場面ですけれど、要件定義っていうのは現実を見つめる作業なんですわな。

 

「これならできる」という実現可能性を語るわけなんですわな。

 

で、実現可能性って何かといいますと

 

「これなら作れます」とすんなり言える場合はよいのですが、「これは難しいです」あるいは「これは無理です」という場合、それがどういう理由によるのかが裏側に存在するからです。たとえば、「作る人の実力が足りない」のであれば、それは依頼先を別の人にすれば実現できるかもしれません。あるいは「現実的に無理:というような場合があれば、要求自体を改める必要があるでしょう。他にも「予算が足りないから無理」とか「基幹が足りないから無理」というようなケースも現実には多く見受けられます。

 

できる、できない、こうだったらできるというのを要求に対して行っていくのが要件定義なわけですな。

 

そうやって、作って欲しい人と作る人の間の合意を取っていくことが要件定義なわけですな。

 

ちなみに要件定義は・・・

 

作って欲しい人の要望

作って欲しい人の要求(要望の整理)

作る人の検討

作るひとの提案

作って欲しい人の検討(作る人の提案に対してね)

作る人と作って欲しい人の合意(これが要件定義)

 

 

あとね、要件定義というのは要件定義をするのが目的じゃないのよね。

作って欲しい人が求めているのは、

完成したソフトウェアがもたらしてくれるであろう期待している便益(ベネフィット)

なのよね。

 

要件定義書というドキュメントを作って欲しい人は求めているのではない。

ベネフィットを手に入れる手段として要件定義書というドキュメントが欲しいのだ。

 

無論、いきなりベネフィットを顧客に提供することができないので、プロジェクトおゴールは「そのソフトウェアを利用できる状態にする」ことなのだな。


とはいえ、要件定義の元になるというか、そのサービスを作る最初の企画というのがあるわけで、その企画がずれてしまっては元も子もなくなるわけですよ。

 

その企画をまとめる、つまり企画書を作るのに必要な情報は

 

①プロジェクトの名称
②なぜ・目的
③何を・目的達成のために作るもの・作るものの説明・作るものを利用する人・利用する人が得られる便益
④作るための体制・期限

 

なんだとな。

 

こういうところをベースに要件定義を進めていくのですわな。

 

無論、要件定義は設計・開発という後工程が待っているので、後工程を請け負う人々と歩調を合わせていかなければならないわけですわな。

 

いきなり、確定した要件定義書をぽ~んと投げて、後工程を担う人たちから「できません・・・」という声が聞こえてきてはダメなんですわな。

 

 

はじめよう! 要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

 

 

なぜ、システム開発は必ずモメるのか?―49のトラブルから学ぶプロジェクト管理術

著者:吉田啓二
発売元:日本実業出版社

 

目次

1 要件定義(「言った・言わない」と「やる・やらない」)
2 プロジェクト計画と管理(線表だけが、管理じゃない!)
3 設計(ベンダとユーザが協力すべし)
4 プログラミング(動けばいいってもんじゃない)
5 テスト(テストの対象、わかってる?)
6 契約と仕事の完成(約束したのは何だっけ?)

 

感想

 

これ、タイトルは「●●が△△だから□□」ってタイトルな、そんな本な気がしましたが

いろいろ読んだ、要件定義な本の中で一番良かったかも。

 

「こうすればいいことありますよ」という書き方ではなくて「こうだから、ダメなんだよ~お前は~」と上司から怒られるような書き方となっているので、骨身にしみます。

 

あぁ・・・ごめんなさい

と、素直に思えてしまいます。

 

まぁ、失敗こそが最大の教科書といいますからね。

そんなわけでして、この本はものすごい良い教科書だったりしますわ。


たとえば、要件定義した後に、多くのユーザーさんは「アレもしたい。これもしたい」って騒ぎ出すのですけれど、そういう場合はどうすればいいのかがちゃんと書かれている。

 

それは

 

◎要件変更要望があった際には、そのメリット・デメリットをユーザに説明し、一緒に賛否を検討する
◎追加要望の場合には必ず費用を見積もる
◎見積りの際には、要件変更の賛否検討や要件変更の管理工数を予測して、プロジェクト管理費に含んでおく


のだとな。

 

で、こういう話をすると、機能の話に落ちるのですけれど、機能の話はベンダーとユーザーの間の思いの差が大きかったりするわけですよ。

 

なので何やるのか?何の機能なのか?を明らかにして、お客さんと握らないとヤバイ。

そして、それは機能要件以外、非機能要件でも発生するので、注意ということですわな。


で、要件定義をやり慣れているSierや、Web開発のベンダーと、事業会社の方々は違うわけですよ。

 

事業会社の情シスの人たちだって、年がら年中、要件定義をしているわけではない。

要件定義のスキルに関しては、ユーザー側が大きく劣る。

そりゃ、業務用権ではユーザー側のほうが知見は多いけれどね。

で、そんな要件定義に関してはユーザーを導くことが求められるわけですよ。

ユーザーにおまかせではなくな。

で、それを本書では

 

◎ベンダはユーザの決めること、調べることを積極的にガイドする
◎要件定義は、役割を超えてチームで徹底的に議論する
◎要件定義チームには出来る限り多くの利害関係者を入れる

 

 

事が重要だと、書いておりますわ。


あと、最初から1つのツールにこだわるな、とも書いてあるね。

これ、ものすごく重要。

あと、重要そうなこととして

 

システム開発の要件すべてが、要件定義工程の完了時点までに決まることは稀有です。決まらない要件は未決定事項とし、解決担当者や期限等を定めて継続的に管理することが大切です。

 

と書いてありますわ。

 

まぁ、期限と担当者が重要ですがね。

 

これが漏れちゃダメ、と。


で、お客さんのやりたいことって山ほどあるんですけれど、それをきっちり全部、最初の開発で実装できるわけがない。

順を追って実装していくのですけれど、この考え方をていぎしたものあるのね。

MSCoW分析っていうのね。

何かというと

 

一つ一つの要件をMust(必須)、Should(できればやる)、Cold(あれば尚良い)、Won't(将来的にはやりたい)に分類する

のだとな。

 

いままでなんとなく思っていた&やっていたことを定義してくれたのが嬉しい。

 

あと、機能の有り無しは目につくけれど、その機能があっても実行還流するまでの性能に関してはあまり定義していなかったりするので、注意ねっていう話も良かったわ。

 

あと

「塔子のチェックリスト」

っていうのが良い。

開発プロセスをレビューするためのチェックリストが使えるよ。

これをなぞるだけでも、クォリティはものすごく上がるよ。

あと、参考文献がいろいろ紹介されているのも良い。

 

  

成功する要求仕様 失敗する要求仕様

成功する要求仕様 失敗する要求仕様

 

 

 

アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

アメリカ国防総省直伝 プロジェクト・マネジメント実戦教練ブック

 

 

 

ソフトウエアの要求「発明」学

ソフトウエアの要求「発明」学

 

 

 

要求仕様定義ガイドライン(UVCプロジェクト報告書2007)

要求仕様定義ガイドライン(UVCプロジェクト報告書2007)

 
非機能要求仕様定義ガイドライン(UVCプロジェクトII)

非機能要求仕様定義ガイドライン(UVCプロジェクトII)

 

 

を読みたくなりましたわ。

 

 

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

 

 

要求定義のチェックポイント427

著者:本園明史
発売元:翔泳社

 

目次

第1部 要求定義オリエンテーション

第1章 要求定義担当者の心得
 要求定義とは
 要求フェーズの作業の流れ
 要求定義を成功させるためのポイント
 要求フェーズの一般原理

第2部 フェーズ別チェックリスト

第2章 準備フェーズ
 プロジェクトの作業を定義する
 要求獲得の方法について考える
 キックオフミーティングを開く
 プロジェクトの認識を合わせる

第3章 基盤整備フェーズ
 問題を明確にする
 システムの目的を明確にする
 業務を理解する
 既存のシステムを検証する
 システム化の範囲を検討する
 ユーザ情報を収集する
 制約条件を明確にする
 トレードオフ条件を明らかにする

第4章 要求獲得フェーズ
 ルーチン作業のヒント
 機能要求を獲得する
 非機能要求を獲得する
 トレードオフ条件を明らかにする

第5章 引渡しフェーズ
 すべての要求を見直す
 テスト可能性を検証する
 要求の曖昧さを排除する
 追加変更要求に対応する

付録 一歩踏み込んだフェーズ別チェックリスト

 

感想

開発案件で揉めてしまうのって、お客さんの要求をきっちり引き出せていないことが多いからなんだよね。

 

まぁ、お客さんが望んでいたものを、ドンピシャに開発しても、そもそもその要件じゃ課題が解決できなかったりするんだけれどね。

 

そういうこともあるんだけれど、それはそれということで、正しい要求定義の書き方がしっかり書かれていますわ。

 

で、個人的には要求仕様確定Phaseの成果物ってRFP,つまり要求仕様書だけでいいんじゃねえか?って思っていたりしたんだけれど、ソウじゃないんだな。

 

それは50ページにしっかり書かれている。

 

□正式な納品物として何を想定しているか。
→要求フェーズにおける正式な納品物の例
 ●要求仕様書
 ●ユーザマニュアルなど
□開発用のアウトプットとして何を想定しているか。
→開発用のアウトプット例
 ●開発用の要求仕様書
 ●問題リスト
 ●制約リスト
 ●リスクリスト
 ●ユースケース
 ●要求管理データベースなど

 

これは改めて勉強になりましたな。

あと、同じ流れで要求仕様書のページ建てというか、内容がしっかり定義されていて、それも52ページに書いてあった。

 

IEEE/ANSI標準
1.はじめに
 1.1要求仕様の目的
 1.2アウトプットの範囲
 1.3用語の定義、頭文字、および略語
 1.4参考資料
 1.5要求仕様の概要
2.一般記述
 2.1製品の概要
 2.2製品の機能
 2.3ユーザの特性
 2.4制約条件
 2.5仮定および依存事項
3.要求仕様
 3.1外部インターフェース
 3.2機能的要求
 3.3性能要求
 3.4論理データベース要求
 3.5設計の制約
 3.6システムの特性
 3.7品質の特性
付属資料
索引

 

こうやって構成されてるんだとな。

 

で、そんなしっかりとした要求仕様書を作成するためのチェック項目が54ページに書いてあるのだな。

 

それは

 

□基本事項
 ●要求に番号がふられているか。
 ●要求の発生日はいつか。
 ●要求は新規か、追加・変更か。
 ●要求の出処はどこ(誰)か。
 ●要求が要求仕様書に記録された日はいつか。
□要求詳細
 ●要求は何か。
 ●要求の基になった原因・背景は何か。
 ●要求の実現システムの目的はどのように貢献するか。
 ●要求の実現は誰にどのようなメリットがあるか。
 ●要求の実現は誰にどのようなデメリットがあるか。
 ●要求の実現によって得られる効果は何か。
 ●要求の実現によって得られる効果は計測可能か。
 ●開発工数、費用はどの程度に見積もられるか。
 ●投資対効果は検討されているか。
 ●要求に付帯する非機能的要求(品質・性能等)は明確いなっているか。
 ●発生するとすれば、どのような変更要求が発生するか。
 ●要求の優先度は明確か。
 ●要求の重要度は明確か。
□他の要求との関係
 ●要求は他の要求に依存しているか。
 ●要求は他の要求の前提条件となるか。この要求の実現を前提条件にしている要求はあるか。
□既存の要求への影響
 ●要求間の依存関係に変更はあるか。
 ●要求間の前提条件、制約条件の変更はあるか。
 ●既存の機能間のインターフェースに変更はあるか。
□開発可否の判断の記録
 ●開発可否の判断会議が実施された日はいつか。
 ●判断会議の参加メンバーは誰か。
 ●判断に使用された情報は何か。
 ●判断基準は何か。
 ●判断結果は何か。
 ●判断基準、判断結果に関して特記すべき事項はあるか。
 ●判断に使用された情報が誤っている、あるいは正確性に欠ける可能性はないか。
□要求のステータス
 ●要求の処理状況の例
  ・要求管理ドキュメントに記述済み。
  ・開発可否の判断待ち。
  ・開発可否の判断済み。
  ・要求仕様書の記述済み、など。

 

いや、ためになりましたな。

 

要求定義のチェックポイント427

要求定義のチェックポイント427