経験年数で何がわかるか
経験年数が問われることはしばしばあります。 私も聞かれたり聞いたりしたことはあるけれど、それで何かがわかったことはありません。他の話のきっかけに使うのがせいぜいです。
たとえばJava経験15年とか言われれば「Java5が出た前後か、この時期をどう過ごしたか聞いてみようかな」なんて思ったりします。 Java5はジェネリクスやenumなど、Javaにとっての一大転換期です。とはいえこの時期に新人だったとすると、社会人として精一杯で言語のバージョンに意識が向いていなかったかもしれません。 とはいえ次の転換期であるJava8の話は間違いなくできます。転換期の振る舞いは何を期待していいかを知る重要な手がかりになると思っています。 対して経験年数が5年未満であれば、Javaの転換期の話をしても仕方ありません。それよりも言語の選択肢が増えている昨今ですから、他の言語など横に広げて聞いた方が実りのある話ができる気はします。 いずれにしても経験年数はあくまできっかけであって、それで何かの成果を期待するものではありません。
経験年数でスキルを測るのは、よくある誤ったメトリクスと同じ構図です。 コード行数とかバグ密度とかが適切な条件を揃えないと意味がないのと同じ。（適切な条件を揃えると意味はあります。「古臭くて何の役にも立たない」って切り捨てちゃってる人はちょっと見直してあげて欲しい。） 選択肢が狭くコンテキストのズレが少ないのであれば、経験年数で何かを測れた頃もあったんだとは思います。 しかしながら、現在は既にそのような時代ではありません。 開発に携わる皆さんは、時代遅れのメトリクスにとらわれる不幸は多くみてきたはず。不適切なものは排除するのが健全だと思います。経験年数の誤った適用は辞めましょう。
経験年数の他に年齢も似たように扱われ、結構な頻度で聞かれます。経験年数よりも聞かれる頻度は多いのではないでしょうか。 そして年齢、もっと扱いづらい……どころかほぼ役に立つシチュエーションは無いと思っていて、私は意識的に捨てることにしました。8年前に某セッションで「年齢を気にしない」と話していたり。
何かができるできないの理由に年齢を持ってきたくなかったんですよね。「若いのに」とか「結構なご年齢なのに」みたいな言葉がすごく嫌。 たとえ10代だろうと当人を見ればいいだけの話です。プロとして関わっているのだし、少なくとも「いい大人」です。変に気を使うのは当人にも失礼だと思っています。 それで期待と合わなくても、それは「若いから」とか「学生気分」とかではありません。単にその人に対する期待が違っていただけで、差分を見極めてギャップ制御すればいいだけの話。 こんなところに年齢を持ち込んでも何も問題に制御不能なパラメータを突っ込むだけなので、何も解決しないのです。
年齢を含む最古のツイート……当時の私に何があったんだろうね。もう覚えてないや。
当時……と言うかそれよりも前からですが、私は基本的に年齢不詳でやっていて、直接聞かれても濁したりしています。うっかり言ったこともあるので知っている人は知っていますが。 実際のところ別段隠すつもりはなくて、単に覚えてないのをごまかしている＆引っ込みがつかなくなってるだけですが、まあそれはどうでも良くて。 自分のできるできないの理由を年齢に持って行きたくなくて。これは年齢の割にできないとか、この歳で何かを始めるなんてとか言いたくない、みたいなやつです。
槇原敬之の東京DAYSに「24歳の年に初めて照れもなくスケボー抱えて」というフレーズがありますが、私スケボー今年始めました。10年前からこんなこと言ってる私の現在年齢なので、たぶん24は超えてると思います。
経験年数で何がわかるか
さてタイトルに戻って、経験年数で何がわかるか。
経験年数だろうとなんだろうと「情報を仕入れる＝何かを判断する材料にする」です。そして経験年数で何かを判断できるか。私はせいぜい冒頭に書いた「期待値設定するのに役立つ可能性のある話題の予想が立てられる」くらいです。これも予想に過ぎなくて、外すことも多々あります。外れた事実や反応を次の手の判断材料にするだけですが、よほど相手に対する事前知識がない時くらいしかこんな周りくどいことはしませんね。
年齢でわかること？せいぜい雑談ネタじゃないかな。とはいえぼっち属性だったので、同年代だったとしても別に同じ話題なんて……うん。ドンマイ。
経験年数が増えて私がどうなったか
新しい技術を習得する速度が上がりました。
未経験からの「経験n年」での到達点（それが測れると仮定して）に、かなり短時間で到達できると思っています。 コンテキストが違うので、このことを他の人には適用する気はありません。同じような人は多いだろうけれど、前提にはしない感じ。
で、何歳？
少なくとも昭和生まれらしい。前々時代ですね。年齢書く欄があるたびに指折りしてたりするし、結構な頻度で計算間違えて書いてます。
やるまえに確認せよと言う呪い
呪いにかかると鈍くなる。 仕事には数多くの呪いがある。
前置き
本稿での「確認」は「やるかどうかや進めるかどうかのお伺いを立てること」を指します。 完了の定義や制約条件等、内容の確認は違う軸の話。 確認を依頼する側（実行者、メンバー）と確認する側（仕事を依頼する者、リーダーやマネージャー等）が登場人物で、確認を依頼する側の視点ではなく、確認する側の自戒として書いています。
やる前に確認せよと言う呪い
確認は美徳のように扱われることも多く、何か問題が起こったら「なぜ確認しなかったんだ！」と言ったり、チェックシートを作ってみたり、頻繁にするように指示したり。そんなマイクロマネジメント万歳な事をのたまいつつ、「自分で考えて行動しない」とか愚痴ったりする。何かがおかしい。何がおかしいのかを考えてみる。
「やる前の確認」は待機を伴う同期処理になる。 確認がされるまでその作業を進めることはできない。 その間に他のことをすれば無駄にならないと言うかもしれないが、待たなくていいのとは比べるべくもなく、スイッチングにかかるコストは非常に軽視されている。スイッチングのコストを過小に見積もって、うまく行くはずがない。マルチタスクが効率的だと言うのが幻想なことくらい、そろそろ当たり前の話になってほしい。
また、確認を依頼する際に期限を指定することはあまりない。 往往にして確認を依頼する側の方が立場が弱く、依頼された側は多忙なもの。依頼する側が期限を切るのは難しいだろう。仕事は立場の上下関係ではなく協力関係であるべきなので、これが難しい時点で何かがおかしいのだけれど、現実は現実として受け入れなければ話が進まない。 このため、確認を依頼した側はいつ返ってくるかわからない確認結果に心をさきながら待つことになる。 確認しなかった場合に冒頭で挙げたような「なぜ確認しなかったんだ！」と言うような関係では当然そうなる。
「やった後に確認」だと何が問題なのか。 手戻りが大きい、無駄なコストをかけることになる、、、などが挙げられるだろうが、手戻り（これも嫌いなのだけど）の大小やコストの有効無効を判断することは、確認を依頼する側にはできない。その判断ができるほどの情報を持っているのであれば、おそらく確認は不要になる。ここにジレンマがあり、判断できない方に確認のトリガーを任せているところに無理がある。
このように情報弱者に確認トリガーを押し付けると、あらゆることを「やる前に確認する」しかなくなる。 確認が必要かどうかの判断がつかないのに、確認をしなかったら「なぜ確認しなかったんだ！」と責められるわけだから。 当然確認するためのコミュニケーションにコストがかかるし、いちいち立ち止まるから遅くなる。確認待ちの間は他のタスクを行っていても返答の待ち受けるスレッドは常駐せざるを得ないので余計だ。 そのうち確認していいかの確認をすることになっても不思議ではないし、実際そうなっているのを見ることもある。
「やる前に確認する」はおかしい。 おかしいにも関わらず、誰にも指示されていないのに「やる前に確認しなければならない」と思い込んでいたりする。これまでの経験から思い込まされていたりするんだろう。 このようなおかしいことをやってしまうのは、正しく 呪い なんだろう。
やる前に確認が必要なものは、確認の必要性を判断できる側がするべき指示。 これに対して「やる前に確認せずに進めたこと」を責めるのはお門違い。 確認を指示されていたのにそれを無視したとしたら問題ではあるが、責められることは確認しなかったことではなく、指示に従わなかったことになる。 と言うことで、確認タイミングも指示するのが正しい。ようこそマイクロマネジメントへ……あれ、おかしいな。
マイクロマネジメントの何が悪いって話もあるが、それはさておき。 これを避けるため、つまり「やる前の確認」を実行者が自発的に行うためには、情報を持つ必要がある。判断しきる情報があればそもそも不要だが、そこまでいくと最初の「やれ」と言う指示から不要になるので堪えておこう。少なくとも「確認が必要かどうか」を判断するための情報はあって、最低限この情報を与えなければならない。もしくはその情報を当然知り得る環境を整えなければならない。ここで誤ってはいけないのは、後者の場合に「なぜその情報を知らなかったんだ」と責めること。情報を当然知り得る環境とは、例えばWikiやチャットなどに書く、ミーティングで言及する、などになる。環境を準備してそれで情報を得られていないとしたら、それは情報を知らなかったことを責めても意味はない。対象個人と環境とのミスマッチに過ぎない。個人よりは仕組みに帰属させたい。
仕事には数多くの呪いがある。 呪いにかかると鈍くなる。 呪いが解けたらどうなるか。鈍の対になるものは何か。鈍いには鋭い。鈍感には敏感。後者で居たい気はする。
リモートワークを劣化で終わらせたくない
年明けからリモートワークの流れが進み、緊急事態宣言解除を受けて揺り戻しが起こっている頃かなと思います。
なお、本稿に結論はありません。なんとなく思っていることを、なんとなくのまま書いてますのでご注意ください。いつも通りといえばいつも通りなんだけど、いつも以上にそんな感じ。
オンラインツールやリモートワークをオフラインの劣化かのようなのには反発したいんだけど、うまく挙げられなくて悶々としてる。何か見つけていいとこ取りしたい気持ちがずっとあります。
https://twitter.com/irof/status/1266001682011320320
さて、掲題の「劣化」ですが、
- リモートでもXXX（オフラインでやっている何か）を再現できる
に違和感を持っています。このような言葉は最近出てきたものではなく、数年前から「再現できるからリモートワークできる」みたいな表現で使われている印象があります。一見はポジティブな言葉ですが「再現できる」なんですよね。
これは開発者なら常々直面していることの相似形に思います。 業務のシステム化でも既存システムのリプレースでもよくある話で、現行の再現が目的になりかねないところが、私の感じている違和感なんだなと。
再現が目的になると、再現率みたいなものがぼんやり見え、劣化コピーに妥協する可能性を孕んでいるように感じています。 また、再現性が低い枝葉に注力するようになったりして、無駄なことにコストをかけるようになるのではないかと。実際かけている例も見受けられます。 再現するのは目標にしてもいいかもですが、目的ではないですよね。再現できなくても仕事ができたらいいはず。先に挙げた「業務のシステム化」や「既存システムのリプレース」でよく見る履き違いで、枝葉末節や不具合の再現までやろうとする、非効率街道まっしぐらパターン。
閑話休題。このニアワーク（リモートの対として、本稿ではこう呼ぶことにします）の再現を図にするとこんな感じ。
リモートワークとニアワークがあって、それぞれ得意部分があり、どちらでも変わらない部分があり。再現が目指すのはリモートワークによる侵食かなと。とはいえ破線部分は広げられたとしても、そもそもがリモートワークの苦手部分でありニアワークの得意部分。そこで勝負してもなぁ、と言う感覚的なものです。リモートワークせざるを得ないと言う情勢では妥当なんでしょうけれど、リモートワークは劣化ではないと思っているので。
そもそも、リモートワークとニアワークは別物です。オフィスについてふんわり考えてこんなこと呟いてまして。
仕事のためのオフィスが仕事の効率がよいのは然るべきで、仕事の効率が家に劣るオフィスは存在意義を見つめ直すのがよかろうね。
https://twitter.com/irof/status/1263618006304780288
オフィスはニアワークでの仕事効率を最大化するための仕掛けであり、仕事の足を引っ張るようなオフィスは淘汰されてしかるべきなんじゃないかなと。例えば「オフィスのインフラでセキュリティを担保している」などがありますが、足を引っ張るんじゃなく、個々で対応するよりも効率的で仕事に注力できる環境がオフィスである……とかであって欲しいなーと思っています。 オフィスは「8mの距離感]」を得やすいものであってほしくて、リモートオフィスなんてのができるとしたら、そこを目指してくれたら嬉しいかな。 オフィスで隣の席に座ってても「8mの距離感」に居ないように感じるのも、思い返せばよくあった気がする。
リモートワークとニアワークで重複する部分もありますが、リモートワークならではの強みがあると思っています。移動が不要とかそう言うのではなく、仕事中そのものを取り出しても、リモートワークの方が向いているものってのがあるんじゃないかと。具体的にコレってのは見つけられていませんが、あると信じています。根拠などない。
先の図に仕事の範囲を被せるとこんな感じかなとか思っています。
集合の図としたら四角で全体あらわしてニアワークの面積を大きくする方が妥当なんだろうけど、仕事の範囲が動くってのを表したかった感。得意部分でも今の仕事に要らないものもあるよね、とか。
ニアワークだけで仕事している場合は苦手範囲もニアワークでやっているわけですが、仕事の性質を見れば多分分類できるんじゃないかなと。そしてリモートワークの得意部分はリモートワークで、どちらも得意なものは好きな方を選択すればよく、どちらも苦手な部分も多分どちらでもいいんだと思います。得意な道具があるものは得意な道具を使って仕事したい。
TAKAKING22さんのリモートワークにおけるモブプログラミングのコツやkyon_mmさんのテレワークじゃなくてもスクラムイベントではZoomをつかう を聞いて、リモートワークの需要拡大でツールや使用側の練度が鍛えられれば、それを常時使うメリットが見出されやすくなったりするんじゃないかな、なんて思ったりしてます。
以上、未来にこのエントリを読んで「あー」って自分が言うために書きました。
こんなこと書いてますが、仕事は可能な限り現地行く派です。リモートが多いけど、可能な限りは。
