Magnolia Tech

いつもコードのことばかり考えている人のために。

報告資料は読む人の「知識」「時間」「要求」「行動」を意識して書きましょう

何か相手に説明するための資料を書く時に、自分が何に気を付けているか、他人の資料を読む時にどんなところを見て指摘するかを考えてみると、おおざっぱに言えば「読む人の気持ちを考えましょう」になるし、細かく言うとキリが無く、コンテキスト次第......みたいになってしまうのだけど、もうちょっと整理すると、この4つじゃないかと収斂していった。

「WEB+DB PRESS Vol.130」の「イミュータブルデータモデルで始める 実践データモデリング」は必読なので、マジで今すぐ本屋へ走って買おう

川島さんの「イミュータブルデータモデルで始める 実践データモデリング」は必読なので、マジで今すぐ本屋へ走って買おう、としか言いようの無い、お得情報満載。

ビジネス要求の持つ複雑を表現しているモデル、表現していないモデルの境目が分かるようになるし、そもそも「複雑とは何か?」ということが分かるようになる。

あと、「モデルとして複雑な物はどう表現しても複雑…だけど、それを扱うアプリケーションの複雑さを軽減することができる」という考え方、視点が得られるだけでも超お得。

音読しよう、100回読もう、枕元に置いて夢の中でも読もう

どうやっても複雑さは減らないので、複雑さをコントロールできるようにしていこう!!

もう一回読もうっと。


『熊とワルツを』を読んで、リスク管理の重要性が分かっていながら、できていないのは何故か?と考えた

先日の吉祥寺.pm30onkさんの発表で、『熊とワルツを』という本が紹介されていた。

onk.hatenablog.jp

この本と、トム・デマルコさんという著者のことは知らなかったけど、別の著書である『ピープルウェア』は名前だけは聞いたことが有った、くらい。


日本語版が出版されたのが2003年と、約20年前の本ということで後半に書かれている「リスク管理の方法」や、「数量化の方法」などは他の書籍でも散々紹介されている話なので、今更感は有るけど、前半の「なぜリスクを管理しないのか」あたりは今でも十分に通用する学びが有った。

「リスクを管理する」と言っても、さまざまな階層が有って、この本で語られているような管理手法により定量的に、公式に評価されたリスクがリスト化され、経営層やプロジェクトオーナーが目にする形で管理・更新され、内容が逐一「議論・承認」される場合も有れば、現場のリーダーが「ちょっと気になって先に確認しておきたいことリスト」みたいなメモレベルで管理され、「できる分だけやる」みたいな場合も有れば、「ちょっとした思いつきで、念のために確認しておいた」みたいな場合もある。

誰しもが、自分の権限に於いて、管理可能な範囲でのリスク管理は自然とやっていて、それがその人やプロジェクトのスキルレベルや、権限、予算などに応じて「網羅的に上げられているか」「可視化されているか」「共有されているか」「あらかじめ対策まで計画されているか」「追加費用が用意されているか」「リスク対策が実行されているか」といった濃淡が変化していくものだと思っている。

誰しも、言うか言わないか、計画するかしないか、行動するかしないか…は別として大小さまざまなリスク管理は行なっているが、プロジェクトは上手く行かない……または、上手く行くかもしれない……不確実だ!


今読んでも十分な学びが有ったのが、第5章「リスクを管理すべきでない理由」(タイトル通りの理由は無いよと、本文では書かれているので、勘違いしないように)で、リスク管理をしない言い訳が並んでいる。その言い訳の一つとして「発注者がリスクに直面できるほど成熟していない」というものがあると書かれている。

つまり、「言ってもしょうがないから」言わないということだけど、じゃあ一歩踏み込んで、なぜ「言ってもしょうがない」という考え方に到達するかを考察してみると、上記のような「”リスク管理のために必要な権限や予算”を超えてしまうリスク」が存在する時に、報告し、承認する相手はどう反応するか?を先回りして結論を出しているからではないでしょうか。

「リスクがあります、こういう対策が必要です」 「じゃあ、予算はそのままで、そちらの責任で対策費も含めてください」

という会話をしたくないから……つまり、持てる権限や予算を超えて管理しなければいけないリスクに対する、より上位の層の理解が足りない時に「公式なリスク管理」は行われなくなるのではないか?と考えた。

問題が起きてから、「なぜもっと早く報告してくれなかったんだ」という会話がされる場面はあるあるなのだと思うけど、それは報告する側が「報告するメリットを感じていないから」ではないでしょうか。

と言う訳で、最も大きな権限を持つ人が、リスクをちゃんと言ってもらえる環境(権限や、予算などの承認)を作る、というのが最も大事なリスク管理ですね......みたいなことを考えました、終わり。

『私たちはどう学んでいるのか: 創発から見る認知の変化』を読んで、勉強することへの取り組み方について考えたこと

ときどき、TwitterのTLに流れてくる情報をもとに本を買うことがある。

普段、読書といっても技術書や、好きな作家の小説に偏りがちなので、自分が自然に手に取らない本を読むためにも「教えてもらったものを、とりあえず”買って”読んでみる」という方法は有効だと思っている。


今回それで知って、読んで面白かったのが、この『私たちはどう学んでいるのか: 創発から見る認知の変化』。

ソフトウェアエンジニア界隈でよく議論になる「エンジニアは土日も自主的に学習すべきか」という話題が有って、その是非はここでは触れないけど、”そもそも学習ってどうすれば効果的なのか?”ということは意識しておいた方がいい。昔、改めてプログラミングを勉強しなおそうと思った時に、入門書を買ってきて頭から読み始めて、ノートにメモを取ったり、掲載されているサンプルコードを打ち込んでみたりしても、何だか全然身についている感覚が無かった。だけど、勉強会やカンファレンスに参加して、色々な人の取り組みを聞いたり、実際に気になった機能を自分で書いてみたり、紹介されたコードを読んでみたりするうちに、段々と自分でもコードの書き方が身についてきた感覚が得られるように変わっていった。

それ以来、学習のステップや、環境次第で、学んだことが実際の「知識」や「能力」として身についていく度合いは大きく変わっていくものなんだな、ということを意識するようになった。


本書は「能力」や「知識」とは何か、それらは思ったほど固定的なものではないし、それらを身につけていく過程も単純ではなく、いろいろな特性が有る、というテーマで書かれている。

第1章 能力という虚構

第2章 知識は構築される

第3章 上達する―練習による認知的変化

第4章 育つ―発達による認知的変化

第5章 ひらめく―洞察による認知的変化

第6章 教育をどう考えるか

特に、第1章で語られている「能力には文脈依存性が有ること」と、第2章で語られている「知識は直接伝わるものではなく、情報から、その人の中に構築される、とても属人的なもの」という整理が興味深く、この本を読むことでこの辺りの認識を変えられたのがよかった。

「情報」がそのまま「知識」になるわけではないし、何ができて、何ができないか、どのくらいできるか、という「能力」についても、極めて、その状況に応じて発露する度合いは変わってくる、という学びが最大の収穫だった。また、本書で一貫して主張されているのが「学びについて、学校教育を基に理解しようとするが、必ずしもそれは正しくない」という点も改めて考えてみると納得感が有った。


自分や、他人(組織のメンバなど)のスキルを伸ばす上で、やり方や、指導方法についてのヒントを得たい人にはすごくお薦めの1冊。

『初めてのGo言語―他言語プログラマーのためのイディオマティックGo実践ガイド』、『Learning Go: An Idiomatic Approach to Real-World Go Programming』の邦訳が出版される

『Learning Go: An Idiomatic Approach to Real-World Go Programming』の邦訳が出版される。

『初めてのGo言語―他言語プログラマーのためのイディオマティックGo実践ガイド』という署名になっているけど、サブタイトルがいいな。原著と全然違うんだけど、本書を読んだことがある人なら、「あーこっちの方が合っているなー」と思えるはず。

原著が出た時にすぐに買ったのに、積んであったのを最近ISUCONのためにようやく読んだ。

blog.magnolia.tech

既に何らかのプログラミング言語を習得している人が読むことが前提で、プログラミング言語が備える機能の概念ではなく、機能を設計の背景含めて流れるように解説している感じが割と好きな構成だった。過去に読んだプログラミング言語の入門本の中では一番理解しやすかったかも。

というわけで、既に何らかの言語を習得している人がGo言語を学ぶ時にはお薦めの一冊ですね。

『チームトポロジー』と、『How Do Committees Invent?』を読み直して「コンウェイの法則」について考え直した

コンウェイの法則」というのがある。

Melvin Conwayが『How Do Committees Invent?』という論文にて発表した考え方を指す言葉。筆者自身による論文の紹介文に書かれている、以下のくだりが端的にその内容を表している。

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.

システムを設計する組織(ここでは情報システムだけでなく、より広い意味で定義する)は、必然的に組織のコミュニケーション構造をコピーした構造を持つ設計を生み出すことになる。

「組織をつくる人」は、それぞれの階層に於いて、その課せられた目的を達成するために自分がコントロールし易いように成果や役割を分割し、それに合わせた「組織」を作り上げていく。当たり前だけど、「組織をつくる人」の視点から見れば、それらの分割された成果は合成可能であり、その統合によって目的が達せられる。

初めてこのコンウェイの法則を聞いたとき、「それは組織をつくる人の意図通りの結果なのだから、当たり前では?」とか、「縦割りの組織に所属している人からの悲鳴?」とか、「組織を外から見ている人の皮肉?」とか色々な考えが巡った......つまり、「組織をつくる人」「組織に所属する人」「組織を外から評価する人」…誰の視点からのメッセージなのか、よく分からなかった。

一方で、「逆コンウェイ戦略」と呼ばれる考え方がある。

組織の構造がシステムの構造を規定するのであれば、作るべきシステムの構造に合わせて組織を作る考え方だ。これは…確かにその通り…というか、元から組織は目的に合わせて作られるべきだし、目的に合っていなければスクラップ&ビルドされるべき……後から見ればいくらでも言えるだけなのだけれど。

ちなみに、元の論文をよく読むと、最後にちゃんと書いてある。

Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

それは、「デザインはコミュニケーションの必要性に応じて組織化されるべき」という、デザイン組織の構造化の基準を見出したことである。

This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

この基準では、その時々のシステムコンセプトによって通信の必要性が変わるという問題が発生します。なぜなら、その時点のシステムコンセプトによって、いつでもコミュニケーションが必要だからです。したがって、効果的な設計を行うためには、組織の柔軟性が重要である。

わざわざ「逆コンウェイ戦略」とか言わなくても、大事なことはちゃんと書かれている。逆じゃなくない?


で、じゃあその考え方をうまく取り入れて組織を作っていくにはどうしたらいいか?「コンウェイの法則」をベースにした具体的な組織構造の作り方が『チームトポロジー』に書かれている。

現代的なソフトウェアアーキテクチャの特性を背景に、チームの構成や、人数、コミュニケーション設計の方法などが解説

もちろんそのまま取り入れればいいというものでもないし、謎のカタカナ用語が多すぎて(「イネイブリングチーム」とか、「コンプリケイテッド・サブシステムチーム」とか...)、そのまま発声するにはちょっと躊躇するけど、「具体性」という意味では非常に参考になる事例が多く掲載されていて、最初に書いた疑問である「この法則は、誰が理解すべきなのか?」ということに対しては「組織をデザインする人」ということがようやく理解できた。

個人的には、「ソフトウェアの境界のサイズをチームの認知付加に合わせる」という考え方が非常に納得感が有って、ここを失敗すると組織の生産性や品質は格段に下がってしまう、と感じている。


コンウェイの法則」以外にも、色々なソフトウェアエンジニアにとって有益な考え方や、視点がざっとまとまっている『達人プログラマ』もお薦めです。一つ一つのことを深く掘り下げるより、ざっと「こういう視点がある」ということを掴むのに、お薦めの1冊です。

ネットワーク知識のリフレッシュのために最新の『マスタリングTCP/IP 入門編 第6版』を読んでみた

最初にネットワークの基礎を学んでから随分時間も経ってしまったので、ネットワーク知識のリフレッシュのために『マスタリングTCP/IP 入門編 第6版』を買ってきた。2022年に入って、10年ぶりに改版された第6版が出版されたので、購入のタイミング的には丁度良かった。

QUICや、Wi-Fi 6など、今時のキーワードも網羅している。一方で10BASE2や、10BASE5などの、もうめったに見られない技術も出てきて、さすがに入門書からは消しても良かったのでは?と思ったり......

でもすっかり忘れてた知識を、学び直すことができたので良かった。


いろいろなネットワークの教科書を読んでみると、OSIの7階層モデルが出てきて、物理層から始まる下位レイヤーから、より上位のアプリケーションのレイヤーに向かって解説が進んでいくのだけど、上位の層から下位の層に向けて学んでいく方が良いのか、下位の層から上位の層に向けて学んでいく方が良いのか、ということを考えた。

ネットワークを構築する人の視点だと前者なのだろうし、サーバサイドのアプリケーションを構築する人の視点だと後者の方が良い気がする。ウェブアプリケーションを書く人からすると、物理層のこととか、知識として知っていてもいいけど、まずはそこじゃないよねって話もあるだろうし、クラウドだと、昔のようにインフラサイドの人に、物理スイッチや、物理ルータの設置や設定をお願いすることなく、自分で設定してしまって完結することもあるだろうし。

ウェブアプリケーションを書く人のために、上位のレイヤーから、下位のレイヤーに向けて自分の興味に合わせて掘り下げていく順序の入門書が有ってもいいよなーって思った。


『マスタリングTCP/IP』シリーズ、過去に色んな本が出ているけど、その後アップデートされているものばかりでもないので、発行日とかはよく確認しておいた方がよさそう。

最近アップデートされたのは、入門編以外だと、セキュリティ編が新しくなっている。