アジャイル / スクラムを始める - 川口恭伸の「引き継ぎできない！」から始まったアジャイルとスクラム

Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。

私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。

また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。

このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの経緯や背景をお伝えしたいと思います。

【アジャイル / スクラム前史】大学時代に得た、協調という学び
プログラミングを武器に“一人で”課題解決に挑む……けれど
「三種の神器」に感じたアジャイルのポテンシャル
「自分の仕事が引き継げない」をスクラムで解決しよう
「初めてのスクラム」をもたらしたのは、信頼貯金
スクラムを普及し「当たり前」にするために
日本と海外のギャップをなくすための発信活動
日本人にフィットするスクラムを。「 Fun! Done! Learn!」フレームワークの開発
経験と知識の交差がもたらす価値。アジャイルの旅路と、その先
関連記事

【アジャイル / スクラム前史】大学時代に得た、協調という学び

いまでこそ、アジャイルやスクラムは私の仕事の基盤となっていますが、それらとの本格的な出会いは社会人になって数年後のこと。しかし、学生時代に後の自分に影響を与える学びを得ていたのです。

経済学部で経営工学のゼミを選択していた私は、そのゼミの中でトヨタ生産方式やゲーム理論に触れ、これらも後の自分に影響を与えていますが、とくにインパクトが大きかったのは、経営学者である野中郁次郎先生の著書『知識創造の経営』でした。

同書は知識こそが経営の根幹にあり、その知識の原点は、個人のなかに存在する、言葉にしにくい知識である「暗黙知」であり、この暗黙知が複数人の協調活動によって共同化していく*1、と語っており、私はこのくだりすべてに蛍光ペンでマーキングするほどの感銘を受けたのです。

そして、もう一つの大きな学びは認知科学者の故三宅なほみ先生の研究でした。とくに、三宅先生がカリフォルニア大学時代に発表した論文「Constructive interaction and the Iterative Process of Understanding（通称「ボビンの論文」）」として知られる博士論文に基づく講義は印象深いものでした。

この論文の元になった研究では、ミシンの作動原理を知らない学生 / 多少理解している学生を集め、ペアで議論を行わせ、どのように作動原理への理解を深めていくかを観察します。三宅先生による結果分析では、協調活動を通じて新しい発見や知識深化が得られ、とくに、知識が少ない人が素朴な疑問を提示することが、知識が豊富な人へと「より良い説明」を考案させる刺激となる、と示しています。これは、「ペアで作業する」ことが新しい言語化や発想を生み出す助けとなることを示唆しており、私はこの点に強い刺激を受けたのです。

と、学生時代に野中先生、三宅先生から得た「協調活動がもたらす価値創出」という学びは、アジャイルやスクラムにも大いに通じるものがあります。しかし、社会人になった私は、一人で課題解決に挑む「ワンマンアーミー」としての仕事に埋没していことになったのです。

プログラミングを武器に“一人で”課題解決に挑む……けれど

経済学部を卒業し、情報科学研究科を修了した私は、ある金融系の情報ベンダー企業に入社します。配属されたのはシステム開発部門ではなく、情報部門でした。情報部門とは、データ制作を主な業務とする部署で、例えば取材先からFaxで送られてくる情報をコンピュータに入力しデータ化、それを基にした情報のサブスクリプションを販売する部署です。

当時の情報部門は、Excelが主流でプログラミングができる人はわずかでした。私はExcel VBAの書籍を参考にして、ループや条件分岐といったコーディング技術を学び、また、Excelのマクロ機能を利用し、データ整理を効率化するオートメーションを数多く実現しました。PerlとVBAを組み合わせることで、「メールで送信されてくるExcelファイルを自動的に開き、特定の数値部分をテキスト化してシステムに入力する」といった作業を自動化したのです。取材先の企業に「このExcelに情報を入力し、メールで送ってください」と伝えるだけで、新しい情報サービスの提供が効率化されます。それまでのFaxの情報を手動で入力するのに比べ、大きな進歩でした。

このように、情報部門でさまざまな問題をプログラミングにより解決してきましたが、大きな転機が訪れたのです。社内で新事業開発部門の立ち上げが発表され、私はこの新部門のメンバーに採用されたのです。しかし、意気揚々と新部門での仕事に臨もうとする私に大きな課題が浮かび上がりました。情報部門に開発していたシステムやツールの一部が、適切に引き継がれていないことが判明し、一時的に出戻りし対応することとなったのです。

私は、以前の部署で見てきた先輩たちのスムーズな業務引き継ぎを思い出しました。先輩たちは、キングジムのGファイルに仕事の内容や手順を丁寧にドキュメント化し、後任に十分な教育を施してから部署を去っていました。しかし、私が開発したツールやプログラムは、専門的な知識を必要とし、プログラミング知識を持つ人が少ない情報部門では、簡単に他者に説明や引き継ぎができるものではありませんでした。

特に、私が組み上げたシステムは多種多様な言語や技術を組み合わせて作られており、情報部門においては、まさにブラックボックスと化していたのです。

もちろん、ソースコードはPCのメモ帳で開けば誰しもが全て閲覧できますが、それだけでは十分な理解や操作が難しいのです。「暗黙知の共同化」「協調作業による学び」といった、大学時代に野中先生や三宅先生から学んだことが、この時の私の仕事にどれほど大きな意味を持っていたかを実感することとなりました。

「三種の神器」に感じたアジャイルのポテンシャル

新規事業開発の後、プロダクト開発をする部門に移ります。会社の基幹プロダクトのクライアントやエッジサーバのソフトウェア開発をしている部門です。まず最初に小さな新規プロダクトの担当になり、すでに検討と実装が進んでいた製品開発の手伝いに入りました。入って早々、WindowsOSの仕様変更にともなうアップデートの大きな問題が発生し、修正インストーラの作成などをやりました。トラブルの時の小回りの利く開発はわりと得意で、終わってしまえば引き継ぐ必要もないので、楽しかったのを覚えています。

しかし、「自分の知識や技術が役立ちそう、周囲が楽になりそう」と感じられれば、自分にできることはなんでもやるワンマンアーミー気質の強さゆえ、複数人での開発については、明らかに問題を抱えていたと思います。そして、私がアジャイルと本格的に出会ったのはこんな時期でした。

当時、アジャイル関連の書籍が翻訳出版され、各所でその話題を耳にするようになりました。雑誌か何かの記事で見かけた、ケント・ベックの『エクストリーム・プログラミング入門』(第一版) を読んで、すばらしいな、と思いつつ、同書で紹介されていた「マーケティング側の人と開発者が対になって活動する」というモデルが、当時の社内事情と相容れないものに感じ、深入りして学ぶことはしませんでした。

XPをもう少し詳しく教えてくれる人や、本を精緻に読むパートナーがいたら、また違う見解が得られたのでは、とも想像しますが、この時点で深く傾倒しなかった最大の理由は、自分が引き継ぎもろくにできないワンマンアーミーであったことかも知れません。

しかしその後、アンディ・ハントとデイブ・トーマスの『達人プログラマー』を読み、ビルドスクリプト、バージョン管理システム、自動テストという“三種の神器”を知り、これは革命的だと感じたのです。特に、軽量言語を用いたスクリプトでの環境構築の自動化は取り入れやすく非常に印象深いものでした。

続くバージョン管理システムですが、最初に導入したのはゲーム業界で人気のPerforceでした。その後、多くの人々と同様にSubversionを経て、gitへと移行しました。また、自動テストに関しては、最初はユーザーインターフェースの自動テストに焦点を当てて、xUnitやCruiseControlなどのツール導入を検討しましたが、検討コスト、また、導入コストが大きくなることが予見され、効果的な方法が見つからず断念したのです。

「三種の神器」以外にも、採り入れたものがあります。情報共有の手段として、PukiwikiというPHPベースのWikiソフトウェアを活用するようになったのです。これは業務引き継ぎのために導入したのですが、使っていく中で要件定義やリリース説明などにも利用できることに気づきました。

以降、常に自分の業務を文書化するよう心掛けていましたが、ただ文書化するだけでは情報共有の課題は解消されないことを次第に理解します。どんなに読みやすく網羅的な文書を作ったとしても、それを読んで理解してくれる「人間」が必要だったのです。

「自分の仕事が引き継げない」をスクラムで解決しよう

さて、上記のとおり、私はかつて「ワンマンアーミーとして」仕事面ではそれなりに成果を出し、「ワンマンアーミーゆえに」引き継ぎや共有のできなさに悩んできました。

就職して数年の若手に求められることは、個人のスキル向上や目の前の問題解決が主になることが多いと思います。自身の業務が影響する範囲も限定的なので、できるかぎり他の人とのコンフリクトを避け、自分でできる範囲を見極め、さっさと手を動かすことで、かなりのスピードで成果を出せます。そうすると周りの期待が高まり、褒めてくれたりして、業務評価も上々で、「他の人にできないこと」の存在は、まるで自分が必要とされている証にも感じられてきます。

こうした「個人」を軸とした仕事へのアプローチはもちろん重要ですが、それだけではまだ不十分です。なぜなら、業務には継続性が必要であり、自身のスキルを他者に共有でき、ちゃんと引き継げる状況が必要だからです。

かつての私は、自分が置かれていた「引き継ぎができない」状態の本当の意味が理解できていませんでした。なんなら引き継ぎなんてできなくても成果は出ているし、困っていない。「足下の成果はいいから、チームへの共有や引き継ぎを優先してやってくれ」という上司もいなかったのですから。しかし、こうした意識はアジャイルやスクラムを知るなかで徐々に変わっていったのです。

2008年9月、「XP祭り」というイベントに同僚の勧めで参加したのが、「スクラム」という言葉と初めて出会った瞬間でした。このイベントでは、米国で開催されたカンファレンス「Agile 2008」の参加者報告が行われており、その中で平鍋健児さんが指摘した「米国でのスクラムの流行と、それに伴うビジネスの成立」「Agile UXカテゴリの出現」という2つのポイントに、私は強い興味を持ちました。

関心をかき立てられたものの当時、私はスクラムに関する知識ほとんど持っていなかったので、まずはクレイグ・ラーマンの『初めてのアジャイル開発』を読むことにしました。同書はいくつかのアジャイル手法をインタビュー形式で紹介しており、スクラムについての章を読むうちに、野中郁次郎先生の影響を知ったのです。驚いたことに、大学時代に私が読んだ『知識創造の経営』で論じられていたことがスクラムの基盤にあり、この繋がりはどこか運命を感じさせるものでした。その後、自分自身でどうスクラムを実践できるのかを模索し始めたのです。

スクラムは、開発チームを中心に据えたフレームワークです。開発チーム内での綿密なコミュニケーションを基盤とし、プロダクトバックログ（実装すべきアイテムのリスト）に優先順位を設定し順に取り組み、スプリント期間中は外部の干渉を遮断し、集中してタスクを遂行します。チーム内では単なる役割分担よりも、お互いが教え合い、協力的に仕事を進める文化が育まれます。その結果、ただ成果を生むだけではなく、持続的に成果を出せるチームが形成されるのが特徴です。安定したチームで連携し続けることで、伝統的な引き継ぎが大幅に簡略化される、と私は感じたのです。

さらに、XPに関する本を読む中で課題と感じた、マーケティングとの協同作業についてのヒントを得ました。スクラムにおける「プロダクトオーナー」は、関係者とチーム間での調整を担当し、プロダクトバックログのメンテナンスを行う役割を持っています。さらに、スクラム経験を持つスクラムマスターが、チームの環境づくりをサポートします。私は、このプロダクトオーナーが持つ役割が、自分たちの業務環境に適しており、効果を発揮するのでは、と考えるようになったのです。

「初めてのスクラム」をもたらしたのは、信頼貯金

大変お待たせしました。ここから私の初めてのスクラムチームが組成します。ですが、企業の一社員、一人のワンマンアーミー、単なるソフトウェアエンジニアが急にチームを作るといっても、そんな簡単なことではないわけです。私はこれまでに使ったことがない力に目覚める必要がありました。それが「信頼貯金」です。

2008年のXP祭りからさかのぼること半年、Developers Summit（通称デブサミ）というイベントに初めて参加した私は、そこで、当時すでに8年間アジャイルを実践してきたという、関将俊（@m_seki）さんの発表を聞きました。関さんは「XPで最も重要なのは計画ゲーム」と語ります。「なにを優先してやるか、を考えることが、技術的なプラクティス以上に重要だと感じる」という話は目から鱗でした。

そして、関さんは発表の中でもうひとつ強調したのが「信頼貯金」の概念でした。8年前、組織の誰もがアジャイルを知らない時期に、XPという「未知のもの」を導入するためには、それまでに築いてきた「信頼貯金」の存在が不可欠だった、と関さんは語ります。過去にしっかりと成果を出し、他者をサポートする実績があると、新しい取り組みを始めたいと提案した時、上司や同僚たちからの支持を得やすくなるというのです。

この話を聞くなかで、私はこれまでワンマンアーミーとしての成果を積み重ねてきたことで、相当な量の「信頼貯金」を持っているのではないか、いまならば私も「新しい取り組み」を提案できるのではないかという感覚を得たのです。関さんと私の違いは、「信頼貯金」を活用する勇気があったかどうかです。

信頼貯金を原資にして勝負するタイミングは、案外と早く訪れました。入社最初の三年半を過ごしたデータ制作部門の方が、私のところに相談（愚痴だったのかもしれません）に来てくれて、ある新しい仕組みを作りたいのだけど、システム部門が取り合ってくれない、といいます。

その方が実現したいものを聞く私の頭の中には、データ制作部門の現場の仕事風景、かつて携わってきたクライアントアプリケーションの仕組み、アーキテクチャの全体像といったイメージが駆け巡り、「あれ、私がスクラムを組成して開発をリードすれば作れるな……」と直感したのです。次の瞬間、思わず口に出た言葉が「それ、スクラムなら作れますよ」でした。スクラムの実践経験を持っていなかった私なので、ハッタリも十分に入った一言なのですが、今こそ信頼貯金を「運用」するときだ、と考え勝負に出たのでした。

そこからは、私はスクラムを立ち上げるために必要な初動をこなしていくことになりました。新システムの初期エンドユーザーであるデータ制作部門の方たちと会い、要件を固めます。スクラムという「未知のワークフロー」であったにもかかわらず、それに巻き込まれてくれたのは、かつて、私が彼らのPCをセットアップしたこと、複数のツールを開発し提供をしてきたことによって培われた、関係性と信頼があったからに他なりません。

アーキテクチャについては、所属部門の上司や他チームのマネージャー、技術的なイニシアチブをとっている先輩が十分に詳しく、口頭で説明しただけで、「それならできるね」と同意が得られたと記憶しています。

最後にシステム部門です。当時の上長が声掛けをしてくれ、システム部門本部長も含む、10人ほどの関係者を集めたミーティングにこぎ着けたのです。関係者の中には、もともとその開発に難色を示したマネージャーも含まれており、同意が得られるかは未知数でした。加えて、新たなシステムは過去に類例がなく、リスクを含んでいます。しかし最後に、システム部門本部長の一言で方針が決まります。「ミスター川口がやるというなら、やってみてもらえばいいんじゃない？」と。まさに、信頼貯金で前に進む承認を得た瞬間でした。

その後、経営会議での提案を経て、3ヶ月分の開発予算が確保できました。当初の計画では、3ヶ月で基本的な機能を作成し、データ制作部門（エンドユーザー）の評価を受けた上で、ユーザビリティの向上などの追加開発を想定していましたが、追加部分の承認は得られなかったのですが、とりあえずのスタートは切れました。

チームは社内だけではありません。社外からはXP祭りが縁で知り合った、当時としては貴重な経験あるスクラムマスターとして、林栄一（@essence_s）さんが加わってくれ、林さんの会社から開発者を数名迎えることとなりました。

技術的には、短期間で基本的な動作するシステムを作れること、そして私自身がデプロイ環境を整えられることから、Ruby on Railsを採用し開発に着手しました。ただし、チームのメンバーはRailsに慣れていなかったので、初めの1ヶ月はスクラムとRailsの研修に充て、徐々に開発を軌道に乗せていったのです。信頼貯金だけでなく、自分自身のこれまでの経験や知識を活かし、ユーザーにとって本当に価値のあるシステム構築を目指し、私の「初めてのスクラム」が動きだしたのです。

スクラムを普及し「当たり前」にするために

スクラムの実践と並行して、スクラムがより一般化するための環境づくりも必要だと考え、仲間とともにスクラムを学ぶ場の整備も始めました。

私たちは、欧米でのスクラム普及の様子を見ながら、日本でもその波が来るだろうと感じていました。スクラムがやがて日常的に受け入れられるようになれば、私たちの取り組みは「先見の明」を持った活動と評価されるでしょう。そうなれば、スクラムの取り組みがさらに進めやすくなるはずです。

こうした思いから社内の有志、そして林さんがスクラムの勉強会を立ち上げることになり、私は会場確保や映像記録といった方面から、場づくりを支援したのです。社内での根回しをする際も、信頼貯金が大きな効果を示し、多くの方々が協力してくれ、そうして生まれたのが、2009年から現在まで続く勉強会「すくすくスクラム」です。

そしてある日、すくすくスクラムを取材したいという連絡があるメディアから届きました。会社で自分たちが主催しているため、社内に取材対応のネゴを通す必要がありました。ここでも信頼貯金が効果を発揮して、関係者各位の協力が得られ、スクラム勉強会のレポートが商業誌に出ることになり、徐々に会は軌道に乗っていったのです。

スクラム普及のための取り組みは社外にも及ぶようになります。2010年、スクラムの先駆者であるジム・コプリエン氏が東京で認定スクラムマスター研修を開催することとなり、私はその支援をしました。翌年1月には、スクラムの共同考案者の一人であるジェフ・サザーランド氏が初来日し、野中郁次郎先生と初対面するイベント「Innovation Sprint 2011」を平鍋健児さんと共同で開催しました。

さらに2011年の10月には、初のスクラムギャザリング東京を開催。Agile 2009以降、私は北米のアジャイルカンファレンスに3年連続参加し、『塹壕よりスクラムとXP』の著者であるヘンリック・クニベルグ氏や、Agile UXやアジャイルプロダクトマネジメントの分野で著名なジェフ・パットン氏といった識者と繋がりをつくり、彼らをキーノートスピーカーとして日本に招聘したのです。

このような活動を通じ、日本のスクラム実践者の知識を深め、欧米のアジャイルコミュニティとの差を理解し、そのギャップを縮めようと努めてきたのです。

こうした活動の途中、自分自身にも会社を退職するという大きな転機がありました。スクラムギャザリング東京の開催準備期間などに会社業務の繁忙期が重なってしまうと、どうしても業務を優先せねばなりません。スクラム普及活動にフォーカスしたいと考えるようになった私にとって、決断のときだったのです。そして、決断の後押しとなったのもスクラムでした。

自身の業務にスクラムを導入したことで、業務が共有され、かつて悩まされた大量の引き継ぎをせずとも業務が継続可能なチームが存在していたのです。事実、北米でのカンファレンス参加のため一週間不在になっても、何の問題も起きませんでした。この経験から、「私の引継ぎ問題がいよいよ解決したのではないか」と手応えが得られ、退職し新たな道を歩む決意ができたのです。

日本と海外のギャップをなくすための発信活動

日本でスクラムを一般化するための活動に、「場づくり」以外にもう一つ加わったのが書籍の翻訳でした。最初の翻訳はコミュニティで数年間にわたって読書会をしてきた『Fearless Change』でした。読書会の有志で分担して翻訳を行い、私は監訳として全体の手直しを担いました。その後も、ジェフ・パットンの『ユーザーストーリーマッピング』やズージー・ショコバの『SCRUMMASTER THE BOOK』など、コミュニティの有志とともに翻訳出版活動を行いました。

「Agile 20xx」カンファレンスには、2009年以降、現在まで継続的に（コロナ禍での中断はありましたが）参加しており、モブ・プログラミングの発案者であり、実践者でもあるハンター・インダストリーズ社のウッディ・ズィル氏やクリス・ルシアン氏との交流、2000年からアジャイル開発での受託を手がける『ジョイ・インク』の著者、リチャード・シェリダン氏、『レガシーコードからの脱却』の著者ディヴィッド・バーンスタイン氏、『An Agile Transformation Survival Guide』のマイケル・サホタ氏といった、アジャイルコミュニティの識者との間で築かれた関係は、現在も続いています。

また、こうした活動に並行し、2022年からはソフトウェア開発の現場での男女差をなくし、多様性を尊重する「Women in Agile」の日本でのコミュニティづくりを開始しています。米国における人種差別を克服する取り組み「Agile in Color」と合流し、「Agile Together」という形での活動が進行中です。これらの活動を通じて、知識面だけでなく多様性尊重の面でも欧米とのギャップを縮め、日本においてアジャイルな文化を普及させたいと願っています。

日本人にフィットするスクラムを。「 Fun! Done! Learn!」フレームワークの開発

上記のように海外のアジャイルコミュニティと関わるなかで、日本人と欧米の人々との文化の差、そして日本人の特性を意識するようになりました。そして、日本人の特性にフィットするスクラムの進め方が必要だと感じるようになったのです。

日本人は「まじめ」というパブリックイメージがあり、そうしたイメージを持たれる核心には「問題があると、それを無視できない」という性質があるように思います。同時に、問題を無視できないがゆえに、問題があるとわかってしまうと困り、問題がないかのようにふるまったり、問題を顕在化させる行為をする人を腫れもののように扱うこともあります。

日本生まれのトヨタ生産方式は、この「無視できない」特性をうまく利用しているように思います。常に現場を清潔に保ち、問題を見逃さない正直さを教育し、一つ一つまじめに解決することで品質を向上させていきます。一方で、スクラムは問題を表出させるフレームワークです。どんどんと問題を明らかにし、それをどんどん解決していくことで、うまくなっていくものです。こうしたスクラムの基本と「問題を無視できない」特性には、どこか馴染みにくい部分があるのです。

たとえば、スクラムの重要な活動であるレトロスペクティブ（ふりかえり）です。いざレトロスペクティブを実施しても、反省会になってしまって雰囲気が暗いとか、そもそも課題が挙げられない、あるいは、問題ばかり指摘して全然改善されない、という声が聞かれます。できてないこと、もっとこうしたほうがいい、という意見が、放っておいてもたくさん出てきますが、そうして出た反省点をすべて解決するのも困難です。その結果、解決されない問題が毎回指摘され、「問題を無視できない」人たちが疲弊していくというネガティブな循環*2が生まれてしまいます。

沖縄で開催されたアジャイルコーチのリトリートイベントにおいて、私の所属するグループのメンバーたちは、この問題への対応策として新しいレトロスペクティブ方法を考案しました。私はそれに、「Fun! Done! Learn!」というシンプルな名前を提案しました。

「Fun」は楽しかったこと、「Done」は完了したこと、「Learn」は学んだことを指し、この三つのポイントを中心にふりかえるという、シンプルな手法です。もし失敗があっても、そこから新たな学びが得られれば、「Learn」として捉えます。楽しく仕事を達成できた場合は「Fun & Done」。そして、具体的な改善点が見つかった場合、スクラムのプロダクトバックログに追加し、優先順位をつけて対応していきます。

この「Fun! Done! Learn!」の手法を私自身が実践してみると、数々の気付きが得られます。とくに、「事実」が明確に集約される点は、この手法の利点として挙げられます。従来的なふりかえり手法で挙げられる「これが足りない」「こうした方がいいだろう」といった意見や要望は、実は具体的な根拠に基づいていない仮説でしかありません。しかし、「楽しかったこと」「完了したこと」「学んだこと」はすべて具体的な事実です。この方法により、毎回の反省点をよりポジティブに捉え、現実的な改善点を探り、継続的な改善活動を容易に実施できるのです。

アジア圏には日本人と似た文化や価値観を持つ国があるでしょう。そういった国々でも「Fun! Done! Learn!」の手法が有効であると考えており、このシンプルながら効果的なアプローチで、より国際的な拡大を目指していきたいと思っています。そしてそれは、アジャイルやスクラムの普及にも一役買う物だと、私は考えています。

経験と知識の交差がもたらす価値。アジャイルの旅路と、その先

長くなってしまいましたが、私のアジャイルとの初めての出会いや、その後のコミュニティを通じた活動について述べてきました。アジャイルコミュニティの皆様から学んだことは多岐にわたります。チームでの仕事による協調的な学びや、引き継ぎの負荷軽減。「信頼貯金」を意識し、常に他者を尊重しながら成果を出すこと、そして時折、積極的に相談すること。「Fun! Done! Learn!」に表される通り、事実を基にポジティブに行動すること。カンファレンスを利用して多くの知識を吸収し、共同で学びを深めること。

これら私の経験は特別なものではありませんが、歳を重ねるなかで、雑多で多様な経験や学びが実は繋がっていること、そしてその交差点にこそ価値があるということに気付かされてきました。

自身の専門性を追求するあまり、「その領域の知識は自分には必要ない」という意見を耳にすることがあります。しかし、どうか柔軟に学びを深めてほしいと願っています。本稿で紹介した私の経験や話が、皆さんの知識の断片となり、いつか、なにかの価値となれば、それに越したことはありません。皆さんが少しでも価値を得てくれれば、それこそ私が野中先生や三宅先生から学んだ「協調活動がもたらす価値創出」の、ある種の結実なのだろうと思います。

この記事が皆さんの参考になったらうれしいです。ぜひ感想を聞かせていただければと思います。私はこれからも一歩一歩、ムリなくケガなく、勝手に積み重ねていければいいなと考えています。皆さんもぜひ、勝手気ままに好き放題、成長していっていただければ幸いです。そうすればきっと、もっといい未来が待っていると信じています。

編集：はてな編集部

*1:かなり要約しています。同書では暗黙知が形式知（客観的であり言語化された知識）へと変換され、形式知が次なる暗黙知を生み出す知識創造の循環を「SECIモデル」として理論化しています。ご興味のある方はぜひご一読を。

*2:それでもレトロスペクティブを続けようとするわけですから、やはり“日本人は真面目”なのかもしれません。