Magnolia Tech

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

ドメイン知識は、容易に失われる

以前noteに書いた記事ですが、管理上こちらにも転載。

なるべくドメインを表現したコードにしよう、というのはそりゃそうなんだけど、ちょっとした記述方法だけでもドメインが持っていた意図は容易に失われる（だからこそどうやって表現を残すか考えないといけない）っていう趣旨のエントリでした。

ドメインにはドメインの都合があるし、コードにはコードの都合があるんだよね。完全にどちらかに寄るわけじゃないけど、後世の人にとって都合の悪い寄り方はあると思う。

コードがドメイン知識を表現するように書かれるべき、という話と、全体を疎結合にして拡張性や保守性を担保しましょう、という話、完全には両立はしないと思っていて、だってビジネス側の人はそんな拡張性とか保守性の話していなくね？

で、実際のコードを見たら、考えたこともない保守性や拡張性のための抽象化が行われていて、上から読んでもよく分からん、みたいなこと、発生していない？

そうでなくても冒頭の、ちょっとしたコードの書き方でも、元々考えていたドメイン知識からの要求って失われたりしませんか？って

区分コードに5が追加された時、全然違うところにとってつけたような分岐が現れてしまうこと、ありませんか？

コードの改修のしやすさと、ビジネス側からの要求が一致していないとき、後世の人は、先人たちの考えたことが分からなくなってしまうのです。

magnoliak🍧 (@magnolia_k_) | Twitter

2月のブログの振り返り

f:id:magnoliak:20210304001954p:plain ブログのエントリ数を減らすことにしたけど、それでも17本も書いていた。

blog.magnolia.tech

これはもっといくらでも突っ込んで書けるネタなので、いつの日か完全版を書きたい。”設計書は、過去・現在・未来のステークホルダーとのコミュニケーションツールなんだ”ということはずっと言っていきたい。

なお設計書というとExcel方眼紙のことが度々話題になるけど、非常に気になるタイトルの本がリリースされるそうなので、ぜひ読みたい。

エクセル方眼紙で文書を作るのはやめなさい ~「他人の後始末」で、もうだれも苦しまない資料作成の新常識

エクセル方眼紙で文書を作るのはやめなさい ~「他人の後始末」で、もうだれも苦しまない資料作成の新常識

  • 作者:四禮 静子
  • 発売日: 2021/04/14
  • メディア: 単行本（ソフトカバー）

blog.magnolia.tech

『本を読む本』、よく考えるとタイトルの時点でかなり優勝感有る。

本を読む本 (講談社学術文庫)

本を読む本 (講談社学術文庫)

よっぽど本を読むのが好きな人じゃないと読まないタイトルだなって。

blog.magnolia.tech

「箱庭感」、割と気に入っているフレーズでよく使っている気がする。ソフトウェアテクノロジーが持つ箱庭感についてはもっと色んな人に論じて欲しいなって思っている。

blog.magnolia.tech

この「無意識の設計」ってテーマも割とずっと気になっている。”結果的にそうなった”としても設計は、設計なんだよねっていう話なんだけど。

blog.magnolia.tech

これは名著。マジで一家に一冊レベル。

Webで使えるmrubyシステムプログラミング入門

Webで使えるmrubyシステムプログラミング入門

  • 作者:近藤宇智朗
  • 発売日: 2020/11/25
  • メディア: 単行本（ソフトカバー）

PerlはPOSIXの薄いラッパーって感じの関数とかモジュールが多かったから、自然とシステムコールに興味が行く気がする。

blog.magnolia.tech

これ、もっとウケるかな、と思ったけど、そうでもなかった……言われたことないのかな、みんな。

blog.magnolia.tech

これは読み返したので書いたエントリ。本当に言語の成り立ちを理解すると解像度が一つ上がる気がする。

blog.magnolia.tech

付録Cを読もう。

blog.magnolia.tech

たまに読み返すんだけど、必ず挫折するんだよな。全部は読めない。

blog.magnolia.tech

現在、ファームウェアのアップデートの返送待ち。返ってきたら最終レビュー書きます。でもほんといい機種だと思うな（半額なら、という条件付きだけど……）。一回送り返さないといけないのは面倒だけど。

NEC 27型4K対応3辺狭額縁ワイド液晶ディスプレイ LCD-EA271U-BK

NEC 27型4K対応3辺狭額縁ワイド液晶ディスプレイ LCD-EA271U-BK

  • 発売日: 2018/11/29
  • メディア: Personal Computers

blog.magnolia.tech

これは今の目線で見るとけっこう回りくどいし、分量も多いなーって思うけど、やはりこの手の古典は一度は読んでおいた方がいい。

著者の名前、どこかで見たなと思ったら、『ライト、ついてますか』の著者だった。これも名著だ。

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

というわけで3月も引き続き、そこそこ書いていくと思います。よろしければTwitterもフォローしてください。

magnoliak🍧 (@magnolia_k_) | Twitter

『プロダクトマネジメントのすべて』はたしかに”すべて”だった

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

まず単純に、これだけ多岐に渡る題材を一冊にまとめているところが凄い。

プロダクトを考え、作り上げて、世に出す上で必要なことが全部書かれている。知財とかうっかり忘れがちなところまで全部！

ただ、ここに書かれていることをなぞることがプロダクトマネジメントではなく、プラクティスを頭に入れつつ、自分たちが置かれている状況に合わせて考え、判断し、行動することがこの本の”正しい活かし方”なんだな、とも思った。

結局は「プロジェクトを成功させたい」という強い思いが有って、必要な権限を持っていて、意思決定ができる人が成功する・したプロジェクトには必ず居て、でもその人に必ずしも明確な役職名がついているわけでもない中で、こうやって”プロダクトマネージャーというロールである”、という定義を改めてすることで、”周りの”見方が変わるはず。

あとはここに書かれていることが全部できる、等しくできる人はいないと思うので、自分がプロダクトマネージャーとして振る舞うとき、自分がプロダクトマネージャーを任命する際に、どこまで周りの人に「支えてもらうか」「支えさせるか」、その濃淡を付けるときに非常に役に立つなと思った。

「自分が読み飛ばしてしまった」ページに興味を持つ人を探す、という観点。

全部を、過剰に、求めてはいけないのです。

というわけで、プロダクトマネージャーになる人／なりたい人、プロダクトマネージャーを任命する人、プロダクトマネージャーを支える側の人、色々な立場の人が読むといいな、と思いました。

技術力の向上に、issueをちゃんと書けるになる訓練をするのが良いのではと思った

技術力の高い人の特徴の一つとして、言語化能力の高さが有るのではないか。

それは、自然言語なり、コードなり、さまざまな方法で「形」にしないといけないから。

その中でもissueは比較的短い文章で「件名」「概要」「意図した動作」「実際に起きた動作」「起きた時の条件」を端的、かつ明確に書かないといけない。

GitHubもissueは、以前は単なる自由記述だったけど、次第にプロジェクトごとのテンプレートが用意されるようになったので、何も教育も基準もルールもない状態で適切なissueを書くのは誰にでもできる、というわけではなかったのではないか。

なので、まずはissueを書かせてみると、「ものごとを捉える」能力が見えてくるんじゃないかと思った。

Percent-Encodingされた'%2F'は'/'と等価なのか

Scalatraで使っているJettyのバージョンを9.4.37.v20210219に上げたところ、テストが通らなくなってしまった。直後にリリースされた9.4.38.v20210224ではまた通るようになった。何が起きたのか？

ポイントは、このPRだ。

Fix #6001 separate compliance modes for ambiguous URI segments, params and separators by gregw · Pull Request #6005 · eclipse/jetty.project · GitHub

このPRは以下のPRの内容を一部元に戻す変更を取り入れている。

Fix #4275 #6001 separate compliance modes for ambiguous URI segments and se… by gregw · Pull Request #6003 · eclipse/jetty.project · GitHub

元ととなったPRでは、URLにおける..;と..を等価に扱うべきではないという主張に基づき、複数の解釈の余地が有る紛らわしい表記である..;を無効なURLとしよう、という内容だった(RFC3986ではあくまで..はディレクトリを一つ上に戻すと書いているが、..;で戻しても良いとは書かれていない)。

あまり見かけないけど、URLではpathのsegmentにも;を使ってパラメータを付加する、という考え方が有る(例えば、name;v=1.1のように)。RFC3986の中でも、しばしば使われる、程度の表現しかしていない。

そして合わせて”同様に複数の解釈が可能な表現を制限すべきでは？"という考え方から、Percent-Encodingされた.と..と/が無効なURLとなった。つまり、%2E%2Eと%2Fだ。

Scalatraでは%2FがURLに含まれるパターンのテストを用意しているので、これを組み込みのJettyでテストしようとしたところ、一律無効なURLとして判定されエラーになっていた。

直後でさすがに既存のコードへの影響が大きいということで、Percent-Encodingされた.と..と/を無効にする件は元に戻された。

しかし、一連のPRについているコメントを見ると、Percent-Encodingされた.と..と/を通すか否かは、サーバによってだいぶ違っていて、必ず通るわけではないので必ず仕様を調べましょう。ただし、RFC3986ではエンコード前後で等価で扱うべきだし、そもそもこれらの文字はPercent-Encodingすべきではないと書いている。また、そのパースのされた方はサーバの実装によると注意喚起を行っている。

なお、Scalatraでは謎の2段階デコードが行われていたので、それを止めるPRを書いた。

Changed path encoding to be selectable · magnolia-k/scalatra@2d57577 · GitHub

本来ならエンコーディング前後で意味論は変わらないので、デコードしてからアプリケーションに渡しても良いが、それでは互換性が崩れてしまうので、今はpercent-encodingされた状態でアプリに渡るようにしている。Servletの仕様では単純にrequestPathを取ると全てデコード状態で渡されるのだけど、わざわざ自前で作り直している。

というわけで、URLに%2Fと%2Eを含める場合はサーバが通すか否かをきちんと確認しましょう。特にローカルのdev環境とproduction環境でサーブレットコンテナが違っている、という場合は要注意です(あんまりない気がするけど)。

コードは、業務のレア度や重要度には関心を示さないのだ

noteからの転載

つまり、何が言いたいかと言うと、タイトルの通り”コードは、業務のレア度や重要度には関心を示さないのだ”ということ。

人間が意味を見出さないといけない。

重要な業務のロジックだから品質保証をしっかりやろう！と言っても、実行するコンピュータはそんなことに関心を示さないし、そんな色付けをできるプログラミング言語を、私は知らない。そこに人間が意味を見出さないといけない。

当たり前のようで、これがなかなかコンセンサスが得られないことなのだ。

コードに色は無いけど、人間はそこにレア度による優先順位を見出していて、「そこはめったに通らないルート」「ここはめったに通らないけど、バグが有ると死ぬルート」「ここが通るかはDBの調査が必要」「これが発生したら100年に一度の事件」みたいな層別を行っている。

ただ、それは後世の人は容易に区別することはできないので、全部同じ粒度、同じ優先度で必要！と思ってしまうんだけど、案外「一回も使われていない」みたいなルートが多数を占めていたりする。

ビジネスの人は「細かいことはいいんだよ」と言い、システムの人は「その細かいこも含めて先に全部揃えておかないと後で死ぬ」と思っていて、その価値観の差異が会話を困難にしているのかもしれない。

『要求仕様の探検学―設計に先立つ品質の作り込み』……”要求されなかったことは決して実現されない”なんて話は30年前から言われていたことなんだ

要求仕様の探検学―設計に先立つ品質の作り込み

要求仕様の探検学―設計に先立つ品質の作り込み

いつ買ったのかも覚えていないし、確実に買ったまま読んでいなかった本を本棚から発見して読み始めた。

『要求仕様の探検学―設計に先立つ品質の作り込み』……もうこのタイトルの時点でたぶんこの2021年において色々な人が読まなければいけない本じゃないだろうか。

本書は、長年システム開発のコンサルタントを勤めていたドナルド・C・ゴーズと、ジェラルド・M・ワインバーグによる所謂システム開発における”要件定義工程”のノウハウを解説した本だ。

原著は1989年に出版され、日本語訳が出たのも1993年と非常に古い本だ。タイトルだけ見るとウォーターフォール的な「最初の工程できっちり文書化することが大事」みたいなことが書かれている本と捉えてしまいがちだが、まったくそんなことはなく、現代でも通用することばかりが書かれている。というより、30年前から何も変わっていなくて、進化もしていないかもしれない。

もう冒頭から名言が連発。

  • ”何について語っているのかさえわからないようなら、そのことについて正確さうんぬんをしても意味がない” - ジョン・フォン・ノイマン
  • ”ソフトウェア・ビジネスは、製品開発に対する厳密な学という根拠のない幻想に悩まされていたのだ”
  • "有効性は常に効率性よりも先にくる”
  • ”するに値しないことは正しくするに値しない”
  • "発見には価値がない；発見すること（探求（探検）すること）がすべてだ”
  • "文書には価値がない；文書化することがすべてだ”

また、「I．コンセンサスの形成」には本書で最も大事なことが書かれている。

  • あなたの望んでいることを伝えれば、ほぼ確実にそれが手に入る。
  • あなたが望んでいることを伝えなければ、それはおそらく手に入らない。

当たり前のように思われるかもしれないが、ここでは一つの実験（4つのチームに、一つだけ要件を変えた仕様書を渡したときに何が実現されるか？）に基づき、説得力をもって解説されている。そう、本当に当たり前のことなのに、なぜこれが理解されないのか、解決するために努力されない事案がこんなにも多いのか。

その後続く設計の表記方法に関する論点も非常に興味深い。

もっと前に読んで色々な人に理解して欲しかったことが、全部ここに書かれていた。

そう、みんなオレオレ表記方法を「直感的でシンプルで理解し易い」と主張しすぎる。全然そんなことは無いのに……その表記方法が”表記しないこと”を理解することが一番大事なのに。そして実際の開発では常にその”画期的な表記方法”がサポートしないことをどうやって書き表していくか？ということを独自に工夫していった結果、「シンプルで直感的」とは程遠い成果物が出来上がっていってしまっているのに。

プログラミング言語や、設計方法論と同じで、「絶対に正しい解決策」なるものは存在しないし、そんなことを主張している人がいれば、まずは疑うところから始めるべきなのだ。

以降は、どうやってあいまいさを排除し、明確な要求・要件を特定していくか？という話がみっちり続く……が、個人的には以降は拾い読みでもいいかな、と思っている。割と会話調で続くとか、会議の良いやり方など、「この本でなくても……」とも言えるトピックも多いのだ。ただ、それがこの本に価値が無いか、というとそんなことはなく、冒頭の一貫したメッセージに基づいてプラクティスとしてまとめられているので、自分に必要と思える部分だけを拾えば良い。

それよりも、「あなたの望んでいることを伝える」ためにはこれだけの膨大な営みや注意点があるのだ、ということを理解することが大事なのです。

「なんかいい感じに提案してよ、プロなんだから」では絶対に良い成果は得られないんですよ。

ちなみに本書の最後に「読書案内」と称して関連書籍の紹介があるのだけど、その最初がクリストファー・アレグザンダーであり、まぁやっぱり良い思想・書籍は長い年月を経てもその価値は落ちないんだなって思った。

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉

ワインバーグのシステム変革法 (ソフトウェア文化を創る)

ワインバーグのシステム変革法 (ソフトウェア文化を創る)

ワインバーグのシステム洞察法 ソフトウェア文化を創る〈2〉

ワインバーグのシステム洞察法 ソフトウェア文化を創る〈2〉

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

ワインバーグの文章読本

ワインバーグの文章読本