デッドライン読書会#10「Design It!」(前半)の感想文

課題図書

第10回のデッドライン読書会(デッドライン読書会とは?→読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「Design It! ―プログラマーのためのアーキテクティング入門」です。オライリー社から、2019年11月に翻訳・出版されました。今回は、本書の前半部分(最初〜226ページ、第1部と第2部)が範囲です。

訳者の島田 浩二さんが本書を紹介するブログのポストがありましたので、そちらのリンクも掲載します→https://snoozer05.hatenablog.jp/entry/2019/11/16/181626

感想文

今回のアウトプットもこれまでと同様に、最初に「全体」の感想を書いて、続いて気になった部分を「個別」として、引用にてコメントするスタイルで行きます。

全体

今回の読書会の範囲は、

  • 第1部:ソフトウェアアーキテクチャ入門
  • 第2部:アーキテクチャ設計の基礎

でした。

本書は、「チームのアーキテクト能力を高める」ことを重要視していることが特徴的なテーマだと思います。アーキテクトのロールを持つ個人がその能力を高めるためだけに本書を読むと言うよりは、チームメンバーが持つ設計力のレベルを上げるにはどういったアプローチがあるかも整理しています。序文で、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)

どうも「アーキテクト」とは孤高の人というイメージがありますが(なんでだろう…)、本書のイメージは上記引用の通り。

次回(#11)

スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。

  • #11の候補書籍
    • Design It!(後半戦)
  • デッドライン
    • #10の感想交換1Week(2/24〜3/1)
    • インターバル(※今回は前半と後半の間のため、ありません
    • #11の読書する時間2Week(3/2~14)
    • #11のブログポスト期限(3/15)
    • #10の感想交換1Week(3/16〜22)

【読書メモ】闘うプログラマー

闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」を読みましたので、読書メモです。

本の紹介

闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」は、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を知っている人は、「こんなことにまみれながら、作られていったんだ!」と感動を得られると思います。読んでよかったです。

以上です。

【読書メモ】トム・ピーターズのサラリーマン大逆襲作戦① ブランド人になれ!

CCCメディアハウスが出版した「トム・ピーターズのサラリーマン大逆襲作戦① ブランド人になれ!」を読みましたので、その読書メモです。

本の紹介

トム・ピーターズのサラリーマン大逆襲作戦① ブランド人になれ!」は、翻訳書である本書の出版が、2000年です。原著の「The Brand You 50」は、1999年が出版でした。すでに20年前の本になるのですね。先輩からの紹介で手に取りました。

トム・ピーターズさんは、マッキンゼーのコンサル時代に、あの「7つのS」を開発した人としても有名な方です。ホームページはこちら→https://tompeters.com/

本書はタイトルに番号がついている通り、シリーズ(サラリーマン大逆襲作戦シリーズ)ものです。②が「セクシープロジェクトで差をつけろ!」、③が「知能販のプロになれ!」と続いています。

読書メモ

ブランド人とは、自分の人生・自分の仕事に、責任を持ち、「あいつらのせい」なんて言わずに、新しいミレニアム(ってもう20年たっちゃいましたが)を、(文字通り)生き抜いていく人をさしています。ブランド人になるために必要な、ものの考え方や、ノウハウ、気合いを50カテゴリあげています。50ある時点ですでに多いのですが、50それぞれに「やってみよう」という実践セッションがあり、読者ができる具体的なアクションが列挙されています。それをすべて足し合わせたら、200〜300くらいやることがあるなんとも熱い本です。ちなみに、200〜300のうちの1割は「前のページをもう一度読め!」とか「前の項目を口に出して10回読め!」みたいなものです。大事なことだから繰り返しましたってことですね^^

本書でとにかく何度も言われることを私の覚えで箇条書きにすると、

  • 自分は会社だ。「○○○○株式会社」(○は自分の名前)と思え。
  • まずはアクションしよう、それもいますぐに。実ることに時間は書かあるかもしれないけど、動き始めるのは今だ。21歳も51歳も関係ない。いま実行だ。
  • 仲間を増やそう。相棒を増やそう。朝食、ランチに誘うのだ。
  • ○○○の会を作ろう。みんなで議論するのだ。
    • 例えば、「ブランド人クラブ」、「時間に悩めるものを救う会」、「アイデンティティ勉強会」、などなど
  • つまらない仕事は、胸の高鳴るプロジェクトへ変えるチャンスだ。
  • 一点に集中しよう。

さきほど20年前の本だと書きましたが、書かれている内容はまったく色褪せないです。世の中は、むしろトム・ピーターズさんの予言通り「ブランド人」がどんどん増えている印象があります。所属する組織や団体以上に名前にブランドがある人たちです。ちょっと時代を感じさせるなと思える「名刺」についての教訓ですらも、「いまっぽくEightに突っ込んどけばよいか」と思っていた自分は、ちょっと反省する必要がありました。名刺は何度も見返し、そこから仲間を増やすのだと。

お正月に、今年一年の計ということで「やってみたいこと」を100個作りましたが、その中に「見識家の話を聞く」(賢い人の講演を聞きに行く、みたいなイメージです)といった項目がいくつかあります。この本を読んで、ただ話を聞きにいくのではなく、ランチにお誘いしてみるなど、次に繋がるようなアクションに変えてみたほうが面白そうと。失うものもないので、失礼に当たらないようにして・・・。

具体的なアクションに、勉強会や、セミナーに参加しましょうといのうがあって、そのなかに「トーストマスターズ」に顔を出してみなさいというのがありました。トーストマスターズというのを知らなかったため調べたところ、

トーストマスターズは話し方、パブリックスピーチ、リーダーシップを学ぶ国際的な非営利団体です。全世界143ヵ国にある16,600 以上のクラブから自分にあったクラブを選び、会員同士が相互に学び、スピーチとリーダーシップスキルを向上させることが目的です。

http://district76.org/ja/about/

いま自分に必要なやつだ。日本にも200クラブくらいあるとのことで、隣町にもクラブがありました。一度ゲスト扱いで参加させてもらおうかなぁ。

最後になりましたが、本訳の品質について。本書は洋書の翻訳書ですが、著書トム・ピーターズの気概や勢いもそのまま伝わってくるとても良い翻訳でした。後続のシリーズはもちろんのこと、(人となりも分かったような気がするので)「エクセレント・カンパニー」も読んでみたいと思いました。ただ、、本を読むより前に、本書のアクションをまずはやれっていうところなんでしょうが・・・がんばろう。

以上です。

デッドライン読書会#09「IT業界の病理学」の感想文

課題図書

第9回のデッドライン読書会(読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「IT業界の病理学」でした。2019年11月に発行された書籍です。今回は1回で全ページ分を読む回になります。

感想文

感想文です。全体を通して感じたこと、個別に気になった部分へのコメントをまとめます。

全体

感想の前に、本書の構成を説明します。

本書では、IT業界に存在する「病」を、研究して治療・予防することを目指して病理学とうたっています。各章が病名となっており、症例は合計34ありました。それらに対して、

  • 症状と影響
  • 原因・背景
  • 治療法
  • 予防法
  • 異説
  • 補足

という切り口で対処方法などをまとめています。

本書で取り上げられた「病」は私も見たことある(罹ったことがある!?)ものがあり、各章のタイトルだけ見ても「それね!」と思うものが多々ありました。例えば、

  • 「運用でカバー」依存症
  • プロジェクト管理無計画病
  • 再発防止につながらないトラブル解析

各章は著者らの現場での実体験に基づくものが多く、必ずしも読者の現場(や、その病)にはぴったり当てはまらないかもしれませんが、各章で上がった症例の着眼点や病理学の切り口が参考になり、自身で過去の苦い思い出を思い出しつつ、自分で分析するのが面白そうだなと感じました。

個別

本書で個別に気になった部分をまとめます。

キーワードは「歯を磨くように」です。

2-01 全部揃ってからレビュー P.55

なにかのレビューをするときにビッグバン的に全部揃ってからレビューをスタートするのではなく、気軽にカジュアルに小さな単位で進めましょうというメタファーです。この歯科治療のメタファーはちょっと面白いと思って、メモ。

■設計ドキュメントに記載されていない内容はテストされない(テストが漏れる)

■テスト担当者の大きな責任の1つは、設計レビューのレビューワー全員が見落としている欠陥を指摘することであると考えている

2-06 テストケース肥大病 P.77

ちょっとこの記載は微妙と思いました。

ここでいう設計ドキュメントに記載されていない内容とは、(ドキュメントは横においといて)「設計されているもの」だろうか、「設計されていないもの」だろうか、それともいわゆる「当たり前品質」的なものだろうか。気づきレベルではテスト担当者が指摘できるかもしれないが、それを最後の砦と役割付けるのだけではなく、もう一歩の改善策が必要なんだろうな。

QAW(Quality Attribute Workshop)という手法を使うと効果的です。QAWは、そのソフトウェアに対して、将来にわたり、どのような品質特性(性能や使い勝手など)を求められるかについて、関連部門(マーケティング、営業、評価、運用部門など)のキーマンを集め、ワークショップを開いて、関係者で予測・合意するものです。

3-01 困りごとが解決されないヘルプデスク P.83

QAW…はじめて聞きました、勉強不足・・・。ネットで調べましたが、日本語の解説が特に見つからなかったので、出処と思われるSoftware Engineering Institute(SEI)の資料を見つけました。ご参考までに。

ワークショップで作る成果物(目的)は、アジャイルサムライで言うインセプションデッキに近いものですね。インセプションデッキの内容を一部掘り下げ、より品質特性にフォーカスした議論を追加すると行った形式もありかもしれません。

会議では「三現主義:現場、現物、現実の重視」を必須ルールとします。

4-06 問題解決のための会議に当事者が参加していない P.131

この三現主義という言葉が気に入ったのでピックアップ。NRIの用語解説の説明が詳しかったです。→NRI用語解説 経営戦略・事業戦略 三現主義
3 Reality Principle

受託開発下において、「現」をないがしろにしてしまう雰囲気をよく感じます。ここでいう「現」というのは、例えば、「ソースコード」、「開発の現場」、「エンドユーザーの現場や気持ち」、「(サーバなどの)本番環境」、など。こういった「現」に対して勘がちゃんときくように、

  • ソースコード/本番環境
    • プログラミングする能力を始め、ソフトウェア開発の基礎スキル
  • 開発の現場
    • チーム運営や、評価、プロジェクト管理スキル
  • エンドユーザーの現場や気持ち
    • ヒアリング能力や、チェンジマネジメントに関する知識、懐に入るひととなり

といったことは日々研鑽しなくてはいけないな〜と思います。身にしみる。

治療法

「その解決策を1年前に知っていたら、今回のトラブルは発生しませんでしたか?」

4-07 再発防止につながらにトラブル解析 P.133

このキラークエスション、良いですね。当時知っていたら、もしくは、当時実行していたら、そのトラブルは発生しなかったかを、振り返りの際、深堀の観点として入れるとより良い議論ができそうです。なぜいま(振り返りの際には)気づけたのに、それを当時(問題が発生した時点)は気づけなかったのか、もしくは、実現できなかったのか。などなど。

次回(#10)

スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。記念すべき#10の書籍はまだ決まっていません。候補はこのあたりでしょうか。

  • #10の候補書籍(検討中)
    • Design It!
    • INSPIRED 2nd Edition
    • フィンテックエンジニア養成読本
    • チーム・ジャーニー(ただし、2020年2月17日発刊)
  • デッドライン
    • #09の感想交換1Week(1/27〜2/2)
    • インターバル(2/3-9)
    • #10の読書する時間2Week(2/10~2/22)
    • #10のブログポスト期限(2/23)

【子育て】4歳児の読書

昨年第二子をさずかったことをきっかけに本ブログの過去ポストを読み返しました。自分で書いたにも関わらず3年も立つと、時をまたいで役に立つものですね。長女が小さい頃に、こんなことを考えたり苦労していたんだってことを思い出しました。

せっかくなので次女の誕生をきっかけに、育児関連も再び書こうと思います。今回は、上の子の4歳児の読書(絵本)について整理しておこうかなと、書き始めました。

4歳児の読書

テーマは「4歳児の読書」です。

4歳児は読み聞かせ黄金期と言われる通り、絵本を落ち着いて聞いていられるようになる年頃です。幼稚園・保育園でも読み聞かせの時間もあります。パラパラとページをめくっていただけの子が、自分で文字を追って読むようになるタイミングかもしれません。

我が家の場合は、とにかく寝る前の「今日は何冊!?」(by こども)と戦う日々です。「2冊」→「少ない!」。「4冊」→「良いよ!」→(読み終わったあとに)「足らない!あと1冊!!」。たくさん絵本に興味を持ってもらえるのはとても嬉しいのですが、喉と睡魔が大きな壁になります^^;

絵本の選び方

私が絵本を選ぶ際にはいくつかカテゴリがあります。しっかり分類されたカテゴリではなく、子供が好きそうな(もしくは親が好きそうな)領域を自然に作っていたという感じです。本を購入する際や、図書館で借りる際に意識しています。そのカテゴリと例を、まずはまとめてみました。

1.シリーズものでお気に入りを見つけてみる

同じ登場人物・キャラクターを使って複数冊の絵本が出版されているモノです。一度、当たりのシリーズを発見すると、そのあとそこからひけるので、本を選ぶことに安心感がうまれます。4歳にちょうどよいシリーズモノといえば、例えば、

ねずみくんの絵本のシリーズ

ねずみくんと動物のお友達の話。赤いチョッキがトレードマーク。

ぱおちゃんのシリーズ

ぞうのぱおちゃんと友達のお話。園の生活を絵本にしているようなお話が多いです。

ルラルさんのシリーズ

大きな庭の一軒家に住むルラルさんと周りに住む動物たちのお話。ルラルさんはいっけん強面(こわもて)だけど、のんびりとした正確なところは親もほっこりします。

おさるのジョージ、ひとまねこざるのシリーズ

おさるのジョージは有名ですね。昔の作品の名前は「ひとまねこざる」といいます。ひまねこざるのほうが絵本のページ数は多いです。倍くらい。

バーバパパえほんのシリーズ

いまだにバーバパパがなにものかは分かりかねますが(おばけ?植物?わたあめ?)、絵本を通して、自然破壊や、教育問題への追求もあったりと幅広いお話。バーバパパの家族の名前を覚えるクイズゲームがけっこうおもしろい。

他にもミッフィー(うさこちゃん)、アンパンマン、のんたん、ぐりとぐら、こぐまちゃんえほん、11ぴきのねこ、だるまさんシリーズ、などがあります。

2.作風が好きな作家さんで選ぶ

お気に入りの絵や、作風を覚えておき、作家さんで選ぶというカテゴリです。たとえば、

◆せなけいこ さん

切り絵調の絵が素敵。たくさんのおばけを覚えることができます。童謡の歌詞をそのまま題材にした絵本もあります(ねこふんじゃった、など)。今冬は、せなけいこ展も開催されています。

◆村上康成 さん

柔らかく、特徴をデフォルメした絵を描く作家さんです。魚のやまめの絵などは有名です。私は下の「星空キャンプ」を読んで、子供とこんな生活がしたいなーと憧れています。

他にも、五味太郎さんや、長新太さん、ヨシタケシンスケさん(あとからもう一度でできます)、などなど、お気に入りの作家さんを意識して探すと楽しめると思います。

3.昔話をいろんな絵本で読む

昔話は同じ話を様々な作者が書いています。「はなさかじいさん」を例にとっても数十冊はあるんじゃないでしょうか。それを横断的に読むのも面白いと思います。

ちなみに我が家では昔話を狙って図書館で探すのが大変だった(あるのはあるけど、古くてぼろぼろ、もしくは今の年齢の子供の集中力にあった文字数の絵本がなかなか見つからない)こともあり、シリーズで入っている、ポプラ社の「はじめての世界名作絵本」を買いました。いわゆるアニメ絵本です。一冊辺り350円という値段が素晴らしい。第一期で買ったときには30冊まで出揃っていましたが、いまや第四期60冊まできているようです。最終的には2020年10月で第六期80冊まで出るようです。

4.自然科学も大事

理系っぽい絵本ですね。地域の図書館でも小さくても専門のコーナーがあると思います。虫や動物、自然、季節の絵本など。ちょっと理科っぽい本を読んであげたいときに選びます。薄い本だと「ちいさなかがくのとも」のシリーズも良い。

5.定番を漁る

自分自身もも読んでもらった覚えがあるような何十年も読み続けられているような絵本です。あげだしたらキリがないでしょうが、例としては、

などなど。

6.読み手の大人も楽しめる

読み手の親も楽しめたり、学べたら一石二鳥ですよね。下の選書は私の趣味も混じってますが、例えばこんな絵本です。

ヨシタケシンスケ さんの絵本

絵本の内容が深いです。物事をよく考えよう、違う視点もあるんだよ、様々な多様性なども教えてくれる作品が多いです。いちど親がはまると新作含め全部読みたくなります。絵も可愛いく楽しいので子供ももちろん楽しめます。

コップってなんだっけ?

考え方、アイデアの発散の仕方を学べる絵本。

せいめいのれきし

地球ができてから、現在までの歴史をお芝居形式で楽しめる絵本。作者のバージニア・リー・バートンさんは、本書を作るために博物館にこもってこつこつ調査したそうな。いまは改訂版が出ていて出版当初の良さを残したまま、新しい見識もちゃんと反映されています。

絵本の手に入れ方

我が家はまずは図書館での貸し出しを頼りにしています。

地元の図書館は一人2週間15冊まで借りれるため、その枠で隔週で図書館通いをしています。お財布的に本当に助かる、これだけでも税金を払っている意味があると感じます。。。w

ちなみに図書館には、普通の絵本はもちろんのこと、大型絵本(子供の布団くらいありそうな)や、紙芝居など、ちょっと変わり種もありますよね。たまには趣をかえて、紙芝居で読み聞かせをすると、楽しいです。お友達が集まって遊ぶときにも重宝します。(ちなみに紙芝居は読み聞かせではなく、演じるものとのこと。奥が深い!参考:紙芝居ネット 紙芝居の演じ方

図書館で、借りて読んで、良いなと思った絵本は、その段になってはじめて買うことが多いです。もしくは何かのメディアで紹介されていて一目惚れで買う!といったこともあります。それでも、さきほどの「はじめての世界名作絵本」のシリーズを除けば、月に1冊買えば多いほうです。

おわりに

4歳の長女との付き合いで学んだ絵本のことについてまとめてみました。頑張ってカテゴリわけしてみようかなと思いましたが、まだまだ分けきれず。当てはまらない絵本もたくさん借りています。図書館の棚で見つけたものを文字の量とフィーリングで選ぶことが多いです。

次女が4歳になるときにはこの記事+αの知識で接することができると良いなと思います。

デッドライン読書会#08「レガシーコードからの脱却」(後半)の感想文

課題図書

第8回目のデッドライン読書会(読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は第7回に引き続き、「レガシーコードからの脱却」の後半部分です。後半部分の範囲は、8章プラクティス4「協力しあう」から最後まででした。第7回の感想はこちら(デッドライン読書会#07「レガシーコードからの脱却」(前半)の感想文)です。

感想文

全体

あらためて本書で紹介しているプラクティスを転記すると、次の9つになります。

  • プラクティス1:やり方より先に目的、理由、誰のためかを伝える
  • プラクティス2:小さなバッチで作る
  • プラクティス3:継続的に統合する
  • プラクティス4:協力しあう
  • プラクティス5:「CLEAN」コードを作る
  • プラクティス6:まずテストを書く
  • プラクティス7:テストでふるまいを明示する
  • プラクティス8:設計は最後に行う
  • プラクティス9:レガシーコードをリファクタリングする

9つのプラクティスは、この書籍独自ではなく、これまでに他書で語られていたプラクティスで特に重要視すべきものをまとめた形をとっています。それぞれのプラクティスでは、概要、目的、はじめ方、制約などを語っています。さらにその詳細(いちおう各章に「実践しよう!」っていう節もありますが、それでも概要かな…)が必要なときには関連書籍へゴー!という位置づけです。後半部分を読んで特にそう感じました。

本書の概要の具合からすると、もしくは、「エンジニアはそういったことを気にする必要があるんだよ」というマネージャーなどの周辺の人向けの本なのかもしれないですね。

で、「関連書籍へゴー!」となると、主要どころでは次の本になると思います。

エクストリームプログラミング

リファクタリング(第2版): 既存のコードを安全に改善する

テスト駆動開発

本書の最後に「レガシーコードからの学び」というまとめの章があります。ここで著者のBerstein氏が強調していることは、アジャイル型の開発において、マネジメントプラクティスだけではなく、もっと技術プラクティスに着目しようと言っています。

技術プラクティスはアジャイルのマネジメントプラクティスと少なくとも同じくらいには重要である。しかし、多くの組織ではほとんど注意が向けられていない。アジャイルの技術プラクティス抜きでアジャイルのマネジメントプラクティスをやっても、多少は利益があるだろう。だが、アジャイルの本質的な価値は、エクストリームプログラミングの技術プラクティスを適用することによって得られるのだ。

14章 レガシーコードからの学び(P.243)

自分自身に当てはめても最近はソフトウェア開発のソフトな部分(コミュニケーションなど)によく興味を持っていました。原点回帰し、技術プラクティスを精進するのは重要ですね。ソフトウェア開発の、、、ハードな部分とでも言うんでしょうか^^;

個別

勉強になったところを個別に抜き出します。

私が「ユニットテスト」の「ユニット」といった場合、多くの開発者が想定しているメソッド、クラス、モジュール、関数などのようなエンティティを指すものではない。

 ユニットとはふるまいの単位、つまり独立した検証可能なふるまいのことだ。

10.3.2 振る舞いの集合体(P.169)

自分の中には「関数があってユニットテストがある」ということが染み付いているため、この整理はすっきりしますね。テストファースということは、振る舞いをテストする必要(このテストは、別名でいうと、チェック、ふるまい、設計、仕様、などか)があり、ふるまいの単位がユニットなのだと。

そこで私はクライアントに、シャント、依存性の注入、及びモックを使った…

10.7 テスト駆動開発は失敗することがある(P.173)

シャントがわからなかったので調べました。たぶんテスト駆動開発にある「Self Shunt(自己接続)パターン」のShuntだと思います。オブジェクトが他のオブジェクトときちんとやり取りしていることをテストするためのパターン。その他にも右記のサイトではモック、スタブと並列して解説されていました→CunninghamのWiki:Mock Stub Shunt

コードは読むためのものだ。本や新聞の記事と変わらない。平均して、コードは書かれる回数の10倍読まれている。

12.3 コーディング対クリーニング(P.208)

「1回書いたら終わり」って考える人は流石に少ないだろうけど、1回リリースできたらもういいかなっていう人は多そう。読めるコードでなくてはだめ。コメントで語るのも良くない。

次回(#09)

スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。

  • #09の候補書籍(検討中)
    • Design It!
    • INSPIRED 2nd Edition
    • フィンテックエンジニア養成読本
    • IT業界の病理学
  • デッドライン
    • #08の感想交換1Week(12/30〜1/5)
    • インターバル(1/6-1/12)
    • #09の読書する時間2Week(1/13~1/25)
    • #09のブログポスト期限(1/26)

デッドライン読書会#07「レガシーコードからの脱却」(前半)の感想文

課題図書

第7回目のデッドライン読書会(読書×締切ではじめる「デッドライン読書会」を始めました)の課題図書は、「レガシーコードからの脱却」です。原著は2015年発行、和訳の本書は2019年9月発行です。オライリーのソフトウェア開発の汎用スキル系(どういうカテゴリなのか良い名前が思い浮かばない…)の本です。

今回前半の範囲は、本書の最初から7章「プラクティス3 継続的に統合する」までの範囲です。

感想文

全体

本書で言う「レガシーコード」とは、変更ができないコードを指しています。ソフトウェア開発自体が発見的なプロセスであるべきで、つまり、変更が前提とされるのに、そもそも変更ができないコードのことをレガシーコードと呼んでいるわけです。

よくあるうまくいかないソフトウェア開発(例えば失敗するウォーターフォール型とか)っていうのは、レガシーコードを作り込み、あとから品質を作り込み(品質強化テストみたいな営みで)、そのなかでたくさん人が投入されて火消し役と呼ばれる人たちが活躍する、といった形が多いのかなと思います。レガシーコードを作り込むというのは、まさに最初のサービスインがゴールで一発勝負だという前提で進めている場合に起きやすいのだと思います。受託開発の形式で起きやすいとかあるんじゃないかなぁ。開発で儲けて、保守は手離れよく…みたいなマインドのときです。

この本では、それはもうやめにして、原理・原則を把握し、具体的なプラクティスを大工の道具箱のように備えることによって、世の中を良くしていこうという内容です。この大工の道具箱に入れるのが9つのプラクティスで、それはスクラムやリーンの考え方より具体的で、エクストリーム・プログラミングの考え方より抽象的(よりプラクティスの数を絞って)で、まとめられています。

脱線しますが、この「大工の道具箱」といった表現が私は好きです(本書では「自由に使える範囲の知的な道具」という表現もありましたね)。システムエンジニアの道具箱にはいったいどんなものが入っていると面白いのでしょうか。そのうちのソフトウェア開発の技術的な部分にあるのが、この本の9つのプラクティスでしょう。それ以外にも、人事、コミュニケーション、ビジネススキル、哲学、ワークライフバランス、などいろいろなものが入っていると面白いですね。

個別で気になった部分

気になった箇所を引用しつつ、一言コメントをします。

アジャイルやスクラムの目的は急いで仕事をすることではなく、小さなかたまりで仕事をすることだ。

3.3 アジャイルを実践する

これって、本当によくある勘違いを、正しくしているところです!スピードを早めるためにアジャイルやスクラムをやるんではない。小さなかたまりで仕事をすることによるメリットを享受することが一番の目的と思います。

コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。

4.1 専門家が知っていること

急がば廻れといいますか、丁寧にお仕事しようということですね。苦手だなぁ。精神的にどっしり構えらえることも実は重要そうですね。

ソフトウェア開発者として、プロダクトオーナーと顧客がを欲しいのか、なぜ欲しいのかを知りたい。そしてのためのものなのか知りたい。どうやってやるかは教えてほしくない。

5.2 やり方を目的に転換する

これは自分は比較的この通りやってこれたかなと思います。あんまりどうやってやるかを言われたことはないかなぁ。ただ「何」と比較し、「なぜ」や「誰」は深掘りが弱かったと感じます。ところで、逆に「どうやって」を顧客が言ってくれたとしたら、「そこまで分かってくれる人なのか!」と感心してしまうんだけど、その感覚はどうなんだろうか。

だが、私は10分でも遅いと思う。

7.4 ビルドを自動化する

手厳しい…「10分」はビルドの所要時間を指している、本書の最初の方でもビルド時間は3分とあった。そして多分この「ビルド」には、

  • コードの取得
  • ビルド
  • ユニットテスト
  • 受け入れ環境用の展開
  • 自動受け入れテスト
  • 各種フィードバック

などが含まれているんでないかと想像。(システム規模によると思いますが)システム全体のクリーンなビルド(ゼロからのビルド)で3分って難しいような気がするから、システムを小さく分割して差分的な技を駆使することにより短時間でビルドシステムからフィードバックを受け取れるように工夫しなさいということかなぁ(と、期待というか、甘えというか…)。

でもここで表現されているような高速なビルド・自動テストは憧れますね。気持ちよく開発できそうです。いまは高速な静的解析くらいは努力しなくてもツールによってできますが、高速なビルドと自動テストはエンジニアが頑張らなくてはいけないところだと思います。

次回(#08)

スケジュールはGoogleカレンダーで分かるようにしています。第8回は次の要領です。

  • #07の書籍
    • レガシコードからの脱却(後半戦)
  • デッドライン
    • #07の感想交換1Week(12/9〜15)
    • #08の読書する時間2Week(12/15~12/28)
    • #08のブログポスト期限(12/29)