Mura-Mi

AI vs. 教科書が読めない子どもたち

年末年始に『単体テストの考え方/使い方』(原著: Unit Testing Principles, Practices, and Patterns, 以下 UTPPP) を読んだ。単体テストの考え方/使い方作者:Vladimir Khorikovマイナビ出版AmazonUTPPP 内でも紹介されているが、テスト駆動開発 (TDD) には大きく「デトロイト学派1」と称される考え方と「ロンドン学派」と呼ばれる考え方が存在して、その最も大きな違いはモック (テスト・ダブル) に対する考え方にある。自動化されたテストによるアプリケーションのテストカバレッジを向上させる上でテスト・ダブルの活用は避けて通れないが、テスト・ダブルの利用にはメリットもデメリットもあるため、2つの学派のスタンスを踏まえた上での落とし所を見つけることが重要となる。テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして、私は後者なのでほとんど使わず、このエントリに深く同意するところです / “モックは必要悪で、しないにこしたことはない - …” https://t.co/VjDvospTKu— Takuto Wada (@t_wada) 2021年10月15日  デトロイト学派のバックグラウンドとなる書籍として有名なものが Kent Beck による『テスト駆動開発』(通称: TDD本) であり、一方でロンドン学派による TDD 手法が解説されているのが『実践テスト駆動開発』(通称: GOOS) である。JUnit を始めとする "xUnit" と称されるテスティングフレームワーク群を用いたテスト手法パターンを解説した『xUnit Test Patterns』(通称: xUTP) もバイブルとして挙げられるだろう。UTPPP では、この3冊の内容を踏まえた上で、現実的なエンタープライズアプリケーションにおける自動テストの実践方法が説かれている。 TDD本やGOOSが単体テストを通じた「真っ当なオブジェクト指向プログラミング」へと導いてくれるように、UTPPP も書籍を通してテスタブルなアプリケーションアーキテクチャを実現してゆく過程で ヘキサゴナル・アーキテクチャへと行き着く流れがよく出来ていると感じた。極めて個人的な視点で、そんなUTPPPの推しポイントを2点紹介してみたい。エンハンスし続けるアプリケーションの目線からみたテストの価値観「良い単体テストとはどのようなものか？」という問いに対するよく聞く回答の一つに「良い単体テストは F.I.R.S.T. の原則を満たす」と言われる。Fast: 高速に実行されるIsolated / Independent: 他のテストケースや依存先から隔離され、独立しているRepeatable: 繰り返し実行できるSlef-validating: テストの成功・失敗を単体テスト自身が判断できるThorough: 網羅性がある2この F.I.R.S.T. の原則は間違いなく重要だし、効果的な単体テストを書くスキルを身につけるための出発点であることは間違いない。一方で、F.I.R.S.T. には「プロダクションで動くアプリケーションをメンテナンスし続ける」ために必要なバランスという視点が欠けているようにも思える。『Googleのソフトウェアエンジニアリング』にて「エンジニアリングとは、プログラミングを時間方向に積分したもの」という言葉があるが、F.I.R.S.T はまさにプログラミングの視点で「テストを書く」ための指針なのである。そこで参考になるのが、UTPPPの示す「良い単体テストを構成する4本の柱」だ。これはまさに単体テストの「エンジニアリング的」な価値基準を表しているのではないだろうか。それぞれの詳しい解説は本書に譲るが、具体的には、以下の4つである。リグレッションに対する保護リファクタリングへの耐性迅速なフィードバック保守のしやすさUTPPP の中ではこの4本の柱の中でも「保守のしやすさ」以外の3つはトレードオフの関係にあると述べている。1つめの「リグレッションに対する保護」はテストの存在意義そのものであるためトレードオフ上捨てるという選択は存在しない。どのように残りの「リファクタリングへの耐性」と「迅速なフィードバック」のバランスを取り、テスト・ピラミッドを構成してゆくのかを考えることが本書のテーマだ。だから「単体テスト」と題名に冠されているが、最終的にはインテグレーションテストまでを扱うことになっている。モックの使いどころの理路整然とした解説これまで自分自身も、サーバーサイドアプリケーションを開発する上でさまざまなテスト・ダブルを活用してきた。「この場面ではXXXをモック化するべきか、実態を利用するべきか」は常にチーム内で議論になるものだし、言語化も難しいテーマだ。なんだかんだ開発がスムーズに進む場所で落ち着きはするのだが、もう少しロジカルな納得が欲しいと思っていた。UTPPPでは、依存関係を「共有依存」と「プライベート依存」、「プロセス外依存」などの分類をしながら、どの依存関係にテスト・ダブルを導入するべきかを説いているところが良い。自動テストのピラミッド理論を知っていたとしても、そのピラミッドを体現するための匙加減や技術的なコツをしっかりと言語化した資料にはなかなか出会えないのではないだろうか。言うなれば、UTPP はテストに関する経験値稼ぎのショートカットになるのではないかと思う。これまで「ちょうどよいテストピラミッドを構成するための勘所はメンターと仕事を共にして養おう」となっていたものが、そのようなメンターに恵まれなくてもなんとか試行錯誤をする勇気をくれるのではないかと思っている。各論でいえば「そうは書かないだろう」と思う部分もあるし、C#というプログラミング言語に疎いが故に持つ違和感もあるのだが、全体的にはとても良く整理されている書籍だと思いました。気になる方はぜひ。↩↩

『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう

測りすぎ――なぜパフォーマンス評価は失敗するのか?

THE FIRST SLAM DUNK re:SOURCE (愛蔵版コミックス)

単体テストの考え方/使い方

昨年の振り返りで書いたように、2021年10月をもって正社員として働いていた会社を退職して以降、半独立した形で複数の企業と関わる1ようになった。t-and-p.hatenablog.com結局は2022年もこの形式のままフルで過ごした。既に関わらなくなった企業を含めると今年1年で5社と関わったことになった。もちろん自分にできる貢献を各社にしつつ、様々な学びをさせてもらい続けた日々だった。求めてくださった皆様に感謝の限り。「アジャイル・コーチング」と言う恥ずかしさが消えたのは一番多かった仕事は開発プロセスやチーム運営に関する支援だ。スクラムの実務経験がないメンバーでチームを組成している状況で手本を示したり、チームリーダーの壁打ち相手になるような仕事である。これまで自分自身が経験してきたことを踏まえつつ、クライアントの「外側」にいる立場だからこそ「こういう事もできるけど、あなたはどうしたいの？」と問うことで、クライアントにも自分にも様々な発見があった。当初は自分の仕事を「アジャイル・コーチング」と呼ぶことにどこか恥ずかしさがあった。日本国内を見ても、アジャイル・コーチというキーワードで出てくる顔ぶれが錚々たるもので、自分がその人々に肩を並べて同じ働きをできるのか？と思ってしまったのだ。自分がやっている仕事は所詮 "自称: アジャイル・コーチ" でしかないのでは？とも思っていた。この気持ちを拭うきっかけになってくれたのが、これまでも何度か自分のキャリアの転換点を作ってくれた横道稔さん (id:ykmc) だった。今年の前半のどこかで彼とお話しさせてもらったとき、誰だってきっと最初は "自称" だったんだよという言葉をもらって重荷が取れたように思う。確かに、認定資格があるわけでも、誰かが自分の "アジャイルコーチング" を評論したり点数をつけるするわけでもない。目の前のクライアントに向き合うこと以外の邪念の多くを捨てることが出来たような気がしている。感謝しかない。「教育」と言うのはおこがましいけれどもアジャイルコーチングの他に、"ITプロフェッショナルの卵" を対象にした研修にも関わるようになった。自分が新卒で入社した会社を退職するまでの4年半の間には、内定者研修を手伝ったり、新人を現場で指導するメンターとして働くこともあった。その頃から「もっとこうすればよい新人が育つのに」と思うことも多かった。その当時の思いも胸にしつつ、これまでにないバランス感覚の求められる仕事をさせてもらっている。実際に研修の企画や実施を行うとなると、想像した以上に変数が多い難しさを感じる。社会人生活を初めて3〜4年目の青かった頃の自分がそのまま新人教育に関わってたら大変なことになっていただろうなぁとさえ思う。エンジニアリングマネージャーとして働いたり、様々なフェーズの会社に身を置いてきた自分だからこそ出せる成果やできる貢献がある、と思って仕事をしている。来年は研修周りの話もどこかでパブリックにできれば良いと思っている。翻訳レビューとか翻訳とか仕事外のことでいえば、書籍『ソフトウェアアーキテクチャ・ハードパーツ』の翻訳レビューに関わったことも新鮮だった。翻訳レビューに参加した『ソフトウェアアーキテクチャ・ハードパーツ』の献本が届きました！ほんの少しですが初めて書籍制作に関わらせて頂いて様々な学びがありました。過去の職場で悩んだことをおさらいになったり発見があったり、読書としても最高の体験でした。 @snoozer05 さんお疲れ様でした！ pic.twitter.com/RxOy87VUai— むらみん (@Mura_Mi) 2022年10月21日  内容もさることながら、その編集プロセスを見ることが出来たのが個人的に大きな経験だった。CSS組版などの概念は知っていたけれども、実際にそれがワークしているプロジェクトを見たのは初めてだったからだ。普段の自分の生業であるシステム開発では当たり前のように継続的インテグレーション (CI) や継続的デリバリー (CD) を実践していたし、それがない世界を考えたことが殆どなかった。一方で自分の中ではこれまで「書物」や「ドキュメント」を CI と紐付けたことがなかったので、この経験を通じて CI が存在する意義や生産性の圧倒的な向上を再認識したように思う。この学びは本業にもフィードバックすることが出来て、研修コンテンツの制作には Vivliostyle — Enjoy CSS Typesetting! を活用して、 textlint や markdownlint を組み込むと言った鉄板構成に取り組むようになった。また、InnerSource Commons JP コミュニティに関わることになり、そこでも英語コンテンツの翻訳に関わるようになった。インナーソースの話は個人的に大きな関心を持っているんだけど、どうしても仕事と絡んだ話になるので、また別の機会にじっくり話したいと思う。innersourcecommons.connpass.com総括とか来年とかそんな感じで、2022年はこれまでにない経験をたくさんできて、これまでの職業人生活とは違った充実を感じ、大きな進歩を実感することとなった年であった。この記事では言及してないけど、私生活でも息子が産まれて2年が経ち、今年も未知の世界を息子に見せてもらい続けた。一方で、ストレスゆえか身体に出るような不調があったのも事実で、ハイテンションで駆け回って知らぬうちにダメージを負ってたのかなというのもある。公私それぞれ思い当たる節がないわけでもないので、自分なりにストレスを受け流したり忘れたり遠ざけたりしながら、来年もいい感じで生きていこうと思う。契約社員として雇用形態を結んでおり、それ以外の企業とは個人事業主として業務委託契約を結んでいる。↩

2022年のこと

ブクログやAmazonの購入履歴を振り返って5冊を挙げてみる。教育部門: 個別最適な学びと協働的な学び続きをみる

2022年に読んで良かった本5冊+1絵本

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

同僚から「CI のみで JUnit による単体テストが失敗するので診てほしい」と頼まれたので調べた話。良い設計とか良いテスティングを考えるために敢えてちょっとストーリー仕立てにしています。興味があればお付き合いください。 起きるはずのない NullPointerException実際のコードはもっと込み入っていたのですが、簡単に書くと、失敗して問題となっていたのは以下のようなテストコードでした。  @Test  void testListWeekends() {    Weekends result = DateUtils.listWeekends("20221201", ...

怪奇な NullPointerException はどこから来た？

今更だけど、2022年のベイスターズの話をしたい。あんまり話題になってないのかもしれないけど、今年のベイスターズの取り組みで面白かったのが『ワーキングハマスタ』という企画だ。www.baystars.co.jp2019年に新設されたプライベート観戦スペース「NISSAN STAR SUITES」を1部屋数名に対して開放し、朝から球場開門までの約6時間の間、リモートワークを行うコワーキングスペースとして利用ができるという実験的企画。自分は4月のある試合、朝からワーキングハマスタ、夜は試合観戦と一日まるまる堪能コースを味わった。ワーキングハマスタでは、室内もテラスも利用できる。それはもちろん、テラスに出て早出練習の様子を観ずにはいられない。1 詳細な時間は覚えていないが、最初にそれらしい姿が見えたのは誰もいないスタンドだった。上下とも黒のシャツとハーフパンツ、真っ黒のサングラス、そして只ならないオーラ。 その影が左翼ポールから現れても、三浦大輔であることは明確だった。数々の球団ドキュメンタリーや広報素材で見慣れた、淡々と客席の間をぐるぐると回る姿は現役時代は現役時代と変わらない。ただ一点、視線を落とし、スマートフォンに打ち込んでいる様子はジョギングというよりウォーキングであった。そういえば、ベイスターズ内でのコミュニケーションには Slack が利用されている という。それを知った時は「デスターシャのカスタム絵文字は入ってるのかな」「今永の個人チャネルには哲学的なつぶやきが流れているのかな」なんていう "ベイスターズSlackあるある" を考えてしまったけど、「マネージャー」が Slack 中毒にならざるを得ないのはここでも同じなのか、と思ったのはこのときだ。時はチーム内で COVID-19 の集団感染が発生しており、選手登録が毎日のように目まぐるしく入れ替わっていた。現場を預かる指揮官だ。今日は誰のコンディションが悪い、スクリーニング検査の結果はどうか、みたいな話がひっきりなしに入っているんだろうか、と思った。グラウンドで言うと、最初に出てきたのはこのオフに6年にわたる大型契約を球団と結んだ宮﨑敏郎だった。宮崎が一番最初にグラウンドに出てくる、という話も聴いたことがあったが、本当だったんだ。試合開始の8時間も9時間も前になる光景であった。ゆったりとした時間ではあったが、簡単に触れてはいけない緊張感があった。これが人生をかけて、億の金をかけてやる野球なのか、と改めて感じた。この日、些細なバッテリーエラーに乗じて二進を試みた宮﨑は脚を痛めて途中交代。翌日以降は様子を見たものの症状は好転せずに登録抹消となった。脚力を期待されている選手でもないのだからあのような走塁で無理をするな、という声を当日のSNSでは多く見かけた。確かに最もだと思う。一方であの光景を見た自分には言えない言葉だった。        View this post on Instagram            A post shared by Murakami Takuya (@mura_mi) ちなみに言うと、ワーキングハマスタからの球場での観戦は、球場周辺に気軽にシャワーを浴びれたりじっくり休む環境を確保できないと30歳オーバーの身体にはしんどかった2。試合自体は F・ロメロが阪神相手に立ち上がりに打ち込まれ、そのタイミングで酒も回ってしまったのもあり、あまり堪能できていない。2022年の後半によく見られた、派手ではないが着実に勝つ試合であっただけに少々勿体なかったが、藤田一也の復帰後初ヒーローインタビューは感慨深く聴いたものだった。利用規約上、練習風景の写真を撮ってはいけないルールになっているので写真はありません…↩ハマスタ終了から試合開始までの間でオンラインセミナーに参加しなければならず、その時間が取れなかったので一層厳しかった。↩

『ワーキングハマスタ』で観た、忘れ得ぬ光景

スクラムにて効果的なスプリントバックログを書き出すには？という話です。スクラムに則っていることを前提とします。スプリントバックログとはどうあるものかスプリントバックログ (以下: SBL) は「スプリントに設定された目標1を達成するために必要だとチームが考えている作業の一覧」です。スクラムではこのスプリントに設定された目標を達成するために取り組むプロダクトバックログ (以下: PBL) を選定するので、SBLの大半は「PBL を完了させるために必要な作業」となります。2PBLを完遂するためのSBLを書くただし応用として、複数のPBLの上流となる作業が生じることもあるし、PBLとは直接関係しない作業もSBLとして扱うこともあります3。単純なPBLとSBLによるツリー構造になるとは限らないことに注意したいです。PBLとSBLは必ずしもツリーではない有用なSBLを書き出すことで、PBLの完了間際になってチームが慌てふためくことを防いだり、大半のPBLが未完了のままスプリントが終了してしまうリスクを軽減したりできます。これは、PBLが完了するまでの道のりが SBL として明文化されてチームで共有されるためです。これはスクラムの柱のひとつである「透明性」の実現にあたります。完了までの進捗を把握する有用なスプリントバックログをどう書き出すか「完了の定義」と「受け入れ基準」を活用することで、予め抜け漏れが生じづらい有用なスプリントバックログを書き出すことが出来ます。むしろ、後から困ってしまうような「完了の定義」と「受け入れ基準」を運用しているならそれは問題で、改善する必要があると言えるでしょう。これを上手にやるには「完了の定義」と「受け入れ基準」をそれぞれ理解している必要があります。完了の定義と受け入れ基準完了の定義 (Definition of Done = DoD) は、開発者を中心としてチームが主体的に定める「すべてのPBLが完了時に満たすべき事項の一覧」です。インクリメントはどの程度テストされているべきであるかや、開発環境にデプロイするところまでをもって完了とすること、など。完了の定義は、PBLの実装内容に依らず共通するはずです。受け入れ基準 (Acceptance Criteria = A.C.) は、「PBLがプロダクトオーナーの意図した通りに実現されていることを確認するための手段」です。受け入れ基準はPBLごとに異なります。例えば、「タイトル欄が未入力で送信することができないようにする」というPBLと、「タイトル欄に絵文字を入力できるようにする」というPBLでは、実現する機能や価値が異なるので、PBLが完了とみなされる基準 (= プロダクトオーナーが受け入れる基準) も当然異なります。受け入れ基準は PBL の一部なので、その記述内容はプロダクトオーナーに責任があります。全ての PBL が DoD を満たすべし！完了の定義と受け入れ基準からスプリントバックログを導き出す「PBLを完了させる」とは「完了の定義と受け入れ基準を満たす」ことであり、「PBLを完了させるために必要な作業をSBLとして書き出す」のだから、「完了の定義と受け入れ基準に沿ってSBLを書き出す」ようにすれば、必要な作業の大半を洗い出すことができる はずです。抜け漏れの起きづらい SBL の書き出し方ここまで来ると、スプリントバックログの表現方法ごとに再現性のある書き出し方法を工夫できます。miro などのオンラインホワイトボードツールなら、完了の定義を満たすバックログはコピー&ペーストやテンプレート呼び出しで一気に出せるようにする。ホワイトボードの物理カンバンなら、受け入れ基準やその他の PBL は付箋で、完了の定義はマグネットシートで表現する。Jira のサブタスクで SBL を表現しているなら、完了の定義に相当する SBL を書き出すオートメーションを実装する。自動化や型化できるところにマインドシェアを割かず、スプリントごとに異なる要素にクリエイティビティを発揮できるようになると、自ずと成果につながるスクラムの実践ができるんじゃないかと信じています。↩バックログ、スプリントバックログともに、項目の一覧のことを「バックログ」とよび、個別の項目を プロダクト・バックログ・アイテム や スプリント・バックログ・アイテム と故障することもある。本稿では項目のことを「〜バックログ」と書いている。↩バックログとして起票し、確実に実施されるようにします。↩

「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」

この1年、様々なチームを支援する中で共通して出てくる話題もなんとなく見えてきて、そのひとつが「相対見積もり」の取り組み方に関することだ。そして、テクニックの話の前に、相対見積もりに対する「発想」や「スタンス」に問題があって機能不全や逆効果に結果することが多いと思っていて、その話をしたい。ちなみに、個人的には「相対見積もり」のことを「ストーリーポイント」と呼ぶのは好きじゃないんだけど、その話はまたどこかで。ベロシティはスプリント計画の「予算」1つのスプリントが終わった時にそのスプリント内で「完了」したプロダクト・バックログの相対見積もり値の合計のことを「ベロシティ実績」と呼ぼう。次のスプリントを計画するときに、直近の数スプリントのベロシティ実績から、次のスプリントで実現できそうなベロシティを予想する。例えば直近最大5スプリントの平均値をこのスプリントの予想ベロシティとしよう。スプリント計画では、この「予想ベロシティ」にほぼ収まるようにスプリントに取り組むプロダクト・バックログを選ぶ。ゆえに「予想ベロシティ」はスプリント計画の前提となる「予算」である。相対見積もりを行う目的は、この「予想ベロシティ」を算出することに他ならない。誤ってもスプリントの中盤から終盤になって誰か (大抵の場合はマネージャー) が相対見積もり値の予定と現時点の実績を持ち出して「XXポイントを完了させなきゃいけないのにまだYYポイントしか出来上がってないよ」と鐘を叩いて急がせるような真似をしてはいけない。また、スプリントの終了時にスプリント計画時よりも大幅に下回ったベロシティ実績 だけ をみてチームの能力や成果を判断してはならない。一度そうしてしまったら、相対見積もりを行う開発者は次から自らの身を守るために保守的な見積もりをするようになる。開発力も見積もり能力も上がらずに相対見積もりの値だけが大きくなる様子は、インフレーションというよりスタグフレーションという例えが適切に思える。ベロシティは変動する「ベロシティ」という言葉は長い道のりを自動車やマラソンなどで走り切る際の「速度」にインスパイアされた比喩だ。このとき、速度には2種類ある。速度計が指し示す「瞬間的な速度」と、特定の地点からもう一つの地点までの走行距離を走行時間で割った「平均的な速度」だ。スクラムの相対見積もりにおける1スプリントの実績ベロシティは瞬間的な速度である一方、スプリント計画時に利用する予想ベロシティは平均的な速度の考え方に則って算出する。大切なのは、車にしても人にしても、終始一定の速度である程度長い距離を走ることはない ということだ。例えばレースの中盤に差し掛かって走者の身体が温まってくることもあるし、逆に異変が生じるかもしれない。走っている道がフラットな一直線なのか、入り組んだ市街地なのか。カーブが続く道で速度計のみを凝視して運転してはならない。だから、スプリント計画を行う時には、必ず予想ベロシティ以内にチケットを収めなければならないわけでもないし、予想ベロシティ以上を積むのを禁じるわけでもない。でも迷ったら少なく積む方を選ぶかな。少なく積んで集中して確実に仕留めるのが「リーン思考」のハズなので。互いの「コミットメント」を信じる日本語で「コミットメント」というと、「後に引けない程に覚悟を持った約束事」のような意味合いで使われることが多い。一方で commitment を辞書を引くとかなり多義なのだけれど、そのひとつに 「献身」 という意味がある。積極的な関わりとか、傾倒していることとか。以下の椎葉さんの記事にもあるように、どうやら「スクラムの価値基準」にあるコミットメントというのは、献身の意味で捉えるのが正解なようだ。bufferings.hatenablog.comコミットメントは『献身』であり、それは最終結果に対してではなく、行動や努力に対して適用するものである相対見積もりが正しく機能して生産的なチームを支えるために一番必要なのは、スクラムチームのメンバーが互いのコミットメントを信じることができる状態なんじゃないかと思う。マネージャーが相対見積もりを使って開発者の尻を叩くのは、開発チームのコミットメントを信じていないからではないだろうか。開発チームがベストを尽くしているなら、そんなことをしても成果は改善しない (ストーリーポイントをインフレさせればベロシティは向上させられるだろう)。コミットメントを信じられない一方で、相対見積もりという分かりやすい数字が手に入ってしまったが故に、入り組んだ道をアウトバーンと同じ速さで走るように求めてしまうことはないだろうか。「スプリントに少なめにプロダクト・バックログ・アイテムを積んで開発者は遊んだり手を抜いたりしないだろうか」という誰かからの指摘に対して「早めに全て完了すれば、プロダクト・バックログから適切なアイテムを自主的に取るか、必要に応じて生産性向上のための投資をします」と、自信を持って言えるだろうか。そして、1人の開発者としてコミットメントを信じてもらえるように、透明性の高いプロセスで最高の成果を出すことはできているだろうか。信頼の構築は「鶏と卵」だ。「鶏と卵」の問題は自分が動かせるものから動かすしかない。そんな前提を成立させるところからスプリントプランニングやリリースプランニングの成功は左右されるんじゃないかな、と最近は考えている。

相対見積もりが機能するために必要そうなこと

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

脱サラパーソナリティ、テレビを飛び出す～佐久間宣行のオールナイトニッポン0(ZERO)2021-2022～

個別最適な学びと協働的な学び

遊ばせる技術 チームの成果をワンランク上げる仕組み

深解釈オールナイトニッポン ~10人の放送作家から読み解くラジオの今

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

Clean Craftsmanship　規律、基準、倫理 (アスキードワンゴ)

流れる時を、淡々と、しかし意志を持って生きる、という生き方を感じた。

明日、野球やめます 選択を正解に導くロジック

ビジョナリー・カンパニーZERO ゼロから事業を生み出し、偉大で永続的な企業になる

* LeSS の Definition of Done の解説 https://less.works/less/framework/definition-of-done* 『完成の定義と受け入れ基準の違いは何ですか？』https://www.ryuzee.com/faq/0077/* スクラムの定義の改訂 - スクラムアップデート2011 https://kawaguti.hateblo.jp/entry/20110807/13126525182022/07/05 「考えてみよう」スライドをのぞきました。「まとめ」のスライドを追加しました。

スクラムにおける「完了」と「出荷」の話 / About Definition of Done

2022-06-17 に非公開の勉強会で行った講演のスライドです。アジャイルマニフェスト https://agilemanifesto.orgアジャイルマニフェストはどう生まれたのか https://kawaguti.hateblo.jp/entry/20110213/129753122950分でふりかえるアジャイルムーブメントの歴史 2017年版https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017Modern Agile https://modernagile.org/アジャイルの「ライトウィング」と「レフトウィング」https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html『More Effective Agile』 https://amzn.to/3mwuWIQスクラムガイド https://scrumguides.org/スクラムは抽象クラス https://www.ryuzee.com/contents/blog/7131『スクラム実践者が知るべき97のこと』https://amzn.to/3NAAFJLScrum.org によるスクラムの一枚絵 https://www.scrum.org/resources/scrum-framework-poster

「アジャイル」の入り口に立つ / Entrance for "Agile"

2019年に文春野球フレッシュオールスターに応募したけど箸にも棒にもかからなかった原稿が出てきた。文春野球FASは「素人の祭典」ではあるのだけど、当時からかなりの激戦区。「自分しか知らないなにか」も無しに挑んで選ばれるには筆の力が足りなかったのである。2022年になって読み返すと、引退した選手たちはみな裏方としてチームを支えており、田中健二朗はトミージョン手術前のもどかしい時期。色々思うところがある。2019年2月1日。沖縄。宜野湾のベイスターズキャンプに脚を運んだのは2回目だったが、初日に居合わせるのは初めてだ。朝8時30分。自分としては早起きをして室内練習場の前に陣取っていると、颯爽と自分の目の前を歩く選手が2人。改めてこの間近さに感動しながら、ひとりは伊藤光だとわかる。相変わらずの端正な顔立ちだ。もうひとりは、見慣れぬ顔だけど誰だろう。記憶の引き出しの中を探しながら、ウィンドブレーカーの袖に書かれた「0」が目に入る。中井大介だ。10年以上在籍した巨人を去り、志新たに挑む新天地。かつてチームメイトだったのはホセ・ロペス、そして監督のラミレスくらい。そんな状況で、同い年の伊藤光は頼りになっているのかな、と想像を膨らませていた。時計の針を7年前に巻きもどす。2012年1月29日、横浜はみなとみらい。新規参入の気合が空回りしたデザインになるのではと心配していたのに、蓋を開けたらいい感じに「継承と革新」を表していた、新星・横浜DeNAベイスターズのユニフォーム発表会。三浦大輔、金城龍彦、山口俊ら主力選手によるユニフォームお披露目の後に行われたのは、新入団選手紹介であった。その年の末には谷繁元信の後継者になると将来を嘱望された高城俊人、キャプテンシーあふれる遊撃手として期待された桑原将志ら9人の新人たち。ありとあらゆる不安の中で一筋の希望に目をキラキラさせる高校生たちを見ながら、その春に大学を卒業して4月から社会人になろうとしていた自分はちょっとだけ不服だった。「そうか、同い年、いないんだな」2007年の高校生ドラフト一巡目で入団したセンバツ優勝投手の田中健二朗は、目立った活躍をできないでいた。佐藤祥万、大田阿斗里もポテンシャルを発揮できずにおり、坂本大空也はすでに球団を去っていた。2011年のドラフト会議、球団を手放すことが殆ど確定していた横浜ベイスターズの編成陣は、当初の入札こそ東洋大学の藤岡貴裕を指名するも抽選を外すと、1位の北方悠誠からドラフト6位の佐村トラヴィス幹久まで高校生を指名する。高卒社会人だった松井飛雄馬を指名するとさらに高校生2名を指名して選択終了。指名された大卒選手は一人もいなかった。野球ファンが勝手に選手に感情移入を抱くきっかけは星の数ほどある。同郷、出身校、名鑑に載る同じ女優がタイプだったこと… その中でも、自分と同じ「世代」であることには、どこまでも厚かましいくらいに力強いつながりを感じさせてくれる。事あるごとに「自分は松坂世代」と言う男性に出会ったことは1度や2度ではない。平成元年産まれの自分が心待ちにしていたのは、感情移入する同い年の大卒スターだった。風向きが変わったのは2013年のドラフト会議。大卒社会人の平成元年世代がドラフト解禁となるこの年、ドラフト2位で平田真吾が、同4位で三上朋也がベイスターズに入団する。中でも三上は新人ながら守護神に抜擢され、大車輪の活躍を見せる。球団史上初のクライマックスシリーズ進出を果たした2016年、「リリーフ四天王」と言われた鉄壁のブルペン陣の2つの柱が、三上と田中健であった。2017年から、立て続けに他球団から89年世代が加入する。2017年オフに武藤祐太、2018年シーズン途中にはトレードで伊藤光、米球界から中後悠平。そしてこのオフには巨人から戦力外通告を受けた中井。あの日、みなとみらいで少しだけ絶望した自分からすると、どこか不思議なチカラが89年世代をベイスターズに引き寄せたような気がしてならない。2019年、平成元年世代は30歳を迎える。普通のサラリーマンであれば脂が乗ってきてバリバリと活躍する頃。自分も仕事を自ら作って自分で仕事のペースをある程度コントロールすることができるようになったからこそ、早上がりをしてハマスタに行く機会も増えた。だが、プロ野球の世界で「30歳」が意味するところは違う。若手と呼ばれる時期は過ぎ、少し気の早いアナウンサーや新聞記事はベテランとさえ呼ぶようになる。昨今の米球界では、これまで以上に過去の実績より将来性を重視して選手契約が結ばれるようになり、30歳前後でフリーエージェントになった選手は一気に苦しくなるという話も聞く。確かにその選手人生は第三コーナーを抜けたところだろう。身体の動き方もそれまでとは違ってくるだろうし、選手としての価値の相対評価を大きく上げることは難しいかもしれない。でも、ファンとして願うのは、その選手が納得する野球人生を全うできるかだ。完投した若手投手をマウンドまで笑顔で迎えに行く伊藤光をこれからも見たい。右肘クリーニング手術で今季の大半をリハビリに費やすことになった三上がブルペンに居る安心感は誰もが知るところだ。チームで20失点した昨年9月の阪神戦で先発した今永昇太を救援したものの流れを止めれれなかったあの日以来一軍登板の無い田中健も、このまま終わっていいと思っていないはず。毎年のように活きの良い若手選手が加入し、台頭し、活躍するベイスターズだからこそ、30歳を超えた選手がチームに精神的安心をもたらしてくれたと思える機会も多く訪れるだろう。そんな同級生の姿に勝手に勇気をもらうファンは、自分だけではないはずだ。

不思議な力でベイスターズに集った「平成元年世代」

マーケットインパクトとは金融の世界には「マーケットインパクト」という言葉がある。市場 (マーケット) での自分自身の行動が市場に影響を与えてしまうことを言う。例えばある株式*1を大量に買い入れるために注文を入れると市場に流通する株式を買い上げてしまうために需給バランスが崩れ、当初よりも買い入れ時の価格が上がってしまうようなことを指す。自分の出す注文量に応えられる株式の流通量が市場にないときに起こる。世の中のプロの投資家は人間の判断での売買だけでなく株式の値動きなどをモデル化した上で売買アルゴリズムを組んでマーケットに挑むわけだが、このアルゴリズム開発を難しくするのがマーケットインパクトだと言われる。目論見よりも不利な方へ価格が動いてしまうマーケットインパクトが働くためにアルゴリズムの思惑どおりに売買が成立しない、というケースは多いらしい。*2転職媒体を用いた採用活動とマーケットインパクト自分がここ数年関わるようになったキャリア転職の採用活動でも、このマーケットインパクトは存在すると感じている。世の中には様々な転職・求人媒体があって、転職検討者や潜在候補者に企業からアプローチする手段も増えてきた。その環境下で、採用活動も 『THE MODEL』 よろしく定量的な管理をするべきで、採用活動とマーケティングは同じでファネルの形状なので通過率を前提に採用目標数から逆算してファネル流入数ターゲットを定め、その達成のための行動量をKPIに置く。目標から逆算してアクションを決める取り組み自体は絶対に必要だし、計測可能性を担保しない改善活動はワークしない。ただ、ファネルだけを見てひたすらアクションを打ち続ける採用活動をすることは悪手だ。 それは、単純に「穴の空いたバケツに水を流すな」で済む話でもあるのだけど、それに加えて 普通のプロダクトマーケティング以上にマーケットインパクトで自分たちの首を絞めるんじゃないか、と思っている。理由は2つ。プロダクトはピボットできるが、会社はピボットできない。一般的な商材やプロダクトのマーケティングをする際、企業はマーケティングのさまざまな戦略を微調整したり仕切り直しをしたりすることができる。事業の方針を大きく転換することを「ピボット」と言ったりする。ベンチャー企業は体力が続く限り、ピボットや微調整を繰り返して何度も試行を重ねて、プロダクトや事業が成長する道を模索する。その過程で同一の顧客セグメントにアプローチする事があっても大きな問題になることはないだろう。採用活動の場合はどうか。採用候補者に企業を知ってもらい、さまざまな縁が繋がって入社にいたることをファネル・マーケティングに例えるとき、買っていただく商品は企業そのものである。採用活動で買ってもらう企業は1つしかない。採用を成功させるために企業のあり方をピボットさせるわけにもいかない。*3自分たちが直面している人材市場の狭さ「企業のピボット」が出来ないことがなぜ問題なのかと言えば、企業に対して間違ったイメージを抱かれたり、シャープではないメッセージを送ってしまった時に、再アプローチしても最初に与えた微妙な印象はそう簡単に拭えないからだ。アプローチに失敗した候補者に再度アプローチできる可能性が生まれるにはそれなりの時間待たなければいけない。人材市場は有限なので、そうやって潜在候補者数は減っていく。新卒のポテンシャル採用だったら能力の高い学生から採っていけば良いし、毎年供給が洗替えされるので「流動性はとても高い」状態と言っていいだろう。*4 キャリア採用市場はそれが通用しない。職種によっては「業界」が狭いゆえ、採用活動を1、2年やっていれば同じ顔に出会う可能性も「無視して良いほど低い」ことはない。業界内の人材の間にある程度のネットワークもあるだろう。そうすると企業のイメージや評判も伝わりやすいから、微妙な候補者体験を経験した話も比較的容易に広まる可能性がある*5。「500通のスカウトを送信すれば、そのうちn％の人から返信が来る」という単純計算で採用活動をしてもうまく行かない理由のうちいくつかはここにもあると思う。じゃぁどうするの最もらしく語ってきたが、そんなこと求職側も求人側も承知の上だよ、という面もあるだろう。求人側の目線から「じゃぁそういう環境下で、どう採用活動したらいいの？」ということについて抽象的な話をする。具体的な施策への落とし込み方は会社によって違うだろう。書いてみると当たり前のことなんだけど改めて重要だなって思う。ファネルの流量より通過率を見るファネルマーケティングのセオリーであり、言い換えるならフロー効率をリソース効率より優先するということだ。たくさんの候補者を選考プロセスに流し込む前に、たくさんの候補者が流れ込んできたときに問題になる過程を早めに察知して改善する。何が問題になるかは様々な文脈に依存する。実際の企業の現場でうまく伝えきれないケースが多い*6のだが、フロー効率をリソース効率より優先するということは、「数の多いことを評価しない」ということを意味しない。フロー効率がある程度高い状況を作り出したら満を持して流量を増やすための蛇口を開いて「育てた果実を食す」フェーズに移行するべきだ。ただし、この蛇口の開き方も突然フルスロットルというわけではなく、各工程に本当に無理が出ないかを確認しながら少しずつ開いていくのが理論上は望ましそうだ。細かいサイクルでの効果検証、仮説検証を行うフロー効率を重視する戦術の一つがバッチサイズの縮小、つまり「1度に流す流量を短く刻む」ことだ。当然、1回の効果検証のコストを下げたり、アジリティを向上させるのも狙いなのだが、マーケットインパクトを真正面から食らうことの回避にも役立つ。極端な例だが、10個の施策の効果検証を行うに際して、最初の2,3個の施策でほとんどの潜在候補者へアプローチを行ってしまい、残りの施策を試そうにもアプローチした段階で「あのとき断った企業」と思われてしまえば手詰まりである。なるべく早い段階で小規模に勝ち筋を見極めて、少しずつスケールアップする、という順番を忘れないようにしたい。採用手段のポートフォリオを組む仮説検証を行う上で、仮説を複数用意して、その複数のプランをプランA,B,Cの順に実行したり、並列に実行して検証したりする。大事なのは複数の手段や仮説があることだ。キャリア採用活動の場合、エージェントや転職媒体などの採用チャネルのポートフォリオを組むことは教科書に載る基本だし、それぞれのチャネルでアプローチ方法を用意して二枚腰三枚腰の取り組みができればなんとか自分たちなりの勝ち方が見えてくるんだろうと思う。もちろん、それが大変なんだけれども。タレントプールの活用「タレントプールとは何か」の話は、採用というか人事領域を担っている人には釈迦に説法すぎて恐縮。知らない人もググれば親切な記事はたくさん出てくるだろう。「一度アプローチをした人材にしばらく再アプローチできない」というゲーム構造を変えるには、最初に候補者とコンタクトを取れたときに「またお互いの状況が少し変わったときに可能性を模索したい」と思わせる他ない。とはいえタレントプール化するためにもカジュアル面談などの機会にこぎつけないといけないので、スカウトの時点で候補者体験の上がるアプローチの重要性は変わらないと思う。最後に: 採用ゲームのプレイヤー個人ではどうしようもない話自分のメインフィールドであるソフトウェアエンジニアやシステムエンジニアの採用マーケットは、自分が関わるようになった4年の間でも過熱の一途を辿っている。求職側としても引く手数多だったり給与を上げる手っ取り早い手段になっていたりするのもあり、人材の「採った・採られた」は業界全体で見るとゼロサムゲームだなと感じることもある。それって産業全体が成長してる感じがしなくて「なんだかなぁ」と思うこともあって、長い目で見て「育成できる企業」が強いんだなぁと、こういうノウハウを整理しながら改めて思う。最近、日本の伝統的大企業での IT 人材リスキリングの取り組みが始まった事例がニュースで取り上げられたり、ユーザベースが Play Engineering という取り組みを発表していたけど、まさに中長期的にはこういう取り組みで人材を良い意味で「輩出」できる会社が増える必要があるんだなと、業界の隅っこでひっそりと考えた。*1:株だけじゃなくて金融商品全体に当てはまるが、金融疎い人向けなので端折ってる*2:ちなみに私自身はアルゴリズムトレードには関わったことが無いので、全て「聞いたことがある」レベルの話だ。*3:「別の商材をアプローチする」という意味では異なるポジションのオファーをするということは考えられるのでは？という人もいるかもしれないが、候補者が重視すべきはポジション以上に企業とのマッチだし、企業側も最適なポジションが他に用意できるなら最初の採用プロセスの中で提案するべきだろう。*4:ただし、イメージの再生産みたいなのは起きるだろう。新卒採用に仕事で取り組んだことがないので詳細を知らない*5:もちろん、逆に「良い候補者体験をした企業」の話も流通しやすいと感じている*6:僕の能力不足で

採用活動とマーケットインパクト

複数企業で仕事をする中で「ミッション・ビジョン・バリューを体現する」ことを並行できるのか？について雑に話しました。

複数企業に所属してミッション・ビジョン・バリューを体現できるか

パラレルワークをする中で、組織のコンテキストにどっぷり浸からずに価値を出すために「質問をする」ことで価値を出そう、という話をしました。

尋ねる力を価値とする

他者と働く (https://amzn.to/3F3RJ5v) の概要と、それを読んで思ったことについて。

『他者と働く』を読んで

「何をやるかより、誰とやるか」という言葉の理解が、自分の中で変わった、という話です。

「何をやるかより、誰とやるか」または Disagree and Commit について

チームトポロジー (https://amzn.to/32E7AdR) を読んだ上での感想について話しました。

『チームトポロジー』を読んだ話

収録が滞った背景とか、最近の子育てで電動自転車を導入した話などをしました

近況報告とか

振り返ると、人生としては楽しかったが、仕事だけに着目すると大して進捗ないのに慌ただしかった2021年だった。振り返りつつ、来年以降どう生きていこうと思っているのか書く。 1,2月CADDi にいた。引き続き採用活動やマネジメントも担いつつ、前年末くらいから新しいシステムの立ち上げを始めたタイミングで、 Rust ではなくてサーバーサイド Kotlin で API を作ろうということでフレームワークを選定したり、アプリケーションの下地を作ろうということで久しぶりにゴリゴリとコードを書いていた。Rust についてカジュアル面談で頻繁に訊かれる質問と、それに対する個人的な回答 - CADDi Tech Blog という "やや煽り気味" の記事を表向きには書きながら、仕事では Kotlin を書き始めていたので、そのことも Tech Blog に載せなきゃな、とずっと思っていたのだが、言語選定という "可燃性" のある話題をいろんな方向に配慮しながら書くのは年に1本が限界だったなという感想…。きっとそのうち CADDi の誰かが書いてくれるはず。3月育休をとった。息子が生まれたのは去年の夏だったのだけど、CADDi を含む世の中の大抵の会社に於いて育児休業は「その会社で働き始めてから1年間は取得できない」という規定があって、自分の場合はその期間が明けるのが2020年3月だった。実際に夏に息子が産まれてから、在宅勤務もあって育児には目一杯取り組めていたのだけれども、4月から通わせる保育園も決まっている中で、子供とじっくり過ごせる時間が少なくなるかもという不安を抱えていたのが、1ヶ月でも育児休業を取ろうと思った一番の理由だった。今になって、今は今でやろうと思えば子供との時間は目一杯作れるだろうとは思うし、実際に最近でもコードも書かず技術書も読まずに息子と戯れて終わる幸せな休日は多い。それでも、仕事を一切忘れて息子と過ごす1ヶ月間は本当に楽しかったので、休暇取れてよかった。職場に穴を空けるという意味では、昨年12月に EM の Ken Sato さんが加入してくれたことで色々と我儘を言えたりお願いをできたのが大きかった。後に自分が CADDi を退職したのも含めて、彼にはめちゃめちゃ負担をかけたと思うので感謝しかない。 (退職に関しては4月に入った じろーさん  も！)4,5月復帰した。と同時に、「自分のキャリアの方向性」という、以前まではそれほど考えてこなかったことが気になったり、迷ったりするようになった。後に Podcast でも話しているのだが、特にこの時期は自分が「マネジメントをする立場」と「ソフトウェア開発者の立場」のどちらにどう比重を載せているのか分からなくなっていて、どちらかに寄せ切ることもうまくできず、その中で自分の気持の整理がつかなかった時期だったように思う。その理由は自責も他責もいろいろ考えられるし、「いやそれをなんとかして自分の中で割り切って成果出せよ」と言われればそれがゴモットモなんだけれども。そんな時に「マネジメントのロールを強く必要としている」「EM 一本でジョインしないか」という誘いをもらったのはひとつの転機と感じて、会社を移るという決断をした。6月~10月ココペリ という会社にいた。入社にあたって考えたことは以前ブログに書いたとおりで。t-and-p.hatenablog.comやってみて、EM の仕事に注力するからこそできることも見えてきたし、Control せずに Influence するみたいな仕事も面白いと感じていた。そういえば、この頃に野良 Podcast を始めた。日々の仕事で感じたことを抽象化しつつ喋る、という取り組みをすることで、ネタが見つからなくなるということが、日々の仕事の振り返り、抽象化不足だと気づけたりもした。open.spotify.comじゃぁなんで辞めたのという話で表向かって書けることはあんまりないのだけれども、多少なりとも意気込んで入った会社を5ヶ月で辞めるつもりは自分もなかったので、残念というのが正直な気持ち。Podcast も、EM であることを自分の意志で辞めた瞬間に何も話せなくなってしまい、収録を止めた。未公開エピソードが1つだけあったりするので、それを公開させるところから、ちょっとずつ収録も再開するかな…11月と今そのような形で残念ながら退職をするという話を何人かの知人にした際に、本当にありがたいことに、「手伝ってくれ」と声をかけてもらえる機会に複数恵まれた。声をかけてくださった方々それぞれに、自分の今のいろいろな迷いも理解していただいた上で、現在はその中のいくつかの企業と、業務委託または契約社員という形で関わらせてもらっている。去年まで、というか今年の10月までの自分は「1つの企業のコンテキストにどっぷり浸かる」ことで価値を出してきた身だったし、そうでもしないと価値は出せないと決めつけている部分があった。それゆえ、「複業」とか「パラレルキャリア」というものは全く想像がつかなかった。偶々そのような働き方を実践してみたことでの発見もあるし、もどかしさや戸惑いも当然ある。そもそも自分が実際にどれだけ価値を出せているかも自信がないけれども、やってみれば出来ないことはないし、自分の中で様々な会社の取り組みやあり方を相対化して捉えられることを強みとできているのが良いところ。一方で、当然ながら稼働時間の制約があるのでイメージしたアウトプットや貢献が出来ないことがあるのは事実だし、実際に一緒に働いている人々に気を遣わせているのかなと思うことも無いわけではなかったりする。これから複数の企業に関わっていると書いたが、特に組織周りの仕事をさせてもらっている企業では「種蒔き」の段階の仕事が多いので、それらが実を結ぶような2022年に出来たらよいと思っている。来年は何かしらを自慢できるようになっていたい。今のような働き方をどれだけ続けるか、良くも悪くも決めていない。足元で大きく困っているわけではないけれども、本気で何らかの成果を出すために1つの仕事にフォーカスしたくなる時が来るんじゃないかな、とも思っている。その時が来たら考えたい。結び方が難しいけれどもそんな感じで。

2021年と, これから

プロダクトバックログやスプリントバックログを、Jira のようなデジタルツールで運用するべきか、ホワイトボードのようなアナログツールで運用するべきか。フルリモートの環境下でどうするべきか。などについて話しました。

58: スクラムのアーティファクト, デジタルか、アナログか

以前にこの Podcast んで話した「絶対数で勝負しない KPI」を3ヶ月実践した今、何を思うか。以前に話したトークはこちら → 7: 数で勝負しない採用活動の目標

57: 率のKPIと規定打席

ソフトウェアを扱う組織の非機能要件感度は、技術者が引き上げる必要があるよね、という話。

56: 非機能要件の感度を上げるのが、技術者の組織貢献

最近、自分が採用面談をしていてよく話題に上がる「社会意義のある仕事」という言葉について、掘り下げてみると良い面談になる… かもしれない。という話。

55: 『社会意義のある仕事』ってなんだろう

スプリントの長さや、いつをスプリントの開始/終了とするか、を決めるときに普段考えていることについて。

54: スプリントの期間を決定する上で考えること

『失敗の本質』についての最終回です。

53:失敗の本質⑤ 人的ネットワーク偏重の組織

「学習棄却」のできない組織となってしまう背景について、『失敗の本質』から学べることについて話しました。

52: 失敗の本質④ 学習棄却を欠く組織の背景

「失敗の本質」の核心である「学習棄却」について話した前編です。

51:失敗の本質③ 学習棄却の事例研究

『失敗の本質』が言及している「戦略目的の曖昧さ」について話しました。失敗の本質 (Amazon)

50:『失敗の本質』② 戦略目的の曖昧さについて

『失敗の本質』という本の紹介、今更ながら読み始めた理由、遠ざけていた理由などについて話しました。失敗の本質 (Amazon)

49: 『失敗の本質』① 読み始めた理由や背景

大学時代の後輩にプロフィール写真を撮ってもらいました、という雑談です。

48: プロフィール写真をフォトグラファーに撮影してもらった話

『イシューからはじめよ』を読み返して思ったこと

47: 『イシューからはじめよ』の第1章だけ読み返した話

人事評価は難しいし、うまく出来た経験があるわけではないけれど、最近こういうことを意識しているよ、という話をしました。

46: 人事評価でサプライズを起こさない 1:1 をしたい

振り返りの活動をどうファシリテーションするか、なぜオリジナルの振り返りフレームワークは生まれるのか。- Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き

45: 振り返りのフレームワークを自作する

新卒時代の上司に教わった「プロジェクト成功に重要な3要素」と「チームビルディングの重要性」について

44: チームビルディングはなぜ重要か

書籍『ライティング・ソフトウェア』についての紹介、感想です。後半です。『ライティング・ソフトウェア』(Amazon)

43: 書籍『ライティングソフトウェア』② アーキテクトが担うプロジェクトデザインの役割

今の職場に EM として加入して3ヶ月の感想をダラダラと話した回です。エンジニアリングマネージャとして会社にジョインするのは難しい - だいくしー(@daiksy)のはてなブログRe: エンジニアリングマネージャーとして会社にジョインするのは難しい

42: EM としてジョインするのはやっぱり難しい

書籍『ライティング・ソフトウェア』についての紹介、感想です。『ライティング・ソフトウェア』(Amazon)

41: 書籍『ライティング・ソフトウェア』① 戸建住宅建築とソフトウェア開発

スクラムのスプリントレビューを実施する際の心得、注意点について話しました。

40: how to スプリントレビュー

新卒研修のときに言われた忘れられない言葉について

39: 思い出の言葉シリーズ①「ランチ代を稼ぐためにやってるんじゃないぞ」

エンジニアリング組織で O/KR を策定するときに考えていることについて話しました。- [ロードマップに機能を書くべからず](https://note.com/ozyozyo/n/nfb370fadd70c)

38: エンジニアリング組織のOKR、機能と非機能、機能と数字

ベイスターズの大村巌コーチと筒香嘉智選手 (現: ピッツバーグ・パイレーツ) のエピソードなどを通じて、「プレイヤーをプロデュースするコーチ業」について話しました。 大村巌 日本の4番が誕生した「伝説の2週間」　筒香が批判を覚悟し名コーチと歩んだ軌跡

37:ベイスターズが教えてくれたこと② 選手をプロデュースするコーチ業

プログラミング言語変われば、採用方法が変わる

36:エンジニア採用市場と言語

スプリントゴールの設定の仕方、スクラムは What と How の両面に取り組むフレームワークだ、みたいな話

35:スプリントゴール、スクラムの What と How

三原修の名言「アマは和して勝つ、プロは勝って和す」という言葉について、またそれをエンジニアリングに当てはめると？ということについて話しました

34:「勝って和す」エンジニアリングってなんだろう？

メンバーとの1:1で思い出した、私の師匠から教わった「良い技術書に出会う確率を上げる方法」について話しました

33: 良い技術書に出会う確率を上げる

1 on 1 のログを Notion に残し、メンバーと共有することについて話しました

32: 1 on 1 のログを Notion で共有する

想定オーディエンスを踏まえた話をすることを、マネージャーが意識するべきという話

31: 想定オーディエンスを理解する。古典、歌舞伎、一文笛。

採用活動の原則をリファラル採用の中でどう意識するべきか、について話しました。

30:リファラル採用も採用活動だ！

エンジニアリングマネージャーとして、リモートワークしているメンバーの働いてる様子を定量的に観測する方法について話しました。

29: マネージャーは見ている

自分の未熟さを棚に上げて、仕事に必要なスキルは「スタンス」「ポータブルスキル」「テクニカルスキル」に分かれることを話しました。

28: ポータブルスキルを意識しよう

社内向けのノウハウやドキュメント、コードではない成果物の管理に Wiki と Git のどちらを使うべきなのか？について話しました。GitLab Handbook https://about.gitlab.com/handbook/handbook-usage/#wiki-handbooks-dont-scale

27: Wiki と Git

情報共有を改善するための「透明性」と「予測可能性」について話しました

26: 情報のアクセシビリティは何から成り立つか

リファラル採用を「目的」ではなく「手段」として活用するための大前提となるスタンスについて話しました

25:リファラル採用の大前提

ダルビッシュ有のスタンスに学ぶ、強いチームのリーダーの話をしました。ダルビッシュが「パ・リーグとセ・リーグの格差」について語った動画はこちら。ちょいちょい音が途切れてしまってすいません…

24:ダルビッシュ有のオープンネスに学ぶ

ソフトウェアテストの粒度に応じてボリュームをコントロールしよう、テストの目的や範囲を意識しよう、という意味で「テストピラミッド」について話しました。『More Agile Testing』 https://amzn.to/3smg9m7

23: テストピラミッドを通じて自動テストをマネジメントする

「リーン」や「フロー効率」という考え方を組織に植え付けてゆくに当たってどのようなことに気をつけているかについて話しました。フロー効率については、 @i2key さんのスライドがわかりやすいです。 https://www.slideshare.net/i2key/devlove-devkan-103489350

22:「リーン」を組織に植え付けていく

タイトルは、ちょっと正確じゃない。続きをみる

「最後に株主総会に携わった世代」として : シンプレクス再上場の報を目にして

スカウト採用を成功させるスタンス、スカウト文を用意する上での注意点について話しました

21: スカウト採用で気をつけていること

千葉ロッテマリーンズ投手コーチの吉井理人のコーチングスタンスに学ぶこと、「自分で考える人材」について。エピソード内で言及した書籍はこちら『最高のコーチは、教えない』https://amzn.to/3AIEqWG『コーチング論』https://amzn.to/3sihNFg

20: 吉井理人コーチに学ぶ「自分で考える人材」の育て方

ソフトウェアエンジニアの仕事とエンジニアリングマネージャーの仕事で共通するところと、異なるところについて話していたのですが、結構共通するところが多いな、と話しながら結論が変わってきた様子をそのままお届けします。

19:SWE の仕事、EM の仕事

開発者に技術選定をしてもらう際に気をつけることと、「プロダクションレディネス」について話しました。プロダクションレディマイクロサービス https://amzn.to/3APf9dx

18: 技術選定とプロダクションレディネス

スクラムまたはスクラムに部分的に準拠した開発プロセスのコーチングをするときに、どこから始めるかという話。完了の定義を共有するところを出発点とすると何が起きたか。

17: 完了の定義をチームで共有しよう

横浜DeNAベイスターズが教えてくれた「人が入れ替わってもリセットされない組織」について話しました。トークの中で紹介した池田純さんの「空気のつくり方」はこちら https://amzn.to/3fwqJlx

16: ベイスターズが教えてくれたこと① 人が入れ替わってもリセットされない組織を作る

普段よく聴くラジオについて話しました。番組ページ https://www.allnightnippon.com/sakuma/番組から出た書籍もあります https://amzn.to/3AgHIjH

15: 佐久間宣行のラジオが面白い話

採用活動の中でカジュアル面談を行う際に気をつけていること、工夫などについて話しました。

14: how to カジュアル面談

オンボーディングに対する心構え、マネジメントが気をつけるべきだと考えていることなどについて話しました。

13: オンボーディングの課題か、マネジメントの課題か

かつての職場で社内ラジオをやっていた理由、どう活用していたのか… など。

12: 社内ラジオをやっていた話

フルリモートワークのチームに加入するときに意識するとよいこととして、「早くアウトプットを出すこと」と「自己開示」について話しました

11: リモートワークと新入社員、結果を残すことと、自己開示

夫婦間で家事＆育児タスクを共有するための [Rmemeber the Milk](https://www.rememberthemilk.com/) を運営するために工夫していること、気をつけていることについて話しました

10: 家の Remember the Milk が破綻しなくなった話

ネガティブフィードバックが難しいという話と、書籍『実践！フィードバック』について話しました。本編にて、書籍名を「フィードバック入門」とご紹介していますが、正しくは『実践！フィードバック』でした。お詫びして訂正致します。書籍はこちら https://amzn.to/3zHbGwU。

9: 書籍『実践！フィードバック』紹介

好きなラジオ・パーソナリティ 伊集院光のトークの凄み、そこから学ぶべき「マネージャーによる情報共有」について話しました。

8: 伊集院光、枕、情報共有

open.spotify.com「エンジニアリング・マネジメント」という言葉がバズったのは2018年の下半期だったと思う。エンジニアリング組織論への招待 や エンジニアのためのマネジメントキャリアパス という本が出版され、Engineering Manager Advent Calendar は vol.2 まで行った。Engineering Manager Meetup というコミュニティが立ち上がり、そのコミュニティ発信で em.fm という Podcast が生まれた。そんな世の中から3年経ち、ひとり語りで EM の仕事について話す Podcast を今更始めてもバズったりはしないだろう。バズりたくてやっているわけではないので別に問題はないと思っている。じゃぁなんでやろうと思ったのか？思いつく限り並べてみる。仕事でエンジニアリングマネジメントに集中するようになった。仕事で必要な考え方やセオリー、スタンスについてしっかりまとめる習慣が欲しくなった去年から「継続して何かしらアウトプットをする」ということを決めて 毎週 note.com に文章を書いていた。3ヶ月続いたんだけど、2つの理由で止めてしまった。1つは想定外のコロナ禍で外出や休日のレジャーがめっきり減って話題を供給し続けられなくなったこと。加えて、そして文章は無限に推敲に時間をかけることができてしまったこと。文章力が無いので一発で納得できる文章に仕上げることが出来ず、あーでもないこーでもないとやる時間がどんどん増えていってしまった。こだわるほどにコスパが悪かったがそのトレンドを止められなかった。なので、継続的なアウトプットをしたい、仕事の話をちゃんとまとめたい、でも編集時間はあまり取りたくない、となったときに Podcast で音声撮って出しをするのは悪くないかな、と思った。ちょうど息子の保育園が始まって、ちょっと遠いところになったので歩いている時間がもったいないな、と思っていた。Podcast は 30min や 1h のプログラムも多いが、撮って出しなのもあるし、そんな構成力もないので 10min 程度で終わるものを継続して出すので良いな、と思った。話してて構成が気に入らないな、と思えば棄てて次の日に再レコーディングすればいいし、気楽な気持ちでやっている。本当はもうちょっと良いマイクを用意して防風とかしたいんだけど、Anchor を見てると2000年前半のホームページかってくらい物哀しい再生数なので、もうちょっと聴衆がついたな、という数字が出たら購入しようと思う。

今更、エンジニアリングマネジメントについて一人で話すPodcastを始めた

エンジニアリングマネージャーによるソフトウェアエンジニアの採用活動の目標をどこに置くのか、という話をしました

7: 数で勝負しない採用活動の目標

議論のファシリテーションをする上で気をつけていることについて話しました

6: ファシリテーションのコツ

EMに専念して仕事をすることで上手くいったことなどについて話しました

5:「プレイングマネージャー」の弊害

EMが組織に加入して最初に採用活動に取り組むと良い理由、採用活動の最上流は組織の現状理解であること、求人票の更新の仕方などを話しました

4: 採用活動は組織の現状理解から

人事の仕事の3階層「ベタベタ人事／ベタ人事／おもしろ人事」について話しました。

3: 採用の前に、人事活動の3階層について

シニアなメンバーとの1 on 1、マネジャー同士の1 on 1について

2: 1 on 1 について その2

1 on 1 を通じた現状理解やコーチングについて話しました。

1: 1 on 1、リモート、コーチング

自己紹介とからEMの仕事に対する考え方について

第0回 自己紹介とEMの仕事について

6月から、 株式会社ココペリ というところで働いています。そういえば6月からこんな会社で働いています (Twitterに書いてなかった pic.twitter.com/C67PL4ARrb— むらみん (@Mura_Mi) June 15, 2021  mobile.twitter.comこれまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の方々も含めて、「こいつは何をやるヤツなんだ？」という視線を多かれ少なかれ感じながら、日々の業務にあたっている。これまでの職場では「必要に応じてサーバーサイドエンジニアとして働くことも、エンジニアリングマネジメントをすることもできますよ」というスタンスで働いていた。特に CADDi に加入したときには、CTO からは「ゆくゆくはマネジメントを担ってほしい」という期待値を確認しつつ、最初は現場のエンジニアメンバーからの信頼を得るためにエンジニアとして手を動かすようにしましょう、という配慮をしてもらい、機能開発やテスト改善を実行しつつ開発プロセスの中に入って一緒に整理をしたり、持ち回りの勉強会に早めに登場したりしていた。対して、ココペリに転職するに際してはマネジメントに専念することもあり、会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした。実際、私が職務として主に経験してきたのは JVM 系の各言語 (Java, Scala, Kotlin) と Rust だが、一方でココペリのプロダクトはほとんど PHP で動いており、一部 Go を使った新規サービスや、既存サービスの書き換えが行われていたりする。そんな経験言語のギャップの話を自己紹介やメンバーとの初回 1 on 1 でも包み隠さず伝えていることもあり、余計に「こいつがマネージャーに入って何ができるんだ？」と思われても不自然ではないような状況だと認識している。そんな折、 Scala関西Summit でもお話したことのある id:daiksy さんが、同じように EM として転職された話を書かれているのを目にした。daiksy.hatenablog.jp自分の悩みは だいくしー さんと比べれば足元に及ばないような話ばかりかもしれないが、共感できる部分が多くて、「あぁ、方向性は間違ってないんだな」と安心したりしている。「観察」自体は成果を産まない入社してすぐは、正社員/業務委託/派遣 など雇用形態を問わず、私がレポートライン上関わることになるメンバー20人弱や、部署こそ違えど同じミッションを担うメンバー、ほぼ全部署のマネージャーとの 1 on 1 を通して現状の確認を行った。何事もまず「観察」であり「計測」である。過去に起きた出来事や足元で起きている事象も、視点が変われば見え方も変わる。会社設立から14年、ソフトウェアによるサービス開発・提供が始まってから約6年というココペリの歴史は、上場企業としては短く思われるかもしれないが、その間にも組織は様々なイベントを経験しており、知るべき歴史的経緯は掘れば掘るほど出てくる感覚がある。私自身が最近勤務していた2社が創業して3~4年のスタートアップだったこともあり、大河ドラマのような重厚感さえ感じることも多い。いろいろな気持ちを抑えて「観察」を重視するスタンスを保っているのがこの1ヶ月であるが、観察するという作業こそ、その作業自体が成果を生み出さない最たるものであり、ソフトウェア開発に於ける「テストは品質を向上させない」という至言に近いものを感じている。マネージャーの仕事の大部分は成果が見えづらい中で、実際に成果に結びつかない作業が多くを占めているタイミングなので、感じる不安も大きい。しばらくはこのことに耐えるしか無いのだけれども、自分は だいくしー さんよりもビビりなので (たぶん)、入社1ヶ月のタイミングを待たずに、入社初日から日報を社内グループウェア (Notion を使っている) に投稿して、その日に行った仕事を振り返るようにしている。ちなみに、そんな私の様子を見たメンバーもひとり、ふたりと真似して日報を書いてくれるようになったのは、意図していなかったけれども嬉しいことだった。 日報を積分すれば月間の振り返りになるわけでもなく、手を止めてじっくり振り返って見えてくることもあると思うので、自分もそろそろ1ヶ月の振り返りを書いてみるかな… と思っている。「観察」と「直接的な干渉」と「間接的な干渉」前述したような「こいつは何する人？」という視線が多少なりともあることを自覚していることもあるし、いきなりポジションをかざしながら大鉈を振るうようなコトをしても何の成果も出ないだろう。一方で、刻一刻と悪くなっていく状況が目下で繰り広げられている中での「観察」は、まさに「指を咥えて観ているだけ」になってしまう。ではその状況で直接手を出してよいのかと言えば、だいくしー さんの言うようにそれがメンバーのストレスになることもあるし、チームが自律する機会を失う可能性もある。特に自分が唯一の EM ともなれば、大きな組織のごく局所的な問題の解決に奔走したために全体がうまく回らなくなるリスクだってある。なので直接的ではないアプローチで様々な働きかけをしたいのだが、それはそれで成果が出るまでのリードタイムが長くなるから焦る気持ちも生まれる。問題がどの程度致命的かという問いに対する回答は定量的には下せないことも多いので、最後の最後には少なからず主観的な選択をしなければいけないことも自覚しつつ、観察と干渉のバランスや、干渉の直接的なアプローチと間接的なアプローチのバランスは本当に難しいなと思っている。思考 (およびインプット) をする時間先日、日々つけていた「日報」と、「自分がやりたいこと/やるべきことバックログ」(個人的な「ざっくりリスト」を持っている) を見返していたときに、日々「観察」の作業を重視するあまりに思考する時間が取れていないことに気がついた。最近の仕事は、メンバーと隔週で設定している 1 on 1 と、状況把握のための各種ミーティングへの出席、そして入社当初から具体的に動ける採用活動が大半を占めてしまっている。しかし観察するのは何らかの成果を出すためだ。そして、成果を出す行動をするためには、観察の中で目についた表面的な事象に対応するのではなく、事象の根本に横たわる問題への理解とアプローチが重要だし、根源的な問題にアプローチすることで複数の問題を解決できる可能性だってある (そうでもしないと時間と気力が足りなくなる)。「観察の作業をしただけで仕事をした満足感を得てはいけない」ことは、言葉にすれば当然のことであるが、改めて自分の肝に命じたいなと思った次第だ。採用PRということで、ココペリではソフトウェア・エンジニアリングに関わる職種は (リクルーティングサイトに載っていないポジション含めて) 全方位募集中です。少しでも気になったら、すぐの転職の機運がなくてもぜひ声をかけてください。本稿は文量が増えちゃうのも良くないと思い、なんで私がココペリに入ったのかとか、何が面白いと思っているのかについては言及しませんでしたが、そこらへんの話もできるかなと思います。www.kokopelli-inc.comそれでは。

Re: エンジニアリングマネージャーとして会社にジョインするのは難しい

ライティングソフトウェア | Juval Loewy, 株式会社ロングテール 長尾高弘 |本 | 通販 | Amazon を読んだ。とても良かったのでメモ。積読.add pic.twitter.com/JC39XPJ3io— むらみん (@Mura_Mi) April 22, 2021  「システムデザイン」と「プロジェクトデザイン」本書は、システムアーキテクトの責務を「システムデザイン」のみならず「プロジェクトデザイン」までと論じているのが特徴だ。全体のページの 1/3 が前者、2/3 が後者を占めている。システムアーキテクトがプロジェクトデザイン (プロジェクトマネジメントではない) までを責務とするべき理由は、本書の第6章で述べられている。マズローの欲求階層説を引き合いに出しつつ、システム開発プロジェクトに於いて、システムデザインの健全性の土台にはプロジェクトが時間、人的資源、リスク管理の観点で健全であるという説明は納得度が高かった。プロジェクトを構成する工程の依存関係やリスクの評価、工程を圧縮する判断はアーキテクチャを始めとする技術的判断が根拠となるため、アーキテクトの果たす役割が重要となる。根拠のあるプロジェクトコミュニケーション本書で紹介されている「工期・コスト・リスク」のトレードオフ上の選択肢を複数提示するプロジェクトデザインの方法は非常に具体的だ。もうちょっと詳しい読書メモ、考えたことなどは適宜更新していきたいので、以下の Scrapbox に。scrapbox.io

『ライティングソフトウェア』システムアーキテクトの新しい "Must Read"

1年間お疲れさまでした。子育て続きをみる

2020年振り返り

ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器 だと捉えることができる。こんなすごいものを作りたい！と、大きな絵 (まさに "Big Picture") を描いたとする。この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとするとチームはその "大きすぎる" 絵を受け止めることは出来ない。なので、大きな要求は細かくする。しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。というのはメタファーなんだけど。スクラムでは Product Backlog というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。アジャイルエンタープライズ (Object Oriented SELECTION)作者:Mario E. Moreira発売日: 2018/03/19メディア: 単行本（ソフトカバー）この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。

絵に描いた餅のままでは実現できないので、小さく切って1列に並べる

コロナ禍に伴う突然のリモートワーク (Work From Home, 以下 WFH) 生活となってはや9ヶ月。とにかく Amazon と楽天で設備を買って色々試行錯誤した日々だった。いくら出費があったのか総括するのが怖い。購入履歴をさかのぼり、買ってよかったものを振り返る。これらで整備した自宅のデスクの写真は会社のテックブログで晒されてるんですが、あまりに整理してなくて恥ずかしいやつです。続きをみる

で、結局WFH環境の整備で買ってよかったものは?

先日公開した記事の執筆中、どうしても書きたかったんだけど文量的にカットせざるを得なかったトピックです。続きをみる

Mura-Mi

AI vs. 教科書が読めない子どもたち

『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう

AI vs. 教科書が読めない子どもたち

測りすぎ――なぜパフォーマンス評価は失敗するのか?

THE FIRST SLAM DUNK re:SOURCE (愛蔵版コミックス)

単体テストの考え方/使い方

2022年のこと

2022年に読んで良かった本5冊+1絵本

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

怪奇な NullPointerException はどこから来た？

『ワーキングハマスタ』で観た、忘れ得ぬ光景

「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」

相対見積もりが機能するために必要そうなこと

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

脱サラパーソナリティ、テレビを飛び出す～佐久間宣行のオールナイトニッポン0(ZERO)2021-2022～

個別最適な学びと協働的な学び

遊ばせる技術チームの成果をワンランク上げる仕組み

深解釈オールナイトニッポン ~10人の放送作家から読み解くラジオの今

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

Clean Craftsmanship　規律、基準、倫理 (アスキードワンゴ)

明日、野球やめます選択を正解に導くロジック

ビジョナリー・カンパニーZERO ゼロから事業を生み出し、偉大で永続的な企業になる

スクラムにおける「完了」と「出荷」の話 / About Definition of Done

「アジャイル」の入り口に立つ / Entrance for "Agile"

不思議な力でベイスターズに集った「平成元年世代」

採用活動とマーケットインパクト

複数企業に所属してミッション・ビジョン・バリューを体現できるか

尋ねる力を価値とする

『他者と働く』を読んで

「何をやるかより、誰とやるか」または Disagree and Commit について

『チームトポロジー』を読んだ話

近況報告とか

AI vs. 教科書が読めない子どもたち

『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう

AI vs. 教科書が読めない子どもたち

測りすぎ――なぜパフォーマンス評価は失敗するのか?

THE FIRST SLAM DUNK re:SOURCE (愛蔵版コミックス)

単体テストの考え方/使い方

2022年のこと

2022年に読んで良かった本5冊+1絵本

継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣

怪奇な NullPointerException はどこから来た？

『ワーキングハマスタ』で観た、忘れ得ぬ光景

「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」

相対見積もりが機能するために必要そうなこと

プロになるJava―仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

脱サラパーソナリティ、テレビを飛び出す～佐久間宣行のオールナイトニッポン0(ZERO)2021-2022～

個別最適な学びと協働的な学び

遊ばせる技術 チームの成果をワンランク上げる仕組み

深解釈オールナイトニッポン ~10人の放送作家から読み解くラジオの今

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

Clean Craftsmanship 規律、基準、倫理 (アスキードワンゴ)

明日、野球やめます 選択を正解に導くロジック

ビジョナリー・カンパニーZERO ゼロから事業を生み出し、偉大で永続的な企業になる

スクラムにおける「完了」と「出荷」の話 / About Definition of Done

「アジャイル」の入り口に立つ / Entrance for "Agile"

不思議な力でベイスターズに集った「平成元年世代」

採用活動とマーケットインパクト

複数企業に所属してミッション・ビジョン・バリューを体現できるか

尋ねる力を価値とする

『他者と働く』を読んで

「何をやるかより、誰とやるか」または Disagree and Commit について

『チームトポロジー』を読んだ話

近況報告とか

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

遊ばせる技術チームの成果をワンランク上げる仕組み

Clean Craftsmanship　規律、基準、倫理 (アスキードワンゴ)

明日、野球やめます選択を正解に導くロジック