2時に寝て7時に起きた。タスクが全然消化できなくてしんどい。ただ燃え尽き症候群は落ち着いて次に向けての気力が出てきた。

神戸お土産探し

3年ぶりに出張が増えそうなので神戸のお土産探しも始めようと思う。今回は リッチフィールド さんのバウムクーヘンと丹波みるく黒豆萬をもっていく。オンラインで注文すると取り寄せに1週間かかる。ちょうど発注するときのタイミングが悪くて間に合わない。店頭受け取りだとそのリードタイムが4日になる。明石駅に店舗があったので電車に乗って朝9時から受け取りに行ってきた。電車の待ち時間を含めて往復で約1時間で受け取れる。もっていくお土産は自分がおいしいと思うものをもっていきたいという考えもあって単品でも購入して食べてみた。バウムクーヘンはしっとりした食感で普通においしい。プレーンよりも黒糖の方が風味の自己主張が強いという特徴があって私は好きかな。丹波みるく黒豆萬は濃厚なミルク餡で丁寧で上品なお菓子という印象を受けた。甘いのが苦手な人はややしつこいかもしれないけど、普通においしいと思う。黒豆がちょこんとのっているのが他の乳菓子との差別化かな。(なんの認定にもならないが) 私の審査は軽く通るお土産だとわかった。

開発者として効果的に伝える方法

関心のあるタイトルをタイムラインでみかけたので読んでみた。

• How to communicate effectively as a developer

期待したほど私にとって参考になることが書いてあったわけではないけれど、読んでみて参考になることはいくつかあった。著者は「効果的に伝えることを共感的に文章の解像度を高めること」と定義している。私の周りでもエンジニアリングの文脈で解像度の高低というキーワードをよく聞く。一方で共感というキーワードを私は意識していなかったのでこれは素直に参考になった。読み手を想像してその人が共感できるように書くことの重要性に言及している。empathically=「共感して、親身になって」という意味だから日本語らしく訳すと相手の気持ちに寄り添って書くとか、相手のために親身になって書くとか、それ自体はよいことのように思える。高解像度、且つ共感性の高い文章を書くことは労力を要するものの、次のことから win-win-win だと著者は表現している。

• 読者はより深く理解し、レベルアップする
• 組織は知識の共有が進み生産性が向上する
• 自分の考えを伝えるのが上手になり、キャリアアップにつながる

いまとなっては後の祭りではあるが、私がいまの3倍速く巧く文章を書ければたしかにもっとキャリアップできていた気がする。書こうと思いながら筆が進まずに断念した文章はいくつもある。最後の結びの言葉も気に入った。

自分が相手の立場なら喜んで読んでくれるような文章を書きましょう。

課題管理の勉強会の資料作り

来週の出張で使うかもしれない課題管理の勉強会向けの資料の叩き台を作った。過去の資料を見返しながらスライドを作り直していた。過去に資料を作ったときは納得して作ったものを、いま見返すと誤解している箇所があったり、あまり重要とは思えなかったり、当たり前の話しだけど、スライドやドキュメントも時間が経って見返すと粗が目立つようになる。こういうとき私は自分を信じないと再確認できて慢心せずにすむ。常に課題管理システムに日々の学んだこと、考えたことを書き続け、チケットの構成を整理し直したり、チケットとチケットの関連を結びつけたりしているうちに過ちや無知に気付くきっかけになる。この暗黙知をいつか形式知として言語化できるようになりたい。

23時に寝て1時に起きて2時間ほどだらだらしてて6時に起きた。

最後のふりかえりイベント

最終週なのでこのチームでのスプリントのふりかえりは今日が最後になる。メンバーが気を遣ってくれてこれまでの活動に感謝を伝えてくれた。いくつか出たコメントをあげる。

• インフラを整備した
• チケット駆動開発の基礎を伝えた
  • 課題管理のよさもわかってきた
  • メンバーが課題管理を行う習慣化につながった
• 社内でもっとも backlog を使いこなしているチームになった

1年に渡って開発に参加して課題管理を見守ってきたので課題管理とは何ぞやの基礎をメンバーの大半は理解できるようになったと思う。(私からみて) ワークフローを洗練させるという視点で現状の運用は入門レベルではあるけれど、根っこの部分をちゃんと理解できているメンバーもちらほらみえてきたのであとは時間とともに上達していくのではないかと思う。このままもう2-3年取り組めばスクラムに頼らなくても高い生産性と迅速な情報共有ができるチームになるかもしれない。1年前はチームで課題管理がほとんどできていなかったのに、いまは大半のメンバーがやろうとするようになった。他のメンバーの行動を変えられたのが私としても嬉しい。いくつかの組織やチームで何度もやってきたことなので半年から1年あればできるというのは一定の信頼がおけて自信ももっている。今後の私の課題としてはこれを3ヶ月で達成する、1ヶ月で達成するための体系化やリーダーシップを作り上げていくことが考えられる。

hannali dao 始動

Hannali DAO に参加した。Metaアカウントへの移行(Workrooms向け) によると、2022年8月30日以降は meta アカウントではないと workrooms にアクセスできないらしい。ここ2-3ヶ月 workrooms を使っていなかったのでまとめてシステムのアップグレードや meta アカウントの移行なども行った。まったく難しくなくて手順通り作業を進めればアップグレード作業も含めて1時間もあれば完了するぐらいの作業量。当初は workrooms で開催する予定だったが、諸事情あって zoom 開催になった。とはいえ metamask の設定などをいろいろやっていたので結果的に zoom でよかった。

おがわさんが作った dao で利用できる PROG という名前のカスタムトークンをメンバーに配って受け取る。受け取る方も metamask で wallet と接続しないと受け取れない。polygonscan というサイトで自分のアドレスへの polygon ネットワークのトランザクションを次の uri で確認できる。PROG というカスタムトークンを 50 受領しているのがわかる。

• https://polygonscan.com/token/0x14e1bd8689c150509a14db70b2d8c8cd33747cdf?a=0xe1688b4b017ae362261f14415cc0db72b8b53e10

これだけのことをやるのにまったく作業の勘どころが働かなくてみんな四苦八苦していた。たったこれだけを2時間ぐらい。その後、dao や世の中の事例について雑談。お互いの情報共有になっておもしろかった。私は web3 関連に技術体系には否定的なスタンスを取る方だけど、技術そのものを否定しているわけではなく、なにかしら価値はあると考えているのでどういった用途に使うのがよいのかを探りたいという思いがある。最後にそれぞれのメンバーがもっている PROG トークンの比率に応じて投票権をもつ。みんなの投票結果を使って次の開催日を決めてみた。本当の投票は手数料がかかるトークンを使ったアプリになるのだろうけど、このアプリは手数料なしで使えるらしい。

• 次のDAO イベントいつやる？

0時に寝て、2時、3時、5時に起きて7時に起きた。夜中何回も起きる。

データ移行スクリプト

あるテーブル間のデータ移行のために久しぶりに python のスクリプトを書いた。python の文法を忘れるぐらい最近は書かなくなってしまっていた。1時間ほど書いていると興がのってきてそれなりに書けた。書いていれば体が覚えているので自然に動く的な。dump データ (insert 文) から json 文字列を含むデータを移行しないといけなかった。json 文字列を1つのカラムの値としてパースするのが思ったより難しかった。とはいえ python だとこういう煩雑な文字列操作は得意なので1-2時間で実装して移行作業を完了できた。

SECI モデルのワークショップ

たまたま twitter でフォローされたアカウントのタイムラインでみかけた ゲームで体感！SECIモデル～チームビルディングの瞬間に迫る！～ に参加した。SECI モデルとは野中郁次郎氏と竹内弘高氏の論文で提唱された知識創造のフレームワークの1つ。私は実践知の本で知って、スクラム本でも紹介されていたのでよく覚えていた。

• アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

暗黙知と形式知がぐるぐるまわるんだよという頭だけで理解していて、違和感もなかったし、普通に理解していたつもりだった。SECI モデルを学ぶことを意識したワークショップに実際に参加してみると、知識で理解していた概念と実際に行動 (ワークショップを通してチームで学ぶ) を通して得たフィードバックのようなものがあって、参加前の私は SECI モデルを誤解していたことにも気付いた。単純に知識創造だけのことを言っているわけではなく、チームビルディングや人間関係も知識創造には影響を与えている。私が他人にあまり関心をもたない人間だから人間関係や多様性が知識創造にどういった影響を与えるかを軽視していたと思う。

このワークショップは有償なのもあるだろうけど、2時間で SECI モデルとチームビルディングを組み合わせた要点が学べるようによく練られたものになっていたと思う。チームビルディングの3要素として、目的・関係性・多様性をあげていた。SECI モデルは個人、チーム、組織、環境の集合の要素としてモデル化されていた。個人よりも大きい集合 (チーム、組織) の重要性を私は軽視していたから気付きが多かったという話し。SECI モデルで提唱されていることは、多寡はあっても開発者は普段の業務で普通にやっている。受講後に SECI モデルで実践していることをよりエンパワーメントする仕組みを課題管理もしくは課題管理システムの文脈でできないだろうかと考えたりもしていた。ふらっと参加したのに私にとって気付きが多かったのでこのワークショップを運営しているコミュニティのイベントに今後も継続的に参加してみようと思う。

0時に寝て2時、3時と起きて5時に起きた。最近は夜に寝ているのか起きているのか、自分で分からなくなってきた。7時過ぎにはオフィスに着いてた。

サービス残業

今日は非稼働日なんだけど、半日ぐらいは開発していた。大掛かりなリファクタリングをするので今日中に主な修正をテスト環境にデプロイしておきたかった。スプリントが水曜日始まりの1週間なので運用に影響がありそうな大掛かりな機能追加やリファクタリングは金曜日中にはテスト環境へデプロイするように私はしている。そうすると、月・火で他のメンバーがテスト環境を触るのでリグレッションがあればバグをみつけやすくなる。さらにお小言を書くと、他の開発メンバーはこういう感覚がまったくない。大きな変更を伴うコミットを火曜日に普通にしようとする。「明日リリースですが、これをマージしてしまって検証できますか？」というツッコミを私が過去に何度もしている。大半は無理だと次スプリントへ持ち越しになる。残業しない開発者はタスクがスプリントをまたぐことになるので見た目以上のロスがある。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつも9時から雑談しているけれど、今日はお互いに歯医者があって15時に変更した。直近のお仕事探しの近況から情報共有をした。いまのところ、3社の選考が進んでいて、私の中の優先順位も明確になっていて、あとは実際に契約を締結するまでもっていけるか。ほんの2週間前までお仕事探しの書類審査すら通らない状況だった。最悪のケースとして11月からしばらくお休みすることも想定していた。現時点では3社もあればどこかに決まるだろうという楽観的な展望をもっている。

ある案件で react から next.js への移行の目的が seo 対策だという話しをしてたら、google のクローラーは spa アプリケーションも扱えるけれど、twitter, facebook のクローラーが全然ダメらしくて sns で記事をシェアするときにプレビューをきれいにみせたいといったときに課題があったりするらしい。spa の後にまた ssr (server-side rendering) やるというのは本当にあほみたいなことをやっていると私からは思えてしまう。

あと私はもうスクラムの議論には関心がなくなってしまった。昨日の日記にも少し書いた。いまは組織を変えられるかどうかに関心をもっていて、よいプロダクトにはよい開発文化が必要だ。そこで「よい開発文化」とはなにかを体系化しないといけない。そのうちの1つとして書くことをこれまで訴求してきた。その後もずっと考え続けてきて私の中では次の3本柱でいこうと決めた。

• 書くこと
• ワークフロー改善
• 実践知リーダーシップ

いまはまだキーワードだけでその意図する具体的な内容は私の頭の中にしかない。この3つを軸に私のスキルと経験を詰め込んだ製品開発をしていく。

23時に寝て2時に起きてその後どうしていたかあまり覚えていないが気付いたら8時だった。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も全然ストレッチできなかったのになぜか数値はよくなっていた。ストレッチを受けていて調子の悪さも感じなかったので気候が過ごしやすくなってきて体調がよくなった結果として普段の生活における活動量や新陳代謝などにも影響を与えているのかもしれない。トレーナーさんからは涼しくなったのだから運動をしてくださいと言われた。ほんとその通り。

知識と経験

• You’re Not a Senior Software Engineer

たまたま目を通した medium のおすすめ記事に出ていて、タイトルにひかれて斜め読みしたらおもしろかったので後で deepl を使って精読した。最近は英語の記事を deepl で訳して読んでいる。まず deepl で全訳した後に文脈から訳文の意味をとれなかったり、明らかにおかしいところだけを手直しする。著作権的に機械翻訳を公開はできないため、その翻訳内容は課題管理システムのイシューで管理している。この記事だと手直し数回ぐらいで大意を読める。普段、英語の記事を日本語アカウントで紹介することはないんだけど、これは素晴らしい内容だったのでそのまま共有することにした。軽く所感も書いてあるが、課題管理システムのイシューにはさらに詳細な分析やコメントも残している。

知識とはやり方を知っていることで、経験とはやってはいけないことを知っていること。素晴らしい記事だった。 / You’re Not a Senior Software Engineer by @repsofsunshine https://t.co/3qitFOFTJp

— Tetsuya Morimoto (@t2y) September 10, 2022

多くの若いチームでは課題管理の重要性を理解していない。その無理解の原因の1つとして、ものごとを検討したり判断したりした時点では正しかったことが未来のある時点で誤りになってしまう可能性を想像できないからだと私は考えている。記憶と忘却の仕組みから前日のことですら半分以上忘れてしまうので数ヶ月前の詳細など、ほとんどの人は覚えていない。にも関わらず、日々の小さい判断の積み重ねや意思決定の履歴を記録として残さないのはなぜだろうか？それはその詳細があとで重要になるかどうか、多くのケースでその発生時点ではわからないからだ。例えば、システムのアーキテクチャに関して言えば Architectural Decision Records (ADRs) というドキュメントが提唱されている。アーキテクチャのような大きなものでさえ、明示的に残さないと経緯がわからなくなるのに、もっと小さい粒度である日々の開発や運用の誤りを、一般の (普通の) 開発者がその発生時点から数ヶ月や数年経ってふりかえって見直すことができるだろうか？いやできないというのが、多くのチームやメンバーをみてきた私の所感だ。多くのメンバーは過去のある時点の見逃しや判断ミスをなかったことにしようとする。それは無意識にしろ意識的にしろ起きやすい。客観的に詳細を確認できればなかったことになってしまうのは仕方のないことでもある。

私は課題管理システムのコメントに、こういう状況からこう判断したとか、誰それと相談してこういう事情でそうしたとか、自身の感覚からとくに意味もなく決めたとか、常々なぜに相当する内容を残している。そして、あるとき過去の経緯を見返して、そのときの判断は適切だったか、過去のある時点で気付けたはずのことを見逃してなかったか、見逃していたとすればどうすればその時に気付きを得られたか、というふりかえりを日常的なチケット整理の一環として実践している。件の medium の記事にはなぜそれが重要なのかの概念を書いてあるように私には受け取れた。課題管理 + 情報共有の需要な概念の1つだと認識して寝かせておこうと思う。

2時に寝て6時に起きた。疲れていたからよく眠れた。

mvp（minimum viable product）で対応した

スクラムに限った話しではないと思うが、プロダクト開発をしていると mvp（minimum viable product）という言葉を聞くことがままある。昔ながらのイテレーション開発よりも、アジャイル開発の文脈でよく使われるように思う。というのは、短い開発期間でプロトタイプを作ったり、最低限の動く機能を作ったりすることをよしとする考え方があるから。昔ながらのやり方だと、イテレーション期間の中でそういった段階的な開発はするものの、外部からみたとき (もしくはマイルストーン) においてはそこそこの機能が提供されているので mvp といった言い方をすることはなかった。もしかしたらアルファとかベータとか呼んでいたかもしれない。最近ある lambda 関数の移行作業を行った。serverless framework でデプロイしていたリソースを cdk で一元管理する。その過程で既存のコードを読むと、ある id をハードコーディングで指定して FIXME がこんな感じに書いてあった。この id が指すリソースはその後なくなっており、本番環境で不要な処理が定期実行でずっと動き続けていたのと、本来は複数の id リソースに対して行うべき処理を実行していなかった。

# FIXME 対象 id 一覧を取得する。(Phase2までに対応します)
id = 'ABC001'

チームの開発リーダーはその存在を全く忘れていたし、このスクリプトを実装したさらに上位の開発リーダーからはこの処理の要否はよくわからないからチームで確認してという曖昧な返事が返ってきた。チームで確認したところ、この処理は必要だとわかり、この機に複数の id リソースに対して対応するようにした。何も知らない私が修正しても5分で対応を完了した。

mvp で対応したんで

このように実装者は話していたが、本当なのだろうか？と思えた。さらにこのスクリプトのエラーログのログストリームを監視して slack 通知する lambda 関数も移行対象で、コードの検証をしていたところ、slack 通知をするための lambda 関数が別途あり、その動作検証をしていたところ、その lambda 関数を呼び出す権限 lambda:InvokeFunction が足りないことに気付いた。これも実装者に問い合わせたところ、動作検証はやっていないし、過去に1度も slack 通知は発生していないという。状況証拠から考えると、権限が足りないために正常に動作していなかったと推測される。結果的に mvp で対応したという2つの lambda 関数は実運用で半年間、無駄にリソースを浪費して何の役にも立っていなかった。当然、引き継ぎも、課題管理システムのチケットも、ドキュメントも何ら残されていなかった。mvp で対応したという表現に開発で大事なものを誤魔化してはいないだろうか。

0時に寝て7時に起きた。祝日なので朝は掃除したり洗濯したりしてた。

yuga labs は未来の gafa かもしれないらしい

中島聡氏が voicy を始められたのでたまに聴いている。とくに web3 関連の信頼できる情報源として聴いている。

• 僕らはweb3時代のGAFAの誕生を目撃しているのか？

氏は yuga labs は技術というよりはマーケティングの会社だと言いながら、どういうマーケティング施策でいまのような人気企業になったかを簡潔に説明されていた。yuga labs という会社名だけは知っていたが、どういう会社かはまったく知らなかったので私は勉強になった。yuga labs のやっていることは中長期でみればポンジ・スキームだと指摘しつつも、その胡散臭さを上回る優れたマーケティング施策で注目を集めているという。yuga labs が手がける nft やメタバースや暗号資産なども高騰していて、実際にそのマーケティング施策で億り人になった人たちも数千人規模で出ていて、今後の動向に期待が集まっているらしい。シリコンバレーのトップレベルの vc も資金を投入しているので vc の思惑からも次の gafa のような期待感があると受け取ることもできるらしい。yuga labs が手がけるメタバースプロジェクトの土地売買で起こった事件なども紹介されていた。あとは2-3年はこういったバブルが続くのかなぁ。

• Yuga Labs、仮想不動産NFT販売で3.2億ドル相当獲得　“ガス代急騰”の影響に謝罪

頭の中の最上位にあるアイデア

たまたまタイムラインでポール・グレアムの 頭の中の最上位にあるアイデア というエッセイを知った。ざっと斜め読みして、私の経験や価値観にも合致する内容だったので印象に残って後から精読した。

学生の頃、原付きの整備士のアルバイトをしていた。そのバイク屋の社長はアウトローな人生を歩んできた方で、私は破天荒な社長の生き様が好きでよく話を聞いて感心していた。あるとき草津から彦根までバイクを届ける遠出の運搬作業があって、トラックで社長と2人で出掛けたことがあった。雨降りの日だった。私は助手席で社長の話し相手をしていただけだったんだが、こんな話しをされた。

若い頃に5年働いてようやく100万円の貯金ができた。すでに妻子もいた。そのときに友だちに騙されて1500万円の借金を背負った。5年働いて100万円しか貯金できなかったのだから、もう人生終わりだと思って、自分を騙したその友だちを殺して自殺しようと思った。しかし、母親に諭されてその友だちを殺すことは思い留め、それから死ぬ気で働いたら2年で1500万円の借金をすべて返すことができた。

社長がどうやって借金を返したかの詳細は知らないし、相当の苦労や無理をしたことには変わらないだろう。そのときに続けて社長が言ったことはこんなことだった。

24時間365日、お金儲けのことばかり考え続けていたらなんか思いつくものなんや

ポール・グレアムのエッセイを読んで社長はこのことを言ってたんだなといま思い返した。私も何度かそういう機会を経験していて、全くわからない難しい問題に直面したとき、納期や品質を担保できそうにないプロジェクトを担当しているとき、課題に着手し始めたときの本音は無理やと思いつつも、どうやったらうまくいくかというのをずっと考え続けているうちに、難しい問題の解決方法がわかってしまったり、トラブルプロジェクトでもそれなりにうまくまわったりした。

いまは課題管理をどうやってビジネスとしてマネタイズ化するかを常に考えている。たまにアイディアがふっと湧いて、その内容を課題管理システムに起票したり、既存チケットのコメントに書き込んだりする。平均すると、1-2週間に1回ぐらいのコメントなんだけど、これを1年ほど続けているというのがいまの状態だ。これを2年3年と続ければ、ビジネスのアイディアが溜まることを経験的に理解しているからいまもずっと課題管理について考え続けている。

昨日は0時過ぎまでオンライン飲み会で雑談していて、それから1時に寝て6時過ぎに起きた。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後162cmだった。今週はインフラエンジニアを始め、深夜と早朝に作業するため、生活が不規則になってしまった。そのせいか、腰と右股関節の張りが強いように感じた。1日は散歩に行ったり、深夜に一駅離れたスーパーに買いものに行ったり、すこし運動っぽいことも生活に取り入れるようにはしている。今週疲弊した身体をストレッチでほぐせたのでまた一週間がんばろうという気持ちになった。

インフラ作業

昨日からの仕掛り中の作業をテスト環境に反映させた。昼間は環境を壊してしまうとテストや検証作業を止めてしまうリスクがあるため、開発者や業務の人たちが使っていない時間を見計らって環境変更の反映や cdk の検証などをやりたい。必然的に土日も都合がよくて気付いたら2時間半ほど作業してた。

開発が遅れる空気

私は勘と経験で納期の1-2ヶ月前に開発が完了しないとわかるときがある。これまでなぜわかるのか自分でもよくわかっていなかった。便宜上「遅れる空気を読む」とでも言おう。私だけわかっても他者に伝えられない、もしくは伝えても無視されることが多かったので必要以上に指摘しないようにはしている。伝えて意図がわからない人たちにそれ以上言っても無駄だから。なにかしら条件があるのではないかと思い当たるところを書き出してみる。

• チームメンバー (開発者) にタスクが遅れているという認識がない
  • 経験が浅いと見積もりの精度が低いため、全体像に対する進捗を正確に把握できない
  • シニア開発者がアドバイスしてもその内容を理解できなくて役に立たないこともある
• 遅れている開発者が遅れを取り戻すための施策 (たとえば残業) をしない
  • 認識していないために残業しないから当然に遅れる
  • 認識していても残業を嫌う開発者は一切残業しない
• 未知の問題や状況に対して「わからない」「困っている」といった報告をあげられない
  • 心理的安全性が低いと、無能だと思われたくなくて開発者が助けを求められない
• マネージャーやリーダーといったスケジュール管理に影響力のある担当者が上位の意思決定者に事実ではなく自身の解釈を述べる
  • 例「このタスクは8割程度完了していて、あともう少しで終わりそうです」
    • 遅れているタスクはこういう報告が何度もあがる
    • 「いつ完了しますか？」と尋ねると予定日時を回答できない
• マネージャーやリーダーが技術に疎く、実務担当者の言うことをそのまま受け入れる
  • 経験が浅い開発者の見積もり精度は低いため、大きく計画が狂うことがある
  • 私はソースコードを読んだ上でこの実装では品質基準を満たさないと判断したりしている
• 上位の意思決定者と現場のリーダーとの人間関係が希薄だと建前の報告になる
  • 心理的安全性が低いと、現場の機微やもやっとしたことが共有されない

こういう空気を私は読んでいて、あるとき「この開発はもう間に合わないですね。」といきなり上長に言い始める。周りはまだ日程に余裕があるのになぜ？とびっくりする。開発って日々の積み重ねなので、日々の活動が正しい努力になっていないと1-2ヶ月後に成果が出ないというのは私からみたら自明だという話し。

0時に寝て3時に起きた。4時までドラクエタクトしたりもしてたけど、夕方に PoC のデモ打ち合わせがあるのになにも準備できてなくて不安で起きて5時からお仕事してた。久しぶりに早起きしたせいか、打ち合わせ終えたら眠いからすぐに帰って、夜はオンライン飲み会しつつくつろいでいた。

情報共有とコミュニケーションコスト

課題管理システムのことを考えていてふと思いついたことを書き出す。私からみると、多くの人たちは「聞かなくてもわかる」という価値を過小評価しがちである。というのは、その価値を定量化するのは難しいので評価されにくい。そうすると、評価されないことはやらないといった合理的な働き方をすればそうなるのは理解できる。しかし、私はその価値を理解しているので軽く考察してみる。

1. 聞けない
2. 聞けばわかる
3. 聞いてもわからない
4. 聞かないとわからない
5. 聞かなくてもわかる

情報共有の過程でパッと思いつくことを段階ごとに書いてみた。1に近い方が容易で5に近い方が難しいという難易度を表しているとも言えるし、組織の情報共有のレベルを表しているとも言える。少し言葉を補うと次のように解釈してもよいだろう。

1. (メンターが気難しくて/メンターに無能だと思われたくなくて) 聞けない
2. (メンターに余裕があって) 聞けばわかる
3. (メンターのスキル不足で/担当者が退職してて) 聞いてもわからない
4. (背景が文書化されていなくて) 聞かないとわからない
5. (課題管理システムを検索すれば) 聞かなくてもわかる

昔は1のような状況を発生させる人もちょくちょく職場にいた気がするけど、いまは淘汰されてあまりみかけない。多くの組織は3か4ぐらいのレベルだろう。5まで達している組織は少ない。課題管理システムについて議論していると、たまに「知っている人に聞けばいいじゃない？」という意見があがる。この質問をしている時点で目指している働き方のレベルや生産性が大きく異なっていることがわかる。というのは、他人に聞くというのはコミュニケーションコストが非常に高い。これは他人に聞くなと言っているわけではない。他人に聞かないといけないことを減らすことで生産性を上げるという話しをしているだけだ。他者へ同じ情報を伝えるのに1時間の打ち合わせが済むのか、3時間の打ち合わせを要するのかという比較をしている。当然、打ち合わせ時間を減らしても伝えられる情報量が同じであれば打ち合わせ時間は少ない方が望ましい。そういう話しをしている。

5のレベルに達していれば、例えば、いまのシステムの仕様はなぜこのようになっているのか？変更するとしたら影響範囲はどのぐらいか？どういったモジュールに注意して改修すればいいか。もちろん前任者やリーダーに聞けばわかるだろう。聞くために打ち合わせの予定を調整するかもしれない。するとリーダーは忙しくて時間を調整できるのは来週になるという。もし課題管理システムにそういった情報が残っていれば、来週まで待つ必要がなくなる。理想的にはリーダーとの打ち合わせも必要なくなる。リーダーは他に重要な業務に時間を割ける。これが「聞かなくてもわかる」という価値である。

昔はなんらかの理由で1の状態にあった組織において、職場の風通しがよくなると、コミュニケーションコストを軽視しがちになる。職場の風通しがよいことは重要だが、打ち合わせや会議ばかりするようになると、キーパーソンの時間を湯水のように使う。キーパーソンはすぐに会議だらけになって物理的に実務ができなくなって、結果的に生産性や品質が下がる。ここで重要なのは権限委譲だが、この話しは長くなるのでここで筆をおく。