みなさまこんにちは、天野です。
私は前職のサイボウズでスクラムを導入し、同社初のスクラムマスターとして長年活動してきました。社内のアジャイル導入の過程でさまざまな職能のメンバーと関わり、特に品質については強い関心を持って取り組んできました。プロダクションレベルの品質をいかに素早く確立するか、スプリントの中でどう品質を満たすか、といったテーマです。
その中でQAのメンバーとも多くの時間をともに過ごし、品質や人材の成長について考えてきました。後年はマネージャーとしてQAメンバーのキャリアを支援したり、QAからスクラムマスターに転身したメンバーをマネジメントしたりもしてきました。
組織の中にいるときは当たり前だったことが、外に出てみてはじめて「あれが自分を育てていたのか」と気づくことがあります。社内での実践と社外への発信を行き来する中で得てきたものを、一人の実践者として届けたい。それがこの連載を書こうと思った理由です。
本連載ではそんな背景をもとに、「社内外を往復するアジャイルQAの育ち方」というテーマで全4回の記事を書かせていただきます。よろしくお願いします。
アジャイルな人材とは
さて、連載の第1回となる今回は「アウトプット」の話から始めたいと思います。
まず、アジャイルなQAとは何でしょうか。私は、QAに限らず「アジャイルな人材」とは、学習する力が高く、これまでのやり方に固執せず、新しいことを吸収しながら改善を重ね、自律的に仕事をより良くしていける人だと考えています。
こうした学習する力は、何によって支えられているのでしょうか。一つには書籍を読む、ウェブから情報を得るなど、個人的なインプットがあります。もちろんそれも重要です。しかし、インプットした情報を踏まえて実際に手を動かし、発信する。そこで他者からフィードバックを得て議論し、新たな知見を蓄積し、さらに実践を深めていく。このサイクルを回している人は、学習する力が極めて高いと感じます。
インプットにとどまらず、実践、発信、フィードバック、それをさらに実践に生かすサイクル。この起点としてまず取り組みたいのがアウトプットです。
「アウトプットした方がいい」のに踏み出せない理由
アウトプットの重要性を語る場面でよく聞くのが、「した方が良いと分かっているけれど、なかなかできない」という悩みです。
アウトプットできない理由としてよく挙がるのは、こんなものです。
- 「時間がない」
- 「マサカリが飛んでくるのが怖い」
- 「自分なんかがやっていることを発信しても大した価値はないのではないか」
- 「もっとちゃんとした成果が出てから発信したい」
正直に言えば、私もかつてはこれらすべてに当てはまっていました。特に「もっとちゃんとした成果が出てから」という気持ちは強く、書けずにいた時期が長くありました。
理由はそれぞれ異なりますが、共通しているのはアウトプットのハードルが高くなっているということです。特にQAに携わる方は、日頃から品質を見極めることを仕事にしているぶん、自分のアウトプットに対する暗黙の品質基準も高くなりがちではないでしょうか。その根底には、アウトプットとは十分な成果をまとめ上げた「完成品」であるべきだ、という前提があるように思います。つまり、アウトプットを活動の「ゴール」として捉えているのです。
しかし、アウトプットをゴールと捉えると問題が起きます。私たちの仕事は明確な区切りがないものも多く、基本的にはずっと続いていきます。「区切りがついたらアウトプットしよう」と思っていると、なかなかそのタイミングが見つからず、ハードルが上がり続けてしまいます。
これはソフトウェア開発に喩えれば、ウォーターフォール的な「ビッグバンリリース」の発想です。すべてが完成してから一括でリリースしようとすると、リリースそのものが重く、遠くなっていく。アジャイルの考え方に従えば、リリースはできるだけ小さく、高頻度に届け、そこからフィードバックを受けて学ぶというサイクルを回します。
アウトプットも同じです。小さくして頻繁にリリースすれば、学習のサイクルが速く回り始めます。そしてそれは、アウトプットそのもののハードルを下げることにもつながるのです。
アウトプットは「思考のインクリメント」
私が提案したいのは、アウトプットを自分の活動から生まれる「インクリメント」の一つとして捉えることです。スクラムにおけるインクリメントとは、スプリントごとに積み上がる「利用可能な成果物」のことです。一定の周期で小さな成果物を届ける仕組みがあるからこそ、「検査と適応」のサイクルが回ります。
アウトプットにも同じことが言えます。自分の活動や考えを定期的に言語化して外に出していれば、そのアウトプットが検査と適応の対象になります。アウトプットは自分の思考の過程そのものですから、つまり自分の思考や考え方そのものが検査と適応の対象になるわけです。
これは極めて強力な、思考を鍛える仕組みです。アウトプットとは、頭の中にあるものをそのまま外に出す作業ではありません。
教育心理学者のBereiterとScardamaliaは、著書『The Psychology of Written Composition』(1987)の中で、書くプロセスを「知識伝達（knowledge telling）」と「知識変換（knowledge transforming）」の二つに区別しました。知識伝達とは、知っていることをそのまま書き出すこと。一方、知識変換とは、読者に伝わるように構成を考え、言い回しを工夫する過程で、「そもそも自分は何が言えるのか」「どこが弱いのか」が露呈し、知識や理解そのものが更新されていくプロセスです。
アウトプットの過程ではまさにこの知識変換が起きています。言語化する過程で、理解の怪しい点が否応なく炙り出されます。書き進めるうちに、曖昧だった思考の輪郭が次第にはっきりしてくる。書いたものを読み返し、スムーズに読めるか、論理に齟齬がないかを確認する。こうした一連のプロセスが、対象についてより深く考えることを促し、累積的な思考量を増やしていきます。
つまりアウトプットとは、思考を「出す」行為であると同時に、その過程で思考内容が検査され、思考を「鍛える」行為でもあるのです。
なぜアウトプットが自己変容を促すのか
継続的なアウトプットは、思考量を大きく押し上げます。書くことでインプットへの欲求も自然と高まり、学びのサイクルが加速していきます。
また、認知心理学では「プロテジェ効果」と呼ばれる現象が知られています。他者に教えるつもりで学ぶと、自分のために学ぶ場合よりも学習成果が向上するというものです。興味深いのは、実際に教えなくても「教えるつもりで準備する」だけで効果があるという点です。つまり、「読者に伝えよう」と意識してアウトプットを準備する行為そのものが、学びを深めているのです。
さらに重要なのは、継続的なアウトプットを支えるには、長期にわたる「一貫したテーマ」が必要になるということです。
一貫したテーマを持つと、常にそのテーマについてアンテナを張るようになります。アンテナを張った状態とは、すなわち問いを立てている状態です。これが普段の思考と行動に影響を与えます。
たとえば「開発チームの品質文化を育てる」というテーマを持っていれば、日々のテスト設計やレビューの中でも常にそのレンズで物事を見るようになります。気づいたことや試行錯誤をアウトプットすることが、さらなる行動変容を駆動する。こうしたループが回り始めます。
また、過去のアウトプットを見返せば、自分の思考の変遷を辿ることができます。差分を比較することで、さらに理解が深まる。このように、アウトプットは強力に自己変容を促す仕組みとして機能します。
ここで一つ強調しておきたいのは、このプロセスを自分自身で経験することの重要性です。今はAIに文章を書かせることも容易になりました。しかし、構成を考え、言葉を選び、論理を組み立てるプロセスそのものが思考を鍛えているのです。それをAIに外注してしまうと、アウトプットから得られる学習効果の大部分を手放すことになります。AIは下調べや推敲の相談相手としては有用ですが、「自分で考えて書く」という核の部分は、自分でやるからこそ意味があります。
PVやバズを目的にすると続かない
昔の私はエンジニアブログを書いては、はてなブックマークが何件つくかで一喜一憂していました。「ホッテントリ入りだ！」「300ブクマ超えた！」といった具合です。正直なところ楽しかったですし、書くモチベーションにもなっていました。
ただ、反応というのは期待したようにはつかないものです。数字を目的にし続けると、伸びなかったときに落胆し、だんだん手が止まるようになりました。また、必要以上に注意を引こうとして、炎上や論争を煽るような記事を作る「歪み」をもたらすリスクもあります。そうした記事には批判的なコメントもつきやすく、不毛な応酬は精神を消耗させます。
PV数やLike数を目的にすると、価値判断の基準が単純な数値に置き換えられます。さらに厄介なのは、「もっと注目されるにはどうすればいいか」という問いが頭を支配しはじめることです。これは、学びの促進や自己変容という本来の目的から大きく逸れた動機です。
では、何を目的にすればいいのか。ここまで述べてきたように、アウトプットの本質的な価値は、累積的な思考の蓄積と自己変容にあります。それを目的とするならば、アウトプットした時点で目的は達成されます。反応がつくかどうかはあくまでおまけです。「書くことそのものが自分を鍛えている」という実感があれば、外部の数値に振り回されることなく、アウトプットを続けていくことができます。
何のためにアウトプットするのか
アウトプットの目的としては、他にもよく語られるものがあります。特に会社のエンジニアブログのような公式の媒体では、「採用につなげる」という目的が必ずと言っていいほど挙がります。実践の結果や学んだことをブログに書いておけばポートフォリオになり、転職や副業の際にキャリアのプラスになるという考え方もあります。
これらはアウトプットの成果として確かに大切です。ただ、人によっては「採用のために頑張ろう」「転職に有利だから書こう」と言われても、今の自分にとって少し遠い話に感じられ、なかなか手が動かないこともあるのではないでしょうか。少なくとも私はそうでした。
そこでもう一つの捉え方を提案したいのが、これまで述べたような「自分自身を変容させるための手段」、そして「学びを得るための手段」としてのアウトプットです。この捉え方であれば、活動自体に意義を感じ、取り組むための心構えができるのではないでしょうか。
そして、自分を鍛えるためにアウトプットを続けていると、結果としてその知見が誰かの参考になっていたり、業界全体の学びの蓄積に貢献していたりすることがあります。採用やキャリアへの好影響も、狙って得るものではなく、続けた先に自然とついてくるものです。
まずはリズムを作ることから
とはいえ、自己変容「だけ」を目的にすると、変化を実感するまでに数年単位の時間がかかります。それはそれでしんどいものがあります。
ただ、実際にアウトプットを続けてみると、もう少し手前の段階で変化を感じられるものです。書く過程で自分の理解の穴に気づく。人に読まれることを意識して構成を考えるうちに、普段の仕事でも論理の組み立て方が変わってくる。こうした小さな手応えは、数回のアウトプットで感じ始める人が少なくありません。
おすすめなのは、「アウトプットのリズム」だけを決めて、淡々と続けることです。その過程で、たまにバズったり仕事の機会につながったりすればラッキー、くらいの気持ちでいるのが長続きのコツだと思います。
いきなり公開のブログを書く必要はありません。まずは日記やメモでも十分です。書くこと自体が思考を鍛えるプロセスだからです。
その上で、もし一歩踏み出せるなら、社内のSlackやチャットで今日学んだことを一言書いてみてください。日報や週報に「気づいたこと」の欄を設けてみるのもよいでしょう。こうした小さなアウトプットも立派なインクリメントです。外に出すことで他者からフィードバックが得られ、学びのサイクルの質がぐっと上がります。チームや組織にとっても、ナレッジが蓄積されるという大きなメリットがあります。
慣れてきたら、書き溜めたものを少し整理して社内のナレッジベースやブログにまとめてみる。隔週でも月一でも構いません。
大切なのは、始めること。そして、続けることです。
次回は、「では具体的に何をどう書けばいいのか」という実践的な話に踏み込みます。日々の仕事を「記事になる形」に整える技術についてお伝えします。
