「アジャイルプラクティス」

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

day-2は「アジャイルラクティス」です。

どんな本

個人的に「翻訳者の中に角谷さんの名前がある」という時点でもう信頼できる・・・という感じはあったりします。

「監訳者あとがき」によれば、 "アジャイルな開発者になるために身につけるべき習慣を、45のプラクティスとして取り上げ”たものです。
(”名詞的な「アジャイル開発者」ではなく、agileが形容詞であることに注目すべきだ”ということも、同じく監訳者あとがきで述べられています。いわく"「開発者がアジャイルである」という状態はあっても「アジャイル開発」というものはありません”。この本で扱っている「(アジャイルな開発者になるための)プラクティス」というのは、「書いてあるとおりに真似すればアジャイルをやれる!」というものではなく、「アジャイルな開発者が持つメンタリティ、マインド、それを行動に移すためのプラクティス」といった感じがあります。つまり、「ノウハウ集」よりも「精神性」を重視しているような、そんな印象を読んでいて持ちました)

ただし、たしかに「アジャイルなプラクティス」でありはするものの、「アジャイルを標榜してやっていく(やっていきたい)人たち)」よりももっと多くの人に共有されるべき価値観もふんだんに盛り込まれているように感じました。
平たく言えば、「うちはアジャイルな感じでやっていないし」って人たちにも読んでほしいし、実践してほしい・・と思うようなことが沢山。そもそも「アジャイルかどうか」って白黒つけて語るべきものでもないと思うけど。・・とりわけ、第2章は凄い色々な人に読んでほしいなー・・という感情を強く掻き立てられました。

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

ユーモアがあり、かつ実際的な構成・「天使の声、悪魔の声、バランス」

パターン・ランゲージのような「problem/context/force」という形こそとらないものの、本書は「複数の事柄を、カタログ的に、同様のフォーマットで記述する」という本です。
で、その項目立てがとてもおもしろいなーと感じました。

各プラクティスの冒頭には「悪魔の声」が差し込まれています。
例えば、「34. 警告をエラーとみなす」で悪魔は「深刻なエラーならコンパイルが通らないんだし、そうじゃない警告なんて無視しちゃえよ!」のような事を述べています。
で、悪魔の声を見た後に、何が問題で・どうすべき(あるべき)か?を解説する本文。悪魔の声があることで、自分の中の(美徳でない)怠惰に思い当たったり、あるいは他人事のような気持ちで「まさかそんな!」とでも思いながら本文に入れるわけです。(で、やっぱり自分に重ね合わせて反省したりする)

その後には「天使の声」が差し込まれます。
悪魔の声と真逆の、「アジャイルな開発者が従うべき心の声」が天使の声です。本文の結論部分を簡潔にしたもの、とも取れるかも知れません。
実際に、巻末に「天使の助言の一覧」があったりします。これを印刷して壁に貼っておきたい・・・

で、ここまでで終われば、ある種の説教臭い「正論」で終わってしまうかも知れません。
そこから踏み込ませるために「こんな気分」と「バランスが肝心」の項目が続きます。

「こんな気分」とは、「プラクティスを実践した時に、そうなるであろう感情」を書いたものだと説明されています。理想的な状態が実現できた時に、何が得られるか?みたいなものですね。
例えば、「13. いつでもリリースできるようにしておく」の「こんな気分」では、「いつ誰が職場にやってきたとしても、プロジェクトの最新版のビルドを躊躇すること無く、胸を張って披露できる」と書かれています。もし、今の自分の業務が「急にQAや上司が来ても、ビルドしてどなっているかを見せるなんて出来ない・・怖いぞ・・・」と感じられるのであれば、それは「このプラクティスをちゃんと実践できている状態に至っていない」と判断できるわけです。

そして、「バランスが肝心」です!
本書のプラクティスの多くはXPに源流があるような感じがします。「エクストリーム」にやろう、という中で「ツールやプロセスより対話を」大事にするのであれば、まぁバランスだって大事だよね??ということを思い出させてくれます。
では、どんなバランスをとればいいのか・・?については、「何を果たしたいんだっけ」と目的に立ち返り、現実的な価値を上げることが最優先指令なのだと思います。そんな事を思い出させてくれる、もしくは読者を(教条的すぎずに)建設的な思考に戻らせてくれるのが「バランスが肝心」の項だなーと感じます。

って言うわけで、「良いプラクティス」を述べつつも、読者の中で何が起きるか?についてのケアもしてくれるような本なのです。

マインドから、個人のプラクティスから組織のプラクティスまで幅広く

アジャイル」はひとりひとりの心のあり方を無視できないとは思うのですが、実際に総実践していくにはチームやチーム外の関係者との協働だったり関わり方も無視できません。
その辺りも、しっかりと抑えにいっています。

マインドであれば「応急処置は泥沼を招く」や「わかるまで質問する」といった話が取り上げられていますし、個人的な技法については「コードで伝える」「Tell,Don't Ask」の話だったり、チームプラクティスは「技術の採用根拠を明確にする」「共同所有を実践する」、チームを超えたコラボレーションについて「顧客に決断してもらう」「みんなに知らせる」などがあります。

こうした幅広く話題を扱っている世界観は、過度な集中を回避して自身の視座を適度に保つのに良いなぁ〜と感じました。

まとめ

ボリュームも少なく、ユーモアもありつつテンポもよく、面白い本でした!
個人の心持ちがなくては始まらない話ですが、こういったものをチームで共有できる語彙として持っておけるととても強力なのでは?とも感じます。ので、個人だけでなくチーム内で共同読書するのもオススメと言えそうな本。

やはり、「アジャイルラクティス」とかって色眼鏡をかけずとも「共感できる、刺さる」「個別に取り込みやすい」ような話もとても多いと思うので、その点では「アジャイル系の人」だけが読むのは勿体ないんだろうなぁ・・とも。

「4. 機雷がなんだ!前進全速!」は「気付いたことや感じていることを、誠実さと勇気を持って表明しましょう」という話なのだけど、この章の「バランスが肝心」には「自分の意見が賛同を得られない時は、彼らの意見が正しいかも知れないと考えてみましょう」とか「勇気を持って表明した結果、バックグラウンドを共有しない人からの反発にあうかも知れない。その場愛には、意思決定者にも理解できる言葉で説明しよう」とか書いてあるわけです。「勇気・尊重」などは、確かに「XPの価値観」とも見なすことが出来るのですが、この辺りの話は「一緒に開発をしている人にはみんな心に刻んでおいてほしいな〜」などと感じたり。

そういった「もっと広くの人に知ってもらいたいな!!」と感じる部分が、多々ありました。(そもそも、アジャイル/XP自体が「部分的にでも知っておいてほしい」というものが多いせいではありますが。)

読後の感想として、副題にある「達人プログラマに学ぶ現場開発者の習慣」っていう方に注目して、どんな内容の本なのかを期待してくれ!!って感じです。
アジャイルな開発者」を標榜する以前に「達人プログラマ」に近づきたいな?って動機でも、十分に読むに能う1冊だな〜と思いました!

「SCRUM BOOT CAMP THE BOOK」

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

day-2は「SCRUM BOOT CAMP THE BOOK」です。

どんな本

スクラムってどんな感じなんだろう?」を、簡潔にまとめた「基礎編」とストーリー仕立てでスクラムを適用していく「実践編」の構成で扱う本です。
恐らく、「日本語で読めるスクラムの入門書」としては決定版と言える1冊ではないでしょうか。

文書が平易なのと挿絵も可愛らしく、徹底的に読みやすさ・伝わりやすさに骨を砕いている様子が感じ取れます。
(そして”間違いない”執筆陣・・・)

フレームワークとしてのスクラムはシンプルだ、しかし実践は難しい」というのをそのまま表すかのように、「短い基礎編と、大半を占める実践編」のようなバランスになっています。すなわち、「決まり事や定義を説明する」ことよりも「読者に追体験をさせるかのような伝え方」に重きが置かれているような印象です。

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

ポイントが頭に入ってきやすい構成

実践編は、架空の会社でスクラムを実践していくストーリーに沿って展開されます。
各章の冒頭には短い漫画があり、主人公の「ボクくん」のお悩みに答えるかのような解説がテンポよく入ってくる、という構成です。(その中では、スクラムマスターの遭遇しやすい「板挟み」な状況・・ステークホルダーやチームに対してどんなコミュニケーションをとっていくか?もまざまざと描かれます)

また、インセプションデッキやカンバン、ユーザーストーリーによるバックログアイテムの記述などの「スクラムと相性のいいプラクティス」についてもサンプルを示しながら解説しています。

という感じで、全体的に「どこが重要なのか」が頭に入って着やすい、初学者に対してもついていきやすいような工夫がなされているな〜と感じました

基礎→実践、という抑え方

スクラムの入門書の中には、「最初から最後までストーリー仕立てで、1つずつ(ゼロベースで)問題とそれに対するスクラムの提供をインクリメンタルに進めていく」という構成もあると思います。
それでも勿論面白いのですが、個人的にはSCRUM BOOT CAMP THE BOOKの「最初に簡潔に基礎・概念を頭に入れてから」というスタイルは、読み手に基準点を与えるような働きをもたらしてい親切だな〜と感じました。もちろん、それが「最初の部分を読むのに苦労するくらいの分量だぞ・・・」となれば頭が痛いのですが、「まぁ今はわからないかと思うけど、いちおう世界観を紹介しておくね!!」くらいな手短さ・簡潔さなのが素敵なのです。

実践編を読んだ後に基礎編を読むと、見事に「今理解した内容のリマインダー」としても機能するものだと思います。

実感の持てる、漸進的なストーリー

先にも述べたように、本書の話は「ボクくんが困った時に、どういう風に(スクラムで)乗り越えたか」というものなのです。
なので、「こういうことになっちゃったぞ・・・」に対して「それには、こうしましょう!」とか「それではダメだよ!」のように一歩ずつ進んでいく感じなのです。読者も、このステップバイステップを味わえます。

ただ「決まりを押し付けている」ようにならないように「なぜ」や「アンチパターン」が示されることで、腑に落ちる感じが増します。アジャイルスクラムに初めて触れる、挑んでいくチームの成長を感じながら、その成長を実現した「仕組み」について種明かしを添えてくれる・・とでもいうような。

この辺りが、読み物としての楽しさを提供してくれるなーと感じます。それもまた、この本が他人に薦めやすい理由の1つ。

まとめ

「なんとなくスクラムがわかったぞ、そういうことなんだね」に最速に至るための一手を考えると、この本を通読してみるというのが解答の1つになるのではないか?と思います。もちろん、チームで輪読会などを催して「どう考えるか」「価値観やプラクティスの背後にある原則について深める」という使い方もしやすいと思います。
ある程度スクラムについての学習を進めた後には、ページをパラパラと捲りながら各章の見出しを読むだけでも重要なポイントを思い出せる&初心に戻れそうだな、という感じ。

これを手に取りながら、チームで一丸となってスクラムに挑戦してみる!!とかは面白い体験になりそうだな〜などと夢想してみたり

「Clean Agile 基本に立ち戻れ 」

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

昨年末〜今年にかけて、アジャイルスクラムについてお勉強してみよう!!みたいな流れがありました。 ある程度まとまった量を読んだかもなーと感じたので、関連分野で自分が読んだ本を紹介する!というのをAdvent Calendarとしてまとめてみようと思いました。

というわけで、このカレンダーではリーンやXP、それとアジャイルとは切り離せないであろう「ふりかえり」を中心にアジャイル関連の書籍・研修参加の感想について文章を書いていきます。 完走できるように頑張ろうと思います。

day-1は「Clean Agile 基本に立ち戻れ 」です。

「今の時代にAgileについて考える上で、最も強いメッセージを持つ本の内の1冊」みたいな印象が自分の中にあり。幕開けを飾る本として選びました。

どんな本

しばらく前に読んでおり、その際に記事にもまとめています。 daisuki.nichiyoubi.land

そこから多少なり知識や実践を積んだ今の立場で読んでみると、改めて発見だったり違う部分で感じるところもありそうだなーという気がします!

本書の特色といえば、やはり「ボブおじさんの本」であり、もっと言えば「著者の昔話がちょいちょい語られている」ところにあるようにも感じます (これは、人によっては冗長に感じられる部分なのかも知れません)。そして、ドキッとするようなパンチワードが所々に散りばめられている、ある種の痛快さのようなものを伴います。"希望はプロジェクトキラーだ” ”アジャイルは早い段階から希望を殺し、継続的に冷たくて厳しい現実を提供する”とか良いですよねぇ。。

アジャイルの生い立ち」を紐解きながら「どうしてアジャイルが必要なのか、何を助けてくれるのか」みたいな概論を扱いつつ、「アジャイルがどういうものか?」の側面については主にXPを引きながら説明するような1冊です。
アジャイルの歴史・教養本」でもないし、かといって「XPを解説したりテクニカルプラクティスを詳細に説明する本」でもなければ「どうやって現場をアジャイルに移行していくか?の手引をする本」でもないと思います。
本当に「全体像を感じる」というものであり、副題に偽りなく「基本に立ち戻れ」だなと。「立ち戻れ」ってことでもあるので、やっぱり「最初に読むべき1冊」ではないかも知れない。少しアジャイルに疲れた(?)ような人が読むと癒やされるんじゃないかなー

アジャイルについての「エモい本」だな、という感じがする

この本は先に述べたとおり「著者のかたり」にユニークさが出ているなぁ、と思います。
恐らく「アジャイルの本」をイメージした時に、中心的な話題に設定されるのはこの本において「3〜6章」のように感じる反面で、この本の本質は「1,2章と7章」にあるような気がしています。

1章は、(アジャイルマニフェスト前夜からの歴史と)アジャイルが何をもたらすのか、ソフトウェア開発の「悲惨さ」について。
2章は、ソフトウェア開発(者)に本来求められていた事は何だっけ?について。
7章は、ソフトウェアクラフトマンシップに触れながら「アジャイルは何を間違えてしまったのか?」とでも言うような話を。

ソフトウェアクラフトマンシップについてはコチラの記事などが参考になるかと思います。

kawaguti.hateblo.jp

なんというか、全体的に「アジャイルの今の姿に嘆きながら、それでも希望を持っていて、(スノーバードで合意したような)あるべき姿への復興を願っている」といった感じの本でした。改めて「基本に立ち戻れ」だな、と。
基本とは何か?というと、本当によく考えられて全てのエッセンスを詰め込んだであろうアジャイルマニフェスト+背景にある原則のはずです。そして、そこには「どういうプラクティスを取り入れるべきか」については書いてないと。
顧客の方を向いているか?開発者とビジネスは同じ方向を向けているか?正しく対話(フィードバック)を出来ているか?みたいな点だと思います。

結論(=最終章)には

これがアジャイルに関する私の記憶、意見、心からの叫びである。 (P171)

という風に書かれています。

まとめ

自分などはまだまだ学び始めたばかりで、実践知も貧弱ではありますが、それでも身が引き締まる思いで読みました。
アジャイルには「どうやって生き生きとした開発を行うか?」という部分への憧れのような、引力のようなものを個人的には感じています。色々なプラクティスが開発され流通しているのを、触れたり知ったりすることもまた楽しいなぁと思う部分です。そこに一生懸命に取り組んでいる姿など、とても勇気づけられます。

そうした明るい気持ちを持ちながら、何かの違和感のようなものを感じた場合(恐らくそれは「やり方」に対するモヤモヤ)には、ボブおじさんの顔を思い浮かべながら「基本に立ち戻れ」を念じたいなーと思いました。

「みんなでアジャイル」

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

昨年末〜今年にかけて、アジャイルスクラムについてお勉強してみよう!!みたいな流れがありました。 ある程度まとまった量を読んだかもなーと感じたので、関連分野で自分が読んだ本を紹介する!というのをAdvent Calendarとしてまとめてみようと思いました。

というわけで、このカレンダーではスクラムを中心にアジャイル関連の書籍・研修参加の感想について文章を書いていきます。 完走できるように頑張ろうと思います。

day-1は「みんなでアジャイル」です。

(このAdvent Calendarの名前の元ネタにしたので、初日に選びました😏)

どんな本

よく間違えられる(?)気もしているのですが、「みんな アジャイル」ではなく「みんな アジャイル」がこの本のタイトルです。
ここが重要だと思っていて、「アジャイルに興味を持っている人(開発者)に優しく紹介する」というよりも「どうやって、組織全体で"be agile"になっていくか?」を考えるものだと思っています。
「非開発」文脈にまで「巻き込んでいく」という訳で、基礎入門というより応用実践発展っていう感覚があります。
(ただし、「いわゆるアジャイルから遠い気がする人を(ですら)どう巻き込むか?」を扱っているという話であり、開発チームや開発組織を考える上でも非常に重要な示唆に富む1冊です)

この本が何をなそうとしているのか?どういうものを捉えているのか?について、とりわけ顕著に表しているのが 「ムーブメントとしてのアジャイル」という表現だと思います。 これは第1章の「「アジャイル」とは何か?なぜ重要なのか?」に出てきます。

それと、個人的に考える象徴的な言葉としては(第2章のタイトルにもなっている)「北極星」を挙げたいところです。

この本に興味を持っている方、あるいは読んだ方も含めて、翻訳者の1人であるryuzeeさんが語っているpodcastがあるので必聴です!! (fukabori.fmはとても面白いですよねぇ)

fukabori.fm

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

「ムーブメント」とは何か

この言葉は、「手法」「マインドセット」と対比する形で登場してきます。

「手法」に関して言えば、(アジャイルマニフェストにある「プロセスより対話を」に語られるように)「○○をやったらアジャイル」みたいな事ではないよね?という世界観をアンチパターンとして紹介します。例えば「2週間のタイムボックスで仕事をしているからアジャイルだ!」とかって話ですね。

そこから、「マインドセット」という捉え方でも不足があるとして批判します。
「プラクティスよりもマインド(考え方)」という点で、価値観への共感に基づいた行動であるはずです。何が問題なのか?それは、「まだ自分たちのものになっていない」ような点にあると言っていると感じました。
本書中の言葉を使えば、

"私は、アジャイルは「マインドセット」だとも聞いていた。アジャイルが思考の大きな転換を必要とするということには同意するが、それを「マインドセット」と表現すると簡単に責任逃れができてしまう気がするようにも思う。アジャイルな考え方だけでは不十分だし、「まあ、私はアジャイル的なものを全部理解しているけれど、一緒に働く人たちはこの新しいマインドセットを受け入れていない。なので私たちにできることは何もないね!」と言える余地を非常に多く残してしまう。”
抜粋:: Matt LeMay “みんなでアジャイル”。 Apple Books

という話であり、

"アジャイルの価値と原則はすでに他人が決めたものである。”
抜粋:: Matt LeMay “みんなでアジャイル”。 Apple Books

という態度では物足りないということです。

「みんなで」アジャイルをやっていくにあたって、此岸/彼岸があってはだめだな、と。
では、なぜ「あっち側」という考えに至る余地が残っているのか・・・?というと、恐らくは咀嚼の足りなさなのだと思います。「他人が決めた価値・原則」としての向き合い方なのか、と。

そして「ムーブメントとしてのアジャイル」という地平に辿り着きます。
ムーブメントってなんでしょうね。「感覚」と「行動」の両方が揃っている、「(組織や個々人の)内側から湧き上がってくる強い動機」「乗っかってみたくなるような強い方向づけ」のようなものを個人的に感じます。アツいエネルギーだぜ!

そもそもが、アジャイル自体が「色々な地点で同時多発的に発生した考え・プラクティスが合流した大きなうねり」であったよね、という事を指摘します。
「XPやっている人とかスクラムやっている人とかが集まって共通の言語に落とし込んだのがアジャイルマニフェストだったよね」のような点です。(このあたり、『パターン、Wiki、XP』あたりを見ると非常に分かりやすい)

そういった、「必然性と共感可能な強い価値観が揃って発現する大きなうねり」みたいなものであると良いよね、と。

第1章の締めくくりにある言葉です。

アジャイルを価値と原則によって駆動されるムーブメントとして取り組むとき、個別のチームや組織のニーズを満たす方法でそれらの価値と原則を実現するためにはどうすれば最善かを考える余地が私たちにはあるのだと主張し続ける。そうすることで、私たちは単なる受動的なフォロワーではなく、アジャイルムーブメントの能動的な進行役としての責任を負うのだ。”
抜粋:: Matt LeMay “みんなでアジャイル”。 Apple Books

北極星について

先にも述べたように「プラクティスや”正解”としてのマインドセット」から脱却していく必要があります。
そこで「目的・意義」を揃えてダブルループ学習を進めていく、現状に対して建設的な批判と改善を絶えず続けていく・・・というのが不可欠になります。
組織にとっての「北極星」がそれにあたる、と。

アジャイルをやっていこうとして陥りがちな罠」について、次のブログ記事を参照しながら説明しています。

toolshed.com

アジャイルを今の仕事のやり方をちょっと変えるだけのことと思っているなら、アジャイルから得られるメリットもちょっとだけになるだろう。今のやり方を選んだ元になっている現時点の思い込みや想定に疑問を持たなければ、どんなフレームワークを試しても今のやり方は変わることはないだろう。アジャイルラクティスを試す前に、以下の質問に答える必要がある。
・チームや組織が将来なりたい状態は?
・チームや組織の現在の状態は?
・将来なりたい状態になれないと思う理由は何か?
これらの質問に答えるのは簡単ではない。より良い仕事のやり方を知りたいと思っている人がほとんどだとしても、「より良い」の意味することを考えると、現時点での思い込み、期待、ふるまいなどを疑問視せざるを得ず、現状の心地よさと安定性を変えてしまうことになる。”
抜粋:: Matt LeMay “みんなでアジャイル”。 Apple Books

ある意味では、「アジャイルマニフェストで掲げられている価値観」についてすら、「自分たちの考えで意義を感じないなら肯定しなくて良い」と言っているようにすら見えます。アジャイルマニフェストを超えていくようなアジャイル、こそが「意義のあるものだ』とでも言うような。
何がそんなに強いエネルギーや深い思考を生み出すんでしょうね?それこそが、「自分たちにとって本当に意味のある実現したい・到達したい世界』であり、北極星なのだと思います。

その他の点も凄い。刺さりすぎる言葉がたくさん

他にも、(先のpodcastで触れられているのでぜひ!)組織重力という考え方であったり。
第5章なんてタイトルから良すぎて「不確実性を計画するのがアジャイル」であったり。(ここに「良い方向に進んでいる兆候」というセクションもあるので、これもワクワクポイントですよね)

また、第7章が「あなたのアジャイルプレイブック」です。
書籍「アジャイルサムライ」のファンは多いと思います。そこで紹介されている「インセプションデッキ」は、特に見かけたことがある人も多い印象です。自分の周りでも、「スクラムフレームワークは説明できないが、インセプションデッキは見たことがある」といった人も見かけるくらいです。
「概念はわかった、どう始めればいい?良い世界にどう近づいていけばいい?」という手引は一定の需要があるものです。オリジナルそのままで使えなくても、「考え方の考え方」としてヒントになる可能性が大いにあります。
って考えた時に、「あなたのアジャイルプレイブック」は尊いな〜と。

まとめ

非常にコンパクトに纏まっている本ではあるものの、「アジャイルを心底体感していくにはどうすればいんだろう?」についてグサグサと刺さります。そんなヘビー級の威力を持っている1冊。
定期的に読み直したい本のうちの1つです!

やったこと・書いたもの{2021,10}

OSS

github.com

ふと思いついて・・・くらいのノリだったのですが。
Sentryの公式SDKのREADMEに「3rd party integration」のセクションがあり、そこにconnehito/cake-sentryを掲載してもらいました。
(コネヒトCTOの了承済み)

勉強会・LT

PHP Conference Japan 2021に登壇しました

その他

Re: 成長戦略(2020)

「まとめよう、まとめよう・・・」と思いながらずっと時間が流れていってた。
今の会社に入って1年が経つので、このタイミングでケリをつけたい。
(その上で、この1年を振り返ってみたり、今考えていることを棚卸ししてみる土台としたい)
※ 2020年の7〜9月ごろから書いてたは貯め書いては貯めしていた記事になります。なので記事中で「ここ1年」とか言っているのは、2019年春夏 - 2020年夏秋くらいのことです。


公開タイミングはともかくとして、こんな記事を書いてから1年ほどが経った。

daisuki.nichiyoubi.land

記事中にも書いたとおり「内容についてはアップデートして行き続けられると良い」と思っており、また実際に自分の中で変化・変更した部分もあるので、改めて読み返しながら「2020年度上半期と下半期の変わり目くらいで考えていること」について整理してみたい。

以前の考え方

先の記事で表そうとした内容は、次のように理解している。

総論: いちエンジニアとしての成長実感の最大化

  1. 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか
  2. ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるか
  3. 「正しさ」を中心的な価値観に据えて、空気」よりも本質的な議論や意見交換に集中できること
  4. 自分がちゃんと本気を出しながら仕事に取り組める事

実際にコレを指針として行動をし・・というよりは環境を変え、そこでまた新しい刺激や「自分自身はどうした方が良いのか」と気付いた事が多々あり、今回の「差分」はそうした経験によるものがメインとなる。

今の考え方

結局の所は「どう成長していくか」をグルグルと考え続けている〜というのは変わらない。
また一言でまとめるならば、

総論: 主体的に不確実性を制御し、成長し続けるためのやり方の発見と実践をする

だろうか。

最も大きな「変化」というのは、実は自分の中の視点であり、逆に言えば「見方」が変わったのに比べれば自身の実力や経験値というのは然程変わっていないのかな、と思う。

その「変わったところ」というのが以下のようになる。

  • 「伸びる環境」というのはあるが、まず先出すのは自身の成長意欲と実践
    • 「すごい人」というのは居るし、憧れるが、「一緒にいる」だけで吸収できるものがあるはず・・というのは幻想
    • その「すごい人」をすごい人たらしめた要因はどこか?が重要そう
  • 「1つの事を徹底的に深くやる」よりも、「中心となる軸を、より立体的に捉えるための副次的な武器・視点」を得たい

これらについて、先のバージョンの「軸」を反省しながら照らし合わせる形で解きほぐしてみる。

差分の深堀り

1. 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか

これはまさに、この1年で経験できた。まだまだ結果が出た訳ではないが、自分にとってのターニングポイントになるものではないかと期待している。

「強い人と働けるのは福利厚生」というのは、この業界・職種でよく耳にするが、実際にそのとおりだな〜と思う。Slackで何気なくつぶやいた事に対して、さらさら〜〜っと関連する概念を紹介した上で「この本に書いてあるよ」とか言われるの凄い。普段の業務の中で出した、なんてことないPRに対しても「この本の概念を借りると〜」などと、原理原則まで立ち返って理解するきっかけをくれる。最高のUX!
他方で、あくまで「福利厚生」だなぁとも思った。

通常の業務において、「妥協せずに持てる知識・技量のすべてを注ぎ込んで成果を出すこと」というのは稀で、どちらかといえば「いま目の前にある課題にどうやって”対処”するか」が仕事の多くを占めていると思う。
時間軸やタスク観点でもそうだし、また組織内の「人」においてもそうだ。人によって、思考や技量が大きく違う。
そこでどうなるか?というと、「組織の平均くらい」の力が、おおよそのプロダクトの「質」になってくる。
もちろん、「内部品質がユーザー観点で即時的な価値を生むか?」というと否なので*1、「仕事をしなければいけない」以上はそれが正しい。
結果的に、「自分が扱う仕事」というのは、綺麗事や理想的なものでなんか出来ておらず、「集団の状態やレベルに合わせてやる」ことが業務となる。
(加えて言えば、大抵は「目の前にあるコード」をお手本としてプロダクトコードは増殖していくものなので、「昔書かれたコードの質が引き継がれる」という重力が強い。)

強い人が居るというのが「福利厚生だ」と思ったのがこの点で、働いたり組織に所属する上での魅力・楽しみになったりはするかも知れないが、「本来の仕事」の質へは必ずしも直接的に影響しないな・・・と。
当然、「その人が居ることによって、ちゃんとしていく部分」というのはもちろんある。しかし、「大多数がちゃんとする」までは「大半はそこそこのもの」であり続けるのだ。その「出来る人」が本当に「改革!!」「刷新!!」というところにフォーカスして動きでもしない限りは、そういう状態が続く・・・楽観的に見ても「ゆっくりしたペースでよくなる」くらいかな、と感じる。また、彼らも「与えられた仕事」があって、その仕事を選定するのは組織側の判断なので、結局「すごい人がいる」というのが「どのくらいの効果をもたらすか」というのは、当人対組織の関係性や働きかけの問題だったり、そもそもの組織としての価値判断がどうなっているか?に帰結していく。

リアルに「バスケットの国アメリカの空気を吸うだけで僕は高く跳べると思っていたのかなぁ…」という気持ちに。

しかしながら、自分にとっては、そこに気付いた事が強烈な希望となった。
「じゃああの人達はどうやって強くなったんだ・・?」という疑問に心を奪われ、自分なりに仮説を持つことが出来たのだ。

  1. そもそも「身を置いている組織や環境から、与えられた成長の質が高く、今の状態になった」という可能性が薄くなった
    • すなわち、「環境に依存せずに自己成長を規定できている」ことを意味する
  2. どうやって自己成長を支えているのか?を観察した結果、まずはインプット量が自分とは段違いだった
    • とにかく本を読む読む・・・!

「明確に自分と違う点」が見つかったことで、じゃあまだ自分も成長の余地が残されてるじゃん!!!という希望だ。

ということで、 「①自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか」は、今はこだわりが無くなった。

居るに越したことは無いが〜〜〜と思いつつ、実際にはこの職種だとコミュニティだったりSNS上で人と出会ったり繋がったりすることができる。
なので、必ずしも「いつも働く場所」に居ることは必須条件ではない。

また、「自分は自力で成長できるか?」というのを試すためには、いっそ「自分しかいない」という所に身を置くとわかりやすい。
新卒して入った会社を発った理由の1つが(当時はWebアプリエンジニアが他にいなかったので)「自分は必要なフィードバックを受け取れているのだろうか」という疑念からだったが、PHPを弄り始めて10年目を迎えようというこのタイミングで、一周して「自分の実力を高めるには自分でガンガンやるしかない」に至ったのは何だか面白いな。

Update: 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる「強い」人が近くにいるかに頼らずとも、自分が成長できるように考えて行動する

2. ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるか

これは、大事にしたい価値観として言えば、今も変わってないかなぁ。。

とはいっても、「結局のところ、組織や集団を動かしたり、既にあるプロダクト(コード)を変えていくのは大変なんだな」というのは先述の通り。
「自分が成長できるか」という期待を、身を置く環境(平たく言えば働く会社)に求めすぎていたなぁという反省を持っている。
なので、「必須条件」ではなくなったと思う。あるに越したことはない。ない場合、恐らく仕事はつまらない物になる・・

ただ、もうその辺りの「環境ガチャ」は不可避だと思うので、期待値を高める〜というよりリスクを下げる〜っていう方に重心を置いてみる方がよいのかな?と。
また、「自身の成長の幅を組織にコントロールされるべきではない」という点で言えば、「自身が影響を与え、変化させていく」という選択肢も必要。
この辺りを考えると「色々な現場で、色々な空気に触れる」というのは合理的かな〜と思うので、副業しながら動いていくのを前提としたいかな、という感覚。
「どこでも通用する技量やコミュニケーション能力」だったり「一般的に共通する課題、パターン」が身につけば、自分がもっと上手くやっていける可能性は高まると思う。

Update: ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるかは大事。そのために自ら働きかけ、築いていけるようにする力が必要

3. 「正しさ」を中心的な価値観に据えて、「空気」よりも本質的な議論や意見交換に集中できること

コレも本質的には変わっていないのだけど、でも掌返しだな・・・って思えるくらい、自分の中で感覚が変わった部分。

何が人格攻撃で何が違うか、は受け手の感じ方次第でしょと思う面がある。もしくは、人格攻撃でなくても「心が折れる」という状態が生じる。一生懸命やったはずが、自分なりの「誠実さ」が通じなくなってくるのは何よりも辛い。

そういうのまで気にし続けながら働くというのは、自分にとっては難しそうだなーと思う。

と先には書いたが、いざ自分が「1番無力な立場」になると、「やっぱりストレスを多く感じるな〜」と身を持って体験した。
この辺りは、↓に書いた内容にも通じる。 daisuki.nichiyoubi.land

「同じくらいの力量同士で、どんなボールでも投げあいながら論を交わせる」というのは理想だし効率良いんだろうなーと思いつつ。
争いは同じレベルの者同士でしか発生し得ないよなぁ〜と。 その上で、(前に人に言われたことだけども)「配慮を覚える」というコストは、支払うべき価値のあるものだな〜という感覚が現状。

そこに至るのが「驚異や不安に晒されてみて自分が辛かった、力を出せなかった」からだ・・というのが軟弱な人間だなぁガキだなぁとは思いつつ、自分自身に原体験として刻み込めたのは良い事。

それでも、「なんか良くないな、でも自分が持っている価値観を変えてまで”心理的安全性信者”になるべきだろうか?」と葛藤していた期間が短くなかった。
そんな時に「チームが機能するとはどういうことか」を読んで、その内容が非常に琴線に触れた。よ〜し掌でもなんでも裏返してやるぞーー!って思えるくらいには。

状況として「自分が実力でどうこうできる範囲なんて凄い小さいな」とも感じていた時期だったので、「より成功するためにはチームの力を引き出しきることが必要」「その目的のために、手段として心理的安全性」というような話が鮮烈に響いた。
心理的安全性」ありきではなくて、よりタフに前に進むためにやれる手段・・・であれば、自分も意気地になったりせずに合意しやすいコンセプトとなる。

確かに理性的に考えて&プロフェッショナルとして「言うべきことは言う」という選択も色々な場面で可能なはずではある。
が、それ以前に、「そもそも言ってみたくなる」とか「ちゃんとしたいと思えるか(気付けるか)どうか」についてもハードルがあると思う。その辺りは、「普段から快適な発言や意見交換を出来ているか」は無意識にフィルタリングされてしまうのではないか・・?

結局の所、「正論はガンガン言うべき」も「然るべき配慮を伴って発言をするべき」も、高次元でみたら目的は一致していると思う。
「誰かが意見を言ってくれない」というのが「自分にとって損な事」という点。
その目的地へと向かうにあたって、「ぶつけ合う」道を選ぶか「引き出す」道を選ぶか?というところ。
理屈として、突き詰めればその2つに差はないと思うんだけど。ただ、実際問題として「人間や心は面倒くさい」ので、「どちらがリスクが低いか」「コストが低いか」のバランスなのかなーと。
そう考えた時に、自分自身が「実際に参ってしまった」というのが「前回と今回の時点での差分」となる。

穿った見方をすると、「発言するのにハードルを感じる」のは「自身の正しさに自身を持ちきれていない」という側面もある場合もあり、すると「稚拙な意見」が表明される可能性もあるはず。
そうなった時に、「組織として成長する方法」を観点として持つことで、「全体的なベースラインを上げる」というのも実行可能な選択肢に含まれるはず。
であれば、「稚拙さ」がなぜ生じているのか・・?を考えるのは、重大な示唆をもたらすのではないか。
「知識が暗黙的になっていて、共有されていない」だとか「埋めるべき技量のギャップが放置されている」だとか。
そういった「寄り添い」がチームを育てると思うし、長期的には「多様な視点、複眼的な意見をチーム内にインストールしていく」という価値を形成していくはず。
だとすれば、やはり「みんなが色々と言いやすい・感じやすい」ようになる方向へと倒すほうが、合理的なんじゃないかな〜と。

もっとシンプルに言えば、「人の意見や感情に向き合う」という謙虚さから、自身やチームが学び取れることは多いはずだ、と。 スタンドプレーや結論を急ぎすぎる組織は、重大な見落としをしたり、ベストではない結論に手を出してしまいかねないリスクに晒されている。 もし自分が「あらゆる正解を出せる実力がある」と信じて、独裁的に振る舞っても問題がないとするのでもない限り、 「自分より他人のほうが凄いかも知れない」という可能性を肝に銘じておく。

Update: 「空気」よりも本質的な議論や意見交換に集中できることは重要。多様で複眼的な意見を吸い上げる事が、より「本質」に向かうための手段となる

4. 自分がちゃんと本気を出しながら仕事に取り組める事

これについては、文字面を見ると「それが出来るに越したことはない」と思いつつ。
他方で、「成長しよう」という観点から言えば、先述としては「環境に自身の成長を委ねすぎるな」が今の気分であり、当時と少し解釈が違うように思う。

先の記事で書かれた内容を掻い摘むとこうなる。

  • 「考えなきゃいけないこと」を減らしたい
    • 例えば自分に課せられているミッションがコロコロ変わるのは辛い
    • 「守らなきゃいけない領域・要素が増える」のは今の自分が望むものか?その場合、「職種」としての実力や経験値は増やせそう*4だが、「技術力を伸ばす」のに集中できるか?といったら、鈍化しそうだ。
  • そうすると、「組織規模自体が少し大きめで、各領域が専門化している・役割分担ができている」「組織開発に力を入れようとしているという姿勢が見える」という条件がついてくる
    • マイクロなところでいえば「EMが機能していそう」というのも含む*5。

すなわち、「1つの分野・領域を、とことん深掘れるようにする」ことに重きをおいている。

Update: 自分の「成長」の源泉はあくまで自分が作り出す。それと「会社に与えられたミッション」の同一性を求めすぎない。ただの「薄くて広い便利屋」にならないように、自身の提供できるトータルの価値を築く必要はある

これらを踏まえて今の気持ちを振り返ってみる

今回は特に②の後半「プロダクトに反映できる事」が重要かなぁという風に思う。
また、④についても芯は同じ。ただ、「EMが居て自分を引き出してくれる」状態を望んでいた前回に比べれば、変容もあり、「自分がやるべき仕事がある」ことを感じやすい環境が良さそう。戦略レベルでは同じだが戦術レベルでは総入れ替え、というか。
要するに、「もっと必死こいて手を動かして、会社やサービスを進化させる側に居る」とい状況を実現したい。

①については、口惜しくはあるが、有る種の「検証」が現職で出来たような感じ。プライオリティが落ちる。
「誰かから教えを盗む・もらう」だけでなく、「自分で学んだ・調べたことをアウトプットしていく」という学習の形も有る。実際、過去を振り返って考えてみると、最も自分の力が伸びたと感じたのは「新しい人が入ってきて、必死にその人のコードレビューをした時」だった。また、大きめのカンファレンスでの登壇を数回経験して感じたのは、「自身の思考を整理する」事によって得られる成長というのは間違いなくあるというもの。
そう思えば、「周りの人間に絶望するより前にやるべきこと」として、もしかしたら周囲のメンバーを惹き付けて相互学習したり、相手のレベルを高めるには?という観点に立つ事で、不満を解消できるかもしれない。

③については、過去の環境で「出来なかった」のがショックでもあったので欲していたが、少し”丸くなった”んと感じているた点。今なら気をつけられる気がする(し克服した方が良いのも理解はしているし)、「やっぱり皆で活き活きできるように頑張るの大事だよね・・・」という方に関心も少しは向いたので、ちょっと視点を変える。
とはいえ、「コトに集中して、理性的に互いへ向き合える環境であるか」の部分は変わらず。一体感が備わっている事は必要。

差分についてまとめると。
「深いところに行ってみたい」のは、当時も今も変わっていないが、「その道のりを変えてみても良いのかもしれない」というのが差分。 「身近に凄い人が居てもそれだけでは十分じゃなかった」という所から修正が加わったので、次は「自分が多種多様な打席に立つことで武器を増やし、それを使ってコアな領域も深める」という形でやってみようか?と。

ただ、これまでよりも遥かに「自学する」ことは必要になりそうだなぁ。そうでないと「浅いやつ」になっちゃう。

今の状態の総括と、今後のことを考えての大方針

  • 自分から見て「すごいレベルの高い人」と一緒に働けた事は大きくて、他方で「そういう人がいる環境で働きたい」といっている自分は「"外部環境"という非常にアンコントローラブルで不安定・不確実な因子に依存していないか」という事に不安を覚えた
    • その「すごい人達」がすごい理由は、自身で自己を高めるべく尋常じゃない研鑽(インプットだったりトレーニングだったり)に当たり前のように取り組んでいるからだ!というのを目の当たりにした
    • 自分も、そのように「自分で自分の成長を実現する」ような力をつける必要がある。主導権を取り返す。
  • 総合的に「より自身の選択について高い確実性を獲得するには」というのがテーマな気がする
    • 例えば「非常に小さなorアーリーな環境も選択肢に含めたい」と思った際に、よりハイキャリアorフルサイクル(もしくは両者)の経験が足りていない
    • 例えば「経験の深い言語やFWの制約を超えた選択肢を含めたい」と思った際に、経験領域の幅が足りてない、少なくとも「学びほぐし」の力は磨いておく必要がある
    • まして、「自分で何かを欲した時に学ぶ・深めることが出来ない」「学ぶべき課題を自ら発見できない」というのは、不確実性の最たるものではないのか。逆に、それができれば生き続ける事が、それまでと違う次元で可能になりそうな気配がする
      • 考えてみたら今の「職業プログラマ」だって、よくわからないままに「自分でコードをコピペしてみて、少し変数の内容を変えてみる」ところから始まっている。その結果として”あり得ない飛躍”が起こって、広告とかインターネットに少し興味あるようなそこら辺の社会学の学生が、「エンジニア職のキャリア」という世界線に突入できたんじゃないのか
      • 今や「コード書けて当たり前」すぎて意識しなくなっていたけど、確かに当時は「やり方がわからない」「出来ないからやらない」なんて全く思わなかったし、「これを真似したら動くの?」という素材集めと真似事みたいなものから始めていたし、むしろ「真似事をする」のが自分の世界観だった

ということで、これまでは

  • 自分の得意領域・強みを強化する形で、深めたい
  • そのために「師匠」といえるような人がいて、自分の取り組むべきコア以外についてはサポートしてくれるマネージャーや組織環境がある

ことを欲していた。これが、

  • 自分の好きなこと・得意なことは、腹くくって自分で勉強していかないと、打ち止めになる
  • 「成長する・できる」について、もっと総合的にとらえる(「仕事」がインプットやトレーニングの全てではない
    • 「会社を使って伸ばす部分」と「自分自身で伸ばす部分」を区別して考える
  • 会社には、いかの要素もしくはそのいずれかを求める
    1. 技術的な幅を広げる: 自分だけでは学習の手が動きにくそうな部分を会社を使ってやる。コンフォートゾーンを抜ける。
      1. インフラとか
      2. PHP以外とか(GoとかJS/TSとか!
      3. フロントエンドとか
    2. 職業的な経験を広げる: 独学しにくい部分、たとえば「集団や組織にまつわる」部分
      1. コミュニケーションやリーダーシップやマネジメントの経験
      2. 「環境に依存するのはリスク」と考えて、「自らが環境や他者に働きかけて”変えていく”側になる

(ここで時間が現在に戻ります!!)

2021年時点の考え、みたいなのも書いておきたいな〜〜〜キャリア的には割と大きい1年だった気がする!

やったこと・書いたもの{2021,07}

OSS

github.com

勉強会・LT

その他

突然(w)Podcastにお誘いを受けて、お喋りしてきました。
以前にもTwitterなどで相互に認識をしてた人にカンファレンスで「お話しましょう!」とメンションを貰って喋ったり、今回もイベントやらカンファレンスで見かける中でTwitter上でたまにリプライをもらったり〜からの招待だった*1ので、不思議なもんだなぁとかとても有り難いことだなぁって感じる。

anchor.fm

*1:共通の知り合いがいるのも大きかった気はするけど