平成金融史

平成のバブルの発生から現代までを追ったドキュメント。
バブルといえば、派手なイメージしかないし、景気の過熱と思っていたけど、長期的に低金利で、高金利はバブルがはじけ始めてからというのがわかる。
金利を上げたいけど、物価上昇がないから金利を上げられない日銀が招いたことと言われても仕方がない気もする。将来を全員が予想できると思う始めると過剰にリスクを取り始めて、それがバブルにつながるということだ。
現在も、低金利が続いていて株価が上がりつつあるので、当時と近しい部分もあると思う。当時と違うのは株価の上昇のそれなりの割合が、日銀による買オペの結果だということだろうか。

自分のように８０年代生まれだと、この本に書いてあることを子供のころから実際に見ているので、非常に面白い。
「中央銀行」を読んだ際にはみんな官僚なども含めてバブルに誠実に向き合ったような印象を受けたが、実際には自分の任期中にはトラブルを起こしたくない官僚や大きすぎて潰せないと思い込んで、もはや退場すべき会社を生き永らえさせているような政策をとってしまう日銀や政府といった面も見えてくる。
退場すべき会社の下支えは現在も行われているように思える。日銀の買いオペは、その例といえると思う。

今では考えられないが、昔は都市銀行が21行もあり、それが統廃合を進めた結果3つになったのだから驚きだ。

不良債権処理計画も当初から10年単位の計画が組まれており、失われた10年などというが、失われるのが計画された10年といえる気もする。

当たり前ではあるが、現代へとこれらの状況が地続きであるから、現状の日銀の資産や打ち手の出口の見えなさなどに不安を覚える。


https://www.amazon.co.jp/%E5%B9%B3%E6%88%90%E9%87%91%E8%9E%8D%E5%8F%B2-%E3%83%90%E3%83%96%E3%83%AB%E5%B4%A9%E5%A3%8A%E3%81%8B%E3%82%89%E3%82%A2%E3%83%99%E3%83%8E%E3%83%9F%E3%82%AF%E3%82%B9%E3%81%BE%E3%81%A7-%E4%B8%AD%E5%85%AC%E6%96%B0%E6%9B%B8-2541-%E8%A5%BF%E9%87%8E-%E6%99%BA%E5%BD%A6/dp/4121025415

イスラム教の論理

著者の飯山 陽は、他のイスラム教の研究者からは批判されることもあるようだが、本書は明らかに良書。
西洋の価値観と違った価値観の世界があることを記述している。
社会主義国家に対しても言えることではあるけど、西側の視点でだけ世界を見るのではなく、いろんな視点が存在するという事実を認識するのは大事だと思う。
内容的には、イスラム過激派がコーランをどのように解釈しているのかを繰り返し述べている。
ちょっと内容的には、繰り返しが多い気もするが、それだけテロを正当化する論理にバリエーションがあるということなのだろう。
イスラム教の論理ではジハードを根拠としたテロ行為を論理的に否定することは難しいという現実があることは分かった。

他のイスラム教の研究者から嫌われるというのもちょっとわかる気がする。
日本人が感じるイスラム教への違和感などについて、正面から一つの回答を出そうとしているだから、それが出来ていない研究者からしたら目障りにはなると思う。
学者としては、回答がない疑問への答えを見つけようとする試みは、褒められるべきだが、そういった評価ではないというのは、日本のイスラム教の研究者社会は学術的価値をあまり生み出していないのかも等と邪推してしまう。

https://www.amazon.co.jp/dp/410610752X/ref=cm_sw_r_tw_dp_U_x_70YhEb5AM6FFJ

良いコードを書く技術

表紙や中身の漫画から内容が薄いかなと想像したが、思ったよりも良書。
普通に名前付けの章とか参考になる。

ライブラリ/フレームワーク
*Scope, *Loader, *Engine, *Provider, *Conversion, *Behavior, *Descriptor, *Cache, *Resolver, *Processor

GUI/フレームワークを拡張する部品
*Listener, *Hander, *Runner, *Command, *Observer, *Node, *Adapter, *Proxy, *Holder, *Context, *Monitor, *State, *Builder, *Factory, *Visitor, *Decorator, *Strategy

アプリケーション
*Action, *Controller, *Dto, *Logic, *Service, *Util, *Entity, *Helper, *Support, *Dao, *Manager, *Bean, *Form, *Exception, *Validator, *Test, *Impl

一部、使わないほうが良いものもあるきもするけど。。

https://www.amazon.co.jp/dp/B07JHP988R/ref=cm_sw_r_tw_dp_U_x_QAjhEbS2N82KZ

中央銀行

これ、かなり面白かったです。

僕と同年代の人なら概ね面白く読めるのではないかと思います。
35歳前後。

学生時代とか社会人なりたての頃にテレビで行われていた経済についての議論の中心にいた日本銀行の総裁の書いたもので、当時感じていた違和感に対する日本銀行の中の人が何を感じていたかがわかって面白い。

当時は、日銀の施策で景気が回復するのだから、日銀がなんとかすべきみたいな論調があったと思うが、金利をいじったりお金の供給量を増やすことで本当に景気が回復するのだろうかという違和感を個人的には感じていた。
韓国企業などには、すでに製造業は負けていたし、海外ではまるでシェアを取れていないことは明らかだった。

実際に日銀の人たちも、金利の操作などで景気が回復するとは思っておらず、景気が悪い原因は生産年齢人口の減少にあるというのは調査から明らかだったようだ。
当時から少子化とは言われていはいたが、経済に深刻なダメージを与えるといった論調は聞かれなかった気がする。しかし、日銀などの内部で明らかだったようでレポートなども作成されている。
https://www.boj.or.jp/research/brp/ron_2012/data/ron120831a.pdf

生産年齢人口の変化は１０章などでも取り上げられており、参考になる。

日銀自体が、巨大なシンクタンクで、レポートも出しているので、今後も追いかけるべきだと思うには十分な説得力を持つ本になっていた。
他のレポートは
https://www.boj.or.jp/research/brp/ron_2019/index.htm/
このあたりにある。

日本の景気に対する見方もちょっと変わったと感じている。
日本人の能力の変化というよりは、不良債券が多すぎたために、企業が新規の投資をすることが出来なくなり、人も雇えなくなり、古いものを古い人達が古いやり方で継続する以外に選択肢がなかった。
その間に、アメリカなどではIT企業が育ち、もはや勝ち目がないくらいに差が開いてしまったといった感じだ。
人も技術も古くなっても終身雇用で人を変えることもままならないというのは、不良債権に限らず、経済的な問題が社会全体で発生した時に、取り戻すのに時間がかかる要因になっているのだなと感じるなどする。

日本型の終身雇用でうまくいくためには、継続的な新卒採用とセットであるが、それも止まった期間があるので、知識や文化の継承もままならず、取り戻すのにあと２０年くらいかかるのではないかと危惧する。


https://www.amazon.co.jp/dp/4492654852/ref=cm_sw_r_tw_dp_U_x_EAihEbY7QR38B

今昔百鬼拾遺 鬼/河童/天狗

京極夏彦の本にしては薄いです。

内容は面白いですが、３巻とも同じパターンとも言えます。

呉美由紀が主人公の物語である。短いせいか内容は他の京極夏彦の本に比べると薄いように感じる。

あの厚さにも意味があるのかなとか思ったりもする。

出版社が３冊とも違うので、企画物。という印象である。

日本人とは何か。上巻/下巻

日本人の成立について追いかけていくことで、現代の日本人がはるか昔から地続きであるということが分かる本。
ある日突然、日本人が近代化に目覚めたわけではないし、高度経済成長をしたわけではなかった。それには、それ以前の日本の状況などがあり、それがその後の変化に続いているというのがわかる。
かなの成立や仏教の伝来(というか変質して独自化)などに触れながら、武家社会の記述に移行していく。
武家社会では下剋上、押し込み、エコノミックアニマルの成立などを追いかけていくことで上巻が終わる。正直、上巻だけでも読む価値はあると思う。
下巻では江戸時代から明治維新に向けて語られていく。
作者の個人的なエピソードと共に語られていくので、読みやすくもなっていて良い。
最後の方で言われることだが、指導者が成し遂げたことは、先駆者によってすでに始められている。という点だ。すでにいる先駆者と分野は何であるかとか考えてしまう。

またいつか読み返して、章ごとにまとめても良いかなと思う。

日本人とは何か。（上巻）神話の世界から近代まで、その行動原理を探る (ＰＨＰ文庫)   山本 七平 https://www.amazon.co.jp/dp/B00FFRZ814/ref=cm_sw_r_tw_dp_U_x_sHbxDbQAX46K1

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

いろいろいいことが書かれている。
章ごとに良い上司悪い上司を上げるなどして対比でわかりやすく解説してくれるので良い。
そんなにたくさんの章があるわけではないので章ごとにまとめていく。

マネジメントの基本

1on1は、多少は私生活に触れること、また、検討事項を定期的に議論すること。定期報告ならメールとかでもよいかも。
フィードバックを求めよう。また、アドバイスを求めるのはおだての効果もあるので聞くのは悪いことではない。
上司は、トレーニングや社内の人を紹介する必要がある。

メンタリング

傾聴するのは当たり前。明確に何を期待しているのか？何を成果としてだしてほしいのか？を伝達する。
人脈づくりの一環でもある。
アルファギークがメンターや上司になると最悪。アルファギークは、簡単にいうと自分が一番頭がよくて他はみんなおろかで、愚か者は公然と侮辱しても許されると思っている人。実際にいるので、人の管理などにはかかわらせないことが大事。
メンターをつけるのであれば、その目的とゴールを明確にしよう。

テックリード

テックリードは、会社によっても違うけどEMみたいな感じもある。ただ、人の管理はしない可能性もある。
テックリードに求められるものは、各メンバーとの1on1、各メンバーのキャリアアップや作業状況のsyncと改善を行う、各メンバーの能力開発に協力する、である。
テックリードは、システムアーキテクト、ビジネスアナリスト、プロジェクトマネージャーなどの役割も担うことがある。
プロジェクトの管理の簡単なコツは
・複数の工程に分割すること
・細部への引っ掛かりや道の要素にくじけない。
・プロジェクトは調整しながら進める
・変化に対応する
・プロジェクトの終盤では最後の詰めをする(premortemとか)
プロセスは、チームのニーズや目的を満たさなければならないという前提をきちんと理解する必要がある。
プロセス警察みたいなことはしてはならない。

人の管理

信頼関係や親近感を構築するために1on1は行おう。

新しい部下には1ヶ月、２ヶ月、３ヶ月の計画を建てさせる。

オンボーディングのドキュメントはきちんと整備して新人に更新してもらう。

1on1では、ドキュメントできちんと記録をとろう。

部下から、話し合いたいtopicを上げてもらう。

四半期ごとにフィードバックを行おう。

管理職どうしなら、経過報告もあり。

管理職を育てるのであれば、

・自分が出たほうがよいMTGを新人管理職と相談して決める。

・詳細を報告してもらったほうが良さそうなものを一緒に決めて進めていく。

実践としては

・成功とは何かを定義して、そのための数値の収集方法を提示してもらう。一緒に作る。

・システムから情報を収集する。

・プロジェクトの状況に合わせて収集すべき情報を修正していく

・基準を設ける。修正後に単体テストをどの程度加えるべきか。など。

情報は常にオープンにするほうが良い。

継続的なフィードバックが当たり前になるように継続し続ける。

フィードバックの内容自体は、

・１年全体に目を向ける。

・具体例を上げる

・長所も上げる

・改善点は簡潔に記述する

・決して驚かせてはいけない。定期的なフィードバックを行いながらいきなり悪い評価に驚くようなことはしてはいけない。

ローパフォーマーがいる場合は、改善計画を立てる。

何がダメで、どうなったら良いのか？いつまでそれを行うべきなのか？それを明確にして短い期間でのフィードっバックを行う。その際に、人事などにも入ってもらうのが良い。

チームの管理

ITスキルの維持には気を使おう。

人間関係の問題は早めに手を打とう。様子を見ても大抵は改善はしない。

過労には気を使う。ある程度期間が過ぎたら継続性を重視する

息抜きも大事なので飲み会や雑談は行うようにしよう。

チームが意思決定をできるように支援するには？

・データ重視にする

・顧客とは誰で何を求めているのかを明確にする

・将来のことも考えておく。

・意思決定の振り返りを行う。

・選択肢を提示して、意見や情報などのフィードバックを求める

問題行動のあるメンバーには早めに対処する。

何が問題かを明確にして、あまりに無礼であれば全体の前で批判することの重要になる。

その場合は、上司に相談するか人事に相談する必要があるだろう。

複数チームの管理

時間管理と優先順位付けはきちんとしなければいけない。

重要でない緊急の仕事に惑わされてはいけない。

頻繁な仕事は基本的に難しくても簡単でも移譲したほうが良い。

なぜならボトルネックになるから、難しい仕事はフォローしながらも任せることが重要。

頻繁でない複雑な仕事の代表は、勤務評価や人材募集計画だ。それは移譲していった方がよい。

なにか許可を求めてきた場合に、何回も同じことを言っていたら、ポリシーを決めるときが来たと思うべき。

チームの健全性は数値でみる。deploy頻度、インシデントの発生頻度、コードの生成量など。

チームのアイデンティティに、メンバーの得意なものを求めない。求めるとイングループが生まれる。

良いチームは

・リーダーがいなくなっても立ち直れる

・目標を駆動条件にする

・直属の部下ではなく、自分と同じレイヤーの人がチームであると認識する

複数管理者の管理

・スキップレベルミーティング

現状のプロジェクトの状態を現場から知ることと、うまく言っていない上司がいるのかを見極めることにもなる。

・責任を課する

どんな責任があるのか、何を明確に伝える必要があるのかを明確にする。上司が喜ぶことだけを言う人は実際にいるので、その人から情報が吸い上げられるようにしよう。

問題のある管理者がいた場合、その人の苦手な部分を手助けしてくれるような人をサポートでつけるのもありだ。例えば、プロジェクトマネージャーとか。

率直に言って、経営幹部の章と文化の構築については概念的な話が多いように思う。

だが、キャリアラダーをどのように作るのかなどは参考になるし、自分が管理職になってキャリアラダーに明確さがなくてみんなが困っているかもしれないと感じたら、参考にして作成するのが良い気がしている。

確証のチェック項目があるので、それをチェックするだけでも価値はありそう。

• マネジメントの基本
• できる上司のどのような行動や業績を素晴らしいとおもったか
• 1on1が現状確認になっているなら他の手段があるか
• 私生活の一大事を上司に話せるか
• 上司からフィードバックがあるか。フィードバックを与えられているか
• 目標設定で手助けをしてくれたか。手助けを出来たか。
• メンタリング
• インターンのメンターを希望しますか
• 新人研修のアプローチはどのようなものですか
• 新人のメンターを受けたいと上司に提案したいですか
• そばらしいメンターがいたとしたら、どんなところが素晴らしかったですか
• 成果が上がらなかったケースがあったら、それを今なら同会ゼインしますか
• テックリード
• テックリードがいるならば、Job descriptionは明確にありますか
• プログラム以外の仕事もしなければ行けないし、コードは熟知していなければなりませんが、そのような人ですか
• テックリードの期待値を上司とすりあわせているか
• 最高のテックリードを見たことがあるなら、どんな行動でしたか
• 不満があるテクリードがいるとしたら、どんな行動に不満でしたか
• 人の管理
• 定期的な1on1を計画していますか
• 前回のキャリアアップについての内容をもう一度持ち出すことができる状態にしていますか
• フィードバックを与えていますか
• 最後にみんなの前で誰かを褒めたのはいつですか
• 問題行動のあるメンバーにフィードバックをしたのは、問題行動からどのくらい時間が立ってからですか
• 問題行動のフィードバックは、個人的にでしたか
• 無駄な勤務評価が合ったとしたら、それをどうすれば改善できましたか
• 一番有益だったフィードバックはなんですか
• 昇進の手続きは公開されていますか
• チームの管理
• チーム管理者の責務とは
• チーム管理のために他の人に譲った作業はなにか
• チームがデプロイやサポートで日々直面している課題はなにか
• 作業完了の報告頻度は
• 最後にコードの変更を行ったのはいつか
• 問題行動を起こすメンバーがいた場合の対処方法はみえているか
• 仕事以外の話をメンバーで最後にしたのはいつか
• 意思決定のルールはあるか
• 管理者が下す意思決定に基準はあるか、それはどんなものか
• プロジェクトの振り返りをして目標との差分をかくにんしたのはいつか
• チームが担当しているプロジェクトをチームが持っているべき理由はあるか
• プロジェクトで削ったことがあるならば、何で判断基準はなにか
• 複数チームの管理
• 最後にスケジュールの見直しをしたのはいつか
• 過去３週間のスケジュールと今後３週間のスケジュールで、何を成し遂げて何を成し遂げたいか
• 就業後にまでコードをかいているならばその理由は
• 最後に移譲した仕事はなにか、複雑か単純か、いまはその作業は問題なくじっしされているか
• 有望な管理者がいるなら、その人の昇進のためのコーチングはなにをしているか
• プロジェクトのルーティーンはスムーズか、最後に大きい問題が発生したのはいつか、その時のチームの対処方法はなにか
• プロジェクトの範囲を削る命令をしたのはいつで、なにか。スコープか品質か
• 週末にメールしたか、それは返信が必要なものだったか
• 複数管理者の管理
• 自分に届く情報を受動的ではなく積極的に取るためにどのような手段をとっているか、それにどの程度時間をさいているか
• 各管理者に期待していることはなにか、どんな責任をおっているか、その管理者の評価結果をどう評価しているか、彼らに必須の成功の条件とはなにか
• 上の期待値と会社のJob descriptionに差分はあるか
• 各管理者において研鑽が必要な項目はどこか、底に対するフィードバックの時間をとっているか
• 自分がよく知らない分野の進捗や成功具合を聞いている頻度はどれくらいか
• 自分がよく知らない分野で外せないポイントや成功の条件について担当管理者からレクチャーしてもらったか
• スムーズなチームがあるならば、そのチームの他との違いは何か、どんな連絡方法をとっているのか
• 管理者候補の面接では、哲学を聞いているか、メンバーと面談させているか、身元照会は行っているか
• この四半期の目標はなにか、技術的な目標とどうすり合わせているか
• 経営幹部
• コーチングは社外のプロになる可能性が高い。自腹でもやる価値はある。
• 社外に経営者仲間はいるか、ネットワークを持っているか
• 尊敬する技術幹部がいるなら、どんなところか
• 優先順位を変えた場合に、どうやって進めたか、その時の反応はどうだったか、いまならどうすすめるか
• 会社が目指す方向を把握しているか、その時の技術的な戦略はなにか
• 会社の近い将来の目標を達成するために各チームが当てるべき焦点はどこか、開発速度、人材採用、技術革新
• 首脳陣は、自分の優先順位をどの程度理解しているか
• チームに、自分がどの首脳陣と仲がよくて、どの首脳陣と仲が悪いか、わかるか聞いてみる。どう見えているか
• 自分がロールモデルとなっているか
• 業務で定期的に顔を合わせない部下に話しかけたのはいつか
• シニアエンジニアに守って欲しい基本原則はなにか
• 文化の構築
• 会社や部署のポリシーはなにか、文書はあるか、最後の更新はいつか
• 企業理念は、各チームでどのように体現されているか
• キャリアラダーは定義されているか
• キャリアラダーは、現在の反映か、将来の理想か
• 重大なリスクはなにか、メンバーに不必要なプロセスを押し付けることなくリスクを避けられるか

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド   Camille Fournier https://www.amazon.co.jp/dp/4873118484/ref=cm_sw_r_tw_dp_U_x_YxsqDb7BTVJ09