書籍・雑誌

2022/09/12

「物理学の野望」の本が分かりやすかった

物理学の野望 「万物の理論」を探し求めて」の本が分かりやすかった。
物理学は、世界のすべての現象を1つだけの考え方で統一して説明しようと頑張っている。

【参考】
物理学は一つの認識論: プログラマの思索

物理学を攻略するためのマップ: プログラマの思索

「小水力発電が地域を救う」の感想: プログラマの思索

その発想の原点は、オッカムの剃刀にある。

ウィリアム=オブ=オッカム

(引用開始)
ウィリアム=オブ=オッカムが云った言葉に「存在は必要以上に増やされるべきではない」というのがある。これは、真理は単純明快なものであり、それを説明するのに余計なことはできるだけ省くべきであるという意味で、「オッカムの剃刀(カミソリ)」と云われている。
この言葉は、一般にある問題についていくつかの解答があった場合、「より少ない原理でより多くの現象を説明できる理論の方がよりよい」ということで、例えば天動説と地動説では、天動説では天体の運動と地上の物体の運動とで別々の法則を立てなければならないが、地動説は両者を一つの運動法則で説明できるから、こちらの方が正しい、と言うように使われる。
(引用終了)

数多くの現象を集めても無意味で、それら現象をより少ない原理で説明されるべき。

物理学の野望 「万物の理論」を探し求めて」ではこんなストーリーになる。

まず、ニュートン力学により、地球の外にある天上の世界を1つの原理で説明した。
次に、物理学者たちは、地上の現象を説明しようと頑張った。
彼らが取り組んだのは、熱、光、電磁気。
熱はエネルギーの一つの要素と分かり、光は電磁波と分かり、電気と磁気は相対する関係と分かった。
そして、マクスウェルの方程式でそれらの現象は統一して説明できるようになった。

そして、電磁気力、弱い力、強い力は最終的に法則で統一された。
最後に残るのは、重力。

物理学の野望 「万物の理論」を探し求めて」には書かれていないが、おそらく超弦理論が4つの全ての力を統一する法則を提供するのだろう。

物理学の野望 「万物の理論」を探し求めて」で興味深かったのは、発電所は、磁気モーターで電気を作り出す仕組みが根本にあり、そのモーターを回す仕組みを○○力発電と呼んでいるだけ、ということ。
たとえば、水力発電、風力発電、火力発電、地熱発電、原子力発電は、磁気モーターをどの力で動かしているか、という違いを表しているに過ぎない、と。
なるほど、たしかにそう考えると当たり前なのだろうが、詳しくないので新鮮だった。


| | コメント (0)

2022/08/28

「現代病「集中できない」を知力に変える 読む力 最新スキル大全」の感想

「現代病「集中できない」を知力に変える 読む力 最新スキル大全」を読んで面白かったのでメモ。

【参考】
Twitterは最速のメディア: プログラマの思索

ビジネス特化SNS「Linkedin」から見えるもの~人脈はデータマイニングで作られる: プログラマの思索

Facebookはセルフブランディングの最強ツール: プログラマの思索

MEDIA MAKERSの感想: プログラマの思索

Clubhouseは路上ライブや朗読のためのツールかもしれない: プログラマの思索

Google、それは強大な広告代理店: プログラマの思索

コロナ禍の時代にいかに情報収集&アイデア発散収束のスキルが必要か、経験を交えたノウハウが良かった。

・SNSは2種類を使い分ける
 人間関係重視はFacebook、LINE、Instagramなど
 情報収集はTwitter

・ネットからプル情報を取りに行く
 ∵今は情報洪水の時代
⇒RSSリーダーを使う
 ∵情報源のニュースサイトの新着情報だけキャッチする
⇒キュレーションサイトも活用する

・Twitterを情報収集のツールとして扱う
 例:新型コロナが良い例
 ∵新聞も本も真実が少ない。
 ∵Twitterに流れる専門家の情報が貴重な情報源になる

・Twitterでフォローすべき専門家の選択基準
 その分野の専門家であるか
 専門用語を適切に使っているか
  ∵素人は、特定分野の専門用語を知らない
 乱暴な言葉使いがないか
  ∵中途半端な人ほど断言しやすい
 専門家集団から信頼され評価されているか

・本を読むのも大事
 ∵情報が集約される
 ∵情報が網羅されている
 ⇒多様な視点が持てる
 ⇒アウトライン→観点→全体像の流れで説明してくれる

・Kindleを使え!
 ∵どこでも買える
 ∵テーマの全体像をサクッと得られる
 ∵文章を検索できる
 ∵文章をコピペできる
 ∵リンクからWebサイトへ辿れる
 ∵大きな文字で読める。老眼ならメリットあり。
 ∵本棚が不要
⇒電子書籍が読みにくいのは慣れの問題
 iPad、KindlePaperwhiteを使う

・今読むべき本の基準
 本と自分の相性を知る
 本に対し自分のスキルが足りているか
 向いていない、無理とおもったらいったん潔くあきらめる
 今読んで楽しい本は知肉化する

・本、電子書籍の読み方のコツ
 付箋、ハイライトを使う
 抽象的で難しい部分こそ熟読する
 ハイライト、マーカーした部分はメモアプリにコピペする ∵知肉化する
 何の感銘を受けたのか、短い覚書を残す
  ∵エピソード記憶、連想、言い換え、疑問
 参考文献を元に芋づる式に読みまくる

・読書スタイル
 スキマ時間で2h/日を捻出する
  ⇒1冊/3日で読める
 色んな時間や場所で小刻みに読む
 ⇒ミニマリスト生活に慣れる
  慣れればどこでもくつろげる

・2つの保存方法を使い分ける
 頭の中の保存
  概念化されている
  ストーリー、物語を作る
  記憶容量が狭い
 コンピュータに保存
  容量制限なし
  検索できる
  記憶に強い

・知と知を結びつける
・無意識の領域でコビトが献身的に働くようにする
・コビトに餌をばらまく
 頭の中で概念がふっと思い出されて、コビトが結びつけてくれる
・世界観と知肉が舞い降りる
・脳をクリアな状態にする
 ∵世界観と知肉が舞い降りるには、ゆったりした時間と場所が必要で、脳みそを忙しい状態にしない

・雑務は徹底的に効率化する
 スケジュール管理、タスク管理、道順、請求書発行
 →雑務はアウトソーシングする
  クラウドサービスを使いまくる

・ブラウザは用途で使い分ける
 情報系ブラウザ=Chrome
 雑務系ブラウザ=Firefox、Edge、Safari

・散漫になりやすい
 集中しにくい
 ⇒散漫をコントロールできれば、仕事はいくらでもこなせる

・舞い降り=アイデアは発想を作り出す
 頭をキレイでまったいらな場所を作る
 散漫でいい

・タスク=請求書やパワポ、エクセルで資料を作る
 集中力が必要

・日々のやるべきタスクを分類する
・ネットで情報収集→Feedly+Pocket→スマホ
・書籍や資料を読む→重い本or軽い本、読書メモ→タブレット
・資料を作成→自由な思いでアイデアを練る、アイデアをドキュメントに落とし込む→PC
・原稿を書く→文章の構成を考える、思い執筆→PC
・メールチェックや請求書作成→PC
・息抜き→Youtubeなど→スマホ

・ポモドーロ・テクニック
 事前に仕事のリストを作る
 25分集中+5分休憩が1セットを繰り返す

・自分の最適なインターバルを探す
 3分、5分、15分、25分と変えていい

・もう少しやりたい気持ち、飢餓感を使う
 飢餓感が舞い降りをもたらす

・Bootstrapでやる気を起こす
 PCのOS起動と同じ
 やる気のロードは時間も手間もかかる

| | コメント (0)

2021/02/01

本を書く時の心構え

結城さんが本を書く時の心構えを公開していたのでメモ。

【参考】
次に書く本を考えているときのこと(思い出の日記)|結城浩

(引用開始)
でも、次に書く本を考えているときは、モードがずいぶん違います。
自分の心をとにかく広く広く広げる。遠くの地平線のその向こうまで見るような気持ちで、自分の四方を見渡す。
自分の両手がまるで大きな大きなコンパスになったような心持ちで、ぐるーりと巨大な円を描く。
「よーし、ここまでは届くかなあ。いや、もっと行けないかな?」などと考えつつ。

自分が、現在の段階で、その領域の境界部分を詳しく知っているかどうかはあまり考えない。
でも、数ヶ月の後に、その境界付近にある「とっても面白いところ」に接近できるかの見込みは立てる。

……私が次に書く本を考えているときには、そんなことをイメージしているように思います。

書き始める時点では知らなくてもよいけれど、書き終えた時点ではかなり詳しくなっているはず……という微妙な案配を見極めるのは難しい。
つまり、「自分がすでに知っていて何も考えなくても書ける」という難しさの本だと、私は書いていてつまらなく感じる。
それよりも「調べつつ・考えつつ・謎解きしつつ書かなくちゃ」という難しさの本がよい。
(引用終了)

僕は、本を書くということは、「今ここにいる自分」の知識と経験をフル動員して書くものだと思っていた。
僕は、全ての書物は、私小説だと思っていたから。

なぜなら、何かを書いて本として公開する、という意味は、自分がどこまで理解して、今まで誰も知らなかったことを発見したから世の中に広く知らしめたい、と思っていたから。
たとえば、自分の理解度が浅かったり、経験が少なければ、書物の内容はとても浅薄なものになりがちだ。
よって、書き始める時点で、内容のほとんどは自分が抑えていて、コントロールできなければならない、と思っていた。

たとえば、戦前の日本の小説家が書いたスタイルである私小説は、小説家自身の生活をベースに書いていたから、彼らのインプットが非常に少ないので中身はとてもつまらないと思っていた。

一方、結城さんの意見では、「最終的に本を書き上がる時点の自分」の知識と経験を書けばいい、というスタンスだ。
つまり、書き始める時点では、中身はまだ曖昧模糊でもいい。
書き終えた時点で、骨格も中身もプロットも全て完成していればいい。

よって、書き始める時点では、調べて考えてストーリーが決まったな、という範囲を予測できればいいし、その予測した範囲が自分の手の内に収まる程度であるか見積もりすればいい。
つまり、調べながらあれこれ考えたり、空想したりする余裕がある。
謎解きする楽しさの余地を残している。
書き始めた時点のストーリーが、謎解きするうちに、書き終えた時点では全く違うストーリーで完成度が仕上がっている、みたいなイメージになるのだろう。

今度書く機会があれば、こういう発想を使ってみたい。

| | コメント (0)

2020/12/06

考えながら書く人のためのScrivener入門の感想

「考えながら書く人のためのScrivener入門 小説・論文・レポート、長文を書きたい人へ」を読んで、改めて、物書きになる環境について色々気づきがあった。

【参考】
統合執筆環境Scrivenerのリンク: プログラマの思索

「考えながら書く人のためのScrivener入門」の帯には、「書く才能はある!足りないのはScrivener」という文言がある。
僕も出版した経験があるから理解できるが、書物1冊を書き出すのは本当に大変だ。
大変な理由は、1冊20万字くらいの文字数を書き出すこともあるだろうが、むしろ、構成やストーリーの一貫性や整合性を考える点の方にあるだろうと思う。

「考えながら書く人のためのScrivener入門」には、3人の小説家がScrivenerを使って執筆した経験談をインタビューしてくれている。
読んでみると面白い。
気になった点はいくつかある。

一つは、小説や書物という長編を書く場合、何かしらの文書の構成方法や構成を管理する環境が必要になる点だ。
たとえば、200ページの本を印刷してつなげると、16メートルの長さになるらしい。
すると、修正する時に、該当の箇所を探し出すのに、画面スクロールを16メートルも指を動かしているわけだ。

修正を何度も繰り返すたびに、そういう動作を何度もやっているわけで、そういう無駄な作業時間をストップウォッチで計測したら相当なロスになるはずだ。
実際、単純な検索機能では、同じような文言が見つかったり、構成を見直すためにあちこちを修正する場合は、考える時間よりも探し出す時間の方が多くなり、せっかくのアイデアが失われてしまう。

そこで、Scrivenerの出番になる。
Scrivenerでは、文書を1ペインのアウトライナー画面、2ペインのテキスト画面、コルクボード形式でアイデアを発散させる画面など数多くの機能がある。
つまり、ある時はアイデアを適当に発散させたり、あるシーンだけを詳細に書いたり、いくつかの物語のプロットの構成を考えながら節ごとに入れ替えたり、などと考える場面に合わせて変更できる。

他にもタグ付け、ラベル付け、とか、数多くのファイル出力機能、Dropboxと連携してバックアップの同期を取るなどができるらしい。
個人的には構成管理が気になるが、スナップショット機能があるらしいので履歴管理できるらしい。

2つ目は、3人の小説家は統合執筆環境Scrivenerだけで書いているのではなく、小説を書くまでのアイデア発散フェーズではマインドマップやアウトライナーのエディタを使ったり、遂行する段階ではPDF出力して印刷した紙で読み直すなど、割とアナログな面も残していることだ。
結局、ITというツールをいかに使いこなして、生産性を上げているとしても、その根っこにあるアイデアの発散や連想によるアイデアの結合などは、従来のアナログの手法とは変わらない。

この点は、Redmineのようなチケット管理ツールでも、その背後にある開発プロセスの話に結局落ち着く点に似ている。

3つ目は、長文の原稿は数多くの短編に分割して管理するのが推奨されていること。
ソフトウェアにおける分割統治と同じ発想だが、ソフトウェアが階層化してポインタを使う手法に対し、執筆では、文書を階層化するとしても1ペインのアウトライナーを有効に使う手法になる。

つまり、Wordのアウトライン機能のように、レイヤごとに見出しを揃えるが、その見出しはフォルダでもありテキストにもなりうる。
BEITELというアウトライナーのエディタのように、1階層目の見出しだけでもストーリーとして読めるし、2階層、3階層の中間レイヤの内容だけでも十分にストーリーとして読めるような構成にするわけだ。

BEITELとは - アウトラインエディタ BEITEL(バイト)

僕はマインドマップが大好きなのだが、何かしらの報告書や議事録のように、長文の文章を書く時にマインドマップでは何か物足りず、何かしらの機能が必要だと思っていた。
たぶんその原因は、発散したアイデアを一つの文章という1次元のデータに変換して、論理構成を保つには、アウトライナーのようなツールが必要だと直感していたためだろうと思っている。

この辺りの思考ツールや書き方については色々まとめてみる。


| | コメント (0)

2020/04/09

ソフトウェア・ファーストの感想

「ソフトウェア・ファースト」を読んだので、感想をラフなメモ書き。
非常に良い本だったので、自分の気づきをメモしておく。

【参考】
ソフトウェアファーストを読んで開発組織と外部委託について考えた | masaytan's blog

『ソフトウェア・ファースト』読書メモ その1 - Qiita

ノンプログラマーの機械屋が読んだ「ソフトウェア・ファースト」

【1】「ソフトウェア・ファースト」は良い本だ。
「ソフトウェア・ファースト」のターゲットは、特にメーカーの経営陣、中間管理職の人達だと思う。
そういう言葉は書かれていないが、トヨタの話やメーカーの生産管理とソフトウェア開発の比較、などの話が多いので、メーカーの人にはとても響くだろう。
特に、メーカーにいて、ITに詳しくないが、ITが経営に直結している立場の人達、つまりメーカーで経営上の意思決定をする人達が読むべき本だ。
どのメーカーも、トヨタが生み出したJIT生産、なぜなぜ分析、自働化など数多くの概念を自社に取り入れようと努力してきたから、あのトヨタも変わっているのか、と気づくだろう。

【2】IT技術者として「ソフトウェア・ファースト」を読んで興味を惹いた部分はいくつかある。

【3】メーカーがソフトウェア開発を内製化していない点を痛烈に批判している。
メーカーの生産管理では、自社の工場で生産計画・生産統制をできるだけ内製化し、その品質管理だけでなく、外部取引先から調達する部品の品質管理も徹底的に行なっている。
「手の内化」というトヨタの言葉はその通り。

たとえば、日本の元請け企業は自社の技術社員を、下請け企業に派遣して、調達する部品の品質管理や進捗管理を行うだけでなく、わざわざ下請け企業の社員に技術指導まで行っている場合が多い。
つまり、日本のメーカーは、自社の工場だけでなく、自社の製品に関わる下請け企業までを生産管理の対象とみなし、一連のサプライチェーンを品質管理することで、品質向上を図ってきた。
だから、日本の製造業が生み出す製品の品質はとても高い。

一方、メーカーのソフトウェア開発では、自社でソフトウェア開発は内製化しないだけでなく、外部からの委託・調達したソフトウェア製品やソフトウェア成果物の品質管理すらも全くできていない。
つまり、メーカーは製造プロセスのサプライチェーンまで自分でコントロールしているのに、なぜ、ソフトウェア開発ではまともな品質管理すらせず、コントロールしないのか、と。
IT技術は知らないから、というのは言い訳に過ぎない、と痛烈に批判している。

たとえば、「ソフトウェア・ファースト」の一節に、トヨタの豊田章一郎社長が社長に就任した時に、企画開発チームに実際に赴いてその知見を乞うたが、あのトヨタの社長でもそうならば、ITが経営上重要になっているならばソフトウェア開発の現場に経営陣も自ら赴くべきではないか、と。
3現主義と言いながら、ソフトウェア開発の現場は見ていないでしょ、と。

【4】SaaSはソフトウェアの特徴をうまく活用している、という主張は本当に興味深い。
SaaSの最大の特徴は、ユーザの生の声をフィードバックで収集できる点だ。

自動車であれ大半のメーカーでは、工場や最新機械などの固定費が膨大な為、資本を減らすために、販売店などを切り離している。
よって、メーカーは販売した製品に関する消費者の生の声を集めるチャネルを持っていない弱点がある。
この弱点は、昨今のGoogle・Apple・Facebook・Amazonを見る通り、メーカーにとって致命的。
トヨタのようなガソリン自動車メーカーは直販プロセスを持っていない一方、後発の電気自動車メーカーであるテスラは、直販チャネルを持っている上に、さらに、自車の運行データをユーザから収集して自動運転に活用しようとさえしている。

Saasでは、ユーザの生の声はカスタマーサポートからシステムのアクセスログに至るまで、数多くのチャネルがあるので、それらを収集して分析することで、より良い製品へ改良するきっかけになるし、開発チームにとっても、製品改良のモチベーション向上にもつながる。

特に、GAFAは、ユーザのフィードバックの収集・分析・改良・リリースという一連のプロセス構築がうまいのだろう。
その一連のプロセスは、アジャイル開発そのものだ。
従来のメーカーが大事にしてきたPDCAサイクルとは本質的に違っていると思った方が良い。

僕自身が持つアジャイル開発の認識も古くなっていると思った。
僕は以前は、アジャイル開発の本質は小規模リリースだ、と思っていたが、今は1日数十回もリリースできるような高速な開発プロセスにまで洗練されている。
そのアジャイル開発の本質は、DevOpsだ。

DevOpsは単に、運用も開発もチームが一体化したもの、という認識だけではないと考える。
ソースを機能改善したら即反映できるリリースプロセスを整備したもの、と認識すべき。

以前のアジャイル開発のボトルネックは、リリース工程にあったと思う。
継続的インテグレーション、継続的デプロイなどがXPのプラクティスにも含まれていたが、それらが重要なプラクティスであった理由は、リリース工程がソフトウェア開発の最大のボトルネックだったからだ。

実際、今でもWF型開発でソフトウェアを開発していれば、製造工程よりもテスト工程とリリース工程で膨大な工数がかかっているはずだ。
多くのプロジェクトマネージャは、テスト工程でリリース工程で手を焼いているはずだ。
つまり、下流工程と呼ばれるテストやリリースの工程がソフトウェア開発のボトルネックであり、それを制御するのは難しい、という現実を示唆していたのだと思う。

しかし、今では、クラウド上でカナリアリリースやInfrastructure as Codeのように、本番環境やリリース作業を構成管理の配下でコントロールできるようになったおかげで、自信を持ってソースの機能改善ができるし、新機能に挑戦できる心理的メリットも生まれているはずだ。
つまり、システムの機能改善という、ソフトウェアの本質的な価値を具現化するものにより力を注げる開発プロセスを構築できるようになったわけだ。

【5】メーカーがソフトウェア開発を内製化した時の組織構造や組織文化の話も非常に興味深かった。

一読した限りでは、メーカーの組織文化とソフトウェア開発の組織文化は水と油なので、ソフトウェア開発は別の組織で分社したり、企画開発に特化したり、マトリクス型組織にする、などの示唆があったのは興味深い。
たぶん、著者自身も数多くの試行錯誤をされているのだろう、と思う。

メーカーではないが、サイボウズの組織構造の変化のコラムが興味深かった。
サイボウズも中小企業だった頃は、機能別組織であって、開発・運用基盤・企画営業など縦割りの機能に分かれていた。
しかし、SaaSを販売してユーザのフィードバックをSaaSに反映していくようになると、そういう縦割りの機能別組織では、社内のコミュニケーションが取れず、現場が混乱した。
そこで、製品別組織に立て直し、企画から開発・運用に至るまでのプロセスを一つの部門で担当できるようにしたら、上手く回るようになり、組織文化も良くなっていった、という。
つまり、機能別組織から事業部制に変化したわけだ。

この話を読んで、チャンドラーの「組織は戦略に従う」という文言を思い出させる。
チャンドラーの組織発展モデルでは、企業内部の組織は事業の発展によって、単一の機能別組織から事業部制組織、そして分社化した子会社・関連会社を持つコングロマリットという多国籍企業へ変わっていく。
ソフトウェア開発の組織構造も、メーカーと異なっているとしても、組織構造のモデルという自然法則に従わざるを得ないわけだ。

【6】ソフトウェア開発組織の職種として、エンジニアという技術専門職だけでなく、プロダクトマネージャーとエンジニアリングマネージャという管理職も上げている点が興味深かった。

僕の理解では、エンジニアリングマネージャはアーキテクトかつプロジェクトリーダーのイメージ。
プロダクトマネージャーは、Scrumのプロダクトオーナーのイメージ。

プロダクトマネージャは、ソフトウェア開発の経験があるのは良い点だが、その経験が逆に邪魔する時がある。
本来の製品のあるべき姿は、その時代の技術の制約から離れて考えるべきなのに、ソフトウェア開発の経験が邪魔して、その時代の実装方法に依存した製品イメージを描いてしまい、本来の姿とかけ離れてしまう弱点もある、と。
そういう指摘は非常に参考になった。

| | コメント (0)

2019/12/27

捏造された聖書の感想

とても面白い。
キリスト教が誕生して、カトリックと三位一体説が正統派として確立するまでの間、数多くのキリスト教の流派があり、それぞれで議論して闘争していたのがよく分かる。

つまり、中国の諸子百家、インドの仏教とジャイナ教の対立のように、原始キリスト教も数多くの流派がそれぞれの自説を主張して生存競争をしていたわけだ。

「捏造された聖書」を読む前に、下記を読んで、キリスト教における三位一体説を理解していたので、聖書が改ざんされた意図や背景が良く理解できた。

キリスト教の発展、分裂後の東西ローマ帝国 http://www.geocities.jp/timeway/kougi-19.html

論点は「イエスは神なのか?人間なのか?」
現存のキリスト教は、三位一体説を奉じるので、イエスは神であり人間でもあるが同質である、という立場。

原始キリスト教の世界では、イエスは人間だったという養子論、イエスは神であるが旧約聖書にあるユダヤ教の神とは違うという仮現論、イエスは人間イエスと神キリストの二つの物理的存在に分割されているという分割論、など多数の流派があった。

しかし、三位一体説を奉じる流派が唯一生き残ったことにより、それら流派の解釈を許さないように、聖書の文言を改ざんしていった、というストーリー。

だから、最近になって、三位一体説を否定するキリスト教の流派、たとえば、エホバの証人、とか、モルモン教などが、現存のキリスト教はおかしいのであって自分達が本来のキリスト教なのだ、と主張しているわけなのか。

こういう理解ができた後、今のキリスト教を信じている人は、この本は信仰を否定するような内容になるので、危険な本だろうな、と思う。
読んでいてハラハラした。

捏造された聖書では、他にも、現代から真の聖書を探していく作業、つまり文献分析学の話を相当詳しく説明してくれているので、とても分かりやすい。

| | コメント (0)

失敗の本質―日本軍の組織論的研究の感想

旧日本軍という当時最先端の高度な官僚組織が日本を破滅に陥れた原因を、組織論に求める、という内容だった。

(1)7つの失敗事例の詳細は、地図を見ながら読まないと完全理解できないと思うけど、失敗に至った話を読むと、とても身に沁みるように感じるのは、たぶん、自分も古い日本の大企業にいるからかもしれない。

改めて思うのは、80年前も今日も、日本のトップは、巨大な官僚組織を上手く使いこなすのが下手、ということ。
一人ひとりの部下を動かせても、「組織を動かす」という能力が足りない、という感触を受ける。

日本の大手企業や官公庁のトップは、その大きな組織の重みをコントロールできず、誰も舵を取らないまま暴走してしまい、破滅に向かう。

一方、アメリカや中国は、官僚組織を使いこなすのが上手い感じはする。
その違いは何にあるのだろうか?

| | コメント (0)

お金2.0 新しい経済のルールと生き方の感想

自然界のあらゆるものは時間の経過と共に価値が減っていくのに、通貨のみは価値が減らないどころか、金利によって増えていく。それは欠陥だ。
だからスタンプ貨幣を導入して、通貨にマイナス利子率をつけよう、というゲゼルの主張。

ビットコインは、報酬設計が秀逸。
インセンティブを強調しすぎて崩壊する金融市場。
誰が得するのか不明な新技術。
理論の美しさのみで実現する気のない思想論文。
しかし、ビットコインは、経済、テクノロジー、思想のそれぞれが役割を果たして、うまく報酬設計がなされている。
ビットコインの発案者は理想主義者ではなく、動くものを作りたい現実主義者ではないか、と。

| | コメント (0)

2019/02/11

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

【追記】
hekitterさんはTwitterを使っています: 「「サピエンス全史」「ホモ・デウス」の図解のリンク https://t.co/6KSKQH4Dph 今日UMLのことを調べてたら、思いがけず興味深いのがあるやんとみてたら、やはりakipiiさんの記事だった。(まだちゃんと読めてないので改めて読む)」 / Twitter

| | コメント (0)

2014/07/05

出版システムや文書共有システムを作った事例

出版システムや文書共有システムを作った事例の資料が最近たくさん出ている。
以下リンクしておく。

注目点は、いくつかある。

1)GitHubやBitbucketを執筆データのリポジトリにする。
2)執筆データはMarkdownのようなテキストファイルで保存
3)ReViewやSphinxなどのツールでPDF・EPUBに変換する
4)定期的にビルドしてDropboxなどに配布する

昔は手書きの原稿用紙に書いて、その後、推敲して修正して、組版に載せていた。
僕も小学校の頃、ガリ版で卒業文集を書いた経験がある。

でも、今は、Wordでもなく、テキストに書いて、即座にビルドして配布する仕組みが普通だろう。
スマフォへ定期的にビルド&配布すれば、通勤や待ち時間でも、著作物をレビューできる。
そのフィードバックを受けて、著作物をさらに洗練させていくことができる。

執筆環境ももっとアジャイルになるべき。

| | コメント (0)