こんにちは、ファインディでFindy Toolsの開発をしている本田です。 この記事は「 エンジニア達の人生を変えた一冊 」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 Part7では、本田・加藤・山田の3名でお届けします。アジャイル開発との出会いになった本、iOSアーキテクチャ設計の答え合わせになった本、AI時代に再読して背筋が伸びた本。3冊それぞれ切り口は違いますが、いずれも自分の中の「開発の判断軸」を作り直してくれた一冊です。 それでは、さっそく紹介していきましょう。 RailsによるアジャイルWebアプリケーション開発 第4版 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ iOSアプリ設計パターン入門 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ 世界一流エンジニアの思考法 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ おわりに ■ 本田 / フルスタックエンジニア ■ ファインディでFindy Toolsの開発をしている本田です。 RailsによるアジャイルWebアプリケーション開発 第4版 RailsによるアジャイルWebアプリケーション開発 第4版 作者: Sam Ruby , Dave Thomas , David Heinemeier Hansson オーム社 Amazon 本書は、原著「Agile Web Development with Rails」をもとに、Rails 3.1に対応する形で翻訳された一冊です。著者には、アジャイルソフトウェア開発宣言の起草者の一人であるDave Thomasと、Railsの作者であるDavid Heinemeier Hanssonが名を連ねています。アジャイルの源流とRailsの源流が、ひとつの本のなかに揃っているというのは、今振り返ってみると改めてすごい組み合わせだと感じます。 ちなみに、そのDave Thomasが、2026年6月17日・18日にファインディが主催するオンラインカンファレンス 「エンジニアの役割の変化に向き合うConference 2026」 に登壇予定です。本書の著者本人の話を聞ける機会でもあるので、興味のある方はぜひチェックしてみてください。 この本を読んだきっかけ 業界4年目の頃、私はC#でウォーターフォールの開発をしていました。仕様を固めて設計書を書き、それに沿って実装し、最後にまとめてテストとリリース。それが「開発」というものだと思っていました。 そんなときに、Railsを使った新しいプロジェクトが立ち上がりました。チームメンバーは全員、Railsも本格的なアジャイル開発も未経験で、何から始めればいいのか分からない状態でした。そこで、みんなでこの本を教科書にして、毎日お昼に少しずつ読書会をしながら進めることにしました。各自一章ずつ読んできて集まり、分からないところを話し合い、サンプルを動かしてみる。それを繰り返して、RubyやRailsを少しずつ自分たちのものにしていきました。 本を中心にしたチームの学びの時間は、いまでも当時を思い出すたびに頭に浮かぶ景色になっています。 本の内容 構成のおもしろさは、Depot（デポ）というオンラインショップの架空のプロジェクトを、章を追って少しずつ作り上げていく形式になっているところです。最初は商品一覧の表示だけ、次にカートをつけて、注文できるようにして、メール送信を加えて……というふうに、本一冊を通じて一つのアプリケーションがインクリメンタルに育っていきます。 機能ごとの章タイトルが「タスクA」「タスクB」と続く構成で、まるで開発の現場でユーザーストーリーをこなしていくかのような体験になっています。Railsの機能を学べると同時に、 「動くものを少しずつ広げていく」開発スタイルそのものを擬似体験できる ように設計されていて、書名どおりまさに「Railsによるアジャイル」を体現した本だと感じました。 この本から影響を受けた点/学んだ点 この本を読んで一番大きかったのは、開発の進め方そのものに対する自分の考え方が変わったことです。 それまでの私にとって、「仕様を固める」「設計を作る」「実装する」「テストする」は、それぞれが大きな塊として順番に並んでいるものでした。ところがこの本でDepotを作っていく体験は、まったく違いました。小さく動くものをまず作って、そこに機能を足し、動かしてみて、足りなければ調整して、また次の機能を足していく。短いサイクルで「動くもの」を中心に開発が進んでいく感覚は、当時の自分には完全に新しいものでした。 同じくらい衝撃的だったのは、Rubyという言語とRailsというフレームワークの書き心地そのものです。それまで書いていたコードと比べると、コードの量が圧倒的に少なくて、それでいて表現したいことがすっと書ける。フレームワークが規約として用意してくれている部分にうまく乗ると、書くべきものに集中できる。これも「開発って、こんなに違うものになるのか」という気づきでした。 「Webアプリケーションをアジャイルに作る」というのは、ツールやフレームワークだけの話ではなく、考え方と書き心地と進め方が一体になって初めて成立するものなのだと、サンプルアプリケーションを作りながら肌で理解できた気がします。 特に印象に残った部分 特に印象に残っているのは、Depotを章ごとに育てていく構成そのものです。 本の最初のほうで作ったDepotは、商品一覧を表示するだけのとてもシンプルなものです。それが章を進めるごとに少しずつ機能が増えていき、最後にはちゃんと注文ができてメールが届く、ひとつのアプリケーションになっている。途中で「これで動くようになった」「ここはこういう改善ができるのか」と、小さな達成感が積み重なっていく感覚は、技術書を読みながら得られる体験としてとても新鮮でした。 そして、それをチームで読書会として体験したことも大きかったです。お昼に集まって、一章ずつ進めて、分からないところは議論して、サンプルを動かしてみる。今思えば、これ自体が「短いサイクルで動くものを増やしていく」という本書で学ぼうとしていたスタイルを、学び方そのもののなかで実践していたのだと思います。本を読むという行為が、ただ知識を得る時間ではなく、チームで開発のスタイルそのものを共有する時間になっていました。 このような方におすすめ 日本語版は更新が止まっているため、今からRailsを学び始める人に第一の選択肢として薦める本ではないかもしれません。ただ、原著は今もアップデートが続いていて、最新版ではRailsの新しいバージョンに対応した内容で読むことができます。 pragprog.com 私個人としては、 Railsとアジャイル開発の出会いをひとつの本でまるごと体験した原体験の本 として、今でも特別な位置に置いています。AIで開発の速度や進め方が変わっていく今だからこそ、「小さく動くものを作って、フィードバックを得ながら育てていく」という当時学んだスタイルが、自分のなかでの開発の考え方の土台になっていることをあらためて感じます。 続いては、Tools開発でファインディ初のモバイルアプリ「Findy Events」を担当している加藤さんです。Clean Architectureを採用したプロダクトをリリースした直後に出会った、設計選定の「答え合わせ」になった一冊について語ってもらいました。 ■ 加藤 / モバイルエンジニア ■ ファインディ株式会社でモバイルエンジニアをやっている加藤です。ファインディ初のモバイルアプリ「Findy Events」を開発しています。 iOSアプリ設計パターン入門 peaks.cc ※現在はPEAKSの公式サイトで電子版のみ購入可能です。 私が紹介する「iOSアプリ設計パターン入門」は、iOSアプリのアーキテクチャを網羅的にまとめた書籍です。 この本を読んだきっかけ 当時の私はMVCのみの開発経験しかない中で、業務でClean Architectureに挑むことになりました。 手探りで設計を進め、なんとかリリースまで漕ぎ着けたものの、本当にこれで良かったのか、正しい形は何だったのかという確信は最後まで持てませんでした。 チーム内でClean Architectureに対する共通認識を取り切ることができず、QCDのDを優先して走り切った経緯もありました。そもそもClean Architectureを採用すべきだったのか、別のアーキテクチャの方が適していたのではないかという迷いも残っていました。 そんなタイミングで本書が発売され、自分の中の答え合わせをしたいという気持ちで手に取った一冊です。 本の内容 本書は冒頭で、一般的なアーキテクチャの歴史と構造を整理するところから始まります。 GUIアーキテクチャとシステムアーキテクチャの両面から解説されており、それぞれの位置づけがクリアになる構成です。 その上で、各アーキテクチャをiOSアプリにどう適用するかが具体例とともに示されています。 アーキテクチャの選定に関する考え方にも一定のページが割かれており、サンプルコードがGitHubで配布されているため、手を動かしながら理解を深められるのもありがたいポイントでした。 この本から影響を受けた点/学んだ点 一番大きかったのは、GUIアーキテクチャとシステムアーキテクチャは組み合わせて使うものだという視点を得られたことです。 それ以前の私は、この二つを同じレイヤーのものとして捉えており、MVCとClean Architectureを並べて比較するような考え方をしていました。 本書を読んでから、例えば、「MVPでGUIを構築しつつClean Architectureでシステム全体を整理する」といった組み合わせの発想ができるようになりました。 実際にその後の業務で「MVP + Clean Architecture」という形に取り組み、本書で得た視点を現場に持ち込めたのは大きな収穫でした。 特に印象に残った部分 第2部のまとめ「アーキテクチャの選定基準」に書かれていた次のような問いかけが、強く印象に残っています。 なんとしてでもClean Architectureを採用すべきでしょうか。 どんなアーキテクチャパターンを採用するとしても、そのパターンの経験があったり、パターンに精通していることが望ましいです。 アーキテクチャパターンが目的になっていないか これらは、当時の私の悩みに正面から答えてくれる内容でした。 Clean Architectureを採用したプロダクトをリリースした直後に本書を読んだこともあり、チームでパターンへの精通が揃わないまま走り切ってしまったことを、ページをめくるごとに痛感させられました。 本来であれば設計を選ぶ前に向き合うべきだった問いを、後追いで突きつけられている感覚です。 iOSに限らず、アーキテクチャ選定の場面では常に心に置いておくべき視点だと感じています。 長期的な開発・保守・運用まで見据えて選ぶことの大切さを、自身の反省と重ねて受け取った章でした。 このような方におすすめ これから、あるいは今まさにiOSアプリのアーキテクチャ設計に取り組むエンジニアにおすすめの一冊です。 iOSアプリのアーキテクチャを体系的にまとめた書籍は今でもそう多くないため、最初に手に取る一冊として機能すると思います。 また、iOSに限らずアーキテクチャの歴史や系譜に興味がある方にも価値のある内容です。 発売から7年近くが経つためTCAは扱われていませんが、TCAにつながるFluxの解説があり、現在のiOS開発の文脈でも参考になる部分は多く残っていると感じています。 最後は、事業推進でカンファレンスサービスを開発している山田さんです。山田さんが選んだのは、世界トップクラスのエンジニアの思考プロセスを言語化した一冊。AIコーディングエージェントが日常になった今だからこそ、再読の意味が増した本について語ってもらいました。 ■ 山田 / フルスタックエンジニア ■ ファインディ株式会社でフルスタックエンジニアをやっている山田です。ファインディのカンファレンスサービスを開発しています。 世界一流エンジニアの思考法 世界一流エンジニアの思考法 作者: 牛尾 剛 文藝春秋 Amazon 私が紹介する「世界一流エンジニアの思考法」は、Microsoft Azure Functions開発チームに身を置く著者が、世界トップクラスのエンジニアたちの思考プロセスと働き方を観察して言語化した一冊です。生産性の本質を「基礎理解の深さ」と「試行錯誤の前に思考する姿勢」に求めており、AI時代に再読する価値がむしろ増した本だと感じています。 この本を読んだきっかけ 最初に手に取ったのは、自身やチームの生産性向上を目的に、社内で技術的に優れたアウトプットを圧倒的な量で出し続ける同僚を意識した時期でした。実装スピードも設計の練度もPRの打数も桁が違う。その差分を言語化したくて、世界一流の現場で同種の人々に囲まれて働く著者の本を読みました。 最近になってAIコーディングエージェントが日常の道具となった時期に、自分の中の「思考順序」がAIを挟んで再び崩れ始めている自覚が芽生え、改めて初心に返り本書を再読することになりました。 本の内容 本書は7章構成で、第1章「世界一流エンジニアは何が違うのだろう？」から始まり、マインドセット、情報整理・記憶術、コミュニケーション、チームビルディング、生活習慣を経て、第7章「AI時代をどう生き残るか？」で締められます。 主軸は「生産性は時間ではなく思考の質で決まる」という立場で、具体的には次のような原則が繰り返し強調されます。 Be Lazy: 作業量を減らし、インパクトのある対象に集中する 理解の三要素: 説明可能／いつでも使える／応用可能、を満たして初めて「理解した」と言える 仮説駆動: 試行錯誤を悪とし、事実→仮説→検証の順序を守る シングルタスク／タイムボックス: マルチタスクは生産性が最低なのでやらない AI時代の生存戦略: 自分が学んだものとAIをどう掛け算するか この本から影響を受けた点/学んだ点 初読で強く影響を受けたのは次の二点でした。 基礎理解には時間をかけること。シニアが平気で数日を「読むだけ」に費やす描写から、表面的に動かす速度よりその後の実装と判断の速度を取りに行く姿勢を学びました。 試行錯誤の前に思考すること。手を動かす前に「事実を掴む → 仮説を立てる → 検証する」の順序を必ず通す習慣です。 再読で痛烈に蘇ったのは、AI時代において自分が崩していた順序の自覚でした。具体的には次の3つの兆候です。 AIのアウトプットの質を上げるために、プロンプトを試行錯誤で叩く回数が、自分の思考時間より長くなっていた AIを並列で走らせる並列業務に流され、シングルタスク原則が崩れていた AIが最初に出した "good code" を正にしてしまい、「bestなコードは何か／そこに至る道筋」を自分の頭で検討する工程が薄くなっていた ここから得た結論は、AIの登場は基礎の重要性を消したのではなく、見えにくくしただけということ。基礎力の向上は今も昔も時間がかかり、長い時間、同じ対象に向き合って初めて芽が出ます。AIを係数として効かせるための「自分側の係数」を、地道に上げ続ける意志が問われていると改めて認識しました。 特に印象に残った部分 第3章で示される「理解の三要素：説明可能／いつでも使える／応用可能」は、初読時から自分の判断基準として一番手元に残った概念です。再読時には、この三要素をそのままAI出力のレビュー基準として転用し、「生成されたコードを自分で説明できるか／別文脈で使えるか／応用が効くか」を改めて意識するようになりました。 もう一箇所は、第1章の「マルチタスクは生産性が最低なのでやらない」という言葉です。AIが並列処理を肩代わりしてくれる時代だからこそ、人間側がマルチタスクで思考の解像度を落とすのは本末転倒で、今手をつけている仕事を1つに限定することがAIを使いこなす前提条件だという文脈は再読で初めて腹に落ちたところがありました。 このような方におすすめ 周囲に桁違いのアウトプットを出すエンジニアがいて、その差分を言語化したい方 AIコーディングエージェントを使い始めてから、プロンプトの試行錯誤に時間を溶かしている自覚がある方 AIが出してきた "動くコード" をつい best として採用してしまっていることに違和感を持ち始めた方 並列タスクで日々が埋まり、1つの対象に深く向き合う時間が減っている方 「AI時代に技術力は不要になるのでは」という風潮に、戒めとしての軸を持ち直したい方 おわりに アジャイルを支える開発スタイル、iOSアーキテクチャを選ぶ視点、そしてAI時代に通用する思考法。今回紹介した3冊は扱うテーマこそバラバラですが、いずれも「自分の中の判断軸」を作り直す体験を与えてくれた本でした。 私はRailsとの出会いを通じて「小さく動くものを育てる」スタイルを、加藤さんはアーキテクチャ選定の問いを、山田さんは基礎理解と思考順序の重要性を、それぞれ本から受け取っています。年次を重ねるほど一冊の影響は薄まるのかと思いきや、振り返ってみるとむしろ「あのとき出会えた」一冊が、いまの判断や設計、思考のクセを支え続けている。エンジニアという仕事ならではの面白さだなと感じます。 皆さんにも、そんな一冊との出会いが一つでも増えるきっかけになれば嬉しいです。 ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください。

こんにちはkubotakです。 弊社では定期的に技術書籍の感想会という取り組みを行っています。 技術書籍の感想会は輪読会とは異なり以下のような取り組みとなっています。 その場で読まない（輪読しない） 事前にシートを用意して感想を付箋で書く 話題にしたい付箋を投票する 投票数の多い話題を取り上げて議論する この取り組みは不定期に行っており、エンジニアメンバーでみんなで感想会をしたい書籍がある場合に自然発生しています。 過去にはこの取り組みを社内でとどめておくのはもったいないので、ポッドキャストとして配信等も行っていました。（現在は停止中） tech.macloud.jp そして今年の4月からは「…

お疲れ様です、エンジニアリングマネージャーの芦川です。 最近私の身に起きた「 奇跡のような時間 」 のお話をさせてください。 実は、有志のメンバー数名で 「 プロダクトマネージャーのしごと 」 という本の輪読会をやっていました。数ヶ月にわたる全16章の旅をようやく終えたのですが、これがもう、私のこれまでの社会人生活の中でも類を見ないほど、最高に濃密な時間でした。 何がそんなに凄かったのか。 一言で言うと、 「 斜めのつながり 」が起こした化学反応 です。 同じチームの人はほぼいない。上司・部下の関係もほぼない。 部署も年次も役割もバラバラなメンバーが、いわば「斜めの線」でつながって集まった、非公式な秘密の場所。そこで起きたことを、自分たちのふりかえり（KPT）の結果を交えながら、生々しく記録しておこうと思います。 きっかけは、忘年会の「ちょっとした立ち話」 そもそも、なぜこの会が始まったのか。 きっかけは、私自身のちょっとした「悩み」でした。 マネージャー同士で仕事をしていると、「もっと目線を合わせる必要があるな」と感じる場面が多々あります。だったら、何かひとつ同じ本でも一緒に読んでみて、共通言語を作ってみたらどうだろう？と考えました。 ちょうど私自身がプロダクトマネジメントを学習したいと思っていたタイミングで、「これをビジネス側のマネージャーと一緒に読んでみたいな」と思い立ちました。 そんな話を忘年会の席などで周囲にポロッとしてみたところ、 「あ、それなら私もやりたい」「自分も興味あります」 という声が予想以上に上がり、気づけば部署も役職も飛び越えた、今の面白いメンバーが集まっていました。 そもそも、何をやっていたのか？ 読んだ本は、オライリー・ジャパンの 「 プロダクトマネージャーのしごと 第2版 」 です。 プロダクトマネジメントの本質は「ビジネスと顧客の間の価値交換の管理人」であること。中身はスキルや手法もありましたが、それ以上に「どういう姿勢で人と向き合うか」という、ものすごく人間くさいことが書かれている本でした。 これを、毎週1章ずつ各自が非同期で読み進めてオフラインの場で感想をぶつけ合う。 ただそれだけのことなのですが、回を重ねるごとに、私たちの会話は本の内容を超えて、自分たちの「キャリア」や「組織のリアルな悩み」へと深く潜り込んでいきました。 輪読会を「ふりかえり」してみた 全章を終えた後、私たちはいつものようにKPT形式でこの会をふりかえりました。 そこに出た言葉が、この会の熱量を何よりも物語っています。 【KEEP】この会が最高だった理由 まず、全員が口を揃えて言ったのが 圧倒的な心理的安全性の高さ です。 「意見に対して否定されることがないので、心理的安定があった」（企画 管理職 井田さん） 「自分にはない視野を聞けた。キャリア相談もできて、自分が見えていたこともあった気がした」（企画 メンバー 安孫子さん） 業務上の利害関係がない「斜めの関係」だからこそ、普段の会議では絶対に言えないような「実はあそこ、失敗だと思ってます」とか「今のキャリアに悩んでるんです」という本音がポロポロと出てくる。 否定されない、マウントを取られない。そんな「聖域」のような場所になっていました。 次に、多角的な視点。 「自分とは違う立場の人から、違う意見を聞けて気づきやヒントをもらえた。納得感や共感がさらに生まれた」（企画 管理職 矢野さん） 矢野さんが言うように、エンジニアの視点、企画の視点、ビジネス側の視点。それぞれの「正義」や「制約」を知ることで、「あ、あの部署があの時あんな動きをしていたのは、こういう背景があったのか！」と、パズルが解けるような納得感が何度も訪れました。 吉田さんも、この多様性を評価してくれました。 「役職・部署・年次の異なるメンバーが集まったこと」（企画 プロダクトオーナー 吉田さん） この「バラバラさ」こそが、議論を立体的にしてくれた最大の要因でした。 泥臭く、人間臭かった「感想戦」のエピソード KPTのデータだけじゃ伝わらない、実際のやり取りの中で私の心に深く刺さったシーンを紹介させてください。 企画 管理職 井田さんの「型」への深い洞察 井田さんは、いつも一歩引いたところから、本質をズバッと突いてくれました。アジャイルやフレームワークの話になったとき、井田さんがボソッと言ったこの言葉が忘れられません。 「サッカーも茶道もアジャイルも一緒だな。ごく当たり前なことなんだけど、とっかかりとしてなにか型を用意したに過ぎないんだな！」 手法（アジャイル）を「目的」にするんじゃなくて、より良い仕事をするための「型」として捉える。この 井田語録 は、ツールに溺れそうになる私たちの目を何度も覚ましてくれました。 企画 管理職 矢野さんの「他部署へのリスペクト」 現場の最前線で戦ってきた矢野さんは、誰よりも「相手への想像力」の大切さを語ってくれました。 「開発の制約があることを想像しながらも、無視して『早く成果を出せ』と振る舞ってきたことがあった。反省。お互いの制約を理解しないと議論は噛み合わないし、そこを埋めるのが会社の成長に直結するんだ」 ベテランの矢野さんが、若手の前で「反省です」とさらっと言える。この潔さと素直さが、この会の空気をどれだけ温かくしてくれたか計り知れません。 企画 メンバー 安孫子さんが見つけた「自分の居場所」 安孫子さんにとって、この会は単なる勉強会以上の場所になっていたようです。 「年上の人とも、本という共通のツールがあることで対等に話を進めることができた。自分のこれからのキャリアについても相談ができて、自分だから見えていたこともあるんだと自信が持てたのが本当に良かった」 上司ではないけれど、経験豊富な先輩たち。そんな「斜めの先輩」にキャリアの悩みを打ち明け、認められた経験。彼女がこの会を通じて少しずつ自信をつけていく様子を見ていて、私も本当に嬉しくなりました。 企画 プロダクトオーナー 吉田さんの「対話への意志」 吉田さんは、本の中の抽象的な言葉を、いつも私たちの現場の課題に接続してくれました。 「『心地悪さは明確さの欠如の兆候』というフレーズが刺さった。放置すると将来の感情的対立や大きな障害になるから、恐れずに表面化させて、その都度対話することが必要なんだ」 「なんとなく気まずいから言わない」を卒業して、良いプロダクトのために「心地悪い会話」をする勇気。吉田さんの鋭い指摘は、いつも私たちに背筋を伸ばさせてくれました。 企画 メンバー 岡田さんが見つけた「改善の第一歩」 岡田さんは、日々の多忙な業務の中でも、いかにチームを良くしていくかを真摯に考えていました。 「大きなタスクはできるだけ分割して方向性を微調整できるようにする。また、お客様と同じ手順でサービスに触れることで、自分たちが本当に取り組むべき優先順位が見えてくる」 理想論だけで終わらせず、具体的にどう動くか。その一歩を自分なりに定義する岡田さんの姿勢は、メンバーにとっても大きな刺激になりました。 奇跡の時間の正体：なぜ「開発MTG」が楽しくなったのか？ ふりかえりのメモの中に、こんな一節がありました。 「読んだ自分の中で変化があったこと。開発とのMTGがたのしくなった。人の理解がちょっとできた」 これ、私も全く同じなんです。なぜ、たかが読書会でMTGが楽しくなるのか。 それは、この会を通じて 相手の背景にある制約や意図に好奇心を持つ訓練 ができたからです。 これまでは「なんで開発はこんなに時間がかかるんだ？」と不満に思っていたことが、「ああ、彼らには彼らの技術的な制約や、守るべき品質があるんだな」と想像できるようになった。 相手を「説得すべき対象」ではなく「共に航海するパートナー」として見られるようになった。 私はエンジニアですが、逆に企画の方に対してもこう強く思うようになりました。 これは、スキル以前の「人間としてのスタンス」の変化なのだと思います。 結びに：この集まりに名前をつけるなら 最後の感想戦で、私たちはこの集まりをこう呼びました。 上下左右輪読 奇跡の時間 役職（上下）、部署（左右）を超えて、斜めに繋がったメンバー。 秘密のDMグループという「非公式な場」で、誰にも否定されずに自分の経験を語り、仲間のキャリアを応援し、共に学習する。 これって、効率化ばかり求められる今の組織の中で、一見すると「無駄な時間」に見えるかもしれません。でも、本の中にあったように 「 無関心は反対よりももっと危険 」 です。 この輪読会に集まったのは、無関心ではいられなかった、熱い想いを持った「当事者」たちでした。 もし、皆さんの周りに閉塞感があるなら、ぜひ部署をまたいだ「斜めのつながり」を作ってみてください。一冊の本をダシにして、本音で語り合ってみてください。 そこには、どんなベストプラクティスよりも価値のある、 働くことをちょっと豊かにしてくれる奇跡 が待っているはずです。 一緒に走ってくれた井田さん、矢野さん、吉田さん、安孫子さん、岡田さん。 皆さんと過ごした時間は、マジで財産です。 「 未完成なものを素晴らしいものにするには、あなたの助けが必要です 」 本の中にあったこの言葉通り、皆さんの助けがあったからこそ、この輪読会は最高の「プロダクト」になりました。 本当に、ありがとうございました！ また次の「奇跡」を、みんなで探しに行きましょう。