「is_null()を使うか === nullを使うか」と何気なく聞いてみたら面白かった

PHP

と軽い気持ちでツイートしてみたら知見が寄せられて面白かった話。
「全然その辺りは好みの問題じゃないかな〜？」というのがあったんですが、1発目・2発目からガッチリ論拠のある意見をもらって「おぉ、なるほど・・・」となった次第。

そもそも

PHP 8 で作る JSON パーサ / php8-json-parser - Speaker Deckを見ていて、「お！ ===だ！」と思って気になったんですよね〜。 該当コードは↓。 github.com

(ちなみに発表内容がすごく面白かったです、今だとLIVE配信のアーカイブ観れますが恐らく後日セッションごとに切り分けられたものが？上がると思うので、動画のリンクは止しておきます)

自分的に「is_null の方が読みやすくない？」って思っているフシがあったので、さてどっちだろうな〜と。

※ 他の方のツイートを埋め込み表示にするの何となく気がひけるので、リンクの明示だけにしておきます

わたしは

is_null() を使う事が多いな〜と思っていて、

  • null と「同じ」である、という表現が何となく気持ち悪いような
    • これ多分SQLのせいだなーって話をしている内に思った
  • 自分は「名前がついている処理」はなるべくソレを使いたいな〜という性質がありそう
    • 「それが用意された」のに相応の理由があるのかな、という気がする
    • 関連して「目立たせておくべき」で「書き換えor読み間違いにくい」というような気もする

落とし所としては

  • 書き方が揃っている ことが最重要な気がする、それさえ抑えていれば「些細な問題」に収まる範疇なのかな？という感覚
  • それを決めるための「論拠」があった方が良い、というのは間違いないです！
    • === null の方が「しっかり」してそうだな、って話を聞いてて思った
  • また、こういうのを「ルール」にしたら(人の力に頼らず)linterに仕事させたい！！

ってことで、以下寄せられた意見

=== null 派

パフォーマンス的な面

「FQSENで記述しないとオーバーヘッドが大きくなる」というもの。
このレスが速攻で飛んできて「すげぇ！」「ありがてぇ！」ってなってしまったw
(いや本当に、反応もらえたとしてもゆるふわっとした感じだと思ってたので。)

PHP的に is_null($v); は2通りの解釈ができて、

  1. 自身が属するnamespaceにおける関数、 ns\is_null() というもの
  2. グローバル(組み込み関数)としてのis_null、すなわち \is_null() というもの

もし \is_null() と明示的に呼ばれていれば問題は起こらないが、そうでない場合、まず1のis_nullを探してから2のis_nullを呼ぶ、というものになる。

もちろん use function is_null; と書けば問題はない、が、面倒くさいのでは・・・？と(個人的に)思った。
それだったら最初から === null でいいじゃん、というもの。

コレ自体は「言われてみればそうだな、確かに確かに」と思ったんだけど、補足のリプで「opcodeを追ってみればこんなに自明」という風に情報を示されて、「なにそれ面白い早く俺もそっちに行きたい」という感情を刺激されてしまった・・・・

また、別観点として「そもそも明示的に \hoge() と書くの良いかもな〜」というのも思った。
誤読が少ないし、分かりやすい。

ちなみに、逆に言うとルート空間の明示を省略して書くことで「関数をぶっ壊す」というのも可能で、実際にfile uploader周りのテストを書く時に「is_uploaded_file()を無理やりtrueにする」みたいな処理を過去に使ったことがある。

<?php

namespace Vendor\Package\FileUploader\Uploade {
    fnuction is_uploaded_file($filename)
    {
        return true;
    }
}

みたいな。

シンプルさの面

if (is_null($v)) とした時に、

  1. まず is_null: bool がチェックされて
  2. 次に if (bool) が チェックされて

とか何なん！的なもの。(って書き方だとニュアンス伝わりにくい、「関数をコールするよりは式のほうがシンプルじゃないか」的な)

また、「他の値(例えば is_true())の時もそうやってやるんか？？」と言われ、なるほど〜見方によっちゃ揃ってないな？という。
これもまたなるほど・・・

is_int とか is_string とかは使い道ありそうだけど、「nullかどうか」は「null以外はnullじゃないの」となるので、違和感があるな〜とも思った。
「値が1つしか存在しない」というのを前提にすると「nullを特別扱いするか？」が恐らく感覚の境目になってきて、

  • nullは特別だからis〜 でやろうよ
  • is〜を使うことで「値が1つ以上あるから、値の種類で判定したい」みたいに誤読しない？

という対立する判断に進みそうかもな。報われない気持ちを整理したくなるな。

そういや全く関係ないけど、is_string() に Stringable が来たらどうなるんだろうな？勿論「objectなんだからstringじゃない」と言ってもらわないと困る気がするけども。
(お、こういう時にphptを見れば早いのでは・・？💡)

他言語だと == じゃね？

GolangやTSを例に引いて、「”無”なオブジェクトとの比較も == で行うしね、違和感とか覚えなくて良いはず。寧ろ自然じゃないかね？」というもの。

言語特性としてPHPは「色々な歴史がごちゃまぜになっている」という面があると思うので(良い悪いではなく！ただ、間違いなく特徴ではある)、使い手側が「負債を引きずり込みすぎない」というのは意識した方が良いよね〜って気持ちも個人的にあります。
(しかしそういう「PHPのゆるさ」みたいなところについて、RFCでこの仕様はこの言語の暗黒時代の遺産を引き継いでいるって表現を見た時は笑ったw)

その観点から言うと、「他の言語やコミュニティの例に倣う」というのは時に効果的だな〜って思います。

is_null() 派

SQLだとさぁ・・・

SELECT * FROM table WHERE a = NULL;

って書きませんもんね・・！ 全く違う世界の話を引きずらないで、と言われればそうなのですが、やっぱり「nullは中身が確定していない事を表す」はずなのに「イコールで比較とは果たして・・？」っていう気持ち悪さが頭をよぎります。

という人が他にも居てよかったw

(なおココでpy の if v is None: を挙げている人がいないのは、私のTLの偏りだと思います😃)*1

ちなみに、@d_horiyama_webさんにもらった「lintに従う」というのは凄く良い判断基準だよな〜と思っていて、まさにこういう「自転車置き場の色」は機械に覚えさせておいて判定させる、というのが良いですよね。*2

静的解析等で「=== nullを使え」という風になっていれば、それは凄く正しいというか「そうしましょう、なぜならそうすることが良いからです」みたいな話に落とし込めるので現実的に素敵な話。
ただ、これは独自に拡張していたルールなのかな・・？パッと探ってみて見つけられなかったです💦
Pslamでの挙動が一時的に不吉だった時期があったのかな？
=> is_null($value) not treated same as null === $value · Issue #2578 · vimeo/psalm · GitHub

実際問題、そういうのルール作って良い気がする。

f:id:o0h:20201214000919p:plain Psalm - a static analysis tool for PHP

f:id:o0h:20201214000941p:plain Playground | PHPStan

f:id:o0h:20201214001031p:plain Phan in Browser

て感じで、Psalm、PHPStan、Phanだと検出されたIssueなし。PhpStormでもソレらしきInspection見つからなかった・・かな？

「専用の表現あるなら使えば」派

「nullを示すもの」を判別するための「専用の書き方」があるのであれば、それを利用することで読み手の注意を引いたり「何をしたいのか」を判読するコストが下がるのでは？というもの。
(割と期間を一緒に働いていた元同僚なので、そういう温度感を互いに共有していたのかもな〜というメタな感想もいだきましたw)

それと、このツイートで情報として「PHPCSがsquizのrulesetで is_null() を禁止している」という情報が 💡
確かに、見てみるとForbiddenFunctions として設定されています。

github.com

なるほど、PHPCSの文脈で探ると何かあるかな・・？と思ったら、PHP-CS-FixerのIssueで興味深いものが出てきますね。

github.com

ここでベンチマークもはられていて、何だか条件によっては\is_null() の方が有利になる？という話も。

  • PHP 5.6: is_null($x) is 2.5x slower than null === $x with opcache disabled, and 2.2x slower with opcache enabled
  • PHP 7.0-7.2: the performance of both is the same, with and without opcache
  • PHP 7.3-7.4: is_null($x) is 1.2x faster than null === $x with opcache disabled, with opcache enabled there's no noticeable difference (but still, is_null() is 0.2% faster).

とはいえ、このIssue自体は「はっきりしたことが分かるまでは積極的にやる程でもないかなぁ」「生じたとしても微細な差分なので、今までのやり方を変えるほどかどうかは微妙？」というような温度感になっています。
(closeはされていないけども)

ということで

どっちかっていうと === null の方が分かりやすいのかもな〜って気がしてきました！
が、

  • まぁチームの好みに合わせて
  • lint入れてガッとやっちゃうのが健全じゃないかな？
  • でも多分、世の中の多くの人は大人なので「別にどっち来ても気にしないよ(表向きはね)」で済ませているんだと思います

というものです。

ちなみにアンケートも実施されているのですが、=== が優勢かな 😗

あと、他に「is_null() が (isset()と違い)関数なのこんがらがるね」という声もありました。
「is_hogehogeとishogehogeがあるの命名ばらばらで気持ち悪い」と思うか、仮に is_set() だったとしたら「is_hogehogeという命名の中で関数だったりそうじゃなかったりするの怖い」と思うか・・・？
って考えると、脳みそが痛くなりそうですね！とか思ってﾌﾌｯてなりました。

なんにせよTwitterで色々と意見もらえたのが楽しい、こういうのあんまり仕事とか同チーム内でやると変な疲れ方しそうでもあるので・・！

*1:これ https://twitter.com/tadsan/status/1338075560979779584 は私も思うところ、というかinstanceof だけ文章っぽいのが違和感あるんだよなぁ。。

*2:今回の場合、技術的な観点での「こっちの方が良い」という意見が寄せられてますが、「readabilityに勝るもの無し」な差だと思うので「些細な問題」と言わせてもらっています。もちろん、意見表明(まして根拠の説明)をしてくれた人を軽んじるとかそういうアレじゃないです！！！

「光遅い」と言い放ったエンジニアさんの影を未だに追いかけている

PHP

いや、タイトル「何が何だか」って感じですが・・・

#phpcon2020にて喋ります〜

明日、どころか・・もう日付変わって本日行われるPHP Conference Japan 2020にてお喋りしてきます 🎉

fortee.jp

自分は「Composer2.0」の話をしますよ〜とプロポーザルを提出し、採択して頂きました。
実は「Composerの新バージョン」については、昨年のphpconでも取り扱おうとしていた話題ではありました。単純に発表時間が足りなかったのと、また開発状況としてもまだまだ途上だったので見送っています。

それが、1年越しに開催される同イベントで、CfPオープン期間には「v2リリースの目処が立ち」本番を迎えるまでに「安定版がリリースされ」・・・と、着実に続く時代の流れを感じながらも「もしかしたらずいぶん遠くに来ちまった」とも思ったりしちゃっています。

さて、そんな訳で今回お話する内容は自分の中では「前回の内容に引き続き」という面もあります。
(ただ、結局のところ実際にスライドに落としてみたら独立した内容になりましたがw)

その内容を知らなくても理解できる・・というか「読んでいたところで直接の役には立たん」かも知れませんが、
このセッションタイトルやプロポーザルに反応してくれた方であれば「Composerの話」は面白がってくれるんじゃないかな？ということで、紹介しておきます。

続きを読む

プロダクトのための技術力をどう上げるか: ⓪なぜ技術力は必要とされるのか

考え事とか

イントロ

自分は「どうやったら技術力を上げられるかな」という点に興味があり、また最近では「組織から継続的に"成長"を与え続けられるのだろうか」という点に興味がある。
まずは自分の中の認識や仮説みたいなものを形式知としてみようと、取り留めなく散文を吐き出していたのだが、その中で幾つか重要なエッセンスがある事に気付いた。

「取り留めなく」と書いたが、実際に気づいた事や感じた事を1つの文書に纏めようとすると、実際かなり散らかってしまっている(し読むのも書くのも疲れる)。なので、ポイントを絞りながらそれぞれを複数の文書に分け、現在の観点・思考を表して見ようと思った。
この記事がその第1段である。

あくまで「自身の内にあるこんがらがった思考を解きほぐしておきたい」というのが大きな狙いであり、セルフ壁打ちのような効果を期待して取り組むもの。

記事の作成のためのメモ

  • ビジネス対する要求は複雑化し続ける
  • ゆえにソフトウェアも必然的に複雑化し続ける
  • 要求に応えるためには「リスク」が避けられない
    • このリスクをミニマムにしていく事が重要
  • 何がリスクを増大化させるか
    • 本質的な命題の難しさ。「答えのない問い」であること
    • 打手の少なさ。
  • 何がリスクを最小化させるか
    • 仮説を築き、世に問うまでを短くする
  • 技術力の価値 = アジリティを高く保つ武器といえる

本論

まずは「そもそも技術力とは何のために求められるのか」という所を考えてみたい。

勤めている会社などにおいて、「組織の技術力を高める」という命題が標榜されたとする。以下の疑問が湧く。

  • 「技術力」という言葉を安易に使いすぎなのでは、という嫌いがある
    • 自分もそうだし、恐らく他人もそう
  • そもそも「技術力」というのが何であろうか？っていうのが曖昧なままで過ごされている気がするし、あるいは「目的」なき「手段」として存在が許されていないか？とすら思う

この中核にある「技術力」という概念、これに対する「なぜなのか」「なにであるのか」を真正面から捉えることなしに、「それを高める」という夢は叶えられないのではないか。つまり空中分解しかねない。
今回のテーマは、そうした問題意識を下地として思考を試みたものだ。

以下、先に社内向けに書いた文章が先に公開するに至ったので、そちらをベースに転記。
(・・・なかなか主語がでかい話であり不安はあるけど。。)

「目的」から考える技術力

技術力が開発に何をもたらすのか？おおよそ、これらの3つの価値を提供するものと考えている。

  1. スピード
  2. 品質
  3. 妥当性

この3つを兼ね備えると「アジリティ」っていう価値がもたらされ始めるはず。何故アジリティとやらが必要なのか？どう良いのか？は、noteのマガジンで秀逸なのものがある。是非読んでみてください。

note.com

これらのパラメーターが強化されることから、「技術力が高まることは勝ちにつながる」ものといえる。

スピード

開発するスピードが「良さ」なのは特に説明いらないと思う。ソフトウェアやシステムを進化させるのが我々の仕事なのだから、同じ仕事が10時間を必要とするよりも2時間で終わった方が良い。

品質

品質は、例えば「バグを生まない」とか「拡張性が高い」とか「読みやすい」とか。ざっくりいうと「良いコード」というのは「品質」って言葉に代替可能だと思う。もっと言うと、結構「品質の高いコードとはどんなものか？」に対しての回答は人それぞれかもしれない。1つの示唆として、品質という話であればマーティンファウラーの記事に気付きが多い。

martinfowler.com

「どう良いのか」は語れる。が、「何であるか」は難しいかも知れない。むしろ、「良いコードとは」という問いに対する答えを、個々人が持っていると良いと思う。(自分の場合、長らく「リファクタビリティ」が良いコードを言い表すものだと思ってたけど、最近はもう少し広い意味で「書き換えやすさ」かなーって感じ)

妥当性

(コレが1番分かりにくいかな?)
例えば「RDBにするか検索エンジンを使うか」みたいな選択はあるし、ECSかGKEかみたいな選択もある。そこを失敗すると、サービスのスケーラビリティの問題だったり(非)機能要件への適合が難しくなったり。ソフトウェアで言っても、例えばよりミクロな話、外部ライブラリを使うか自前で薄いコンポーネントを使うかみたいな選択とか。オーバーエンジニアリンクになるか、腐敗臭のするデザインになるか?という所にも繋がる。

そしてアジリティ

この3つが満たされれば持続的な成長を維持し続けられるようになるでしょ、それを保証するのが「技術力」だよ、と。
アジリティとは「機敏さ」という意味で、これがあると「柔軟さ」が獲得される。
この「柔軟さ」がビジネスの価値を高める、成功の確度を上げるための強力な武器になる。

anti複雑さ

なぜ「ビジネスの進化には柔軟さが必要」か？

そもそもの大前提として、「ビジネス」は複雑であり、ビジネスを微分したものである「ソフトウェア」や「ソフトウェア開発」も複雑なものである。
何がマーケットに受け入れられるか？自社、競合を取り巻く環境は？顧客や潜在的なターゲット層の「気分」は？
それらは正確に「計測」することも難しければ、正解を教え導いてくれる師範もおらず、更に悪いことに「次の瞬間には状況が変わっている」ということが常である・・・という、複雑さ。

そんな複雑な問題に、どう対処していくか？ 1つのアプローチが「実際のマーケットに、1回でも多く問い、フィードバックを回収し、また次の一手を打つ」というもの。

アジリティを得ることで、「素早く・小さく失敗し、地に足のついたフィードバックを元にして、要改善点を克服し、また素早く世に問う」というループを回せるようになる。
「1発の大振りで成功するかわからないから、100回打席に立ち、その度にフォームをチェックし、修正し、珠に当てにいく」というもの。その逆に、「大振りをするための準備が整うまで、打席に立たないでいる」となれば、フィードバックを得ながら改善をするための(あったはずの！！)機会が損なわれいてく。必然的に、失敗へのリスクが高まる。

アジリティと、スピード・品質・妥当性

とにかく「打席に立つ回数」が必要、ということで「スピードが重要になる」。
スピードが遅いと、打席に立てる回数が減り、「失敗した時に取り返しがつかない」という硬直性も高まる。また、少ない打数で上手くやるには、非常に綿密で高度で正確な「予測」が必要になる。・・・市場はあんなにも気まぐれな生き物だというのに！

品質はどうだろうか？
これは、先に上げたファウラーの記事に詳しい。「内部品質の低下は、速さの逓減をもたらす」というもの。付け加えるのであれば、外部品質だって、低下すれば顧客の離反を招く・・・すなわち「得られるフィードバックの量が減る」という結果をもたらすはず。

最後に妥当性。
「適切な選択」というのは、そもそものスピード(初速)に大きな影響をもたらす。あるいは、「初期の誤った選択」は、後に取り返しのつかない致命的な「負債」となるかもしれない。これも、やはり硬直性を生じさせる。

結局、スピード・品質・妥当性はそれぞれ不可分であり、また高いアジリティを実現し維持し続けるためには、これらを突き詰め続ける必要があるのだ。

「複雑さ」に対する補足

「ソフトウェア開発は本質的に複雑さを伴うものである」という点について。
「変更しやすい」ことを以て「ソフト」な資産、と称される。裏を返せば、「変更されること」が存在価値として織り込まれている、とでも言うべきか。そうやって、次々に「進化していく」ことが宿命付けられている。

「なぜソフトウェアは進化する(させられ続ける)のか」という論点について、論文があるという。

いわく、「使われ続けると、利用者(やその代理人たるプロダクトオーナー)からの要求が生じ、それに応えることで進化を求められる」「ゆえにソフトウェアは進化し続ける(複雑さを増し続ける」ように考えられる。

ソフトウェア開発はとても複雑なものである。

アジリティを備えたプロダクト組織になる

何のために会社がありビジネスをやっているのか？といえば、経済的な価値を生み出すためだと思う。それは、顧客価値を中心に生み出される付加価値の総和である。
顧客価値は創るのが難しい。そのために、複雑な問題に挑む必要がある。
複雑な問題に立ち向かうための武器がアジリティ。
そして、(働く上での)技術力の目的・・「何のための力なのか？」という問いに対して、今の所の自分の見方が「プロダクト開発のアジリティを高めるため」である。

それって、我々に何かメリットありますか？

ここまでずっと「ビジネス」「組織」を主語において話をしてきたので、「なぜ良いのか」がピンと来にくい。
なんだか「正論」という感じで、それが「開発者1人1人にとって関係のあることなのか」については、説得力を持っていないような。

「高いアジリティを持つ組織」で働く、というのは開発者にとってどんな体験だろうか？
結論から言えば、恐らく「そこで働いていてワクワクしながら開発に携われるようになる」というものだと思う。

開発に対するモチベーションというのは人によってそれぞれだというのを前提としつつ、広く共通するのは「何かを良くしたい」という想いではないか。
例えば「ユーザーを喜ばせたい」とか「自分の納得が行くような綺麗なコードを書きたい」とか「より高いパフォーマンスを実現したい」とか。
そうした際に、組織がアジリティをもって開発できていたらどうなるか？恐らく、これらの前向きな気持ちを持った人たちには嬉しいと開発体験につながると思う。

「ユーザーを喜ばせたい」人たちにとっては、「開発コスト(時間、リスク)が高いから難しい」という理由で、望ましい機能の実装提案を却下される場面が減り、「良いと思えるものを作って、リリースする」ことに集中できている状態。或いは「新機能をデリバリーする」ことへの組織が持つコストが低く抑えられることで、リリースした後にユーザーの反応を観察し、取り入れながら更に良い機能を開発していく！というのに集中できる。
これらはスピードが低ければ難しいし、品質が低いようだと「保守に当てるリソース」によってエンハンスメントやアイディア出しのための力が逼迫されることになる。

「良いコードを書きたい」という人たちにとっては、実践的なツールやサービスの導入も、しっかりリスクをコントロールした上で試してみることも出来る。
開発者というのは、『ソースコートを通じて活動する」のだから、ある側面では「自分たちのプロダクトのユーザー」でもある。自分たち自身を「ユーザー」として、開発体験についてのフィードバックとそれを踏まえた改善のサイクルをクルクルと回しながら「より良い開発」を獲得できる事が重要。
プロダクトと一緒に開発チーム自体が進化のペースを保ちやすい状態だ。「高い生産性を生む」という価値実現に向けて、不確実性を制御しながらの前進がもたらされる。

そして深く広い見識と自信から来る「妥当性」は、品質・スピードを安定的に支えるために欠かせない。もし妥当性に関する意識が低いようであれば、「なんでもやってみる」の後の棚卸しが実現せず、負債が貯まり続け硬直性の増加を招く。

「どんな願望もアジリティによって叶えられる」・・・などと言えば眉唾物になるが、しかしながら、実際問題として「前を向き本質的な”コト”に意識を向ける」ための基礎力として「アジリティ」というのは非常に重大な価値を持つ。その獲得のために、やはり技術力というのは重要な下地となる。

—✁—切り取り線—✁—
なんか偉そうな文体で書き始めてしまったばかりに！！
あまり気持ちが籠もらないのですが！！

「技術力つけるときっと楽しい事をたくさんやりやすくなるぜ〜〜！！」って思っています！！！！という事！！！

あ〜〜〜〜楽しいことやりたくない！？！？
楽しいことって、どうやったら出来るんだろうね！！

??? 「 アジリティです、アジリティについて考えてみるのです・・・ 」

って感じ
—✁—切り取り線—✁—

結び

結局の所、組織人としての観点から考えれば、働く上での「何が目的か」というのを平たく言えば「ビジネスを成功させるため」となる。
しかし、ビジネスやプロダクト開発は複雑で大変に難しい。成功の確度を上げる必要がある。その為には「いかに柔軟に動けるか」、「高速にフィードバックループを回せるか、すなわち『問う・観察する・学ぶ・活かす』のステップを繰り返せるか」に拘る必要がる。それがアジリティという言葉で表せる。
そのアジリティを実現する事こそが、開発組織にとっての『技術力の価値」ではないか？と、自分は考えている。
ざっくりと「技術力」というと余りにも大味な表現になるが、「スピード」「品質」「妥当性」という、それぞれが相互に密接に関わりつつも個々が重要な意味を持つエッセンスに着目し、拘り、磨きたい所。

「ビジネスを上手くやる」のに集中できている状況において、人は「コト」へ集中し、本質的な価値創造に取り組めるようになる。
すると、それが「ワクワク出来る開発業務」へと至るはずだ。

その辺りを追求することで、「ビジネス的な価値」「自身の欲求に対する回答」の折り合いがつく場所に到達できるのではないか？と考えている。

「\Throwableをcatchしないで」と伝えていく

PHP

「Throwbaleをcathcしない方が良いよ、って前に言われたことあるけどアレってソースある？」と言われまして。

f:id:o0h:20201128140525p:plain f:id:o0h:20201128175047p:plain

※ 画像はイメージです

自分としては、どちらかというと「考えていったら自然とそう思えたので」という生き方をしており、確かにソースか〜探したことなかったなぁ。。。となり。即答できず。
「理屈はわかる」のと「毎度説明するのが面倒」は別物ですよね。
(寧ろ、折角PHPの本を書いたのだからそこで言及しても良かったかもな〜)

f:id:o0h:20201128140847p:plain

「話すの面倒くさいと説明のクオリティが毎回変わる」ので、あまり気持ちよくありません。
かといって、「毎回ちゃんと説明する」のは非常に骨も折れるので、それもやっぱり気持ちよくありません。

ということで、「Throwableってなに？Exceptionと何が違うの？調べてみました！」です。

  • tl;dr
  • いんとろ
  • 前提: ポケモンキャッチ
  • 改めて \Error とは
    • なぜ Error(throwable) が必要だったのか？
    • 捕捉・復帰ができない
    • エラーハンドラとの兼ね合い
    • finally, __destructとの兼ね合い
    • RECOVERABLEであってもRECOVERするには扱いづらい
  • Error が何か？を理解すると、catchしたくなくなる(はず)
  • まとめ

・・・書いていたら思いの外長くなったので、tl;drをつけます😌

tl;dr

これらの文献のうち、特に顕著な表現としてtrowski氏とThrowbaleのRFCの表現がわかりやすいです。これが「何かソースありますか？」に対する回答、ということで良いのではないか？

Error should be used to represent coding issues that require the attention of a programmer. Error objects thrown from the PHP engine fall into this category, as they generally result from coding errors such as providing a parameter of the wrong type to a function or a parse error in a file. Exception should be used for conditions that can be safely handled at runtime where another action can be taken and execution can continue.
Since Error objects should not be handled at runtime, catching Error objects should be uncommon. In general, Error objects should only be caught for logging, performing any necessary cleanup, and display an error message to the user.

https://trowski.com/2015/06/24/throwable-exceptions-and-errors-in-php7

また、ThrowableのRFCでも「キャッチすべきではない」と端的に説明されとります

catch (Error $e) and catch (Throwable $e) may be used to catch respectively Error objects or any Throwable (current or future) object. Users should generally be discouraged from catching Error objects except for logging or cleanup purposes as Error objects represent coding problems that should be fixed rather than runtime conditions that may be handled.

PHP: rfc:throwable-interface

この辺りが、「ちょっと調べてみよ＆ブログに残しておこ」と思ったきっかけに対する答えとなっております！

以下本編。

続きを読む

プロダクトマネジメント ――ビルドトラップを避け顧客に価値を届けるを読んだ

読書記録

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本（ソフトカバー）

「Amazonでも予約注文のタイミング?によっては発売日にちゃんと届く」という事を知った、というのが本書に関する収穫の1つとなりました。
お急ぎ便使えることもあるのか・・ f:id:o0h:20201028134310p:plain

ということで、一昨日にかけてババーっと読んで、読了しました。
いや〜読みやすかった面白かった。すごい希望に溢れてて「なるほど、こうありたいな！」とワクワクしながら読み終わった。

どんな本？

  • 「プロダクトマネジメントとは」「プロダクトマネージャーの仕事とは」という切り口で、顧客に価値を届けるためのマインドセット、組織の姿、戦略フレームワークについて書かれた本
  • リリース数などのアウトプットに着目することで陥る「ビルドトラップ」の症例と、そこから脱却するには？というのが主題
  • 必要なのは、アウトプットではなく顧客に届ける価値 = アウトカムに注目した、プロダクト主導の組織に代わることだと解く
    • 「作ること」が目的になっていないか？「何を解決するか・どんな価値を提供できているか」に集中できているか？
  • 架空の企業の物語をとりあげながら、著者自身の経験してきたエピソードやNetflix・Amazonといった「プロダクト主導」「顧客中心」で成功している企業の話も織り交ぜながら解説していく
  • 全体的に平易な表現で文章も読みやすかったです。ボリュームも少なめ(224ページ)

ざっくり感想

  • いまいち「プロダクトマネージャー」ってどんな仕事なの？どういう姿であるべき？というのが分かってなかったのですが、知れてよかったです
    • 「何故作るのか」「どんなアウトカムを提供するのか」というのをチームにリマインドし導く仕事
    • 「「何を作るのか」「どう作るのか」については、PdMではなくチームが考えるもの
      • 「何を作るのか」にばかり集中して、「自分のアイディアを他人に押し付ける」のは良いPdMではない(アンチパターン: ビジョナリー、ミニCEO)
      • ユーザーにとっての価値、ビジネスにとっての価値を上手く抽出・定義・実現するための方向づけを行う役割
    • 「プロジェクトマネージャーは「いつ」に責任を持つ」「プロダクトマネージャーは「なぜ」に責任を持つ」みたいな話、なるほど〜
  • 言うは易し行うは難し系だな〜と思いますが、いわゆる「全員をハッピーにする方法論」ではあったので、ここに近づくために少しでも出来ることはあるかな？みたいな気持ちを持っておくのは良さそう
  • 「成功指標」を明確にする。そのうえで、「実験」を素早く繰り返して進んでいく
    • =時間的、金銭的コストが最小限な時点でフィードバックを得られるようにする
    • "重要なのは、自分たちのアイデアだけが良いアイデアなわけではないことを理解することです。"
    • "根本も原因を見つける前に問題を解決しようとする落とし穴にはまるのは簡単です。私達は問題が何なのかがわからなくても、問題を解決しようとしがちです"
  • 企業の「ビジョン」から始まり、どのレイヤーにも「なぜ」をつなげていくべきだ〜という視点が面白かった！
    • レイヤー=ビジョン > 戦略的意図 > プロダクトイニシアティブ > オプション
      • ビジョン = 企業がどこに向かっていくのかを説明するもの
      • 戦略的意図 = "現在の状況を踏まえて、ビジョンを実現するために自分たちが出来るいちばん重要なことは何か？"
      • プロダクトイニシアティブ = プロダクトの観点で課題に取り組みにはどんな問題を扱えばよいかを説明するもの
      • オプション = プロダクトイニシアティブの実現のための手段
  • アジャイル開発が嫌いなん・・？ってくらいの雰囲気を感じましたが、批判というより「アジャイル”開発手法”で足りていない部分(そもそもスコープ外の部分)がある」というのを忘れて盲目的になってんじゃねーぞ！みたいな意思なんだと思います
  • 一方で、「学習から学ぶ」「小さく素早く失敗してリスクを最小化する」みたいなところは、アジャイルと同じ方向を見ている気はする(↓に書いたClean Agileの一節とか)

アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。できるだけ早く知りたいのは、そうすれば状況をマネジメントできるからだ。

Clean Agile 43

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

読書記録

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

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

大変に面白かった。個人的には、色々な啓蒙に富んでいるし今日からぜひ使っていきたい！と思える視点に満ちているという点で、「アイディアの作り方」に通ずるものを感じる。

自分は以前から「思考の枠を外す」と呼んで大事にしている視点がある。意識的に、色々な「もしooだったら」を、極端なくらいに脳内で入れ替えた上で今目の前にある問題を眺めてみる〜というものだ。
この本は、まさに「枠」を俯瞰して眺めてみようという取り組みが大量だった。

全体的には(本当であれば)難しいことを語っているように思う。しかし非常にユーモアの聞いた語り口と、思わず笑ってしまうようなスパイスの効いた(時に効きすぎた)イラストによって、この本の存在を「芯の強い”教授”」から「分け隔てない友達」のようにしていると感じる。
高度な問題をバシバシとやっつけていくような本も良いものだけど、こうやって気軽に頭を使ってみたくなるようなものも良いもの。

読書メモ

以下、実際に読みながら作っていたメモから。
琴線に触れた部分なんかの感想が中心。

(ただ、寝る前にベッドの中で読み進めた部分についてはメモがなかったりする😇)

第1部

P27
ユーモアのセンスのない人のために問題を解こうとするな。

個人的にも「ユーモアって大事よね」というのは常日頃思っていて、ブレスト何かをした時には「ギリギリふざけてないか少しふざけている」ような案を序盤で出せるように、という意識をしてさえいる。それがあってこの一文はグッと来た。

「ふざけたことを言っている」として発言を遠ざけたり蓋をしないで、「そんな馬鹿な！」というくだらない話も一旦受け止めて乗っかってみて、それが柔軟で豊かな視点の獲得につながる〜みたいな話かな。ブレストを「大喜利」のような感覚でやってみる、というのもそれに繋がる話かもしれない。
この文言自体が「おいおい本気で言ってるのか？」みたいなある種のナンセンスさを感じるような部分もあり(ユーモアを持ち合わせているかどうかで手助けしない相手を選ぶの？)、見事な再帰構造だなーって思う。

第3部

P60
たいていの不適合は、認識さえすれば容易に解ける。(中略)たいていはその不適合と付き合わなければならないものの方から処理できるものだ。人間というものは実に適応力に飛んだものだから、ほとんどどんな種類の不適合にも身を合わせてしまう。ただしそれは、当人たちが実はそうでなくてもいいのだ、ということに気づくまでのことである。そのとき、トラブルが起こる。

「トラブルが起こる」なんてネガティブな表現をしてるからビクッとしたけど、これは「問題が問題と認識されて、問題となる」って話だよな。
これはとても「そうだよな」と思うし大事にしたい部分。「思考の枠を外す」なんて言葉が個人的に好きなのだけど、まさに「いま目の前にある当たり前を、当たり前じゃないかも知れないという視点で眺められるか」というのは大きなヒントになるように思う。それが「実はそうでなくても良いのだ、ということに気づくまでのことである」という言葉で描かれている。

P62
どんな新しい「解決策」も、問題の定義が間違っていた時にそれと気づくのは、もとの設計者よりは利用者の方である。だがひとたびはじめに感じた親しみのなさが薄れると、人の適応性ゆえに不適合は目に見えなくなる。このことから、次の規則がどんなに重要かは、分かるわけだ。

結論に飛びつくな、 だが第一印象を無視するな

この後に続く「視点の新鮮さ」と合わせて、重要な示唆だなーと感じる。「なにか変だよね」「どうも使いにくいな」というのは、教育されていくと薄れるものだから、それに対しては「素人」の持つ新鮮な目線がいるよねーという風に思った。

ちょっと思ったのが、例えば「精神的にエネルギーが減っている時に、部屋が散らかっていてもそのまま過ごしてしまう」みたいなやつ。これは「部屋を片付ける気力がない」というのが問題なのだけど、もしかしたら「現状に適合する(抵抗をしない、新しい刺激を求めない)」みたいな力が大きく働いている状態なのかな・・・？「疲れている時はクリエイティブなアイディアが出てこない」みたいなのは馴染みのあるパターンだと思うんだけど、それと同じような事が同じような原因で生まれているのかもな、なんて気がした。

P69
こうなっていれば、答えを何か考え出すのに困難を覚える人はほとんどいない。コチラは「正解」を求めているのではなくて、彼らの意見を求めているのだ、という風に見えるので、威嚇的雰囲気の大部分が消滅するのである。意見なら誰でも、またはほとんど誰でも持っている。そして自分の個人的意見ということになったら、誰でも大家なのだ。

「何を求められているのか」というのを、言外のニュアンスまで含めて見極めようとしがち。
他人への問いかけはそういうとこを意識しながら行いたいし、逆に自分が解答者になっている場合は、そういう無意識なフィルタに邪魔されていないか？は意識しておいたほうが良さそう。

P70
われわれは、可能な場合にはいつでも、問題をまず自分たちにとって最大の快適さをもたらすような意味的レベルに置いてみるものだ。

暗黙的に、問題を大げさに考えすぎたり、その逆に余り単純化して硬直したりする・・・ていうのは、「求められている意味的レベルがズレている」ことによるのかも知れないな。知っている人からしたら「そんなやり方しなくてもここをこうするだけでさ」みたいなやつとか。

P75
10 意味に気をつけよう

※ 章全体に対する感想

なにかの問題を言語化する際に、書き手もしくは読み手が「言外の意味」を補完してしまう、それが極度に問題そのものを難しくしてしまう場面がある・・・みたいな話。
(なので、「明らかに他の解釈が仕様のないような表現を心がけよう」みたいな話だと思うのだが。)

これは凄い難しいよなぁ、そうだよなあ、と思いながら読んだ。頭が痛くなりそうなくらいだ。「そこに少女がいます」といった場合に「その時以外はいなかったのか」「少女以外、例えば少年以外はいないということか」みたいな。教習所の問題文がそんな感じなんだっけ？というのは、SNS等でもよく流れてくる。
でも、実際、気分や相手との関係地によって「教習所」になってしまうことはあるし、或いはそれを意識していないと問題文を書く人が読み手に対して「ここが教習所であることを期待する」ようになっちゃう・・って事はよくあるかも知れない。
で、章のタイトル、「意味に気をつけよう」だ。

第4部

P89
他人が自分の問題を自分で完全に解ける時に、それを解いてやろうとするな

「同じ課題設定でもそれを私(たち)の問題であるとされることで全力で解くようになる」みたいな話、面白いな。
「もしその解決方法を教師が提案していたら、受け入れられたとしても熱意を持って実行されなかっただろう」みたいな。あるいは、「これは彼の問題である」という視点で(他人が)解決策を出そうとすると、また変わる・・とか。

問題の持ち主が「彼」の場合は「タバコを吸うのを禁じる」という「彼が解決するように求める」、「私達」の場合は「みんなでタバコを辞める」とでもいうような(そこにいる90％以上の人はタバコ吸ってないのに！！)、「毎週1人ずつ、タバコより感じの良い楽しくなるやつを持ってくる」っていう。言ってみれば、そもそも「タバコが害」なのではなくて、喫煙者の彼も「楽しむための手段としてタバコを採用した」ってわけで、この「楽しむための集団は何があるか」という課題を共有した感じかな？だから「取り上げる」じゃなくて「皆で享受する・与える」みたいな方向性に変わっている、っていうように見える・・・

第5部

P110
第2の理由は「自然」の無関心さである。もし問題の原因を、人、または現実の事物ないし動作に求めることが出来るのであれば、解決の可能性に関する足がかりが得られる。問題の源泉に手が届くことによって、または問題を作り出した張本人の動機を理解することによって、われわれは問題を解消したり、それを軽減する道を見つけたりすることが出来る。

「変えられる部分」が原因だと考えたら初めてそれが「問題」になる、という感じか。どうしようもない部分に原因を求めると無力さに繋がるし、「公理」として逃れられないものになりそう。
第4部の「それは誰の問題か」同様、「どこに属する問題か」という視点はめちゃくちゃ大事なんだな・・・

P118
問題の出どころはもっとしばしば我々自身の中にある

ややこしいイザコザが発生してしまい、事態が硬直しかけたが、相手を1にの人間として誠意を持って接する(まず名前を聞いて、侮蔑的なあだなではなくて固有名詞で語りかけるようにする！)ことで氷解・好転してどうにかなった・・・という話。誠実さを持って接することで、あちらも「この問題をどうにかしよう」という知恵と力(小銭)を出してくれた、と。

ここまで読んで、「あぁなるほど、そうやって自体がいい方向にガラッと変わる、転回することもあるか。気をつけたいね」と思う反面で、「しかし今まで読んできた他のエッセイと違って、理知的と言うよりは道徳的な話だなぁ」なんて感じていたら「追って書き」である。

P119
追って書き この章は、本書の中でも失望感を与えることの、もっとも多い章の一つである。(中略)悪玉が善玉で、善玉─つまり読者自身─が実は悪玉だったと知るのは、がっくりとくる経験である。

こっちの気持ちを見透かされているのか！？と思って笑ってしまった。
この「実は自分が悪玉」問題、肝に命じておきたい話ではある。あの「自分が老害になっていやしないか」と気づかされ、頬をぶん殴られたような気持ちになった瞬間が思い出される。