言い訳を味方につけてインプット・アウトプットによる成長の習慣を仕組み化する
開発本部 People Experience チーム Developer Concource Unit 兼 Garoon MATSULI チームの西原@tomio2480 です．7 月にあった社内イベントである "開運まつり" の OST で話したネタを改めてまとめ直します．
というのもぼくが完全に忘れ去って数ヶ月，以下のきじまさんの記事でぼくのサボりが発覚したため，2024 年が終わる前に「力強くブログを108記事アウトプットする日の 20241229」で一生懸命書いているという顛末です．
↑ 無事 2025 年になっていました．書き終わりませんでした．
ということで，当日お話ししたことを思い出しながら，自分が考えていたことを改めて整理整頓してここで表現したいと思います．
インプットについて
情報の獲得までの道のりは短い方がいい
どんな内容にしても学習し始めで大事になるのは，学び初めの障壁の少なさです．例えば，何か本を読むにしても「部屋の中から本を探す→読む場所を決める→メモを用意する→本を読み始める→大事なところのメモを取る→……」となっていると，内容を頭に入れるまでにやることや決めることが多く，学習に使うべき体力が持っていかれてしまって，疲れの量に見合わない学習量で萎える…… みたいなことがおきます．
そこで，読む本の候補を置く場所を決めておき，本を読むときのスタイルも決めておき，メモグッズも置いておくと，それだけであまり判断の体力を使わずに本を読み始められるようになります．
こういったアプローチで情報が脳に到達するまでの障壁をどのようにして減らしていけるかが，インプット施策の肝になります．
気になっていることが勝手に入る仕組みを作れるか
今の世の中だと X をはじめとするタイムラインの構築や，YouTube 等のサジェストしてくれるサービスの調教をどれだけ精緻にやるか，という取り組みの質が獲得すべき情報にリーチする速度を高める際のポイントです．
ただ，そうすると一人の趣向で流入する情報のデッキが構築されてしまうため，幅が広がって行きにくい問題にぶち当たります．そうしたときに役立つのが下の記事で紹介している「ブログを読む会」のやり方です．
例えば複数人で読みたい記事をバンバン集めておいて，ブログを読む会の時間で一覧から記事を選んで読む．というようなことをすると，効率はよいままに，自分が選ばないタイプの記事に出会えてお得です．みんなのブックマークの「あとで読む」から選ぶのも面白いかもですね．
つまりインプットのコツは，無意識下での地道な積み重ねが効果を発揮するような環境に身を置くことです．そうした小さな積み重ねがあって，本を通読するなどの，体力のいるインプットを乗り越える胆力がつくはずです．いきなりでかいインプットは厳しいです．
アウトプットについて
開発工数を割いてまでブログを書いたり登壇したりすべきなのか
技術広報的なお仕事をされている方から聞こえてくる「どうしたらみんなブログを書いてくれる or 登壇してくれるんだろう」という悩みについて触れました．個人的には広報のために本数稼ぐみたいな話は，果たして開発工数を割いてまでやる価値があるのかな，と疑問ではあります．
もし，そうではなくて，エンジニア勢の現在地の確認や成長のきっかけとして，ブログや登壇という手段を使うという話であれば，多少工数を割くことについては前向きです．社内ドキュメントの整備のスキルを鍛えるなどの意味でブログを書いてもらうのはいいでしょうし，プロジェクト報告のスキルを鍛えるなどの意味で登壇をしてもらうのはいいでしょう．
この前提を先に伝えておかないと，どうしてこの手段を選んだのか伝わらない気がしたので，わざわざ書いておきました．
アウトプットに至るまでの壁
細かいことをいうともっといろいろある気はしますが，概ねこのあたりの壁でつまづいていると思います．
表現（言語化・図式化）の壁
構造化（取捨選択，関係の理解）の壁
感情面の折り合い（作業に至るまで，表現を公開するまで）の壁
調査（情報の正確性，社外秘情報の点検）の壁
体裁（文法，言葉遣い，見やすさ，アクセシビリティ）の壁
もちろん，インプットにだって壁がたくさんありますが，アウトプットと比較して手軽に取り組みやすいことから，先ほどは触れませんでした．
表現（言語化・図式化）の壁
インプットの際は先方が形式を定めてきているため，その形式に沿ってがんばって理解するところから始まります．テキストなら読み，音声なら聴き，映像なら見て，雰囲気なら感じて…… 尤もこれらは複合的に組み合わさったコンテンツなので，得意不得意によってどこが色濃くインプットされるかは人によります．とはいえ基本，コンテンツ側で最も分厚く表現してきているところを中心に理解を進めるはずです．
一方，アウトプットについては自分の手癖で行こうと思っても，その方法とアウトプットしたい事柄が合致していなくて，そうもいかないことがままあります．例えば，順序立てて先に説明したことを踏まえて伝えるのなら，テキストや画像を選びたくなるはずです．
一方，音声で話すだけだと情報を遡りにくく，目に見える形で構造を理解させるのに向きません．それなら，テキストや画像などの遡りやすく目に見える形式を選んだほうが，より伝わるのではないかという期待が高まります．この伝わるだろうという気持ちが，完成させるモチベーションに直結します．
ここで，ブログという表現方法に立ち返ると，挿絵を使ったとしても，やはりベースはテキストになります．そうなるとどうしてもテキストのアウトプットに苦手意識のある人は筆が進みません．それに実は，テキストでのインプットも苦手な人であれば，やはりテキストでのアウトプットは厳しいように思います．自分にとっていいテキストコンテンツのモデルがないわけですから，真似さえもできず困る，ということが起きがちです．
この場合，テキストでアウトプットさせることに拘らず，音声や動画の形式で口頭でやってもらうとか，そもそも言葉自体が苦手ならスライド形式で図を中心にしてもらうとか，別形式でのアウトプットを OK にして，アウトプットそのもののハードルを下げる方向で調整するのがよいでしょう．
次の記事内容の是非や信憑性については各々検証してもらうこととして，参考までに，少し前に話題になった「ビジュアル・シンカー」と呼ばれる人たちの話が書かれた本についての記事を載せておきます．
とにかく脳内に漂う情報を捕まえて，文字にしたり絵にしたり音にしたりして，別の形にすることが肝要です．これは，新・SECIモデルでいうところの「表出化」という段階の最初の最初にやるべき作業です．
最終的にブログだから文章で〜〜〜，とか，正確に図に起こさないといけないから CAD で〜〜〜，とか，そういうことを言い出すと，そもそも最終成果物に向けて組み立てる材料すら表出化されないまま，浮かんでは消え浮かんでは消えを繰り返してしまうので，まずなんでもいいから書いたり，喋ったりして頭の中から引き出します．なんなら毎週雑談するとかでもいいでしょう．
一応書いておくと，頭の中にあるものを文字や図，音声にすることと，情報として伝わるように組み立てることは工程も能力も別です．これができないから取り組めないな，と諦めてしまわないことが肝要です．
構造化（取捨選択，関係の理解）の壁
自分が書いた他のブログでも触れていますが，論理構造がわからんとどうしようもありません．単なる情報の羅列では読んでもかなりの部分を補う必要があり，そこに解釈の余地が生まれます．そのせいで伝わることがブレてしまい，伝えたいことがまっすぐ伝わりません．
まずは伝えたい事柄に対して必要な情報を揃える，次にそれぞれの関係を整理整頓して論理構造を組み立てる．この二段階の情報整理作業が難しいと，伝えたいことはあるけれど，うまく伝えられないと悩むことになります．
先のブログに書いたとおり，論証図を起こして自身の伝えたいことがどんな要素に支えられ，どういった組み合わせで説得力を持っていくのか，自分自身でよく把握することが大事です．またこの論証図は，論理的な説明で説得するとき以外でも，感想等の思っただけの情報整理にも使える手法ですから，おすすめです．
またもう一点大事なのは，取り扱う話題や事柄に対して適切な論理構造がどれか，ということにも思いを馳せられると，なんだかしっくりこなくてお蔵入り…… なんてことも減るのではないでしょうか．
例えば，手早い説得を期待するなら，結論を先に書いて説明を書くことになるでしょうし，幅広な背景と無限の正解から一つを選び取ったということを伝えたければ，背景を記載してからの両論併記で進めないとスタート時に読み手の内側にバイアスを作ってしまうため，同じ土俵でのフラットな議論が成り立ちません．
これは，「論理的思考」の文化的基盤（岩波書店）という本で触れられていることだと，こちらの動画でも紹介がありますので，リンクしておきます．
感情面の折り合い（作業に至るまで，表現を公開するまで）の壁
「ブログ書いた方がいいのはわかってるんだけど仕事が……」
「まだキリが良くないから記事を書いてる場合じゃない」
「こんな内容を記事にしたところでどうしようもない」
などなど，書き始める段階でも，書いている途中でもこうした邪念によって断念してしまうことがあるでしょう．こうした気持ちが挟まってこないように事前にガードを決めるとスッキリします．
１つめのガードは「理由を明確にする」．「アウトプットして〇〇さんに見せないとダメだから」とかそれくらいの制約でいいと思います．これは若干，荒療治ではありますが，何にも出てこないことに比較して，完成度がどうであれ出てくることそのものを認めて，アウトプットの第一段階を引き出すやり方です．
２つめのガードは「タイミングを決める」．「ここらあたりで区切りをつけておきたいから」という成果物の粒度をコントロールすることを前提にこまめに区切りをつける感じをイメージしています．
区切りがいいからドキュメント化，せっかくなのでブログ化，といった流れがイメージされます．これを逆手にとって，ブログを書いたら区切りとする，みたいな逆転の発想でリズムを作るのもいいかもしれません．
ポイントとしては「言い訳をゆるす」ことかなと思います．内容について自信がないからアウトプットできていなかったところに，無理やり期限を設定して，納得していないかもしれないけどアウトプットできた，という一点だけに集中することが大事だと思います．
特定の曜日にとりあえずやることにしてある例を載せておきます．ちょっと connpass 上ではサボりがちですが Discord で継続している「力強くアウトプットする日」です．隔週金曜日はブログを書く日として，Discord 上にお知らせが流れ，ブログを書きましょうという取り組みです．
３つめのガードは「はじめに想像した最終成果物の姿は忘れる」．"表現（言語化・図式化）の壁" のところでも触れましたが，ドキュメントや設計図などの最終完成"型"は最初の段階では一旦忘れてしまった方がいいです．最終型がイメージできてしまうと，情報を出す段階で，この型式だと使わない情報だから…… と勝手に材料を吐き出す前にフィルタしてしまって，後々足りないなんてことが起きがちです．
そうすると，書き切る直前とか中間の時点でもう一度，情報整理が必要になって，それまで書いてきたテキストがおじゃんになるパターンもあります．このやってきたことが無駄になる感覚がかなり厳しくて，できる限りあたりをつけてから文章を書き始めたほうがストレスは少ないです．
ポイントは "型" を忘れることです．情報が出揃って，どういう整理になると嬉しいかということを考えて，ようやくはじめて合う型がわかります．情報が出揃っていない中でこうかなと思った型がフィットするとも限らないので，それならいっそ捨てちゃったほうがいいよねという話です．
じゃあ，情報出しのときの型にもベストがあるんじゃないか，という気持ちが湧いてきます．その感覚は合っていて，時系列に思い出しながら文章でいくのか，ある事柄に関係する度合いから同心円上に書き出していくのかとか，いろいろあるんだと思います．
ただやはり，気にしていると進まないと思います．繰り返しになりますが，情報出しの段階は逆に，表出化するのにストレスの小さい型を思いついた順に渡り歩いて，とにかく量を担保しましょう．
4 つめのガードは「公開に耐える情報であることを担保してもらう」．これは次のところで触れますので，ここでは割愛します．
調査（情報の正確性，社外秘情報の点検）の壁
技術系のコンテンツとなると単なる感想とは切り離された，正解がひとつだけ存在する情報について記載することも少なくありません．この情報の正確性をどこまで担保できるかが執筆と公開の安心に直結します．
初稿から誤りなしで駆け抜けるのはどんな専門家でも難しいです．実は，誰の目にも明らかな誤りだと思われたとしても，それ自体が誤りであると検証する作業を経ないと確定はできません．直感の違和感だけで断ずることができないことに，執筆の難しさがあるのかなとも思います．
このあたりは事実なのか，解釈なのか，一般的に言われていることなのか，あくまでも個人の主張なのかなど，情報の性質がわかるような書き方を心がけた上で，それぞれの背景や根拠が書かれているか，読み取れるか，書かれていなくても参考文献として根拠が示されているかなどを，点検していくことになります．これである程度は安心して公開できるかと思います．
可能であれば信頼できる数人からレビューをもらって，読みときにくいところを指摘してもらったり，技術情報に誤りがあるかなどを検証してもらうのもいいことだと思います．不特定多数に公開する前に小さい範囲に見せて，修正するチャンスを手にいれると安心が一つ増えるはずです．
また，社外秘情報であるか否かについての判断も同じように，コンテンツ公開時に心理的安全を脅かす要素かと思います．このあたりは会社ごとにレビューの仕組みを持っていて，インシデント発生を防御するように仕組みができていると思います．もしそうした仕組みがないのであれば，自発的にレビューを頼んでインシデント発生を抑止していくべきでしょう．
もしかするとこのあたり，社内に使用を許されている AI が整備されているのであれば， AI に読ませて誤りを指摘させるなどの動きをとるといいかもしれません．まあ，彼らの言うことを信じられるかは疑問ですが，人と同じで AI の主張が誤っていたとしても追検証のきっかけになりますし，マイナスにはならないでしょう．
体裁（文法，言葉遣い，見やすさ，アクセシビリティ）の壁
たとえば登壇資料の見やすさなんかはプロジェクターで投影した際に，字が潰れないか，コントラストが弱くないかなど，比較的試験もしやすいし，自分自身でも十分に知覚できるので，登壇者から参加者の視点に立つだけで直せることも多いはずです．
ただ，この見やすさ以外の要素は，不特定多数の目に触れるとその数だけ解釈や読み取り，理解の度合いが発生して，意図どおりに伝わったといえる範囲に収まるか否かがばらつきます．究極の理想は，誰が読んでも，見ても，解釈が一つに定まることかなと思いますが，相当な労力を割いてもなかなかそうはいきません．
ただ，幸いなことに機械的に判定できることも増えてきているため，有料無料問わずに，ことばやアクセシビリティについて判定してくれて，指摘してくれるツールもたくさん存在します．当事者からレビューをもらうのもよいですが，ツールで対応できることがあるなら，先に対応してしまう方が手間がかからなくていいかなと思います．
例えば過去使ったものをあげると，校正ツールの Just Right! Pro にはお世話になりました．当時はある新聞社がつかっている標準セットを使って校正にかけていました．これでひらくべき漢字の指摘やだらだら文の指摘など，標準的な日本語の範囲を逸脱したものは修正できます．
また，辞書登録もできるのでたとえば「CSIRT」や「C2サーバー」などの専門用語についてもツールでチェックできます．最近だとそれ用に鍛えられた ChatGPT なんかで対応できそうな気もします．
ほかにも色覚異常が原因で情報が伝わらないと問題なので，グレースケールで判別可能な資料をつくるなど，色に依らない情報表現を考えていました．当時は学校現場だったので，輪転機での印刷を意識した資料作成だったこともあり，色を使う方向でのツール選定はしていませんでした．
アクセシビリティ関連については，さまざまなサイトで情報がまとめられているようなので，ここではひとつ例を挙げておきます．
断っておくと自分もブログや登壇資料ではここまできちんとできていません．このあたりのいい加減さを直したいなと思いながらできていないのは，まだまだ仕組み化できていないことのあらわれなんだと思います．
じゃあここに書いたのは何なんですかというと，過去，授業資料や研修資料を作るとき，学生や生徒に紹介するときに意識して確かめていたときに使っていたツールや手法をメモしています．学校のような直接やりとりできる相手に提供するという責任感といいますか，不特定多数を相手にしているのとは違う緊張感で手が動いていたのかもしれないなと思いました．
アウトプット施策の一例
「完成度 1 % 未満の LT を見せつける会」という枠組みを紹介します．これをベースに，サイボウズ社内では Garoon チームの「完成度低いの歓迎LT大会」を皮切りに QA コミュニティや kintone チームなどでアレンジを含みつつ横展開された枠組みです．
表現（言語化・図式化）の壁
スライドをはじめとした資料を必須としない
構造化（取捨選択，関係の理解）の壁
しっかり説明できなくても話したいことなら OK
感情面の折り合い（作業に至るまで，表現を公開するまで）の壁
完成度低いことが得点になる世界なのでミスは存在しない
調査（情報の正確性，社外秘情報の点検）の壁
社内限定かつ感想共有のレベルなので情報発信の責任が軽い
体裁（文法，言葉遣い，見やすさ，アクセシビリティ）の壁
チーム内での普段のコミュニケーションと同じでよい
と，このような形でこれらの壁を取っ払う設計になっており，アウトプットする側のハードルはだいぶ下がっているのかなと思います．もちろん LT 会を運営する人が存在するため，運営の壁がありますが，そこはアウトプットする人の壁ではないのでここでは考慮しません．
言い訳をどう味方につけて習慣をつくるか
インプットにしても，アウトプットにしても，言い訳が敵になって進まないことが多いのではないでしょうか．「自分は詳しくないからできません」「工数を確保できないのでやれません」「優先度が低いからやりません」などなど，のっぴきならない理由もあるのかもしれませんが，このあたりの理由は多いのではないでしょうか．
であれば，同じ言い訳でどうにかやってもらえるように仕組み側を工夫するほかありません．「自分は詳しくないから "これだけです"」「工数を確保できないので "10 分でできる簡単なのもので"」「優先度が低いから "雑談レベルで"」とか何でもいいのですが，ある一定の質を超えないなら意味はない，という風潮自体を払拭していく必要があります．
読み書きそろばんじゃないですが，一週間に 10 分でもブログを読む習慣ができれば，他社の取り組みを知るきっかけにもなりますし，そもそもテキストを読み解く力がつくはずです．二週間に一回でもブログを書く機会があれば，テキストや図でまとめる能力が少しずつついていくはずです．
ある質を超えないからといってやらずにいれば，一週間に 10 分程度しかやっていない人たちに，いつの間にか大きな差をつけられてしまうことも想像に難くありません．一年は 52 週あるわけですからね．いわゆるつよつよエンジニアはこれが自分一人でできるから強いのです．彼らからすれば，集団でやる意味もないし，わざわざ制約をつけて言い訳をしながら低い質でやる理由もないので，受け入れられないかもしれませんが，ベースアップをねらうならこのレベルからなのです．
自分が考えた「完成度 1 %未満の LT を見せつける会」も「テックブログ一気読み選手権」も日常的にできている人からすれば馬鹿らしいのは百も承知です．しかし，自力でその境地に辿り着くことができずに，突然難しいことに手をつけて挫折してしまう人や，いきなり強い人たちの真似をしようとしてできない自分に自信を失ってしまう人もいるのです．
開発組織の地の力を高めるためには，こうしたあたりまえを思われているところからきっちり確認していく必要があります．もちろん，個人の資質をひとりで確かめる意味でもこのアプローチは有効で，何も組織に所属している人だけが恩恵を受けることではありません．
もちろん，全体のレベルが上がってきたらこれ以外の形にするとか，取り扱う範囲の情報をもう一歩だけ難しいものにするとか，それぞれが学びのメンテナンスをしていくことは不可欠です．これは筋トレというよりかはストレッチにあたる取り組みですから，取り組みの立ち位置を忘れないことも重要かと思われます．
以上，開運まつり当日の OST で触れた，インプットとアウトプットに関する習慣化と成長についての話でした．
【余談】 毎年している話にも含まれていました
いろいろ書いたんですが，実はこのへんの話ってサイボウズの開運新人研修で自分が担当している座学でだいたい触れてる気がします．入社したてという前提に立っている分，その色付けがあるけれども言ってることの大筋は大体一緒だと思います．