00:01
こんにちは。言語化.fmは、あんな話やこんな話をキリンとダテの2人で緩く話しながら言語化を試みるポッドキャストです。
というわけで、第13回なんですけども、今日のテーマは、自分がいなくてもまわるチーム作りをする難しさを言語化したいです。
よろしくお願いします。
お願いします。難しさもそうだし、大事さみたいな部分もちょっとおしゃべりしたいなと思うんですけど、
このトピックを出したのは僕なんですけど、なんでこれ話したいと思ったかというと、きっかけあったかな。
名人的なきっかけはないけど、2つの経験から思ってて、
1つは、個人への依存が限りなく少なくなったチーム回しみたいなのを、今の働いてる会社のチームでいって実現できてるところがあって、
それめっちゃいいことだよねって思っていて、何が具体的にいいねみたいなのをそんなに整理したことないなっていうのと、
あともう1つは逆パターンで、僕自身の悪い癖でもあるんですけど、いろんな仕事をよくあると思って巻き取りまくったら、
自分がいなくなったら止まるものがいくつかできてしまって、今更剥がすのに苦労したり、
こうなんない方がいいし大事だよねみたいなのを思って、ちょっと腰を背いて話すかと思いました。よろしくお願いします。
なるほどです。よろしくお願いします。
これは何というか、このタイトルを聞いたときに、多分俗人化してないっていうか、チームがチームメンバーだったら誰でもできるようにした。
それが良かったねっていう話と、自分に俗人化してるタスクが履きついてて、自分がいないとお仕事が進まなくなっちゃうっていうふうの側面でそれぞれ話してるような気がするんですけど、
そもそも自分がいなくても回る状態とは何なのかを語ってもらってもよろしいでしょうか。
めちゃくちゃいい質問ですね。
いやー確かに、ちょっと鋭いな、パッと返せないな。
そういうのを言語化するFMだって聞いてるんですけども。
そうです、その通りです。
そうだな、自分がいなくても回ってる状態とは。
なんか、いやー意外とパッと言語化できないのは難しくて。
例えばさ、チームがいっぱいやらなきゃいけないタスクがあって、なんかAからFぐらいまでのタスクがあって、
03:11
それが空いてる人を突っ込めば誰でも処理ができます。
ハッピーですみたいな状態を目指したいのか、
それともなんかもっと単純に自分が何かしらでチョーキ抜けなきゃいけなくなったみたいな、
ちょっと他のチームのタスクやらなきゃいけなくなったみたいな差し込みが飛んできたときでも、
比較的っていうのは相手でサポートに入れるとかそういう話?
そうだね、どっちかっていうと後者の方が個人的にイメージ近いかなと思って、
前者は多分無理だと思うんですよ。
なんかよほど不確実性のない仕事を扱うような職種じゃないと多分無理で、
だから極端な話、LINE工場とかのスタッフは全然回るじゃん、誰がやっても回るけど、
なんかそういうところまで落とすのは無理かなと思ってて、ってなると後者かなと思ってて、
で、塩梅としてはこれなんか僕の感覚ベースなんですけど、
誰かが突如来週からちょっと半年間休みますってなったときに、
そうだな、まあでもそれ引き継ぎの話か、まあいいや、
しゃべりだしちゃったんで続けると、誰かが来週から半年休みますってなったときに、
その人の穴を埋めるのに2週間から1ヶ月ぐらいで穴を埋められるような状態かなっていうのと、
あとしゃべりながらちょっと思ったのは、それはなんかその人が抜けたときの観点みたいなところだけど、
あとはチーム自体が一週をインプットしてそれをひたすら解決するマシンだとするんであれば、
チーム内のメンバー1人とかが抜けたときに、まあスループッと、
まあ多分処理できる量は減ると思うんだけど、万パーが減るから、
でもその処理できる一瞬の質は変わんないみたいなのが自分が思ってる、
自分がいなくても回るチームみたいなところかな、
でなんか候補者の方がちょっと例えとしてはしっくりきた気がする、しゃべりながら。
じゃあそれをなんかこう、その状態で結構さレベル高い話だと思ってさ、
要は割ともともとチームが専門性に合わせて分けられたりとかしてる話だと思っていて、
そうすると、なんかこう自分が入れなくなっても、
06:01
そのキャッチアップから含めて任せられる専門性を持ったメンバーが揃ってないとそうやってできないじゃない。
うんうん、そりゃそうね。
じゃあ解決法は自分と同じくらい専門性を有してる人をかき集めればできるんですかって話になるんですけど、
その辺はいかがなんですか。
いやその辺、いい質問しかこないですね。
なんか、僕はなんかそのかき集めればいいかどうかで言うと、半分イエスで半分ノーかなと思ってて、
まあ確かにかき集めれば一定その自分がいなくてもあるよねっていう状態が作れる可能性は上がるけど、
半分ノーの理由としてはそのなんだろうな、
本当に自分と同じスキルセットを持つ人が入ったとしても、
もうその人がきちんとすぐにレールに乗れるような仕組みとか、
仕組みってちょっとチープな言葉だけど、
仕組みとかチームとしての機能みたいなのがきちんと備わってないと、
いやー難しいな。
自分が言うところの誰かがいなくても回るチームっていうのは作れないんじゃないかなって気がしている。
具体例をきちんと出してしゃべって地に足つけた方がいい気がしていて、
例えばなんだけど、僕のチームでうまくいった例みたいな話をすると、
僕のチームはSREチームとセキュリティチームとQAチームが内部にいるチームにいるんですけど、
そのSREチームの回し方みたいなところで言うと、
今までは例えばオンコールみたいなものは特定の人しか受けてなくて、
なのでトラブル対応みたいな手順はその人たちの頭の中に閉じていたりとか、
頭の中に閉じるのよくないからドキュメント化しましょうみたいに。
ドキュメント化したとしても難しかったりとかやらないと覚えられないっていうので、
その人たちから全然剥がれないみたいな。
結果としてその人たちが抜けたときにチームのスループっていうのは多分めちゃくちゃ下がる状況だったし、
あとはSREだと用語で言うと問えるみたいな言い方をするんですけど、
例えば他チームからいろんなインフラ関連の問い合わせが来たり、
権限付与をどうにかしたりみたいな話が来たときとかに、
例えばクライマックス関連はこの人しか分からないみたいな暗黙的な雰囲気がチーム内にできちゃってて、
その人にずっと質問が一緒中して、結果的にマゾク人化するみたいなのとか。
そういうのとかは割り込みタスクみたいなのは個人メンションじゃなくてチームメンションしてもらうようにして、
チームメンションが来たものはデイリー朝会できちんと全部眺めるようにして、
09:04
アサイメントを考えましょうみたいな。
例え得意じゃなくても一旦アサイメントしてチーム内で助け合いながらやって、
ちょっとずつ俗人化を進めましょうみたいなことが結構ワークしてて、
そういう仕組みみたいなのがきちんとないと、
同じスキルの人を10人集めたとしても、
10人が同じだけのアウトプットを出す状況っていうのは作れないんじゃないかなという気がしてるって感じかな。
そもそもこの話の前提として、
俗人化しないようにすることは良いことで、
俗人化が高まることが悪いことのように語られていたんだけど、
じゃあそもそもその俗人化をなくしていくとどんな良いことがあるんですかね。
一つはチームがスケールできるようになるみたいな部分があるかなと思っていて、
どういうことかっていうと、
例えばさっきの例で言うと、
オンコールできる人がチーム内で3人しかいないとして、
そこにエサリーチームをどんどん採用していきましょうとなったときに、
オンコールできる人を増やす仕組みっていうのがない状態で採用を進めていっても、
チームのサイズがでかくなるのにオンコールできる人が増えないから、
システムがでかくなったときにオンコールの負荷が上がって成り立たなくなるよねみたいなところとかは、
俗人化のリスクというか、俗人化を解消していくことの一つメリットかなっていうところが一つと、
あともう一つは、
俗人化の希望感にもよるけど、
俗人化している人数みたいなのが極端に少ない場合は、
会社として普通に事業継続のリスクみたいな捉え方ができるかなと思って、
一人しかインフラエンジニアがいなくて、その人が全てを支えていて、
でもその人が今だったら流行り病にかかってしまって2週間仕事できませんってなったら、
障害が起きたら一発アウトみたいな状況になるっていうのは普通にリスクだから、
それは緩和した方がいいよねみたいなところはあるかなっていうところかな。
それはもちろんそうだよね。
要はある領域の仕事をみんなでできるようになっておけば、
買いが利くという言葉が適切なのかはあれだけど、
とりあえず自分じゃなくてもチームとしては前に進むことができるという側面だよね。
それはそれでいいことに決まってるっていう話なんですけど、
逆に属人化を完全になくしていけるというわけではなくて、
12:06
たぶんそんなに属人化なくせたらある程度自動化できるよねみたいなところまでパターン化できちゃうものも中にはあるじゃないですか。
そういうことを言いたいわけじゃなくて、
みんなそれぞれ専門、同じような専門領域にいるんだけど、
得意不得意というか、その人にしかできない専門性みたいなものはやっぱりあるわけじゃないですか。
例えばバックエンドっていうチームがあって、
みんなチームが扱ってる、
例えばこうでいろいろ物を作ってるとしましょうよ。
みんなそれで普通にGoのAPIを使っていろいろ叩いたりとかできるんだけど、
じゃあチームマネジメントっていう観点になった途端にできる人が減ってしまうみたいなのもあるじゃないですか。
そういうのも含めて、OJTで解決していくべきなのかっていう点に関してはいかがでしょうか。
なんか会見みたいでちょっと大きいな。
私から答えさせていただきます。
そうだね。
まあなんか、
そうだね、LINEみたいなの見極めすごい難しいけど、
状況によって変わるっていう、
それこそ会見みたいな、
あらゆる攻めを返すようなちょっとダメな回答をするんだけど、
結構状況によるおじさんなんですけど、
っていう部分はあるかなとは思う。
なんでその前されみたいな例でずっと喋ってるけど、
さっきみたいにオンコールの対応とかエラー対応とか、他チームからの問い合わせは、
他のチームがある程度チーム内でスキルにまばらがっても緩和できる一方で、
緩和するための仕組みを組み上げるための技術力って全員にあるんだっけとか、
ネットワークにめちゃくちゃ特化してるエンジニアがいて、
全員がそのスキルを取得できるんだっけみたいなところは、
確かにというか、普通にシンプルに難しいかなと思ってて、
なんだろうね、そのラインをきちんと言語化したいな。
でもなんか、今頭の中に浮かんだワードとしては、
それを俗に言い換すのはコスパが悪いというか、
どっかにラインがある気がするな。
なんかその辺に難しさがあるんだろうと思ってるんだけど、
15:03
結局その、なんつーか、これは俗人化をなくした方がいいけど、
ここはやらなくてもいいみたいな領域が多分あって、
それはどういうところなんだろうっていう、
やばい、ちょっと堂々迷国が始まってるな。
なんかね、そのテーマに立ち替えるとね、
自分がいなくても回る状態を目指す難しさっていう話だから、
そもそもなんかそのね、俗人化ってワードでもう言い換えちゃってるけど、
俗人化しないようなチームを目指して、
それによって受けられるベネフィットの話をしましたと。
じゃあそれを目指していけばいいんだけど、
何が難しいというか、
これまでの経験でどこに難しさを感じたのか、
再現性はあるのかみたいな感じかな。
なるほどね。
いやー、確かに。
いやー、難しさ。
なるほど、確かに立ち替える。そうだね、立ち替えて。
うーん、ない。
まあそうだな。
これなんか、その普遍的な難しさの話じゃなくて、
ちょっと僕の行動特性の話にちょっとなってしまうかもしれないんで恐縮なんですけど、
うーん、なんというか、なんだろうな。
その、これは、なんだろう、これは俗人化してもいいというか、
俗人化せざるを得ないから、自分でがっつり抱きかかえて、
全速力で走ろうって思うものと、
まあそうじゃないもの。
これは自分がリードはすべきだけど、
自分がいなくなったとしても、
そのある程度、100%じゃなくても40%ぐらい回るようにしておかないといけないみたいなものの2つがあって、
なんかその見極めみたいなのを、
僕は多分あまり上手じゃないのかなっていう自覚があって、
今みたいになんか落ち着いた話で、
このある程度自分の言葉で喋ってるぐらいの冷静さがその時にあれば、
もうちょっと賢明な判断は面場面でできてると思うんだけど、
実際の仕事の現場って、
基本的にはチームの人数の5倍の仕事が降ってくるのがどの会社でも常だと思いますし、
その状況の中で結構シビアにスピーディーにいろんなことを判断していかなきゃいけないってなった時に、
その状況下においておかわりと、
いやこれはちょっと自分でとりあえずやろうみたいに思ってパッてやっちゃって、
後から振り返った時に、
なんかやっちまったなみたいな思うことがあるみたいな、
18:03
でそれをどう防げばいいんだろうなみたいなところを難しく感じてるのかな、
なんかテーマ自体の言語化をしてしまったな。
まあでもあれだよね、
これって、
なんていうか、
自分の仕事を分類して、
この仕事はみんなで回せそうだなとか、
この仕事はみんなでできるようにしようかないと、
仮に自分が何かしらで仕事ができなくなった状態になった時に、
チームがこう詰まってしまうみたいなところのその、
なんていうか棚下ろしというか、
それはやっとかなきゃいけないよね。
たしかに。
それもそうだし、今話聞いてふと思ったのは、
そもそもなんかその、
いやーなんか今自分の仕事を具体的に振り返りながら思ってるんですけど、
僕がそういう意思決定をしてしまったものの大半って、
いやーちょっと話が発散しちゃうけど、
なんかチームの持ち物じゃないと僕が思ったものがすごく多いんですよね。
具体的にどういうことかっていうと、
だから僕は今セキュリティ兼SREチームのソフトエンジニアとして働いてるんだけど、
そこに例えば自分が昔開発したとある機能のトラブルシューティングみたいな仕事が入ってきたときに、
これってなんかSREの仕事でもセキュリティの仕事でもないから、
チームメンバーが取り組んでる仕事としては含むべきなんだけど、
そのチームが持つべき仕事としては解釈せずに、
なんか自分でハンドリングをしてしまうみたいな部分があって、
なんかそれはその、
いやー今頭の中でいろんなプロセッサーがちょっと、
いろんな思考が走ってちょっと言葉止まっちゃったんだけど、
とりあえず走り切っちゃうと、
言いたかったのは、その仕事のオーナーシップがどうあるべきかとか、
その仕事って個人でやるべきか、みんなで取り組むべきかみたいな、
機械的な判断を個人個人が頑張ってするっていう目線で今俺は話しちゃってたけど、
そうじゃなくてその判断自体をする前に基本的にはチームの議論のテーブルに必ず載せるような仕組みにするっていうのは、
なんか普通にやった方がいいなっていう気持ちになった。
それをどう実現するのかわかんないけど、
多分機能開発チームとかの教科書通りのスクラムとかって、
思えばそういう定石になってる気がしてて、
スクラムマスターがいて、開発メンバーがいて、
21:00
開発メンバーが今何に取り組んでて何困ってるかってデイリーとかできちんと追ったりとか、
やるものだけがバックログに載ってる状態にするとか、
その辺の把握とかがあるけど、
ああいうフレームに頼ることができればいいのかなっていう気になりました。
一旦走り切った。
でも聞いてるとあれだよね、
スクラムが絶対的にいいとは見つもりはないけど、
我々で専門的な知識が必要なのでそれは置いといて、
やりたいことは多分そのプロセスの定式化というか、
人が都度プロセスを考えるんじゃなくて、
もうプロセスはチームの中にあって、
あとはそこにインプットを放り込んだらアウトプットが出てくるようにしたいっていう、
だから関数を作るっていう話だよね。
それがタスクの進め方もそうだし、
本コールもそうだし、
未知のものが飛んできたときもそうだし、
それが未知のものであれば一旦チームのテーブルに乗せて、
リスクを洗い出して、
コースを見積もってとかやるんだろうけど、
みたいなものをあらかじめ定式化しておいて、
自分がいなくても、よし今回はこのパターンだっていう当てはめができるようにしておけば、
そんなに専門知識がないメンバーでも、
ある程度に頼った領域の人たちが集まっていれば対処できるだろうっていう、
そういうことだよね。
めちゃくちゃきれいに言語化ありがとうございます。
そういうことです。
何の文句もございません。
っていう話であればね、
っていう話であるんだったら、
最初に言ってた属人化をなくしたいっていうのは1個あるんだが、
属人化していてもしょうがない部分はあるよね。
そうだね。
全部を関数化できないし、
不確実性と向き合う立場で働く以上は多分一定はしょうがないというか。
これは会社組織のパラドックスみたいなもんだけど、
会社組織ってぶっちゃけ中身全員入れ替わっても、
その会社は事業をやっていけるようにパターンを作っていくところじゃないですか。
はい。
なんだけど、その中で評価されて、
お前は本当によく働いてるなって思われるためのコツの1つには、
サスクを属人化させるしかないっていうのがあってですね。
いやー、それはえー。
24:00
じゃないですよ。
この人は何をやってる人なのかっていうのが見えないんですよね、逆にね。
いやー、そうだね。
いや、わかるよ。
だから、プロセスだけを作ればいいっていう話じゃなくて、
プロセスをパターン化すればいいって話だけじゃなくて、
プロセスの中でその人はどう振る舞ったのかっていうのを一緒に評価する仕組みが多分いるんだろうなって思うんですよね。
そうしないと、いつまで経ってもその人の専門性にばっかり目が行って、
その人の専門性によるアウトプットだけで評価するじゃないですか。
うんうん。
なんでこんなことを言うかというと、僕の職業が割と専門性が高くって、
そういうふうな見られ方をしがちっていうのはやっぱりあって。
なるほど。
っていうか、僕は別にそれでいいと思ってるんだけど、
やっぱり世の中そういう人ばっかりじゃないらしいという話ですね。
まあ、そうだね。
いやー、確かに。
そうだね、そこはマジで難しいですね。
まあでも、言った通り、僕が今のとこ持ってる手札だと、
ダテッシュが言ってくれたことが、まあそうだよねって感じはしてて、
まあその、関西に乗っかってるとしてもその時の振る舞いとか、
あとは、どう実現するかみたいな解像度はめちゃくちゃ自分の中では低いんだけど、
その、なんだろうな。
なんかその、きちんと教言語化した言葉でしゃべりたいんだが、
その関数を、再現性のある関数っていうのを作って、
チームメンバーがそれに乗っかって仕事をすることでアウトプットが安定するみたいなところで、
仕事の内容にもよると思うけど、難しいな。
難しいんだけど、
まあなんか、今から自分がしゃべることに対してめちゃくちゃ、
自分で自分に反論できる余地はあるなと思いながらもしゃべるんだけど、
その、なんだろうな。
例えばその、特定の俗人化で、本来その人は持ってる能力というか、
今からしゃべることは、会社において誰かを雇ってその人に活躍してもらうっていう視点に立った時に、
その人じゃないとできない、出せない価値を最大化してもらうっていうのを目的としてるっていう前提のもとを話すんだけど、
その目的のもとで考えた時に、
27:00
ある人がめちゃくちゃ能力あるのに、
なんかその俗人的なその人じゃなくてもいいタスクをめちゃくちゃやってるみたいな状況があったとして、
それってその会社視点でも良くないじゃないですか。
その人は本来もっと価値のある仕事ができるのに、
誰でもいいって言い方は良くないけど、
その人じゃなくても回せる仕事にめちゃくちゃ時間の割合を取られてるみたいな状況が会社にとっても良くないし、
本人も多分基本的にはケースバイケースだと思うけど、
あんま幸せなことないんじゃないかなと思って、
それがチームの、その人が80持ってたのがチームメンバー全員が10ずつ持つみたいになったら、
70の余力が生まれるから、その70で想像的なことをしてください。
それが俗人的なものになってしまったとしても、
それは会社としてその人への期待値がそこにあるわけだから、
問題はないというか、
ケースバイケースだけど基本的には目的通りになってるかなと思ってて、
そういうような余白を、
みんなが持ってるものをみんなできちんと分け合って、
対応したり運用したり関数化することで、
みんなそれぞれがそれなりにその人しかできない仕事をできる状況を作れたら、
素敵なチームだなっていうのを今考えてた。
そうなると評価みたいなところも、
もちろん関数実行してる部分を評価しないという意味ではないが、
関数実行を正しい振る舞いでしているプラス、
その余白で出したアウトプットも評価しますみたいな形にできたらいいんじゃないかなという気はした。
その部分の評価がいわゆる、
よく皆さんの会社にもあるであろうミッション、ビジョン、バリオに沿って行動しているかってやつですよね。
そうだね。
あれはなんつーか、業務そのものを標準化したものじゃないけども、
会社の中でどうやって振る舞うべきかっていうのを記したものじゃないですか。
それに従って行動できるのかっていうのを評価することによって、
その人のアウトプットの価値を上げていくというか。
何が言いたいかっていうと、
今話した関数化するってところは大変なんだけど、できるんですよね。
それはどこの会社もやるんですよ。
仕組み化とかいう名前でよくやったりするんだけど、
そこは多分できるんですけど、
どうしても排除できない俗人化ってさっきもちょっと言ったんだけど、
これが多分大まかに分けて2つぐらいあると思ってて、
1つはその人のもともと持っている能力がずば抜けているから、
30:01
どうしてもそのスーパーマンに何つーか課題解決をお願いするっていうパターンと、
先に言っちゃうと、
1つはその会社のドメインを知りすぎていて、
その人じゃないと歴史的経緯を知らないとか、
経験則的にこれは過去失敗したとか、
こういうメンバーのここに過去こういう問題があったとかね、
そういうドキュメントに落ちない歴史的経緯みたいな、いわゆる生き地引きみたいな。
2つあると思ってまして、
前者はね、前者は別にいなくなったら困るんだけど、
いなくなっても何とかなるんですよ。
何でかっていうとその人の専門性がないと解けない問題って別にないんですよ。
少なくとも我々エンジニアリングの業界でプログラミングしている限りはね。
そうだね、よほどエッチの効いた事業とかやってない限りは多分大丈夫だね。
それは多分大丈夫。もちろんその人がいた方が解決は10倍100倍ぐらい早くなるっていうのはあるから、
いてもらわなきゃ困るっていうのはあるんだけど、そっちの俗人化は多分大丈夫で、
後者の方だよね、会社のことをいっぱい知ってるとか、
あとその会社がやってる事業がちょっと特殊で、
すごく専門領域が深いから本当に何か詩を読み漁ってるとか、
本も出てないような専門知識をめちゃくちゃ持ってるとか、
そういう俗人化の方が怖いんですよね。怖いっていうか、でもかといって解消できないんですよ。
なるほどね、知識はそうだね。
歴史とか行動背景とかは生まれるよね。
生まれる。生まれるのはしょうがない。どっちも生まれるからしょうがないんだけど、
後者の方にフォーカスするためにチームで共有できるナレッジとかプロセスの共通化とかをやっておいて、
できるだけその影響をなくすように努めることはやっぱりやらなきゃいけないんですよね。
確かに。そこに繋がるのか。いやでもそれは間違いない。
だから俗人化をなくすっていう話をひたすらしてきたけど、
その人が抜けてしまって回るようにしたいっていう関数を作るってずっと話してた部分は、
人が入れ替わっても回る仕組みを作るっていう目的ももちろんあるんだけど、
もう一個はその俗人化してる領域を少なくすることによって、
33:00
その人しか持っていない会社のドメインとか専門性に関わる仕事にちょっとフォーカスできるようにするっていうところですよね。
確かに。なるほど。
いいな、やっぱ具体の話したほうが腹落ちするな。
いやー、無限に話せるな。
そう、なんか今出してくれた切り口で言うと、
その俗人化を緩和していくみたいなところで、ドメインとかナレッジみたいなところはやっていくべきなんだが、
たぶん100%解消はこれに関しても基本ないじゃないですか。
なんか事業の成長が完全に止まって、なんか5年ぐらい待ってくれるならみんなそれを覚えられるかもしれないけど、
まあそれって基本的にはないし、ナレッジの増えていくペースの方が早いから、
どこから、どの人が持っているどの知識がクリティカルなのかみたいな部分をきちんと見極めて、
優先度つけるみたいなのも、どのレイヤーの人がやるべきなのかな。
でも会社とか立ちつけによるだろうけど、それぞれの目線から見たときにはそういう目線で、
ノードっていうか意識的に動く必要があるんだろうなっていうのもちょっと合わせて思いました。
これに関してこれをやったら絶対にうまくいくっていうのはたぶんなくて、
でもやっぱりこのアウトプットを小さく小さく出してもらうっていうのは結構有効かなっていう気がしてて、
いつの日かドキュメンテーションの話もしちゃうような気がするんですけど。
それは言語化.fmっていうポッドキャストの第10回質の良い情報を取得発信する方法を言語化したいですね。
なんでそんなスラスラ出てくるの、すごいな。
目の前にGitHubプロジェクトがありました。
要はドキュメントに、例えばその人が専門知識を持った人が退職することになって引き継ぎをやってくださいって言ったって、
もう何かしら会社に嫌気がさせてるわけなんだから、そんな丁寧にドキュメンテーションはしてないじゃないですか。
多分僕だったらしないんだけど。
でもこまめに朝会議とかでもいいし、
手法書くの嫌だけど何かしらテキストに残る形でこまめにアウトプットすれば、
最悪ある日その人飛んだとしても頑張って追っかければ何とかなりそうじゃないですか。
何とかなるね。
そうやって、とりあえずこのポッドキャストじゃないけど、言語化をちゃんとしてもらうっていうのを何とか組み込みたいんですよね。
36:07
何でかわかんないけどさ、
ドキュメンテーション、以前言語化しましたけど、
めちゃくちゃ大事じゃないですか。
大事だし、僕は何か自分のためにもなるから結構多分、
世の平均よりはドキュメント書いてると自信を持って言えるんですけど、
その割に何かめっちゃこの人優勝のエンジニアだなっていう人でも何かドキュメント全然書かないみたいな人もたまにいて、
何かドキュメンテーションに対する価値観と実力の一致の不一致、
ドキュメンテーションに対する価値観と実力の不一致みたいなのがあるなと思って、すごい不思議だなっていうのを思ってる。
どういう軸で評価するかっていう話でしかないなと思ってて。
なるほど。
だからドキュメンテーションする人が優秀だっていう風な文化にしられるんじゃないですかね。
なんか、決して弊社のリスでも他社のリスでもないけど、
いい、かっこいいというか、本質的なバリューズも大事だけど、僕会社を立てるならアウトプットしろっていうバリューを入れようかなって気持ちになった。
その回でも話したけど、だからちゃんとドキュメンテーションすることに対せず、インセンティブがあればいいと思うんだよね。
それは普通に会社がアウトプットというかドキュメンテーションを評価しますということに他ならないので。
そうだね。会社って難しいな。
会社というかあれだよね。人間が集まったら、タイダなやつもいるし、頑張るやつもいるしっていう話だよね。
そうだね。ドキュメント書かない人もタイダとは言い切るつもりはないけど、多様性ですか、これも。
ドキュメンテーション大事だからといって、書いてない人を問い詰めたりとか過激にやるっていうのは、またそれは度外気すぎてる話だから、結局バランスでしかないんだけど。
ドキュメント書かないと結局困るのは将来の自分だと思っているので。
そうだね。確かに。
さっき第10回って言ったけど、第11回でもドキュメント話したな。
結局このポッドキャストはどこでも同じ話をしてるんですよ。皆さん気づいたと思いますが。
39:07
13回も聞いたらもうさすがに皆さんも気づきですか。
大体我々の思考の癖というかその辺が分かってきたんじゃないかなと思うんですけど。
面白いなあ、なんかそれ超かっこいいなあ。全部聞き返したら、よーく聞いたら全部同じ話してるみたいな。めちゃくちゃサクシー。
この癖は聞いてる皆さんに学んでほしいんじゃなくて、ただ我々が言語化したいだけで、
しいてはこの忘れっぽい我々2人が将来聞いた時にちゃんと話を思い出せるようにということで撮ってあるんですよ。
おじいちゃんになった時にね、あの話どうしたっけなあって。
いや、おじいちゃんにならなくてもね、1ヶ月経つともう危ういよね。
正直さっきのドキュメントの話、話したわって伊達氏に言われて思い出したもんね。
そうでしょ。
なんか13回とか言われたけど、今まで12回何をタイトルにして話し方とかずっともう危ういので、
それくらいもう人間の意気込みっていうのは曖昧なんですけど、そんな感じで同じ話ばっかりしてるんですけども、
今日も13回目の同じ話を聞いていただいてありがとうございましたということでね。
ありがとうございます。
たぶん第2、30回ぐらいで、30回分のベンズ書いてどんぐらいかぶってるかちょっとツイートする。
結構かぶってる気がすんなあ。
擦り込みが大事ということで、今回のそうだね、ここもう1回話してくださいって言う方がいたらこっそりDMください。
もしくはハッシュタグ言語界フェイズで。
もう1回話すんだったら過去です聞いてくれよと思うんだけど。
どっかの回にスッと忍ばせて気づくかどうか試す。
それいいね。
裏テーマ的な感じで。
今日、今回も聞いてくれてありがとうございます。
はい。
よっしゃ、いやでもいい言語ができたな。
こんな調子で話したいことをゆるゆると続けていきましょう。
よろしくお願いします。
お願いします。
それじゃあ、皆さんまた次回でバイバイ。
さよなら。
