レビューは「書かれていることが正しいか」だけでなく、「書かれていないことが書かれていなくて正しいか」を見ないといけない

レビュー、書いてあることの確認はしやすいけど、書いてないことをどうやって「書かなければいけないけど、書かれてないこと」をどうやって見抜くかってところが腕の見せ所で有り、レビューする意味なんだよね

— magnoliak🍧 (@magnolia_k_) 2021年3月8日

レビュー、書いてないことを検知しなければいけないので、完全にエスパーの仕事ではないですか、ニュータイプですか、なんですか https://t.co/f2S6TQMbQ9

— magnoliak🍧 (@magnolia_k_) 2021年3月8日

初めてレビューなるものをやることになったとき、なにをどう見ればいいのか分からなかった、という経験の有る人は多いと思う。

そしてそのうち、「書かれていることが正しいか」だけでなく、「書かれていないことが書かれていなくて正しいか」を見ないといけない、ということに気づくことで一段階スキルが上がった感覚を覚えたりしませんでしたか。

ただ、その「書かれていないことが書かれていなくて正しいか」を確認し、漏れていれば指摘するためには、「全体を把握していること」「もとの構成に一貫性があること」など、さまざまな前提がある。誰にでもできるわけじゃないし、組織としてそれができる人を育てて、用意していかないといけない。

レビューがただの儀式になって、「レビューをおこなったこと」自体が意味を持つ場面も有るのかもしれないけど、本質的に正しい成果に近づくためには、上記のような観点で見ていく必要がある。

当たり前かな…とも思ったけど、案外当たり前のことが当たり前でなかったりするので、あえて書いてみた。

magnoliak🍧 (@magnolia_k_) | Twitter

アジャイル人材って、どんな人たちなんだろう？

プロダクト・バックログや、スプリント・バックログに何を入れるべきか、開発する側として議論に積極的に参加せず、タスクを消化するだけだったとしたら、それじゃアジャイルの経験が有ると言えるのか、単にせわしないウォーターフォールに参加していただけではないか、とかなんとか

— magnoliak🍧 (@magnolia_k_) 2021年3月7日

• 事業に貢献するプロダクトの成長スピード感を達成できればアジャイル人材？
• イマドキのモダンなプログラミング言語やツールチェーンを使いこなせればアジャイル人材？
• 単にアジャイルを実践しているプロジェクトに参加していればアジャイル人材？

”アジャイルソフトウェア開発宣言”で書かれていることも当たり前と言えば当たり前だし。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

『みんなでアジャイル』は、開発組織だけでなく、企業のさまざまな組織が、アジャイルに対応できるように変わるためのヒントが書かれている。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

この本で書かれていることから一つアジャイルなスタイルが実践できているか否かの境目を取り出すとすれば、「不確実性を計画する」という概念かもしれない。

アジャイル人材の定義を知りたいけど、結局「サービスを届ける意思がある」「素早くフィードバックして変えていく」「ツールを使いこなす」というところに収斂していくのかもしれない。

みなさんの考える「アジャイル人材」の定義を教えてください。

magnoliak🍧 (@magnolia_k_) | Twitter

古典に学ぶ……『プログラミング作法』……いまでも通用する”全部入り”の1冊

『プログラミング作法』を久しぶりに読み返している。

プログラミング作法 (アスキードワンゴ)

原著は「The Practice of Programming」のタイトルで1999年に出版され、日本でも2000年に一度翻訳されて出版された。 その後、2017年に再度翻訳版が出版されているけど、多少の誤植が修正された程度で中身は元のままだ（表紙は以前の方が好みだったけど）。

さすがに20年以上前の本なので、出てくるコード例がC、C++が中心で比較的新しい(!)言語としてのJava、Perlという辺りは、古い。また冒頭が割とコードレイアウトの話が続いたり、C言語のgetsは使わないとか、「いまここで言った方がいい？」みたいな話題も混じってくる辺りは、フォーマッタにまかせておけばいいし、推奨されない使い方は静的解析ツールにまかせておけばよくない？とも言える。コメントの書き方なんかは、納得感あるけど。

ただ、「アルゴリズムとデータ構造」「設計と実装」「インタフェース」の流れは、言語は変われど、”変わらない基本”が詰まっている。「デバッグ」や「テスト」はツールチェーンが発達した現代にそのまま使うかはアレだけど、考え方は充分に通用する。

---

で、なぜ読み返しているかというと、この300ページ強の本に、プログラミングの基本的な要素が全部ギュっと詰まっている感じが好きなんだ。このリズム、サクっと進む感、それでいてきちっとコードが必要な分だけきちんと出てくる。ざっと読んでもいいし、じっくり読んでもいい。悪いコードは「ここは悪いコードですよ」という注釈付きで出てくる。

ここまでコンパクトにまとまっている本はなかなか無いので、まずはこの一冊を読む、みたいな使い方がいいんじゃないかな、と思う。

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

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

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

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

---

例えば区分コードみたいな値が有ったとして、1の時は○○という処理、2,3,4の時は△△という処理を実装する、という状況のときに、条件分岐が「区分コードが1か、それ以外」で分岐させると、2,3,4と限定しておきたかった、というドメイン知識が失われたりしませんか？みたいなことが有ったり無かったり

— magnoliak🍧 (@magnolia_k_) 2020年7月3日

以前、暗黙知のスライド書いたときにも取り上げたけど、「年齢計算ニ関スル法律」には2月29日生まれのことは何も書かれていないけど、「前日の夜12時に一つ年を取る」というビジネスルールなので、”結果的に”2月29日生まれに例外ルール無しに対応できているんだけど、それは結果論なんだよ

— magnoliak🍧 (@magnolia_k_) 2020年7月3日

さんざん検討して、シンプルなルールで、複雑なパターンや例外パターンに”結果的に”対応できているって事例はおそらくたくさん有ると思うんだけど、その”対応できている”という事実は容易に失われるんだよなぁ

— magnoliak🍧 (@magnolia_k_) 2020年7月3日

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

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

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

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

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

---

magnoliak🍧 (@magnolia_k_) | Twitter

2月のブログの振り返り

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

blog.magnolia.tech

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

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

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

blog.magnolia.tech

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

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

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

blog.magnolia.tech

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

blog.magnolia.tech

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

blog.magnolia.tech

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

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

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

blog.magnolia.tech

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

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

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

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

magnoliak🍧 (@magnolia_k_) | Twitter

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

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

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

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

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

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

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

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

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

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

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

とりあえず技術力を上げたいなら、適切にissueが書ける訓練をした方がいいし、添削してくれるひとを身近に探した方がいい

issueがちゃんと書ける言語化能力は全ての第一歩

— magnoliak🍧 (@magnolia_k_) 2021年3月2日

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

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

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

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

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