PHPカンファレンスに参加しました & 登壇しました #phpcon2022

イベント

9月24-25日に行われたPHP Conference 2022に参加しました。
ひっじょ〜〜〜に楽しみました！！🤩🤩🤩🤩

PHPカンファレンス 2022 実行委員会さん・・コアスタッフや当日スタッフの皆様、スポンサーとして盛り上げるのに一役買ってくれた企業の皆様も、そして個性的でワクワクする発信をしてくれたスピーカーの皆様に感謝感謝です。

コレは社内Slackでワクワクしている私の様子です。「結構」とは。

両日とも、開始〜最初のセッションくらいまでは自宅参加になったのですが、午後からは現地にてオフラインでの参加でした。
そして、9月までに消失する休暇がある＆「イベントの翌日、体力的な披露・・・というよりも、余韻に浸れる時間が欲しい！！！」ということで本日はお休みをとっておきました。うれしいねぇたのしいな〜

そんな時間を活かして、諸々の感想などを。まずは時間を置かずに書こうと思います。
(オフィシャルのフィードバックフォームには回答済みだぜ！！トークフィードバックも後ほどやる。)

プロポーザル採択されました＆登壇しました

幸運にも、自分が提出したプロポーザルを採択していただくことができ、登壇してきました。
スタッフの皆様、現地やオンラインで聴いてくださった皆様、大変ありがとうございました。

fortee.jp

これについては・・・ちょっと別のポストにしようかなー
沢山になりそうなので。チラッとだけ言及すると、このテーマは個人的に数年前から追っかけ続けていたものだったりもするので、自分としてはちょっと特別なものがありました。
少しでも誰かの役に立ったモノがあったなら本当に嬉しい。

全体的なこと

会場うれしいねぇ

ひっさびさの大田区産業プラザ〜〜〜！っていう、自分などオフラインでのペチコンにはこれまでに1度しか参加したことなかったのですが、それでも会場を観たときには(陸橋からPioのロゴが目に入った瞬間！)に凄い高揚感を感じたり。
これは、周りの人の昨年・昨昨年と待望している様子だったり、あるいは今回の「オフラインだやったぁ！！」という感じに、自分も感化されていたのかなと思います。
PHPコミュニティに限らず、「カンファレンスの廊下」の魅力を語る人の話に触れる機会も増えたと感じています。ってことで「行きたいな」があったとさ

毎度ながら「同じような話に興味を持った人が本当に集まってるんだなー、凄いな〜」って思うし、会場スタッフの方も気持ちよく接してくれて楽しい気持ちになりました。
あと、受付する時に自分を認知して何かを言う前に名前を呼んでくれる人がいる〜〜！って経験が出来たのでテンション上がりました。
カンファレンス初心者の人とか「スタッフの人と知り合いになっておく・面識を持っておく」っていうハックはありかもしれない。会場到着時にちょっとホッと出来る可能性が上がる。

人がいたねぇ

それから、過去の同僚やコミュニティつながりの知り合いと再開・交流できたので嬉しかったです。
というか「オフラインでは初めまして！」が発生するの凄い楽しいですよね、最高〜〜。
それ以外にも、一方的に(?)知っている人とエンカウントできたりっていうのが今回もあったのでホクホク＆ワクワクしました！
ただ、まだまだ「話してみたいなー」って思ってた人と邂逅できてなかったりするので、やはりofficial懇親会欲しいな・・・・

所属している会社的なこと

今回は自分の会社からも参加者が現地に来ていて、「あぁ〜良いねぇ〜〜」って気持ちになりました。
地味に(前回のPHPerKaigiが平日日程も含んでいたこともあり)カンファレンス参加支援の制度を策定しており、こういう動きが自分でできるのはTech LeadとかEngineering Managerやっていると便利だねぇ〜〜って思うところなのですが、それを利用しての参加者を発生させられた！って事は、ちょっと役に立てたのかな〜などと感じた次第です。

すぐにアーカイブが見られるのは嬉しい

自分の登壇枠の裏2つとも凄い興味深かったり、それ以外にも注目してるセッションが同じ時間枠だったり・・・！というのはどうしても避けられないのですが、Youtube Liveのアーカイブが即時公開されているのはめちゃくちゃ嬉しいですね！！
恩恵を受けまくっております。

発表の感想とか

アーカイブで色々と見ると思うけど、とりあえずDay1&Day2の間に観られたものだけでも！！

ライブ視聴したもの@day-1

17年続くWebサービスを改善する 〜新卒2年目からみるカラーミーショップ〜 by やんまー、ほみるん | GMOペパボ | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

スポンサープランの「60分セッション」っていうのを見た時に、「これって・・・某社の某”まわりにあるモノすべてがプログラミング"の人が喋るイメージしか湧かないんだけどw」とか個人的に思ったりしつつ、やっぱりGMOさん！と思ったりしつつ、なるほどペア登壇をするパターンだ〜〜。

新卒2年目！！ってことだったので、そこまで「広い年代の人が集まる中で喋る」っていう経験は無さそうだよな〜〜って中でトップバッターなのは結構大変そう！
っていう勝手な杞憂なんて意味がないくらい、「新人だから」「スポンサーセッションだし」とか何とかって言い訳する必要もなく、聴いてて興味深い話だったなって感想。

漸進的改善にせよSLO運用にせよ、「すごく真っ当なことをやれてる環境なんだな！！！」って思ったりしました。組織全体をどう動かす〜？何をやってく〜？みたいな所がミッションになってくる自分にとっては、早くこうした「効果が高いと広く認められてるプラクティスをちゃんと導入していく・実装していく」っていうのは羨ましいなというか悔しいなというか、「あ！！それ！俺もやりたいやつ！！」と思いながら聴いていた次第。

あとUnleash知らなかった！めっちゃ興味あるので調べてみる。

これは若手ではない枠としての立場からの感想です

AWS CDK に魅入られた PHPer がオススメする IaC から入るインフラの話 by ちゃちい | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

ここから会場入り。

CDK、マジで名前くらいしか知らなかったんですが、なるほどそういう感じか・・・・と思って「これ触ってみたいな、面白そうじゃん！！」って気持ちに。 「インフラとふれあえそうですか？」に対しては「やってみたいで〜〜〜す！」って答えになりそう。
(terraformだろうとcloud formationだろうと、AWSでIaCする時って結局は「どうしてもDSLとかよりかAWSのサービスの把握をしないと」って印象になってしまう、ってのもある)

てっきり「PHPでやってみましょう、実は出来るようになってたんです！」的なオチを期待してたので「Issueがある」「あっ・・(察し」で笑ってしまったw とはいえTypeScriptは相性が書いてても呼んでても良さそうな気がするし、良さそうだな〜。

全体的に、本当に「インフラってなんだろうね(普段は意識してないもんねー)」的な目線からの説明になっていたのが印象的でした！

リリースして11年経過したPHPアプリケーションにPHPStanを導入した by 山下祐 | Chatwork株式会社 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

ここ数年で一気に「PHPStanをPJで活用する」っていうのが尖ったことじゃなくなってきたと言うか、「触ってみた！」「〜〜って何？解説！」みたいなものから「導入してみて、運用してみた際の知見の共有」という話題に移ってきている気がするな〜とこの発表を聴いても感じつつ。

実際に「入れていくぞ〜」ってなった時に、序盤の大ボスみたいなところって「直し方が分からんしひたすら面倒クセェー」ってなってしまう人が出ることなのかな？って予想はしているので*1、やっぱりそういう工夫してるのね〜っていうのが聞けたのが良かった。

開発メンバーができるだけスムーズに慣れるための運用体制は必要 ←sorena！！！

↓コレありませんか？

フラットなPHPからオブジェクト指向で自動テストのあるPHPへ、そしてフレームワークへ by 菱田 裕美 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

内容そのもの、登壇者(の過去実績からの)への期待値・・・っていうのがあったのに加え、今回は特殊な事情で「60分セッションがどんな感じか体感しておきたい」みたいなのもありましたw

で、想像していたよりも易しいレベルからの話で、「なるほどそういう風に説明を積み上げていくのか〜〜！」なんて面でも学ばせてもらったなぁという気がしています。
Head First Object-Oriented Analysis & Designと似たようなレベル感で、それを少し「現場より」にしたようなものかもな〜って印象も受けました。というか、コレは実際に誰かに教えているような内容を活かして練り上げたのかな・・？みたいな事も勘ぐったり。良い意味での現場臭さも感じたと言うか。

この話を若手に聞かせて、TDDを拗らせさせて、そのままボブおじさんの新作をブチ込みたいな！！！！！という変な事も考えながら楽しく聴かせてもらいました！

しっかりと「よく聞くけど、あの小難しそうな概念何？」ってところから、TDDやFWといった次につながるような学びの種も落としていくような素敵な発表

PHPで学ぶシステム設計 依存関係のコントロール編 by 成瀬 允宣 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

いやはや安心・安定の成瀬さん、相変わらず発表が面白いなぁ・・・

改めて動画を見てみると、基本的には話すタイミングではちゃんと目線を上げてるなーとか、話すペースのスピードを柔軟に動かしてるなーとか、上手さを感じる・・
自分も、折角誰かの時間をもらって話をするんであれば、ちゃんと聞きやすいような話し方を出来るようにしたいのう

自分が誰かに説明する時に「依存の逆転って何が逆転なの、”逆”じゃないとしたら何？」っていうところに苦労した事があるので、コレ見ておいてね！！で済ませられそうなの嬉しい。

タイトルだけ見ると、クラス間だったりレイヤー間の依存のコントロールかなぁ〜って想像してたんですけど、「チーム間の依存」「組織の依存」を切り口に更に大きい話に繋ぎ込んできたのは「おっ」って思いました。
すべてはプログラミングなんだなぁ

これは現地で、同じ会社の人(若手？でもないか)と聴いてたのだけど、ウンウン頷きながら聴いていたのが印象的だった

PHP メモリ管理術 by めもり〜 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

めもり〜さんのメモリ管理術！

「メモリが足りないなら増やせばいいじゃないか」を感じるコード、しばしば見かける事があるので、世知辛いよねぇ〜〜って気持ちになりながら聴いていました冒頭。

「普段の仕事で使わない知識」と「仕事をやる上で必要な知識」みたいなのって、かなり境界線が曖昧というか、実は「下の視点で考えられる人が当たり前に見えている世界 🆚 低レイヤー(例えば)を避けている人に見えている世界」っていう差があるだけだなーと思ったり。
「自分の領域はココまで！」なんて決めずに、インフラでも組織づくりでもメイン言語よりも下のレイヤでもなんでも、知っていることが多ければソレが武器になるぞーっていうのがアプリケーション開発業だなって気がする。

ob_start() の引数とか、 ZEND_MM_CHUNK_SIZE とか、自分が今まで知らなかった・通ってこなかった知識も触れることが出来て嬉しかったです。
一方で、gc_collect_cycles()とかは、「CIでテストがメモリ不足で落ちる」とか言った場合に(具体的な原因を追うのが難しいので・・・)雑に呼んじゃう、みたいな事も過去にあったなぁなんぇ思い出が蘇ったり。

あと資料中に現れた猫が愛らしかった・・・！

いちユーザーが PHP に新機能を追加するまで - Random Extension 5.x by Go Kudo | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

プロポーザルを見て楽しみにしてたやつの1つ！

個人的に、この2日間で1番の「聴いてよかったな」ってなったセッションだなぁ。
まだ見られていないものもこの後追っかけるので、もしかしたら今はまだ確定じゃないのかもしれないけど、でも恐らくコレがきっとこのままベスト1だぞ〜。

技術的な内容については、今の自分には触れてこなかった部分なので「すごい！！すごそう！」くらいの反応しか出来なかったのですが(知識と力が足りん・・)。

自分的に、カンファレンスの発表などで求めることって違う方向性で3つくらいある気がしていて、

  • 知識を増やすもの、概念や説明にふれるもの*2
    • php-srcの読み方とかRoadrunnerの紹介とか
    • 趣味とか興味とか寄り？知的好奇心を満たしてくれる系
  • 実践的な知見とか経験談を取り入れるもの
    • バージョンアップでやったこととかリプレイスの話とか
    • 戦略ないし戦術を考えるための思考の引き出しを膨らませてくれる系
  • 姿勢やマインドに感銘を受けるもの
    • たまにキャリア的な話とか倫理の話とかで、ド直球なのもあるけど
    • どちらかというと、凄い深さとかを持って発表者のバックボーンとか「凄み」みたいなのを感じさせてくれるようなやつ
    • 自分まだまだだなーって思わされて気が引き締まると同時に、「かっっけぇ〜〜！」ってなる系

って感じなのですが、このセッションにはその3つともギュッと詰まっているような感じがして、凄く圧巻・・・・となった気がしました。

こうした困難な問題に対して、しっかりと向き合って、必要だと感じたらそれが大きな壁だろうと真っ向から食いついて乗り越えていって、世界的なコミュニティの中で関与して結果を残していく・・・みたいな姿勢と実際の結果を見て、感銘を受けたと言うか大きな感動を覚えたと言うか。 あまりうまく言語化出来ないのですが、本当に「めちゃくちゃカッコいいな！！」と。

また、まだまだRFCが採択される前からチラチラと様子を見ていたので、そういった意味では「リアルタイムに見ていた話の裏や内面をその当事者から新鮮な内に聴くことが出来る」っていうのコミュニティの醍醐味だなーきっと

day1、あとはGold Sponsor's Talks 1 を見ました！！(全部書くと分量が長くなっちゃいそうなので割愛、オフィシャルのトークフィードバックに書きます・・・)

当日に追っかけ視聴したもの@day-1

Laravel を低速化する技術 by 富所 亮 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

タイトルが好きすぎて笑ったのですが、蓋を開けたら(そりゃそうなんだけど)普通に役に立つ系の話だなぁ・・・と思ってまた笑っていました。
事前にご本人と喋った時に「ロードバランサーを米国においてサーバーをヨーロッパにおけば世界一周だ！！」とか言ってたんで「凄いなぁ」と思ってたのですが、ちゃんと「現実的にありえてしまいそうな範疇で、何が動作を遅くするのか」という話に落ち着いていた＆それでも地雷が沢山あるなぁ〜と改めて思ったり。

それこそ、Attribute Casting(の悪用w)については「知らないと見抜けないし困っちゃいそうだな」と思ったり、ただ「ちゃんとプロファイリング取らないとボトルネック見つけられ無さそう」「Laravelでプロファイリング取るとcollect()ばかりになって途方に暮れがち・・・」っていう気持ちが湧くなどしていました。

とはいっても、全体を通じて「遅い場合は大体使い方が悪い」っていう風な事を思ったので、モラルを持ってコードを書いていきたいですねぇ。。

資料も発表も、聞き手を飽きさせない感じで上手だなぁと思いました、いいなー。
あと、過去に発表した資料が紹介されていて嬉しかったです！ありがとうございました！！

開発組織の生産性を可視化する ~ State of DevOpsとfour keysとは ~ by いさな | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

沖縄の発表も面白かったし、自分自身がこの辺りの導入・構築をしたいなーって考え続けている日々なので楽しみにしていたやつ。
アクセラレート本、自分もどっかで話したいなと思ってたトピックだったりもするので、他の人からPHPコミュニティで話を聞けるのは楽しいなぁ。

良いなぁ〜素敵だなぁ〜と思ったのは「実際に計測するときには、自分の組織に合わせて拡張していく必要がある」と述べられていた部分。
この本は、4つのメトリクスとか24のケイパビリティみたいな話なので「具体的な戦術・プラクティス」よりの事柄なのかなーと一瞬思いつつも、実はその本質は「目指すべき大方針をまとめた」「しっかりと意味のある指標を定義可能であると示した」というところにあるのではないかなーなんて思っているので。

別観点の指標(SRE、財務諸表)と関連付けて考えよう！っていうのは、すごくナルホド感あった。Data Transfer Objectを組織戦略を考える上でも実装すればいいですよね！！みたいな事を思った次第です。

あとは、折角だからmetrikのことも聞いてみたかったですかね〜使ってる会社さん無いかなぁ。 github.com

全体的に、すごく発表の流れにメリハリ位もあって話も分かりやすくて面白かったです！！
願わくば、この後に「暫くやってみた」「ここがこうなった」「こういう所は問題があった」的な話が聞いてみたいですねー

ライブ視聴したもの@day-2

何か思ったより長くなってきたぞ

急成長3社サービスの開発ストーリー〜継続成長を支える技術と仕組みのお話〜 by FLEXY CTO meetupスピーカーの方々 | FLEXY | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

色々と面白かった、あっという間に終わった気がします〜

・・・いや、オレオレFWってやっぱり現実的な選択肢になってこないか？？とか思えてしまう。学習コストの関係なんですかねぇ。保守コスト、特に新規バージョンに追従していくコストとか「必要としていない変更」を取り込んでいかなければならないコストをどう判断すれば良いんでしょうね。
もちろん、「ちゃんと筋が良いものを作れるか」が肝になると思うので、そのハードルがめちゃくちゃ高かったりはするはずなんですが。

フレームワークの機能を使わずに標準関数使ったら障害起こした話 by asumikam | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

day-2はココから現地。

同社内から自分以外には唯一の一般枠での登壇者で、面白く聴ききましたー。
header()の話とか送出タイミングの話とかは自分もあまり詳細に知っていなかったし、「フレームワーク的な世界観とそれ以前の世界観(オブジェクトとして保持しつつ責務を分けてタイミングを見計らって適切な箇所で処理するるか、結果が確定できたと判断した時点で持ち込みすぎずにどんどん影響を吐き出していくか・・的な)の比較」も感じられて面白く聞きました。

前回のPHPerKaigiでも本番前の壁打ちとかで少々お手伝いしてたりもしますが、いつも「最初のうちは『難しそうなテーマ選んだなぁ、どうまとめるのかな〜』とドキドキして見守りつつ、段々と形になってきてよかったーって思っていると、本番が近づいて完成形が見えてきて、最終的には自分がイメージしていた以上の完成度とか興味深さになって、良い意味で期待を裏切られるなぁ！」なんて事を感じながら、素直に凄いなぁと感心しながら＆純粋に1つのセッション・コンテンツとして楽しみながら拝聴しておりました。

公開の場所で色々と言及するのが立場的に気が引けるのでサクッと・・・

さっぱりPHP 〜 標準関数と文法を極める by うさみけんた | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

うさみさんの発表はいつもキャラが立っている上に説明すべき所をしっかり抑えている感じがあって面白いなーと思いながら、かつ、今回特に楽しそうに喋ってらっしゃったのが印象的で穏やかな気分で見ていました。

PHP、なんとなくそんな気はしてたけど・・・「標準関数」っていうの自体が曖昧なんだな・・・ 朝のトークセッションとは別の意味で「コアなど存在しない」を感じましたw
あと、フォールバックで突発的に壇上でコードを書き始めるの凄い。自分だったらパッと出来ない気がします。

「関数を調べようとすると古い関数が出てきがち」とかも、たしかに言われてみるとそうだなぁ。

導入から 10 年、PHP の trait は滅びるべきなのか ーーその適切な使いどころと弱点、将来について by sji | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

コレもプロポーザル出た時点から楽しみだったやつの1つ。

sjiさんの自己紹介で「普通のサラリーマン」って書いているのはなにかの冗談か・・・？という気さえしてしまうのだけど、期待を上回るような濃さw

「締切駆動でPHPのRFCも投げよう」ってどういうことなんだw

WEB+DB Pressでtraitの話をしている回がそもそも面白かったので、その話＋αくらい聞けたら十分に嬉しい気もするな〜って思ってたりはしたのですが、しっかりと「traitとは何であるか/何でないか/何でありたかったのか/何故こうなったのか」という内容がカバーされていて勉強になりました。

「PHPのコアに提案をした」という経験を引き連れての登壇が、普段のテーマよりもだいぶ一般的だったり実用的だったりするのもちょっと面白いもんだな、と感じました。

治っていくmbstring 令和時代の文字化け by てきめん | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

てきめんさんのmbstring/shift-jis周りの活動も拝見していたので、とても楽しみにしていたやつ。

文字コード闇深そうだよな・・・・と思って、実際に聞いてみたら凄い複雑そうで、そしてラストのスライドの締めが「mbstring全部手を入れて沼に沈みましょう」なの凄い😇

とはいえ、歴史の中で各時代において何とかしようと頑張っていた人たちが居た結果なんだよな・・と思うと、それはそれで偉大。13万行のPR！！っていうのもインパクトがあまりにも大きいけど、そこまでの仕事をやりとげよう〜〜という意志と行動はめっちゃ凄いよな！とも感じたりしていました。

自分が全く知らない世界でも頑張っている人が居るんだな、って意味で「辛い」「凄い」「尊い」が同時に吹き出てくるような感覚で聞いていました

FQDN（ドメイン名）のバリデーションが意外と面倒だった by akase244 | トーク | PHP Conference Japan 2022 #phpcon #phpcon2022 - fortee.jp

LT基本的に言及してませんが1つだけ・・・
当初は「filter_var()くんはドメイン判定するときには避けましょうね＾＾」的な落ちになるかと思ったんですが、なるほど優秀そう・・・！ってなりました。

アカセさんの発表を生で見るの初めてな気がするのですが、スライドも喋りもテンポが良いし話も分かりやすくて凄い楽しかったです！LTだ〜〜〜〜って感じ凄い。

内容もさることながら、スライド最後のオチとそれをうけてのTwitter上でのリアクションですね！！！！！めっちゃ楽しみ・・！

てな訳で

とりあえず、めちゃくちゃ楽しませてもらった2日間が終わりました〜〜ありがとうございました！！ + 開催当日までに見た発表の感想でした！ 書いてたら長くなっちゃった。見直すのも大変なので一旦これで放流・・・。

お疲れさまでした！他のセッションも気になるのてんこ盛りなので沢山見ます！！

*1:前に自分が居た環境でPhanを入れた時は、チーム規模がすごい小さかったので技術力や経験の差があんまりなかったので、そういう壁にはぶつからなかった / その後に若手と一緒のチームでPHPStan入れた時は、PJ立ち上げ時から入れたから負担をかなり抑えられたし人数が少なかったので自分で全部フォローできた

*2:最近は社内とかに対して「自分はそんな必要ないけど、教育的な目線でいうと見ておきたいかもなー」とかっていうのも発生しがちかも

セキュアベース･リーダーシップを読んだ

読書記録

セキュアベース･リーダーシップ

セキュアベース･リーダーシップ

Amazon

読みながらメモとかはとっていなかったのだけど、これは記録に残しておきたいなーと思ったのでざっくりと読書記録を。
GWに対話や関係構築に関する本を読んでいたり(問いかける技術、アサーション入門、フォーカシング)、直近でもシャイン博士が語るキャリア・カウンセリングの進め方: <キャリア・アンカー>の正しい使用法を読んだりなどで、「コーチングとかマネジメントとかリーダーシップについては、色々と知らなきゃいけないことがあるぞ・・無限にあるぞ・・・そしてそれを自分が知らないことによって周りの人が失敗する確率が上がったり、本来望めたレベルが下がったりするのは嫌だな・・・」「知れば知るほど武器になるな、面白いな」っていう気分が高まっていたので。
とりわけ、キャリア・アンカーの話を見ていて「周りの人の実力・才能をもっと豊かに引き出すには？」を深めたいなーという意欲を濃くしてくれたので、積んであった本書を手にとった次第。

どういう本

「セキュア」という言葉が含まれていることから、心理的安全性とかそういう方面の話と関連があるのだろうなーと思いながら読んでみたけど、そうっちゃそう。
読了後に、この本を知った＆買ったきっかけは何だったっけ・・・っていうのを思い出そうとしたんだけど文脈が掘り出せずに残念。購入タイミング的に、LeanとDevOpsの科学を読んでいた時期っぽかったので、その関連かな？

原題が「Care to Dare: Unleashing Astonishing Potential Through Secure Base Leadership」で、「思いやりで勇気を与える」「セキュアベースリーダーシップで驚愕的な才能を開花させる」みたいなニュアンスなのかなー

言うまでもなく、この「セキュアベース」が本書の中核的な概念であり、それがどのような効果をもたらすか？どのように実装・実行するか？を伝える本。

セキュアベースリーダーシップについては、まえがきの言葉を借りれば以下のように定義されている。

守れられているという感覚と安心感を与え、思いやりを示すと同時に、ものごとに挑み、冒険し、リスクをとり、挑戦を求める意欲とエネルギーの源となる人物、場所、あるいは目標や目的
『まえがき (P9)』

個人的なイメージでは、「私はここにいて良いんだ！という肯定感をもたらし、内発的な意欲をもって挑戦を促す」ような施しをもたらす「いつでも帰ってこれると信じられる基地、ホーム」的な存在なのかな〜という捉え方。
その存在は、からなずしも「接点をもった誰か」である必要はなくて、精神的支柱となるような「目標」であったり「過去の経験、エピソード」などでも良いよーと。ふとっちょのオバサンの為に靴を磨く、というのも近いだろうか。遠いか。

1冊を通じて、他人(フォロワー)にとっての「セキュアベース」たるようなリーダーになることを目指す。それは「具体的な何かの行動や思考」よりも総合的な、「人としてのあり方(P13)」として語られる。
そのために必要な「資質」を9つの要素に分解し、しかもそれを「明確で、現実的で、習得可能なもの(P61)」と断言している。
それぞれ、どうして必要なのか？具体的にどんな行動・心理に顕れてくるのか、表せるのか？自分自身がそう振る舞えているかを、どう点検すればいいのか？どのように獲得・強化すればいいのか？
─といった話が展開されていくのだ。

論理的な話であり、自己啓発的な側面も多分に含みながら、具体性・実践的なレベルによく落とし込まれているな〜と読んでいて嬉しかった。

トータルの所感

いわゆる「尊敬・敬意」「謙虚さ」「安全であること」「優しくすること」は、語るまでもなく重要である事には異論はないが、やはりビジネスの局面においては「厳しさ」も必要なのでは？と感じる面もある。
要するに目標達成に向けた力学だ。それが無くて、どうも片手落ちな、ただ他人を恐れて日和ったような平和主義じゃないか・・・と感じてしまうような本もしばしば見かける。
その点、この本は「健全なプレッシャーのかけ方」についても視野に入れているように感じられて、その点がとてもよかった。
個人的にはチームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチを初めて読んだときに、「あくまで目標達成に向けたチームの強化(学習促進)のために、手段として心理的安全性を確保しに行く」というスタンスに目から鱗！！が落ちたのだが、この本もまた「ただ優しいお兄さん的な”安心できる基地”になろう」というだけの話の展開はしておらず、好きな感じだ。

全体的な構成の工夫として、実際にあった(セキュアベースリーダーシップを発揮していると言える)顕著なエピソードを頻繁に織り込まれていて、それも読者の興味を維持し続けるのに貢献していると思う。ワクワク感があった。*1

少しだけ話の展開が冗長に感じられる部分もあるかも知れないが、そういう「何度も1つの物事を少し言い換えて述べる」的な配慮を頼って、少し気楽に読んだりスピードを上げても大丈夫そうだな〜って安心感を個人的には感じた所。

お気に入り箇所

9つの特性

主題であり、本書の論(の具体的な部分)の骨子になる要素。
これらの要素・行動を安定的に実践することで、フォロワーのセキュアベースになろう！というもの。

  1. 冷静でいる
  2. 人として受け入れる
  3. 可能性を見通す
  4. 傾聴し、質問する
  5. 力強いメッセージを発信する
  6. プラス面にフォーカスする
  7. リスクを取るよう促す
  8. 内発的動機で動かす
  9. いつでも話せることを示す

それぞれが「思いやり」と「挑戦(の誘発、促進)」を高いレベルで獲得し提供するために欠かせない、と。

特性1つずつに対して、「(調査で収集した)セキュアベース・リーダーが、それを表し実践していると言える顕著な発言」「あなたのセキュアベース・リーダーシップ行動を評価しよう(点数が低かった部分が重点的に伸ばすべき項目になる)」「特性を伸ばすためのヒント」といった節を設けて肉付けしている。

例えば、特性5「力強いメッセージを発信する」についていえば、

  • リーダーの発信
    • 「彼はこんなメモを書いて渡して売れました。『君は間違いなく正しいことをやっているよ』。メモ用紙に書いてもらったこのひと言が、わたしにとってはとても大きかったのです。本当に大きかった。今でもその紙を持っています」
    • 「彼女は私に『いつでもチャンスはある』と言いました。身動きが取れず、誰も助けてくれないと思い始めていた苦しいときだったのですが、彼女の言葉から自由を感じ、力を得ました」
    • 「わたしが上司との間に問題を抱え、会社を辞めることを決心したとき、人事部門の同僚が、『辞めるときには常に堂々と、落ち着いて』と言いました。彼の言葉がずっと心に残り、この変化の時期を温かい気持ちとプロ意識を忘れずに、乗り切ることができました」
  • あなたのセキュアベース・リーダーシップ行動を評価しよう
    • 力強く覚えやすいメッセージを発信している
    • はっきりと簡潔に話している
    • 非言語のメッセージやジェスチャーを使って、覚えやすいメッセージをさらに強調している
  • 伸ばすためのヒント
    1. 言葉だけでなく、非言語のメッセージにも気を遣う
    2. その一瞬を逃さない
    3. 力強いメッセージをはっきりと、簡潔に、ゆっくりと伝える
    4. 力強いメッセージを書く
    5. 力強く短いメッセージをノートに書きためておく

のように紹介されている。これが、9個とも全てにおいて繰り返される。

各特性についての「あなたのセキュアベース・リーダーシップ行動を評価しよう」に従って、セルフアセスメントをしてみたら、以下のような結果になった。
主に職場において部下・同僚・上司とのコミュニケーションを想起しながら点数を付けてみたもの。
(各設問、1＝まったくできていない〜5＝常にできている で答えるのを3問ずつ)

特性 評点
1. 冷静でいる 6/15 (3未満が2つ)
2. 人として受け入れる 14/15 (3未満が0)
3. 可能性を見通す 13/15 (3未満が0)
4. 傾聴し、質問する 15/15 (3未満が0)
5. 力強いメッセージを発信する 9/15 (3未満が1)
6. プラス面にフォーカスする 14/15 (3未満が0)
7. リスクを取るよう促す 11/15 (3未満が0)
8. 内発的動機で動かす 12/15 (3未満が0)
9. いつでも話せることを示す 8/15 (3未満が2)

意外と高いかもな？？？？(今はそこそこ機嫌が良いからですね、多分)

元々の素質として「人のことを観察してポイントをつかもうとしている」「ちゃんと他人を褒める」という面は持っている*2のに加えて、コーチングを勉強しながら「目の前の相手を信じる」「内側に持っている可能性を引き出せるようにする」というのも重要性を理解しトレーニングしているので、他者に対する尊重は概ね評点が高いのかも。
(傾聴と発問は、座学や読書だけでなく機会を作って実践訓練を積んでいるので。伸びていないと困る・・)

他方で、自身を律することや、他人に対して「課す」ような方面は依然として弱そう。
この辺りは、他人に対する弱気とか、「相手の望みに対する確証が持てない」的な、コントロールできないものへの不安が強く出ているのかな〜という感じがする。自己肯定感が低い(自分の持っているもの・見ているものへの疑いが強い)性質からくるものな気がする。
「力強いメッセージを〜」についても、「簡潔に伝える」が弱いと感じている(＝話がダラダラしがち)ので、これもまた「伝わっているかな？と不安がつきまとっているから」という意味で根が似ていそう。

こうした面が、どのようにリーダーシップや(組織内で果たすべき)他人への影響の与え方に影響しているか？が分かるし、その重要性も解説されている！！というのが本書。

・・・にしても特性1😇
コレに対しての「ヒント」として、(自身の感情や気分に自覚的になって、それを収束させる術を用意すること〜という意味で)「マインドフルネスの練習をする」というのが挙げられている。
いや〜、そうですよねガッハッハ！という気持ちになったけど、課題感はあってちゃんと 積んでいる 勉強しようとしているんですよ！！！というのが下の図。
方向性はちゃんと合っているんだなーとも言えるので少し自信になった。

4つのリーダーシップのアプローチ

本書全般を通じてリーダーシップは「フォローとリード」もしくは「CareとDare」のような軸の掛け算で描かれているが、その「思いやること」と「挑ませること」を用いた四象限で「リーダーシップのアプローチ」を説明している。
これがまた面白かった。チームを動かすときに、リーダーがどのように行動したり判断したりするか・・・？

「思いやりも強く、挑ませる面も強い」となったときに「勝利を目指す」ようなリーダーシップとなる。
逆に、「思いやりも挑ませる面も弱い」場合には「回避を目指す」と。
要するに、チームとしてのリスクのとり方や、「自分でやるか・誰かにやらせるか」という意味でのリスクの置き方が変わってくる。

これもまた、そのようなアプローチを端的に表現するような言葉(セリフ)─「この表現にピンときたら、あなたのアプローチはコレですよ！」といったものが例示されていて、イメージが湧きやすかった。

例)

  1. 勝利を目指すアプローチ(思いやり:強、挑ませる:強)
    • 成功するには人間関係が重要だ
    • 必要なときには、フォロワーが私を助けてくれる
    • 意思決定をするのは楽しい
    • 他者とともに仕事をすれば、最高の結果が出せる
  2. 支配を目指すアプローチ(思いやり:弱、挑ませる:強)
    • 最終的には、重要なのは結果だけ
    • 部下はわたしの信頼を勝ち得なければならない
    • 一人でいたほうがいい
    • 部下はお金のためだけに働いている
  3. 負けないことを目指すアプローチ(思いやり:強、挑ませる:弱)
    • 自分で決定を下したくない
    • どうなるか様子を見よう
    • 他の人からも同意を得る必要がある
    • 批判や反対は回避する
  4. 回避を目指す(思いやり:弱、挑ませる:弱い)
    • 熱心にやる意味はない。これはただの仕事だ
    • リスクはとらない
    • 感謝されていない
    • 部下は勝手にやるだろう

こうしたアプローチについて紹介した上で、重要なのは(個人的に心に留まったのは)

このモデルから得られる最も重要な学びは、「プレッシャーを受けたときにどの方向性に動くか」である。
『第6章 「勝利を目指す」マインドセット (P228)』

という部分。
ただ8行程度でサラッと書かれている内容ではあるが、リーダーシップというのは、固定的で唯一性のあるものではなく、あくまで変動的であり脆いものなのだなーとハッとさせられた。
人は「良い面よりも悪い面のほうが目に付き、印象に残る」ようにできていると思う。
なので、プレッシャーがかかったとき = 弱さに飲まれた時に、どのように力を発揮できるか・・・・？は重要な課題であると感じた。

愛着スタイル

セキュアベース・リーダーになるためには「他者とどう関わるか」が重要になる。
その要素として「自分自身が、自分に対してどのような関係モデルを持っているか」「自分自身が、他人に対してどのような関係モデルを持っているか」の2軸からなる4象限のパターンとして「愛着スタイル」を表せるという。 自己に対する肯定感の＋or−、他人に対するそれの＋or−の組み合わせだ。

  1. 自分を肯定し、他人も肯定する: 安定型 - 勝利を目指す
  2. 自分を肯定し、他人を否定する: 回避・拒絶型 - 支配を目指す
    • 一匹オオカミ
  3. 自分を否定し、他人を肯定する: 不安型 - 負けないことを目指す
    • 不安
    • 過度の依存
  4. 自分を否定し、他人も否定する: 孤立型 - 回避を目指す
    • 引きこもる
    • 気落ちする

これも「基本的なスタイル」があり、様々な要因によって「別のスタイル」が誰しも現れるものだという。 (それぞれの象限が、先のリーダーシップアプローチにもリンクしてくる)

これも本書の中で特に気に入った部分のひとつで、各愛着スタイルごとに、「調子の良い日」「調子の悪い日」におけるそれぞれの行動特徴を説明している。 こうした説明に自身の行動を照らし合わせて、「自分はどの愛着スタイルが基本なのだろう？」とアセスメントをすることができるのだ。
(そして、ここでも「安定型」を目指すための処方箋が紹介されている)

自分に当てはめて考えてみると、自信に満ち溢れている時は安定型で居られることが歳を取るに連れて増えてきたようにも思う。
その一方で、2〜4のどれも出てくるんでないかい？？？という気もした。明らかに「引きこもる」「気落ちする」という反応はあるので。
ただ、そこまで行くことは減ったorリカバリは効くようになってきたとも思うし、少なくとも「他人にそのままぶつける」ほどの問題は抑え込めるようになってきたんじゃないかなー・・・
2,3でいえば、昔だったら拒絶型が強そう、今だとやや不安型に行き着くのかな？という気も。

まとめ

他にも、とても重要な概念が出てくる。「絆」や「信頼構築スタイル」、「喪失」「離別」や「悲しみのプロセス」だったり、「6つのリーダーシップのスタイル」など。

セキュアベース・リーダーは、そのコンセプトだけをなぞると、かなり崇高で聖人君子なビジョナリーでエナジャイザーで・・・・といった現実離れしたコンセプトになりそう。
しかし、本書では「セキュアベース・リーダーになるためには、リーダー自身にもセキュアベースが絶対に必要」とか「リーダーシップや関係性のスタイルは、プレッシャーやストレスによって(一時的に)変動するもの」といった現実的な面を見落とさない。

この「絶対壊れない完璧性」よりも「弱った時に素早く認知して、どう回復するか」と向き合った話に、とても希望を感じた。

自分自身がぼんやりと感じていた課題(「思いやり」はまだがんばれても、「挑ませる」が上手くない気がする)についても、その症状と課題、そして処方箋を得ることができたはずだ。

改めて、「リーダーシップってなんだっけ？」って考えてみたくなるきっかけとなった1冊だった。
自分自身、ここのところ(というかCAL-1を受けてからかなー)は「サーヴァント性よりも自己変革性を伴って行動するリーダーシップを獲得したいな」と感じていたところだったので、この「けしかける」ような側面・・・「フォロワーがしっかりと高いレベルの挑戦を続けられるか」に重きをおいた話は非常に面白く感じた。

強いて言えば、「自分自身がどのようにビジョンを掲げ、それに邁進していくか/周りを巻き込むか」に関しては扱いが薄かった気がする(あくまで「フォロワーを内発的な動機によって行動させる」が目的)ので、その辺りはまた別の本や理論で補っていきたいところ

*1:なんとなく、「ビジネススクールの教科書」みたいな本には、こういう事例を織り交ぜているものが多い気がするなぁ。事例研究やフィールドワークが多いからか

*2:というか、元同僚だったり研修を受けた際のフィードバックなどで他人にそのように言われる機会がしばしばあり、それで知った

GWを振り返る

読書記録

読みたい本がたくさんあるんだ〜〜！って気持ちのままに迎えた連休ということで、本を読みました。

↓1年前 daisuki.nichiyoubi.land

最近の本の読み方

タイトルとか、Twitter眺めてて言及されてた本とか、本を読んだら紹介されていた本とか、「何となく興味を持った」とか「コレはどっかで読む可能性があるんじゃないか？」と思った本をば〜って買っていくスタンスになっているので。
どちらかというと、「1冊を丁寧に読む」っていうよりも「どんなことが書いてある本なのかを知る」みたいな読み方をする割合が増えているかも？という気がする。
(もちろん、じっくり読んだりちゃんと理解して掴もうとする本もある)

年末年始のアドベントカレンダー期間に「とりあえず読了だけはする」と決めて付き合った本が何冊もあったり、4月に入門〜基礎レベルのプログラミングの本を1日？半日？で8冊ほど目を通したり・・・というのを体験したので、なんというか「読み流す」みたいな読み方が上手くなった気がする。感覚を掴んだよな。

そういえば昔から「雑にやっても大事なことだったら何度もでてくるし定着するでしょ」っていう思考なので、まして今みたいに積ん読が膨れ上がっている状態だと、こういう風な読書のモードを簡単に取り出せるっていうのは良いことなのかもなーって感じ

雑感

4/29-5/8までで10冊読んだので、ペースにしてちょうど1日1冊くらいかなー。
前から読んでいてこの期間に読み終わったものもあるし、逆にこの期間に読み始めて今も読書中のものもありつつ。
あと、「1冊は読み終えられるように軽そうな本を挟む」みたいな事もしてた。この辺り、去年のGWに結構たくさん読んだな〜っていうのが1つの目安にしてたなぁ。

ソフトウェア設計、コーチング、PjM、DevOps、PdM、ファシリテーション、「他人に勧められるかな？」目線でレベル的に自分にとっては易し目な本・・・と、自分の興味のあるものを我儘に手にとった感じ🤗

あと洋書が段々と自分の読書リスト(実際に読んだ本)に含まれてくるようになったのは嬉しいな。
これもアドベントカレンダー2021に訓練みたなものができた点だと思う。

アナリシスパターンを読み切るぞ！！！って思ってたけど、結局まだまだ途中だなぁ。

読んだ本の記録↓

読了順に

Domain-Driven Design in PHP

Domain-Driven Design in PHP (English Edition)

Domain-Driven Design in PHP (English Edition)

Amazon
猫も杓子もDDDじゃないですか、っていうことで「PHP利用者にはグッと来やすい」みたいな書評をどこかで見かけたような見かけなかったような気がして積んでた本。
GW初日(その前日の夜だけど)に読み始めて、この期間では1番最初に読み終えて。

いや〜〜〜コードがPHPだとすごい分かりやすいな！？脳みそが楽だ！！！みたいな気持ちになった。
直近でアジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技を読んだ際に「コードが視覚を通じて脳みそに届いて理解に至るまで」の摩擦係数がすんごい高ぇ〜・・・みたいな経験をしたばかりなので、この「ざっと全体俯瞰してもポイントや言いたいであろう事が目に飛び込んでくる」くらいの読みやすさはとっても気楽で嬉しかった。

それもあって、かつ難易度としてもそんなに高くなくわかりやすかった気がする。
コードが具体的、ある程度の「DDDとは」的な所の端折りを許したことで「つまり何」がテンポよく出てくる、みたいな感覚。
どうしても「養殖物」なコードではあると思うのだけど、「集約」とか「ドメインイベント」とか「ドメインサービスとアプリケーションサービス」とかの戦術的DDDを扱う上で出てくる掴みにくいような概念も、自分にとってはスッと頭に入って来やすい感じがしたなぁ。
それは「PHPだから」もあるだろうし、「説明も簡潔だから」ってものあるだろうし、それこそ「何度も似たような本を薄く広く読んできたから解像度が上がる」って効果も感じつつ。

動作可能なサンプルコードもGitHubに上がっているということで、本書にて触れられていないコードとか全体のつながりは補える。
勉強がてら、CakePHPで書き換えてみたいなーって思ったり。

なるほど感が多かった1冊。DDDの「入り口の次」くらいに良いんじゃないかなー
最近、社内でもDDDだったり設計に興味ありそうな人がチラホラ目に入ったり、あと「PHPのコードリーディングを練習してみたい・良い題材がほしい」って人も居たりするので、勉強会してみても面白そうだ。

PMBOK対応 童話でわかるプロジェクトマネジメント

PMBOK対応 童話でわかるプロジェクトマネジメント

PMBOK対応 童話でわかるプロジェクトマネジメント

Amazon

yokohamanortham.63 で言及されていた本。

anchor.fm

まず「なんで童話で語ろうとしたんだwww」っていうお茶目さを感じつつ、全体的にそういった軽快さで記述されているので、読み心地としては軽いしとっつきやすいんじゃないかな〜！という印象。
これ1冊で「プロジェクトマネジメントができるぞ！！」というものではないけど、例えば「自分が参加しているPJでマネージャーがどういう事を考えていそうか、何に気を遣っていそうか」が薄っすらと感じ取れるようになったり、自PJの「なんとなく上手く行ってないかも？やりづらいかも？」を観察するためのメガネにはなってくれるかも。

問いかける技術 ― 確かな人間関係と優れた組織をつくる

問いかける技術 ― 確かな人間関係と優れた組織をつくる

問いかける技術 ― 確かな人間関係と優れた組織をつくる

Amazon

組織開発系の本、ということでいいのかなー。
「問いのデザイン」とか「問いかけの作法」とか(どちらも同じ著者だけど)が「どうやって引き出すか」というよりも、こちらは「どうやって向き合うか、聞き手の態度として何が大事か」のような、より内省的な話を扱っているような印象。
(同著者の「企業文化」「人を助けるとはどういうことか」も積んでる、面白そうだから読みたいんだよなー)

この本は「謙虚に問いかける」という事を重視していて、「謙虚さとはなにか」「なぜ大事なのか」といった話を展開している。
ただ単純に「相手に大して丁寧な態度で接する」みたいな話だけではなくて、もっと受容を重んじるような、「自分の意見を出したり主張したり誘導することなく、本当に相手の中にある/出そうとしているモノを引き出す」といったような話。 相手に興味を持つ、先入観を排除する、「聞く」のに集中する・・・

面白くて新鮮だったのは、「思考プロセスに影響を与えるようなの問い」がアンチパターンとされている点。
例えば「内面に何を持っているのか」とか「根底にどういった思考や価値観があり、そういう思考に至っているのか」といったような、会話(=発言など、表面にできていているもの＝コンテンツ)を生み出している原因だったり過程だったりといったレイヤーに意識を向けるような問いのこと。
「よく聴く、相手を立てる」みたいな実践であるはずのコーチングにおいて、こうしたものこそが「相手への興味の向け方」とされているような感じがあり、明確に違うなーと。

もちろん「どっちが良い、悪い」という話ではなくて「適切に使い分けるべき」という話になるのだけども。
いわく、このような問いかけは「本人は思おもよらなかったことを考えさせる」ような方向づけになってしまい、相手の考えようとしていた事柄の道筋に大きな影響を与えてしまう。言ってしまうと「思考プロセスを乗っ取る」「会話の主導権を握る」ような状態に陥ってしまうのではないか、と。

問いや会話の実践を通じて、信頼関係を築いていく事を指向した1冊。
今回はちょっと駆け足気味に読んでしまったけど、分量もそんなに多くないので、またどこかで再読したいなー

アサーション入門

アサーション入門――自分も相手も大切にする自己表現法 (講談社現代新書)

アサーション入門――自分も相手も大切にする自己表現法 (講談社現代新書)

Amazon

アサーションとかアサーティブコミュニケーションっていうのを初めて知ったのはどこだったっけか・・・というのがパッと出てこないのだけど、どこかでしっかり修めてみたいなと思っている分野の1つ。

こうした考え方を知ることは、単純に「他者と上手くコミュニケーションをとる」みたいな事にも効果を発揮すると思うのだけど、もっと抽象的な部分での「自分が自分を大切にできているか」「何にこんなにも傷つけられているんだろうか」を取り出す力が育まれるのかな〜という気がする。

その点で言えば、第3章「考え方をアサーティブにする」で触れられているものが大事そうな感じも。

フォーカシング

フォーカシング

フォーカシング

Amazon

コーチング、カウンセリング文脈の本を引き続き読んで見る。
フォーカシングはとてもおもしろいし強力だなぁ・・・と思うのだけど、自分の場合、マインドフルネスやU理論みたいな「実際に自分が感じてみないと、どういう感覚なのかを掴むのが難しいもの」という引き出しにフェルトセンスは入っているような。
自分の場合、コーチングを習う過程で少しは体験していたので、最後まで「面白いなー」って気持ちを維持しながら読めた気がする。

フォーカシング、「自分の内面や感覚に意識を向けて、何が起きていてどんな事を感じているのか・・？を知ったり理解したりする」みたいな話で。これが出来ると、例えば「なんでそんなにイライラしてしまうのかが分かった！！」とか「私が本当に望んでいたのはこういう事だったのかも！」みたいな感じで、気持ちや感覚がほぐれたりと。

特に印象的だったのが、

うなくフォーカシングができているときにはどんな感じが出てきてもうれしく感じるものです。「死んでしまえ！」という内面の感じが聞こえてくるかもしれません。これをおだやかに、理解を示しながら吟味することになるでしょう。たぶん「おや、面白いな。宣告されてる感じだ。道理で行き詰まってるという感じがしてたんだ─もしそこにこんな感じがずっとあったのだとしたら。(後略)」 (P51)

のあたり。
こういう、「めちゃくちゃ憤っているのは自分自身」であるはずなのに、その感情の変化や激しい反応自体も切り離して客体化していくことで、そこから踏み込んで「何がそうなれるのか」についても理知的に分析できるーっていう作用の仕方にはすごいパワーを感じる。

これもまた、「こういう考え方もあるんだな」っていうのを知っているだけでも救われる面はあるのでは？といった1冊。

コミュニティ・オブ・プラクティス

コミュニティ・オブ・プラクティス―ナレッジ社会の新たな知識形態の実践 (Harvard Business School Press)

コミュニティ・オブ・プラクティス―ナレッジ社会の新たな知識形態の実践 (Harvard Business School Press)

Amazon

実践コミュニティの話。
会社で考えようとしていたことに関連して、連休の狭間に「ちょっと明日のミーティングに持ち込もうとしているネタについて、うまい説明ができると良いなー」ってことで優先度を上げて読了。

「お互いに知見を共有し合う、同じ領域に興味や課題感を持つ人同士で集まって研究や学習をすすめる」って意味でのコミュニティと、「実際に起きた出来事や行動から得た知識や考察を重んじる、得た知見は現場で活かす」って意味での(理論知でない)実践を、ということで「実践共同体」とか「実践コミュニティ」「プラクティスコミュニティ」とか「PoC(s)」とか言われているものについての本*1。

「ユニコーン企業のひみつ」で紹介されているSpotifyモデルでいうところの「ギルド」とかもコレの1つなんじゃないかな？って思っているのだけど、どうなんだろう。
あとLeSSでも触れられていたり。 調整と統合 - Large Scale Scrum (LeSS)

「こういう取り組みがあるんだな」というのを知るためには十分な1冊だなーと感じる反面で、そもそもの性質として「上手くいくやり方を紹介する教科書的な本」っていうのは難しい話題なのかもな、とも感じた。
事例研究を集めて統合した内容にはなっているけど、かといって「どこにでも当てはまる公式」なんてのは無いよなー人や状況に応じて観察して最適化していくしかないよなー・・みたいな。

他方で、「企業活動としてやらなければいけないこと」みたいなのは抑えている気がして、例えば「業績や評価とどう結びつけるか」「組織内でどう位置づけるか」などなど。 逆に、(例えばアジャイル系な本とか組織開発系な本であるような)「個人としての喜びをどう描くか、どうエンパワメントしていくか」みたいな側面はあまり触れられていないような印象も受けた気がする。最近割とそういった本ばかりを読んでいたからなのだろうけども。

こういったトピックについて興味がある人は目を通してみても良いかもしれない、ただ「やってみるしかない」「上手くいくかどうかは、まずリーダーシップを」(あと上役の理解と支援！)的なところなので、端から端までしっかり読んで頭に入れる〜〜っていう必要性は薄いのかも。
どうやっていくか？という面では、むしろ、Fearless Changeとか学習する組織とかに必要なことが散りばめられているかも。

The DevOps 逆転だ！究極の継続的デリバリー

The DevOps　逆転だ！究極の継続的デリバリー

The DevOps　逆転だ！究極の継続的デリバリー

Amazon

システム運用アンチパターンのまえがき(だっけな)で触れられていたので買った本。
ビジネスフィクションで描かれた「最悪な状態からどうやってDevOps的なコンセプトの実践・実装で大きな成功を勝ち取っていくか」を紹介する本であり、「DevOpsとは〜」とか「○○のプラクティスを紹介します！」といったものではなく。前情報なく読んでみると面食らうかもw

ある意味では「理念」「価値観」「哲学」といったものをまざまざと描き出して伝えてくれる1冊でありつつ、全てが物語の中で展開しているので、「ここから何を(具体的なプラクティスや進め方として)学ぶか」については、読者自身がしっかりと要約したり抽象化する必要がありそうかな？っていう印象。

中身としては(対立者がめちゃくちゃ最悪でストレスが溜まる、っていうのを除けばw)スルスルっと読めるし「あるある」的な内容もふんだんに盛り込まれているし、読み物として楽しめる内容でもあったし〜で面白かった

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

Amazon

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方をGW前(配信開始日)に読んだことをきっかけに、未読だったな〜と思って手にとった本。
今の所の自分だと、何かめちゃくちゃ目新しいことを学ぶぞ・・・！という期待よりも、「何か会社とかで若手に勧めやすい本があるといいな」「他人に説明する時に分かりやすい文章とかを吸収したいな」という期待が強めだった。

読んでみて、評判に違わず「色々な人にオススメして良さそうだな、早い段階で出会ってほしいな」という印象に。
これ1冊で「設計が出来るようになる、引っ張っていける！！」っていうものではないにせよ、大事な心構えが埋め込まれていると思うし、「ガンバに持って帰って実践する」のに能う本だなーと。
「業務ルールにしっかり目を向けておけ！」みたいな点が強調されていたり、「データベースとアプリケーションコードがどういう関係になるべきか (変な癒着を避けないといけない)」という罠っぽいところも抑えてあったりと、抑えているポイントが気持ちよかった。

A Philosophy of Software Design

A Philosophy of Software Design

A Philosophy of Software Design

Amazon

どっかで読まないとな〜〜って思って読めていなかった1冊、これが読めてよかったな。。
必ずしも全面同意ではないものの(モジュール(というかクラスか)についてのスタンスなど)、考えは明快で力強いな！！と思うものがとても多く。
あと英文も読みやすかった印象！

Deep Moduleって単語はこの発表で初めて聞いたものだったのだけど、やっぱりオリジナルを読むと「なるほどな！！」感がまた1つ変わってくると言うか。
あと、個人的には、コメントについての考え方がとてもおもしろかった。
General puserposeとSpecial purposeも共通性可変性分析に通ずるものを感じたし、レイヤー分けとか”Pull Complexity Downwards"とかに繋がっていったりと。
複雑性とは何か？という定義(解釈)についても、シンプルによく言い切っているな〜って感心して納得したり。

仕事でコードレビューをする際に机の片隅に置いておきたいし、そういう仕事をする人には1回読んでみてほしいなぁとも感じる。
名著と名高いだけあるなー

本の最後に「Summary of Design Principles」「Summary of Red Flags」が載っているのも助かるし、著者の想いとか願いとか苛立ちみたいなものを感じる

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

プロダクト・レッド・オーガニゼーション　顧客と組織と成長をつなぐプロダクト主導型の構築

Amazon

ば〜〜っと駆け足気味に読み流した感じ。より思想的な部分、哲学的な部分を期待していたけど、どちらかというと「数字をどう設定するか(何をインジケーターとして扱うか)」だったり「運用をどうするか」みたいな具体の話の方が、この本においては面白かった印象。
そういう意味では、少し物足りなかったり期待が満たされなかったのかも。
組織文化やコアとなる精神といったもので、「根本的に今とは考え方を変えないと強くなれないぞ！！！」と思わされるようなガツンとくる衝撃は無かったかもなー的な。個人的には、プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるの方が好きそう。

「製品開発、サービス提供」の分野については、いくつかのコンテキストで同様に語られることがある気がする。セールス、マーケ、プロダクト(開発)、顧客リレーション・・・例えばカスタマーサクセス系の本を読むとセールスだったり顧客リレーションが多かったり。その意味でいうと、この本はマーケティング畑の本かな？って何となく感じた。

翻訳者ご本人のスライドが https://speakerdeck.com/ykmc09/product-led-organization にあるので、先にコチラに目を通してから本書を手にとって見ると、より面白そう！

*1:長澤さんの記事 https://www.servantworks.co.jp/posts/scrum-master-community-of-practice/ や、ここでも言及されている「Scrum実践者が知るべき97のこと」でも紹介されてる

やったこと・書いたもの{2022,04}

やったこと・書いたもの

OSS

勉強会・LT

PHPerKaigi 2022に登壇しました

その他

@hanhan1978さんにお呼ばれして、2回目のポッドキャスト出演で喋ってきました！
とても楽しかったです✨(普通に喋っているだけなので、これで良いのだろうか？っていうのは毎回思うw

anchor.fm

悲しいのはこの2日前に使っていたマイクが壊れていてEarPodsで喋らざるを得なかったこと・・・

PHPUnitの実行結果(失敗したテスト)をProblem MatcherでPRのdiffに示す

PHP CI

PHPerKaigi 2022でLTしてきます。

fortee.jp

で、Problem Matchersの話に触れるのですが、5分では触れられ無さそうな内容を予め残しておきます。

Problem Matchers？

↓みたいな感じで、PR時のdiff上に「ここが間違っているよ！」を示す仕組み(の1つ)。 f:id:o0h:20220409013844p:plain

ざっくりいうと、

  • GitHub Actionsのアウトプット内容(actionsの実行結果画面って、標準出力的なやつありますよね)からPRのGUIに転記する〜という感じの仕組み
  • 「標準出力をパースするための定義(regexpのパターンや、その反映先のタクソノミーとの関連付け)」を予めどこかに用意しておいて
  • GItHub Actionsのstep上で、特殊な記法(=コマンド)を使って↑の設定ファイルを有効化させる
    • ::add-matcher::{{ 定義ファイルのパス }} という内容をechoする

という流れ。

例えば .github/pm-phpunit.json に定義ファイルを置いた場合、↓みたいなworkflowを作ると動く。
run: echo "::add-matcher::.github/pm-phpunit.json" がミソ

name: phpunit
on: pull_request

jobs:
  phpunit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: latest
          tools: composer, phpunit
      - name: Setup problem matchers for PHPUnit
        run: echo "::add-matcher::.github/pm-phpunit.json"
      - name: Composer install
        run: composer install
      - name: Run PHPUnit
        run: phpunit

詳しい話は↓ github.com github.com

実際の例

例として、こんな感じの定義ファイルを用意してみる。
状況をわかりやすくするために、「patternを1個だけ設定する」ようにしている。その影響で、(実用的では無さそうな気はしつつ)「messageには、ファイル名を入れる」という指定になっている。

f:id:o0h:20220409015529p:plain

これを使わせるためのstepを用意した f:id:o0h:20220409015829p:plain

PHPUnitの失敗したテストがある。
この出力内容を、patternに従ってPR(のFile Changes)に抜き出してくれるようになるのだ f:id:o0h:20220409015420p:plain

じゃーん！

f:id:o0h:20220409015505p:plain

という感じで、「regexpに合致したところから」「パターンにあるグループと、属性(要素)に変換して」「File ChangesのGUI上に表示している」ってな様子が分かる。

PHPUnitのProblem Matcherで、お手軽に使えるやつ

shivammathur/setup-phpもしくはdecnorton/phpunit-problem-matcherを使うのが良い。
php-setupを使っていない(独自のimageをbuildしている、など)の場合は後者一択。
利用方法は、それぞれのREADMEやソースコードを参照。

これら2つも、実際に定義ファイルを用意して利用していることになる。ので、「お手本例」を簡単に見ることが出来る。オープンソースありがと〜〜

github.com github.com

ハマった所

現状、setup-phpの方はいくつかのアサーションに対応していない(ように見える)。要するに、「指定されたregexpで対応できていないものが有る」。

↓これはうまくいく。 f:id:o0h:20220409020628p:plain

↓これらはうまくいかない。 f:id:o0h:20220409020654p:plain f:id:o0h:20220409020709p:plain

setup-phpの方の定義ファイルを見てみると、↓のようにpatternが指定されている。

      "pattern": [
        {
          "regexp": "^\\d+\\)\\s.*$"
        },
        {
          "regexp": "^(.*Failed\\sasserting\\sthat.*)$",
          "message": 1
        },
        {
          "regexp": "^\\s*$"
        },
        {
          "regexp": "^(.*):(\\d+)$",
          "file": 1,
          "line": 2
        }
      ]

紐解くと、

  1. 「数字＋閉じ括弧」から始まる行があって
  2. そのすぐ次の行に「Failed+スペース+asserting+スペース+that」を含む行があって
  3. 空白文字のみからなる行があり
  4. 「文字列＋コロン＋整数文字」の行がある

という感じ。

なので、

  • エラーメッセージがある(失敗例の1枚目には「なんか変だよ！」の出力がある)
  • expect/actualのdiffがある(失敗例の2枚目には不一致文字列の内容の出力がある)

といったケースでは、Problem Matcherがうまく拾ってくれ無さそう。

phpunit-problem-matcherの方ではこれらのケースにも対応できている(ようにみえる)ので、現状ではこちらを利用するのが良いかも知れない。

落ち着いたらPR出そうかなぁと言う気持ち

2021年もAdvent Calendarに参加しました

やったこと・書いたもの

メリークリスマス！！！

タイトルの通りで、2021年も年の瀬にAdvent Calendarに参加しました。
(一部の界隈で言う)Advent Calendarとは、12月に入ってからクリスマスまでの日々をカウントダウンしながら、1日ずつブログを書くぞ！！という催事です。

今回は複数のAdvent Calendarに参加して、胸を張ってクリスマス当日を迎えるつもりでした！💪
が、結果として、やっと今日・・・2022年の2月11日・・・に自分の担当分を投稿し終わりました。。。大遅刻ですね気が遠くなる悲しいな病んでしまう。

何はともあれ、完走したぞ、計72日*1を経て全ての作業を終えた！！グランド・フィナーレ！！やった〜〜！！という訳です。

完走の感想

結果とか出だしとか

とりあえず、書いたのはこんな感じ。

月 書いた本数
12月(advent期間) 55
12月(advent期間外) 2
1月 7
2月 11

adventar.org

adventar.org

adventar.org

やろうと思ったきっかけは、各カレンダーの冒頭に書いてありますが、
「あんまり仕事で開発してねぇ・・・」という状況を自覚した上で「だからって技術や開発に関わる成長が無いなんて事になるのは嫌だ、少しでも防ぐために自分なりにやってきたことはあるだろう、であればアウトプットくらい出来て然るべきだな・・・試すか！！」みたいなモチベです。

1人Advent、2018年にやった時は完全に生活リズム崩れたし辛かった印象が強いので、やりたい気はするけど・・どうしたものか・・・と思っていた所に、知人の「今年は1人Adventやる〜」的な声がTL上を流れていきまして。

はぁ、世の中には頑張っている人がいるぞ、じゃあ自分もどうにかなりてぇもんだ・・・と思ったので決心しました。

で、「複数個やる代わりにネタ出しのハードルをめっちゃ下げる」として、「今年既にやったこと」の放出でいけるモノを〜と考えたのです。
最初は「CfP応募したネタをふりかえってみる」＋「ここ1年くらいで興味を持って学んできた、アジャイル/スクラム系の本の感想みたいなやつ」で2本併走のつもりでした。
が、「どの本にしようかな〜」と思っていたら、25本は軽く超えていることに気づきます(既読/積ん読)。し、選ぶとしたらどういう観点よ???ってモヤモヤ感というか割り切れない気持ちが湧き、「あれ・・？もしかして・・？」と積ん読も完全に解禁して数えてみたところ、「ちょっと範囲を緩くしたら50冊近くあるね・・・・」「んじゃ2つに分けるか」となったのでした。

その結果、75エントリー(全部俺)が組み上がったわけです！！

やってみて

11月のうちに本を読み終わってる、少なくとも7,8割は12月に入る前に読み終わってないと厳しいぞ・・・・・と思ってたんですけどね！！
全然そんな状況になってなくて、12月に入る前から「Adventキツい」っていうのが確定しているような状況で。

実際の読了状況はブクログにある通り。 booklog.jp

てなことで、「読みながら書きながら」をやるハメになったのでした。
しかも、その内の何冊かは「重い本」「厚い本」だったり、それに加えて洋書もあると。

特に1月入ってからは、ある意味で「締切」もなくなったので一気に進捗が悪くなってしもうた。

とは言え、なんだかんだでやりきった。お疲れさまでした。 「1枚はちゃんとスケジュール通りに終わらせていたし」とか「ゆーて期限内に”普通の2倍以上”は書いてるんだよな」とかいった事実もあり、敗北感はあるものの挫折感はないかもな〜っていうのが今の気持ちでしょうか。それ以上に、ずっと続けていた＆平日も休日も頭の片隅にず〜っと渦巻いていたものがコレで解消したと思うと、やった〜〜〜！って気持ちが大きいのでした。

特に、この試みを通じて「良かったなー」と思うのは、

  • プロポーザルとしては削ったことや、「自分の中の課題や気持ちでしか無いから、応募内容に含めるものではないんだよな」といった部分を、そこそこ言語化できた。それを公に残すことも出来た。
  • 難しいぞって(自分の中では)位置づけにあって、実際に過去に数度は読み始めるも頓挫していた組織パターンを読み切った
  • 洋書 * 3をしっかり読み切った(A Scrum Bookは、端から端まで読み切ったわけじゃないけど)。今まで「洋書を1冊読み切ったことってあったかな？」という感じなので、実績を作れたの嬉しい。これでハードル下がった。
  • 自分の中で、長い間「いつか読むぞ〜」って思っていたり(Advent関係なく)大きなマイルストーン的な位置づけになっていた本、「LeanとDevOpsの科学」「組織パターン」「A Scrum Book」をしっかり読むことが出来た
  • 特にXP/Lean周りは、(スクラムに比べて)知識の補給・補強があまり行われていない分野だったので、いくつかの積ん読を集中的に消化できた
  • 「エッセンシャル スクラム」「This is Lean」「スクラム現場ガイド」「アジャイルな見積りと計画づくり」「エクストリームプログラミング」「アート・オブ・アジャイル デベロップメント」など、間違いなく鉄板と呼んで差し支え無さそうな本も通読できた

とかとか。
あとは、当初から目標としていた「まぁスクラムとかアジャイルとか勉強してるんですよ〜っていう感じを、(読書記録の物量を以て)形に落とし込めんじゃない？」というのもゴールにたどり着けたのでは！

書いたもの

せっかくなので！全員集合です！！！！！

*1:記事を書いた日は40日程度

「XPエクストリーム・プログラミング導入編 ― XP実践の手引き 」

1人Advent2021-2 読書記録

この記事は 「ひとりでアジャイルo0h② Advent Calendar 2021」のday-20です。 adventar.org

day-20は「XPエクストリーム・プログラミング導入編 ― XP実践の手引き」です。

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

XPエクストリーム・プログラミング導入編 ― XP実践の手引き (The XP Series)

Amazon

どんな本

「XPシリーズ」の1冊で、エクストリーム・プログラミング入門 の次のステップの位置づけになると思います。
名前の通り、「XPとはなにか」についての入門書的な説明の後の、「それぞれをどうやって使っていくか」といった部分に重きをおいた話になっています。 「こういうイベントを開いて○○を実施しましょう」とか「誰が関係するか」とか、「こんなメトリクスを使うと・・」とかといった話が出てきます。
XP入門が「価値原則」も丁寧に取り扱っていたのに対して、こちらは「プラクティス」よりとも言えると思います。

個人的には、「まずは具体的な話や個別的なプラクティスから理解を広げていってみたい」という人には、XP入門より先にこちらの本から手を出してみる〜というのも良いのではと思います。

お気に入りポイントかいつまみ

「XPって具体的にどんな事するの」が分かりやすい

目次をみると、まるでパターン・ランゲージのカタログのように「具体的な、解法を説明してくれそう」な予感のするタイトルのついた章が並んでいることが分かると思います。
(実際には、パターン・ランゲージのように各章で共通した形式が用いられているわけではありませんが)

目次は紀伊国屋のサイトで確認できます。

www.kinokuniya.co.jp

また、第1章・第2章は全体に関わるものなのでまず目を通した後は、その後の各章は独立して読むことが出来るので、気になったトピックからページを捲ってみる〜という使い方もできると思います。
そのくらい、具体性にフォーカスした内容であると同時に魅力的なパワーのあるプラクティスが取り扱われている、ということです。

「エクストリーム」に想いを馳せる

少なくないプラクティスが、昨今の開発の現場では「当たり前」になっていると思います。
とりわけ「11章 プログラミング」にある、コードの共同所有・リファクタリング・シンプルな設計・継続的インテグレーション・コーディング標準・・などは、XPを意識しなくてもやっている！というチームも多いはずです。
名前が「エクストリーム」とイカつい手法ではありますが、その一方で「誰でも知っているしやっている」ものでもある、というのはとても興味深いことです。

裏を返せば、現在の現場にいる我々や私自身にとって「そこまでやる？」とか「歪なやり方だなぁ」と思えているものが、10年も経たない内に当たり前になっている可能性だってあるぞ、という事なのだと考えています。

「なにをエクストリームに推し進めたかったの」「どういう価値感(常識感)からの脱却があったのか」を考察することは、これからの時代を読み解く上で意味を持つのではないでしょうか。
そういう視点から「ちょっと昔に書かれた、熱狂的なXP教本」のようなXP入門、本書XP導入編を読んでみると、また違った大きな発見があるように感じます。

特に好きな章

  • 14章「テストファースト―意図を伝えよう」は、本書の中では長い部類の章なのですが*1、テストファースト/TDDをすると何がどうやって楽になるの・・？が追体験できるような気がします
  • 16章「行うべきか、行わざるべきか」は、アジャイル的な振る舞いを端的に言い表しているなぁと思います
  • 27章「それはChetのミスだ」は、個々人の勇気を重んじつつも「チームとして動いているのであり、責任は(誰か1人ではなく)チームにある」というのを良く理解できる話でした
  • 20章「イテレーションを運転する」は、タイムボックスを定めて開発をしていると絶対に直面する「思ったより進んでないぞ」や「順調と言えるのだろうか？」についての対処の話です

まとめ

全体的に読みやすい・分かりやすいような文章で、躍動感を持った文体は読者にワクワク感を与えてくれるなぁなんて感じながら読み進めていました。
まだまだ「XPのすべて」という話では無いように感じますが(そもそもそんなものがあるのか？)、取っ掛かりとしては十分、そして実行してみるのにも十分！と言える1冊だと思います。

押し付けのように「XPだ、XPをやるぞ！」とやっていくのは難しいのかも知れません。
しかし、本書のように「そういうお困りごとだったら、ちょっとこれを試してみようよ！」と個別的なプラクティスを少しずつ導入していこう〜を助けてくれるものがあると、とても心強いのではないでしょうか。
そして最終的には、端から端までエクストリームになれると良さそうですね！

*1:コードがあるから、というのも1つの理由かと