ブログを引っ越しました
2020年4月26日 コメントを残す
84zume worksですが、新サイトへ移動しました。
こちらが新サイトです。よろしくおねがいします。
2020年4月16日 コメントを残す
新型コロナウイルスの感染予防に伴い、長女の幼稚園もしばらくお休みになっています。ずっと家にいるものだから、健康維持を目的として、子供と近所を散歩をする機会が多くなりました。しかも季節は春。植物は芽吹き、花が咲き、小鳥なども多くみられますね。
ふと、道端に際している花や、草を見て、これは何て名前なんだろうと思うことがしばしばあると思います。「この紫色の花、キレイだね」と会話するだけでなく、「ツルニチニチソウもいっぱい花が咲きだしたね~」とお話しできるほうが、なんだかリッチな気がします。「小さい鳥たくさんいるね~」より、「ムクドリ、今日は何を食べているのかな~?」みたいな。
そんなときに便利なのが、Googleが出している、Googleレンズアプリ。アプリをかざして検索ボタンを押せば、画像検索をしてくれます。右のイメージです。今朝撮ったものです。Googleレンズアプリで、キレイに対象を捉えることができれば、かなり良い精度で名前を見つけ出してくれます。
小動物はカメラで捉えることさえできればいけるのですが、やはり難しいですね。とおい。近寄るのが大変で、さきほどのムクドリはかなり苦労しました^^;
そのほかにも便利な使い方として、紙の書籍を読むと出てくる難読な漢字(熟語)の読み方を調べるといったことも可能です。いままで読み飛ばすことが多かった難読字を、Googleレンズのおかげでちゃんと調べるようになりました。
最後は読書の話でしたが、散歩のお供にもぜひご利用ください^^
参考:Googleレンズ(https://lens.google.com/intl/ja/)
2020年4月12日 コメントを残す
締切の日曜日がやってきました。第12回のデッドライン読書会(デッドライン読書会とは?)の課題図書は、「みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」」でした。
界隈では「IT業界のサグラダ・ファミリア」と呼ばれたり、日本の全IT人材の1割が関わっていると言われた巨大プロジェクト(みずほ銀行システム統合)の記録です。2部と3部では、それ以前の大規模障害の記録が書かれています。実は「闘うプログラマー(過去に書いた感想はこちら→【読書メモ】闘うプログラマー)」のように、現場の人に着目した本を期待していたのですが、そうではなく管理者や経営者のレイヤからみたお話でした。
そういった上位の話が多い中でも、「メイト」と呼ばれたチェンジマネジメント組織の活動は現場の方々が主人公として書かれており、とても臨場感がありました。メイトは、新勘定系MINORIを用いた新業務を、各営業店にむけて研修や教育などを行う事務サポートメンバーの方々の通称です。メイトは合計170名いたとのこと。驚いたことに自ら立候補した方が40名もいたらしい。新勘定系が定着したあとは、次世代店舗の開発など新しい領域で活躍する方もいらっしゃるそうです。システムの業務定着化を組織的にしっかりフォローできているのは、さすが銀行のシステム開発だなと感じます。
もっと明確に知りたかったのは、この巨大プロジェクトの進捗管理はどうやって行われたいたのかというところです。請負構造のピラミッドが3次、4次と深いため、トップマネジメントが参加する進捗会でどの断面の進捗を報告することができたのだろうかと興味がありました。進捗管理ツールを関係社全部で共通化できていればやりようがあるでしょう。そうでない場合、それぞれのレイヤで報告書を作り、上へ上へと報告するといったことが行われていたんですかね。
銀行の勘定系についての概要を知りたい場合にも本書は良いと思います。
こういったことが他書と比べ、多く学べると思います。
スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。
2020年3月17日 コメントを残す
出口治明さんの著書「哲学と宗教全史」を読み終わりました。とても刺激を受けました。知的好奇心も満たされました。今後の勉強のためにも、読書メモを残します。
本書のスタートは人間が言葉を獲得した時代です。20万年前にさかのぼります。人間は、言葉を獲得し、定住化し、ドメスティケーションを経て、宗教という概念を生み出しました。世界宗教としてゾロアスター教を最初のテーマにあげています。一方で、鉄製の農機具の登場と温暖化から、農作物の生産力が向上したことをきっかけに、有産階級が生まれ知識人が登場しました。これが哲学のスタートです。その後、哲学と宗教が互いに関連しながら進歩し、大陸の東と西を行き来し、ダイナミックに話が進みます。
このあっちに行ったりこっちに行ったりの繋がりを本書は地図のように整理しています。巻頭・巻末には肖像画と一言メッセージがついたチャートがあり、迷子にならずに読み進めることができます。長くて複雑な歴史を、わずか400頁強にまとめ切ったことが本書のすごい点です。なお、バックグラウンドとなる参考書籍は数百冊に及ぶ書籍が列挙されており、圧巻です。
これまでを振り返ると、「哲学」は簡単な解説本を数冊読んだことがあります。今もちょっとずつソフィーの世界を読んでいます。「宗教」は、普段の生活での関わりもありますし、小説調の本(例えば、旧約聖書を知っていますか)を読んだことがあります。両方とも体系だった知識を持つほど勉強してはいません。
ただ最近急激に興味をかきたてる対象になりました。「宗教」でいうと、神社仏閣巡りは普段観光の一貫でしますし、ビジネスの世界ではマインドフルネスやコンパッションといった「宗教」の考え方(もしくは心理学かもしれませんが、その源流はやはり宗教や哲学でしょう)をベースにした取り組みが流行っています。こういった流行りものは好きですが、その土台をちゃんと知っておきたいと常々思っています。「哲学」は、人間の思考のみで(自然科学より先に)世界に道標を作った人たちがどんな人だったのか。どういう考え方の営みが今の世の中を作っているのか、とても興味がありました。
今の世の仕組みの多くは、宗教としての成果、哲学としての成果の結実なのだなと本書を読み終わって感じました。いまある科学技術や考え方や行動原理は葉や花にあたる部分であり、過去ずっと営まれてきた哲学や宗教が枝や幹を作ってくれたんだと気づきました。
本文中でも解説がありますが、これらの歴史が幹になるために統合と分離を繰り返して進化しているというのが面白かったです。よく名前を聞く偉人は、「統合」をした人が多いように感じましたね。本書は通史として、哲学と宗教を見ているため、関連性が良く分かるところが楽しいです。トマス・アクィナスが、
哲学は神学の端女である
と神学の真理と、哲学の真理に上下関係を付けてみたり。フリードリヒ・ニーチェが、
神は死んだ
と言い切ってみたり。それぞれがどう進歩していったのかがよく理解することができます。
本書の中心は、タイトル通り、哲学と宗教です。ただし、前述した幹となる部分はこの2つ以外にもあるんだろうな。
人間の問いに答えてきたのは、昔は宗教がほとんどでした。それから哲学が台頭してきて、やがて自然科学が生まれ、生物としての人間についてほとんどすべてを説明できるようになりました。それでもまだ自然科学は万能ではなさそうです。哲学や宗教は、今、そのよう地平に到達しています。
P.17 はじめに|なぜ、今、哲学と宗教なのか?
「はじめに」では自然科学があげられていました。本書で深く踏み込んでいないため、自然科学が、宗教や哲学とともに歩んできた歴史も通史で知りたくなりました(小説だとダン・ブラウンのテーマですね)。似た観点ですと、やや宗教よりで、芸術分野もどう影響してきたかは気になります。あとは数学も幹の部分を担ったのでしょうか。少し学問寄りに考えてしまいましたが、他にも全く関係ないところに幹となる知恵があるのかもしれません。
本書は登場人物全員について出口さんのおすすめの参考文献が記載されています。本書をガイドとして、自分の琴線に触れた人物をさらに知ることもできます。自分はデカルトの方法序説から広げてみたいな、と思っています。
加えて、日本人の登場人物が少ないため、日本人の哲学家についても著書を読んでみたいです。誰がおすすめだろう。鈴木大拙とか?もうちょっと調べてみようかな。
2020年3月15日 コメントを残す
先日のポスト:読書について 2020で、読書をする際に複数の書籍を併読することを始めたと書きました。2週間ほど実践して安定してきました。感想を残そうと思います。振り返りです。
もともと併読を始めようと思ったわけではありません。読書のスピードをあげて、本をたくさん読めるようになりたかったわけです。そのため速読法をいくつか調べました。速読法は「練習が必要」、「1冊を特殊な読み方をする」などハードルがあり、手に取る気持ちが沸きませんでした。加えて、読書スピードが上がらない理由は、集中力が切れることや、気分が乗ってこないため習慣が途中で切れることが、原因だと思い始めました。
そのタイミングで読んだ本が、HONZ代表の成毛さんの「本は10冊同時に読め!―本を読まない人はサルである!生き方に差がつく「超並列」読書術」です。本書で併読を勧めています。(なお、併読だけでなく読書に関する成毛さんの考え方がたくさん載っているため、タイトル以上に学びが多い本でした。)この本で言う併読とは、
ここから自分ならできる併読法をスタートしました。
この結果、読むスピードは不満にならない程度になったと思います。少し手が止まる本も、別の本に切り替えることで前へ前へ進みますからね。
複数併読することによって、いろんなアイデアがまざるか?という点については道半ばです。アイデアを混ぜるためにはなるべくバラバラとなる選書をする必要があり、それが上手くいっていないです。併読のスキルと言うよりか、選書のセンスをあげなくてはいけないです。上にあげた本にもう1冊全然触れたことがないようなカテゴリを入れられたら良いなと思っています。
総じて効果はありそうです。次の悩みは選書のセンスですね。選書のセンスを解決するには、
といったところからスタートでしょうか。
2020年3月15日 コメントを残す
第11回のデッドライン読書会(デッドライン読書会とは?→読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「Design It! ―プログラマーのためのアーキテクティング入門」の後半戦です。前半戦の感想はこちらになります→デッドライン読書会#10「Design It!」(前半)の感想文。今回は、本書の後半部分(227ページ〜最後、第3部)が範囲です。
第3部はプラクティス集です。チームとしてのアーキテクト力を発揮するために有効な技法をまとめています。「理解」、「探求」、「評価」、「作成」で分類されています。紹介されている多くのプラクティスがチームとして実施することを前提としており、ワークショップ形式の活動が多いです。他書でも詳しい「インセプションデッキの作成」や、ワールドカフェ(のようなもの)もありました。辞書的に利用できるのがこの第3部です。
個別に気になったところを抜き出します。
アーキテクチャ俳句は、アーキテクチャのビューを一枚の紙に収まるように記述する。
アクティビティ21 アーキテクチャ俳句 P.305
前半戦から「俳句」とはどういった形式化を期待していましたが、五・七・五ではないんですね^^; George Fairbanksさんのスライドがあったので転載します。
サニティチェックは、コミュニケーションや理解に関するチームの問題を明らかするように設計された、手短でかんたんなエクササイズだ。
アクティビティ36 サニティチェック P.347
ちょっとしたクイズを作って出し、チームのアーキテクチャに対する責任を促すワークショップです。通常は5〜10分程度。日々のアイスブレイクに使い、こつこつアーキテクチャ能力を高める(アーキテクチャへの理解を深める)のに有用そうですね。
こつこつ開催しているデッドライン読書会は、次回は第12回になります。スケジュールはGoogleカレンダーで分かるようにしています。本日以降は以下の予定です。
2020年3月8日 1件のコメント
石沢ケントさんが、勘と経験と読経:読書について 2020で、ご自身の読書の定点観測をされていました。
これに加えて、最近、いくつかの読書法に触れる機会があったり、読書のために工夫していることががあるため、まとめてみようと思います。
年間に50〜60冊(1万〜1.5万ページ)の本を読みます。1時間あたり50ページくらいでしょうか。脳内音読をするため、読むスピードは早くありません。もっとたくさん読みたいな〜というのが悩みで、早く読めるように楽読などの速読法が気になっています。まだ一歩踏み出すところまではいっていません。
本を1冊読む、読み方については工夫はありません。純粋に頭からお尻まで、順番に読みます。
個人で読む以外に、共同で本を読む方法論も好きです。読書体験を共有できることが楽しいわけです。
特にAcitive Book Dialogueは自分の読書体験を揺るがす画期的な方法だと感じました。
これまではほとんどシリアルで1冊だけを読んでいましたが、最近は並列で読書することに挑戦中です。いっけん関係が薄い複数の本を並列で読むことにより、新しいアイデアの組み合わせが起きたら良いなと考えています。今日現在だと4冊並列しています。
めざせ10冊並列です。
8割がた、物理書籍です。パラパラとページをめくる感覚がまだ必要です。それと、最近思い始めたのは、良書を集めて、家に置いておき、将来的に子どもが手にとって読んでくれないかな〜という点です。装丁がきれいな本も好きですね。で、キレイに本を置いておきたいので、本棚を自分で作るようになりました。「清く正しい本棚の作り方」を参考にしています。
残りは電子書籍。森博嗣さんの小説、Kindle Unlimitedで読める本・雑誌が電子書籍が多いです。
電子書籍より、物理書籍を選ぶのは、難しそうな本を読もうとすると、終わりが見えず、なかなか我慢できないというのも理由の一つです^^;
次の割合で本を選びます。
ブックカバーをつける、紙の付箋を用意する。
気になったところがあれば、マーカーをひく、付箋を貼る。
一言感想を読書メーターに残します。特に気に入った本や、感想がある本は、このブログに【読書メモ】として記録を残しています。
読んだ本を定量的にまとめる癖がありまして、Googleスプレッドにその記録を残しています。記録し、グラフを作り、継続的に本を読むように自分に促しています。
楽天koboを読むときは、kobo gloか、スマホアプリ。Kindleを読むときは、Fire HD8か、スマホアプリを使います。そろそろ電子書籍リーダーを新調したいのですが、最近は値段が高いから萎えますね・・・
ブックカバーは、良いのを見つけるとつい買ってしまいます。
どこまで読んだか覚えておくために、LastLineというブックマークがお気に入りです。文房具屋で見つけたときは買いだめします。
椅子に座って、お茶飲みながら本を読むときは、この書見台が愛用品。EDISONのほんたった。
さきの「どこから手に入れるのか?」で図書館を利用することを書きましたが、それようにツールを作ってます。カーリルのAPIと連携し、お気に入りの図書館に読みたい本の在庫があるか?貸出可能か?また、古本で買うといくらなのか?を毎朝調べてくれるツールをGoogle App Scriptで作りました。ツールが調べた結果を毎朝スマホのTodoアプリに連携してくれます。ふと図書館の近くに立ち寄ったときに、「いま借りられる本」が分かるようにしているわけです。
リビングテーブルで読むことが多いです。お出かけのお供に、文庫本や電子書籍をかばんの中に携えています。
図鑑や、地図が好きなので、たまに買ってしまう。こういうの(世界をまどわせた地図 伝説と誤解が生んだ冒険の物語)や、
こういう(マップス 愛蔵版 新・世界図絵)の。
小さい子どもがいるため、読む本の冊数という点からは、絵本が圧倒的に多いです。
出口治明さんが「教養は児童書で学べ」という本も書いておられますが、絵本も「書籍のカテゴリのうちの一つ」なんだということが最近理解できてきました。絵本は子どもだけのための本ではない。一冊で一つの考え(課題)を与えてくれるといった絵本が、たくさんあると思います。
読書は一人になれる時間です。好奇心をかきたてる手段です。自分の長期記憶に入っている何かと、本を通して新しく知った何かが、結びつく経験を、手軽に、おうちでできるのが読書です。
別の視点だと、同じ本を読んだ人とは文脈を共有できるので、いろいろコミュニケーションが楽になるなぁと感じています。これは他のメディア(映画や音楽)でももちろん同じだと思いますが、私にとってはそれが読書というわけです。
2020年2月23日 1件のコメント
第10回のデッドライン読書会(デッドライン読書会とは?→読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「Design It! ―プログラマーのためのアーキテクティング入門」です。オライリー社から、2019年11月に翻訳・出版されました。今回は、本書の前半部分(最初〜226ページ、第1部と第2部)が範囲です。
訳者の島田 浩二さんが本書を紹介するブログのポストがありましたので、そちらのリンクも掲載します→https://snoozer05.hatenablog.jp/entry/2019/11/16/181626
今回のアウトプットもこれまでと同様に、最初に「全体」の感想を書いて、続いて気になった部分を「個別」として、引用にてコメントするスタイルで行きます。
今回の読書会の範囲は、
でした。
本書は、「チームのアーキテクト能力を高める」ことを重要視していることが特徴的なテーマだと思います。アーキテクトのロールを持つ個人がその能力を高めるためだけに本書を読むと言うよりは、チームメンバーが持つ設計力のレベルを上げるにはどういったアプローチがあるかも整理しています。序文で、George Fairbanksさんが「本書は(略)アジャイルとアーキテクチャをうまく融合させている」と言っていますし、本書原著の副題が「From Programmer To Software Architect(プログラマーからソフトウェアアーキテクトへの道)」でもある通り、「チーム」というのがキーワードであると感じました。
もう一つの特徴は設計の進め方として、デザイン思考の考え方をベースにしている点です。デザイン思考の4つの原則:
1. 人間性の規則(The human rule)
――すべてのデザイン活動は究極的には社会的な性質を持つ。2. 曖昧性の規則(The ambiguity rule)
――デザイン思考者は曖昧性を保全せねばならない。3. 再デザインの規則(The re-design rule)
――全てのデザインは再デザインである。4. 触感性の規則(The tangibility rule)
https://ja.wikipedia.org/wiki/デザイン思考#デザイン思考の性質
――手で触れられるアイデアを作ることは常にコミュニケーションを促進する。
特に4番目のTangibiriltyを言及することが多かったです。アーキテクチャは設計の中でも、解像度(概要と詳細)を変え、ビューポイントを変え、(システムに対する)理解を深めていく特徴があるため、その意図を関係者が理解できるように、様々な形で触れられるようにすべきというわけです。例えば、「線と箱を使いモデルをホワイトボードにスケッチ」することや、「プロトタイプのアプリやコードを作成しデモ」することなど。また、品質特性にフィットできるアーキテクチャかどうかを早めに検証するために、多様な触覚性が求められると思います。ちなみに本書ではその一例を、後半第3部16章に「設計をタンジブルにするアクティビティ」という章で深堀しているようです。後半戦に期待します。
この個別部分では、気になった文章を引用して理解を深めようと思います。
優れたソフトウェア開発チームは機能を素早くリリースするために技術的負債を戦略的に利用する。
1.1 ソフトウェアアーキテクトが行うこと(P.7)
文字通り正しく負債を使うべしというところ。お金の増減をなだらかにすることを目的として負債を利用するように、チームの負荷やパフォーマンスを最適化する目的で技術的負債を利用しなくてはいけない。ただ惰性で借金はしてはいけない。
すべての優れたアーキテクチャは、変化の必然性に責任を持つ。
6.5 変化に向けて設計する(P.95)
身にしみます。そして、次節にて、拘束力のある判断はなるべく遅らせるというとことがポイントとなっていますね。
私たちが選ぶ名前は、設計しているものをどれだけ理解しているかを反映している。理解が深まるにつれ、概念に付ける名前も変わる。
8.2.4 良い名前を使う(P.126)
ここでは、Arlo Belsheeさんの「7 Stages of Naming(名前づけの7段階)」が紹介されていました。Twitterで原典を発見したので下記に引用します。
チームがアーキテクチャを自分たちのものにするには、(略)必要な知識とスキルを、チームへ注ぎ込もう。これがうまくいっているとき、アーキテクトは設計判断をすべて下す権威あるリーダーというよりも、コーチやメンターのように見える。
13.2 意思決定を促し、スキルの成長を促進する(P.215)
どうも「アーキテクト」とは孤高の人というイメージがありますが(なんでだろう…)、本書のイメージは上記引用の通り。
スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。
2020年2月18日 コメントを残す
先月の2020年1月にコネヒト株式会社(「ママリ」というママ向けアプリを提供している企業)の調査に基づいて、男性育休時の家事・育児時間に関する記事が出てちょっとバズっていましたね。下記のリンクは日経新聞オンラインのものですが、「とるだけ育休」が蔓延してそうだという記事が散見されました。
日経新聞「育休夫の協力不十分 民間調査、3人に1人が2時間以下」
もとになったプレスリリースは、こちらです。
PRTIMES「夫が育休を取得した508名のママ調査から見えた「とるだけ育休」の実態と育休の「7つの法則」ー男性育休義務化の流れの中、「育休の質」に焦点ー」
男性育休の取得時間が短いというくだりももちろんありますが、主題は育休活用のカギとして、「育休の過ごし方7つの法則」と育休準備のポイントがある、これらを学び、育休を通して、夫婦(家族)の幸福度を向上していこうという素敵な内容でした。すばらしい。この7つの法則ですが、自分に当てはめるとどうなのかな?と思い、メモがてらコメントを書いてみます。
7つの法則はこちらでした。
我が家は一人目に引き続き今回の二人目も完全母乳。母乳関連のトラブルが多く起きることを見込み、二人目の出産・育児にのぞみました。取っ掛かりの方針として、授乳以外は基本的に夫の役割です。そうなると、「量的に担当する」、「主体的な姿勢で取り組む」、「休息をとらせる」、「必要なスキルを習得する」、「精神的に支える」は満たせていると思います。とはいっても苦手な家事はあるわけで、唯一、家を隅々までキレイにしてって言われると、、、私にはちょっとできません^^;(最初から「諦めて」とお願いしています)
「精神的に支える」で私が大事かなと思っていることの一つが、家族が病気したときに備えられているか、です。急病になったときに行く病院、電話する場所(子ども医療電話相談、など)を知っている。夜間に車を出せるように備えられている(家族の体調が怪しいなと思ったときにお酒飲まない)。などなど。
「十分な期間取得する」。今回取得しているお休みは、当初は有給休暇、途中から育児休業で、出産2週間前から出産後8ヶ月めまでをお休みとしています。
この期間に対する想いとしては2つありました。「出産2週間前」は、私が専業主夫モードに慣れるための準備期間です。普段あまり担当していない長女の幼稚園関係の準備になれることや、出産と産後の準備にあてました。出産直後1ヶ月は妻は基本的には動けないため、いきなり主夫をスタートするのではなく、暖機運転をして出産を迎える形としました。これは成功でした。
一方おわりを生後8ヶ月目までにしたのは、生後6ヶ月目から始める離乳食を軌道にのせようというところです。長女の経験からだいたい2ヶ月あれば大丈夫かなと考えています。出産後の育児が大変になる山場は、出産前後、離乳食開始時、卒乳時だと思うので、そこは意識していきたいです。卒乳時は、いまの育休は終わっているので、別にお休みをとることも考えています。
「家族との時間を楽しむ」。以前のブログにも書きましたが、長女と過ごす時間が長くなりました。朝の時間、幼稚園帰りの時間、帰ってから夕食までの時間、お風呂を出てから寝るまでの時間。平日の夕方に縄跳びの練習や、自転車の練習に付き合うことができています。その裏(?)で、妻はストレス解消にお菓子作りをしてて、帰ったらおやつが出来ているというのはやはり幸せだと感じます。こういう余裕があり、その後の人生を豊かにしてくれるきっかけのひとつを与えてくれることも、育休の大事な役割なのかもしれません。
これが「育休の過ごし方7つの法則」へのコメントでした。この7つの法則は、主に妻と家族に目線が向いていると感じましたので、夫の目線でいくつか追加してみようと思います。
夫側には「3つのゆとり」をあげようと思います。(夫側と書きましたが、書いていて思うには、夫婦どちらにも当てはまりますね。あと私自身の境遇をベースに書いていますので、そこは予めご容赦ください。)
会社員から専業主夫となりますので、環境が一変します。産後当初は物理的にも精神的にもより狭い範囲に集中することになり、ストレスを感じるようになると思います(働いていないことによる「置いてけぼりになるんじゃないか?」といった不安感など)。そのストレスを溜め込まない方法を用意しておくのが大事だと思います。出産は計画出産でもない限り、急に来て、急に育休に入るという方もいると思います。その移行がなるべくなだらかになるように準備しておくのは肝要です。
これは特に出産直後〜1ヶ月くらいの間です。頻回で安定しない授乳の期間は、夫側も完璧を期そうとすると、朝も晩も動きっぱなし。それが原因で夫側が倒れてしまったという話もたまに聞きます。妻と上手く分担すること、夫婦の両親を頼ること、入院期間中は病院を頼ること。
あとは世の中にすでにある育児を簡単にする方法をちゃんと勉強しておくことも有用だと思います。調乳が大変なときに備えて、粉ミルクだけでなく液体ミルクを。着替えをさせるのがめんどくさいときに備えて、肌着が一体型のカバーオールを。買い物はAmazonを。料理は少なくとも上手に味噌汁が作れるようにしておく(味噌汁があれば食事はどうにかなる)。
育休中にに発生する無収入の期間にどう備えるかです。育児休業給付金は給付タイミングがイケていなく、申請後2〜3ヶ月後に最初の支給、その後2ヶ月ごとの支給となります。(愚痴ですが、給付金の上限を80%にするといった議論がありますが、それより支給頻度を上げて、働いているときの給料と同じタイミングにしてくれる方が嬉しい)。普段の貯蓄とは別に、生活の運転資金が安定するような手立てを事前にうっておけると安心です。
自分の過ごし方を整理するために、7つの法則をみてみました。ところで、最初の議論の、ではどれくらいの時間を育児・家事に費やしているかなと思い、だいたいで数えてみると、6時間くらいでした。もし下の子が完全母乳でなく調乳とミルクの授乳があるなら、これにもう1〜2時間くらい足されるんかなぁ。
以上です。
2020年2月7日 コメントを残す
「闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」を読みましたので、読書メモです。
「闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」は、Windows NTの開発記録です。Windows NTは、1993年7月にリリースされましたが、本書初版は原著・翻訳書ともに、1994年に出版されています。リリース間もなく、開発に携わった当事者にインタビューを行い、本書にまとめてあります。登場人物は50〜100名いるんではないでしょうか。ゼロからOSを開発するという巨大プロジェクトの生々しい姿が、とても細かい出来事から組み立て上げられており、苦しい開発を乗り越えた経験があるエンジニアだと、感傷に浸らずにはいられない書籍です。
1.5億ドル、4年間、延期に延期を重ねるリリース日、止まらない要望、潰したそばから爆発するように出るショーストッパー(原著のタイトル、危機的な不具合を指す)にまみれながら、最新で革命的なWindows NTを開発するストーリーです。キーパーソンは、マイクロソフトで伝説と言われるディビット・カトラー。この人の熱量と、信念の強さがとても響きました。
良し悪しがあるのは当たり前ですが、仕事への情熱の注ぎ方はすごいものを感じました。まさに闘うプログラマーです。でも、そんな、ブルドーザーみたいなカトラーだけでは、チームはうまくまとまらず、腹心のロウ・ペラゾーリがファシリテーションの能力を発揮し、チームをまとめていく。最後はデスマーチだったが、全員でスクラムをくんで突進し、リリースに漕ぎづけるという怒涛のストーリーでした。
いくつか、気になったセンテンスがあったので、抜粋します。
マイクロソフトでは、管理者もコードを書くのが原則だ。(略)ソフトウェア会社では、管理者はプログラマーの言いなりになりやすい。スケジュールは守られず、製品は失敗に終わり、予算は膨れ上がる。すべては、現代の魔術師たちがしていることを、トップの人間が理解できないからだ。(略)マイクロソフトでは、プログラマーが管理者だ。
第五章 熊の咆哮 P.145
カトラーが途中、全チェックインを監視する!と言い出したときはびびりました。
実際、カトラーはハリウッドの偉大な監督が持つ特徴をそなえている。スターや優秀な裏方に、自分の好みやビジョンを吹き込むことができる。ユーザーに媚びることを拒否して、自分のビジョンを守り抜く(略)監督としてだけではなく、俳優や裏方としても優れた能力をもっているため、現場に密着でき、最前線にたてる。
第七章 出荷モード P.204
「自分のビジョンを吹き込む」って素晴らしい能力。
次はユーザープロファイルとプログラム・マネージャーの開発を担当したキャロルの節。ここは手に汗握ったなぁ。
キャロルはあせっていた。バグに叱責されているように感じた。
(略)
バグはつぎつぎにみつかった。
(略)
バグはつぎつぎに処理できた。一週間後には、あと一歩で「ゼロバグ」を達成できそうになった。
(略)
この朝は気になっているものがあった。それを見つけて、キャロンはうなった。エスティ・ミンツからのメールが2通ある。(略)新しいバグが2つ。
(略)
最後のバグを始末した。やった。廊下に出て、手を上げて踊って歩いた。だれかれかまわず電話して、「ゼロ・バグ」を自慢した。
第十章 ショーストッパー P.350〜353
そういえば、本書の後半の中心は、ビルド・ラボ。ホワイトボードに書かれたチェックイン一覧をみながら、それを最新のビルドに組み込むか決める。そこにはカトラーも出張ってきて(出張ると言うか、自分の家だって言ってたかな・・・)、ビルドと自動テストの出来に一喜一憂。ここからドッグフーディング用のビルドが配信されるため、まさに最前線です。
この本が読みやすいかといえば、インタビューを集めてストーリー調にしてある、かつ、登場人物は出自から書かれてあり、けっこう読むのが大変でした。ただ、プロジェクト型の仕事をしたことある人や、ちょっと昔のWindowsを知っている人は、「こんなことにまみれながら、作られていったんだ!」と感動を得られると思います。読んでよかったです。
以上です。