1on1は、「課題の解き方を考えたいとき」以上に「課題を見定めたいとき」に有用この記事は何?blog.lacolaco.netこの記事に対するアンサーソングです。lacolacoさんとの関係Classiで同僚として働いています。1on1が有用ということで、わたしが頼んで制度としての1on1というよりは野良1on1をしてもらっているという状態です。さんとlacolacoさんによく1on1してもらっています。だいさんの1on1とlacolacoさんの1on1はどちらも大変有用ですが、かなり違った特徴があります。だいさんの1on1は、どちらかというと、「導く」1on1と言っていいでしょう。課題があるときに、どうその課題に向き合えばいいのか迷ったときに、「こういうアプローチをしてみてはどうか」という助言や、その問題を解く際に役立つ考え方を助言してもらうことが多いです。以下のツイートなんかはまさにそーだいさんから「導かれて」わたしの判断軸として身についていったことだったりします。lacolacoさんとの1on1は、導かれる、というよりも、探索的に進んでいくことが多いです。「それならこういうふうにしたらどうですか」だとか「それにはこういう考え方が効くと思います」という会話は比較的少なく(当然lacolacoさんは問題解決のエキスパートでもあるので、こういう会話がないわけではないですが)、「問い」の形で進んでいくことが多いです。問題視している理由は?」とか「Aという前提からBという結論が導かれているけど、その接続が自分にはよくわからなかったからもう少し言語化してみてほしい」という「合いの手」が入ります。この合いの手が本当に絶妙で、自分が無自覚に飛躍しているところや、無自覚にバイアスがかかっているところに「効き」ます。実際、lacolacoさんとの1on1を通して、「問いの立て方がシャープではなかったな」「本当に問うべきはこちらか」という理解ができたときには、その問いを解決することで大きな成果につながっている実感があります。間違えた問題を解いたところで、なにも解決しないですからね。いうわけで、lacolacoヘヴィユーザーの声としては、lacolaco壁打ちは「問題の解決ではなくて探索に効く」というおすすめの声をあげておきたいと思います。これはlacolacoさんが「しんぺいさん向け」に行なっている1on1であり、他の効力もきっと他のところで発揮しているのでしょう。そのあたりのレビューは他のlacolacoユーザーの声にお任せすることにします。社内で書いた内容から、一般化できる話だけを抜き出して書いた記事です。仕様が複雑になればなるだけ、指数関数的かつ継続的にコストがかかることを理解する必要がある。ユーザーの要求や利便性について優先順位をつける必要がある。それらを揃えた上で「いっちゃんいいバランスで顧客要望に応える」必要がある。初回リリース以後、クローズ以前クローズ実は一番コストがかかるのが「初回リリース以後、クローズ以前」の部分。サービスの一生のうちほとんどの時期がここなので......。初回リリース以前にかかるコストいわゆる「初期開発」が行われる。この時に仕様がシンプルであればあるだけ初期開発にかかるコストは低くなるし、仕様が複雑であればあるだけ初期開発にかかるコストは高くなる。このコストは線形に増えるわけではなく、指数関数的に増える初期開発のコストは大きく分けて設計にかかるコスト、実装にかかるコスト、テストにかかるコストがある。設計にかかるコスト互いに関連する要素の数に対して、指数関数的にコストが上がるのがポイント。要素が1つならば、一貫性を気にする必要はゼロ要素がふたつならば、ふたつの間の一貫性を気にする必要があるみっつになったら、AとB、BとC、CとAの間の一貫性を気にする必要があるよっつになったら、いつつになったら、という感じで組み合わせ爆発が起こる複数の主体(チームや企業)にまたがる設計が生じると爆発的にコストが上がる異なる立場での優先順位などの調整、異なるポリシーのすり合わせなどが必要となるため設計をなるべくシンプルにすることで仕様の複雑さによるコストを「軽減」することは可能だけど、取り返すことは不可能である実装にかかるコストここは仕様の複雑さに対して線形にコストが上がることが多いここだけしか見えていないことでのちのち爆発炎上する事案は世間にすごく多い実装をなるべく綺麗にすることで、m仕様の複雑さ、設計の複雑さによるコストを「軽減」することは可能だけど、取り返すことは不可能であるテストにかかるコスト設計と同じく、互いに関連する要素が増えれば指数関数的にコストが上がるなぜなら、考えるべきパターンが組み合わせ爆発を起こすので初回リリース以後、クローズ以前にかかるコスト大きく分けて、メンテナンスとサービス運用とサービス改善(追加開発)にかかるコストがある。前述の通り、サービスの一生の中で一番長い時間留まる部分だし、一番コストがかかる部分である後述するが、「仕様の複雑さ」がありとあらゆる変更にかかるコストの「ベースライン」を上げてくる。長い時間、一番コストがかかるところのベースラインをいかに上げないかを考えなければ競合に改善スピードがどんどん追い抜かれていくメンテナンスにかかるコストそのサービスが依存しているもの(DBなどのミドルウェア、ライブラリ、フレームワーク、言語など)は、日々アップデートされていくこのアップデートについていかないとなにが起こるかセキュリティ上の問題が起こる(いっちゃんやばい)パフォーマンスが相対的に悪くなる(競合はもっといいバージョンを使っているぞ)サービス改善のスピードが相対的に悪くなる(競合はもっと使いやすいバージョンを使っているぞ)このバージョンアップ作業には、「計画、実装、テスト」のコストがかかる計画については、関連する要素の数に応じて指数関数的に計画が難しくなる。理由は初期開発と同じ。実装についてはやるだけなので、仕様の大きさに対してかかるコストは大きくみれば線形である傾向がある。テストについては、関連する要素の数に応じて指数関数的にテストすべき内容が増える。理由は初期開発と同じ。サービス運用にかかるコスト問い合わせがあったら調査をする必要がある。ここはテストに似ていて、関連する要素の数に応じて、考慮すべきパターンが指数関数的に増える障害があったらそれに対応する必要がある障害が起こる可能性は、「障害が起こりうる点」がどれだけ多いかに関連する。障害点はコード量、ミドルウェアの数に応じて増えるし、要素間の関連の数に応じて増える。障害から復旧するためには、原因調査が必要である。原因調査の難易度は考慮すべきパターンの数に依存するので、関連する要素の数に応じて指数関数的に増えるサービス改善、追加開発にかかるコストサービス改善や追加開発は、実は新規開発よりも難しい。新規開発の場合は「すでにある仕様」との一貫性をとる必要がないが、追加開発ではその必要があるからである。「現状の仕様の複雑さ」が「追加開発にかかるコストのベースライン」となる。このベースラインのコストはいままで見たきた通り、仕様の複雑さに対して線形ではなく指数関数的に増えるこのベースラインが上がっていくと、どんどん「借金で首が回らない」という状態になっていく「既存のシステムが絡まっていて、手をつけられない、あるいは競合に対して大変動きが遅い」となっている仕組み、世の中にたくさんありますね。これは別にエンジニアが無能なわけではなくて既存のシステムが「足枷」になっているということクローズにかかるコストサービスをバツっと閉じてしまうならコストはかからないしかし現実はそうではないことが多い代替となる新機能や新サービスを作るならば、そのための新規開発のコストがかかる代替となる別サービスに移行するならば、移行のための追加開発のコストがかかる上述のコストを考えた上で意思決定する必要がある仕様が複雑になればなるだけ、言い換えればつまり「関連する要素」が増えれば増えるだけ指数関数的にかつ継続的にコストがかかるようになっていく「ユーザーの利便性のためならなんでもやる」も「コストがかかるから仕様をシンプルにすることだけ考える」も意思決定ではない「ユーザーの利便性」と「継続的にかかるコスト」を天秤にかけて、「じゃあどこがバランスするか」を決断するのが意思決定である。エンジニア的観点では、「ユーザーの利便性や要求」について理解をしようとする必要がある。その上で、なるべく各要素の関連を少なくするようなシンプルな仕様、実装で、ビジネスに求められるラインを提案し、実現するために知恵を絞るべきである。自分が意思決定者でないのであれば、その仕様にすることでなぜ将来にわたるコストが低いのかを意思決定者に説明する必要がある。ビジネス的観点では、エンジニア的観点から導かれた「将来にわたるコスト」について理解をする必要がある。「なにが本当に必要なもので、なにを足すと"将来の足枷"が増えるのか」よく理解した上でユーザーの利便性や要求について優先順位を明確にする必要がある。奥田民生の名曲のひとつに『たばこのみ』という曲がある。鍵盤がちょっとドリーミーな雰囲気を与えて、ドラムのフィルインはちょっとリンゴ・スターっぽい訛りかたをしている、中期ビートルズに多大なリスペクトを払ったであろう楽曲だ。www.youtube.comしかしこの曲、コード進行もなんだか変だ。ジョン・レノンもこういう変なコード進行をよくするけれど、それにしてもどう解釈すればいいんだろう?楽曲はGで始まる。最初はなんてことはない、普通にキー:Gメジャーの楽曲として解釈してまったく問題ない感じで始まるのだけれど、歌い出しの「だれがなんと言おうとたばこを愛している」の最後の「る」でいきなりm3rdの音がでてきて、コードもGmになる。つづいて「それはもうナイスな」でコードはCにいく。キー:Gメジャーとしてとらえたらこれはそんなに変ではない。そこから一瞬コードはCmに。これもGメジャーで捉えたらサブドミナントマイナーなのでおかしくない。B♭と進むので、やはりこれをGメジャーとしてとらえるのはちょっと無理があるだろう。GはVIのメジャー、Cはドッペルドミナントであると解釈することができる。こっちのほうが自然だと思う。VIメジャーはダイアトニックコードではなくて、「曲のド頭にノンダイアトニックコード、しかも3rdをメジャーにしたもの」を持ってくるのはかなり大胆な発想がないとできない気がする。C7」の繰り返しになっていて、これをキー:B♭で解釈するのもかなり厳しいものがある気がする。考えると、この曲はたぶん「キー:G」で始まって、そのあといきなり突拍子もなく「同主調であるGm、あるいはその平行調であるB♭に転調している」と捉えるのが自然なんじゃないだろうか。出てくるコードはだいたいキー:Gとして捉えるかキー:B♭として捉えると違和感なく解釈できるようになっているんだけど、そう捉えると今度は「同主調(とその平行調)をフラフラといったりきたりしている」という感じになって、この「落ち着きどころがよくわからない感じ」がこの曲の独特の雰囲気に一役かっている、という感じだろうか。この、同主調をふらふらといったりきたりしていると捉えられるようなコード進行はジョン・レノンもよくやる気がする。そのあたりもやはり中期ビートルズリスペクトなんだろうな。識者がなんかいい解説してくれないかな。2024に登壇してきましたスライドは以下にアップロードしてあります。過去や未来を扱うとき、ソフトウェア開発やサービス運用はその難易度が上がります。サービス運用をしていく中で困らないように、あるいは、今後もコードの改修を伴うサービス改善を行うときに困らないようにするためには、過去や未来を扱う際にどんなことを考えてソフトウェアを作っていくべきか、というテーマです。ベテランからすると、ともすると「当たり前」のように感じる内容の気もしますが、その「当たり前」は意外と言語化されてきていない気もしており、知見の継承という観点でも、われわれ(とは?)のようなおじさん世代が「当たり前をちゃんと言語化していく」ことには意味があるだろう、という気持ちで登壇させていただきました。発表の中で紹介した様々な事例はフィクションですが、我ながらかなりリアリティがあるというか、長くシステム開発運用に関わってきた方ならばどれも「あるある」という感じの事例だったのではないかと思っています。地に足のついた、それでいて特定のケースのみに役立つHowではなく(「それはHowなんよ」を発表の中に入れ損ねた!!)、初めて見るケースや問題に対しても応用が効くような内容にしたいと思っていましたが、それが成功しているかどうかはみなさまからのフィードバックを待ちたいと思います(ブログ書いてね!)。発表を聴く立場としては、PHPでデータベースを作ってみたという発表を最も楽しんで聴かせていただきました。「だってたのしそうだから」で自分の興味のままに物を作り、動かして楽しむ、という、ソフトウェア作りの楽しさの根源みたいなものを思い出させてくれる素敵な発表だったと思います。わたしもなんか作りたくなった。クロージングでも触れられていましたが、「カンファレンスがあることは当たり前ではない」というのは本当にその通りだと思っています。自分のスタンスの話をすると、技術コミュニティとの関わり方に悩んでいる、というのは以前のブログ記事でも一度書きましたが、いまだにその悩みはクリアになったわけではありません。それがクリアになっていないとはいえ、「カンファレンススタッフに対しては感謝の思いがある」ということと、「自分はやはり登壇して知見のサイクルを回すお手伝いをするという形での貢献をしたい」ということには間違いがないな、と改めて思いました。なんらかのカンファレンスにこのような形で関われればと思いますので、その際はぜひ宜しくお願いします。生成技術の発展が本当に日進月歩ですごい。音楽に関しても、もう「なになに風の音楽を作って」というものについてはあと一歩で実用レベルだな、と思わせるところまで来ている。以前もこのブログで以下のように書いた。「こんなイメージで、という指示」をインプットにして、アレンジ済みトラックを出力するような仕事、あるいは「こういう用途で使います」「こういうイメージで」をインプットに、BGMを出力するような仕事は、「よほどのこだわりがある場合」を除いて、生成AIによって早晩奪われていくだろうと思っている。生成AIによって、演奏の仕事が置き換えられていく可能性は低いと思う。回にゃあと鳴くなんならLogic11の新しい機能のSessionPlayerなんかはもう「アレンジ済みの演奏を出力する」「ベーシストとして楽曲制作のお手伝いをする」みたいな私の仕事を一部置き換えてしまったと言っていいのではないかと思う。この流れは多分止まらなくて、思ったよりも早く「劇伴」とかBGMの仕事の総量は減っていきそうだ(全てが置き換えられる、ということもまた起こらないのだろうと思うが)。イラストの世界ではすでに、「文章を売っている」「音声を売っている」みたいなタイプの個人制作の作品におけるイメージ画像(イメージ画像、という言葉を使うときいつも、「イメージイメージ......」と思って違和感を得るんだけど他にいい言い換えをしらない)や挿絵などが、生成技術によって生み出されたもので置き換えられつつあるが、それと同じことが多分あと一年かそこらで音楽でも起こると思う。ぼくはある意味では生成技術によって「金銭を得る手段」をひとつ潰された立場にあるわけだけれど、一方でこれらの生成技術に対して現在あまり嫌悪感を持っていない。それどころか、ちょっとワクワクすらしている。それは、ぼくが音楽以外に生業を持っているからというのはあって、自分はあくまで「作りたいから音楽を作っている」という立場だからなのだと思う。音楽の仕事が奪われた(あるいは奪われる)とはいえ、それで生活に困るかといえばそうではない立場、言い換えれば、簡単に「趣味のひと」に戻れるという立場だ。「趣味のひと」の立場から言えば、「音楽を作るための技術を磨くこと」そのものが楽しいので、別に生成技術がいかに「努力なし」でクオリティの高い成果物を出そうがあまり自分の楽しみとは関係ない(そもそも生成技術を使えば努力なしで良い出力が得られる、というのもぼくは疑問視しているが、それはまた別の話)。いうか、「結果」よりも「過程」を楽しんでいるから趣味なわけで(結果を出さなければいけないならばそれはもうお仕事ですよ)、「結果だけ欲しいならばすっ飛ばしてもいいような過程を、自分の楽しみのためにわざわざやる」という酔狂なことをしている限り、生成技術によって自分の楽しみが奪われることはない。これはDTMの打ち込みによって「演奏しなくていい機会」が増えたのに「わざわざ演奏したがる(しかも素人なので打ち込みよりもなんなら下手)」という酔狂なひとがいまだにたくさんいることと相似な気がするし、あるいは買った方が安いしうまいし手間もかからないのに、わざわざ自分でお菓子を作る人がたくさんいるのとも相似かもしれない。趣味なんだからそれでいいんだよな。雑文なのでなにか強く主張したいことがあるというわけではなくて、「生成技術がおもったよりも早くまともな音楽を作っていっているなあ」という感想と「それに伴って自分のスキルが思ったよりも早く相対的に金になりにくくなるな〜」という感想と、「とは言え趣味人としてはノーダメージだなあ」という感想を書いておきたかったので書いた。ぼくは今日も、趣味人として自分のバンドのレコーディングに赴くのであった。#ya8uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。議論の内容については余裕ができたら改めてまとめるかもしれません。実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコミュニティの関係のあり方を見直すべきだ」と感じる出来事があり、その見直しにこれだけの時間がかかった、という感じです。見直しに時間がかかっているあいだ、テックコミュニティとの関わりを意識的に避けていましたが、少しずつ整理がついていった中で改めて思ったのは「テックコミュニティにうけてきた恩を自分はテックコミュニティに返し切れているのか?」ということでした。返しきれていないわけで、そうであるならば改めてコミュニティに対して恩送りをしないといけない、という当たり前のところに帰ってきて、その最初のきっかけに選んだのがya8にアンカンファレンススタッフとして関わる、という一歩でした。ya8で久々に会ったエンジニアの友人たちに「リハビリ中なんです」と言っていたのは冗談でもなんでもなく、本気でそういう状態だったんですね。そんな中で、@KentarouTakedaさんに嬉しい声をかけていただきました。曰く、以前私がカンファレンスで行った発表が仕事で実際に役立ち、しかもそれをきっかけに別イベントに登壇もされたということでした。これは私にとってはとても嬉しい声かけでした。「自分の知見をコミュニティに還元することで、新しく知見のサイクルが回っていく」ということが起こったということを実感させてもらえたということでもあります。自分は長い間テックコミュニティとの関係のあり方をいろいろと悩んでいたりしたのですが、これを聴いて改めて「コミュニティに対して自分の経験や知見を還元する」というすごくシンプルな関わり方を中心にしていればよい、そのシンプルさを見失わないようにいよう、と改めて思うことができました。自分にとってはとても良い「リハビリ」「再出発」の機会となりました。ありがとうございました。これをきっかけにまたテックコミュニティに対して積極的に関わっていこうと思います。いという言葉をここ数年(つっても10年単位か?)よく耳にするようになった気がする。ひどくずぼらである、というイメージを持たれているひとが「冷蔵庫の中に卵があるのを忘れてて、賞味期限を一ヶ月切らしちゃったんだけど、まあ卵だし大丈夫だろって思って目玉焼きにして食べた」というエピソードを披露すると「その行動は解釈一致」と評されたりする。並べてある」と言ったら「それは解釈違い」と評されたりする。このとき、「解釈違い」という言葉は、あなたのことを誤解していた、というニュアンスではなく「あなたはあなたの人物像に似合わないことしている」というニュアンスで使われていることが多いと思う。このような言葉の使われ方は、比較的新しい使われ方であるように思う。20年前だったら「キャラじゃない」あたりの言葉が使われていたかな?ところで、今から書くこの段落はまるまる余談、脇道なんだけど、ぼくの認識としては、この使い方の「解釈違い」は、最初は二次創作などの文脈で「わたしの原作解釈とこの二次創作の作者の原作解釈は異なる」という意味で使われていた認識だ。それが転じて、自分の持っているイメージと異なる表象を持つさまざまなものに「解釈違い」という言葉が使われていくようになったのではないかと見ている(有識者によるツッコミを待ちたい)。結果としてある意味原作そのものである「本人」との間で「解釈違い」を起こしているのはなかなか面白い現象だ。話を戻して、言葉は、その言葉をつかうひとの認識を形作る。虹の色の数はいくつか、という問いの答えが、使っている言語によって異なるのは、使う言語によって話者の認識が形作られる良い例だ。これは鶏が先か卵が先か、のような話でもあって、その逆方向、つまり、われわれがどう世界を認識しているかによって、言葉が作られていく、こともまた言える。犬と狼を区別しない世界観のもとでは、犬と狼が同じ単語で表される言語が生まれるというような話がこれに相当する。言葉の枠組みと認識の枠組みは不可分だ。「解釈違い」という言葉が、「だれかの人間性に対する解釈、つまりイメージを捉え損ねていた(違っていたのはイメージの方)」という意味ではなく「その言動はその人のイメージにそぐわない(違っているのは言動の方)」という意味の言葉として扱われてるようになった変化は、われわれの認識のどのような変化を反映しているのだろうか。そのような言葉の使い方は、我々の認識をどのように変化させるだろうか。誤解してほしくないが、ぼくはべつに「解釈違い」という言葉が「悪い使われ方」をしている、けしからん、という話をしていない。いうことを言っているだけだ。ここから、「けしからん、先にあるべきはイメージではなくてありのままの人間性のほうだ、解釈などというイメージと実際が違うことに対して、実体の方が違う、というような用法はおかしい」という本質主義的な主張を導くこともできる。「人間性そのものなんてものはアプリオリに存在するわけではなく、他者によって初めて見出され、物語られ、ある意味でっちあげられることによってフィクショナルに社会的に物語的に作り上げられるものだ。解釈違いという言葉が人間性に対して向けられるのは、それをよく表している」という社会構築主義的な主張を導くこともできる。ぼくはどちらかというと後者の立場に近くて、「面白い変化が起こっているなあ」という感じでこの変化を眺めている。そもそも「キャラじゃない」という言葉がよく使われている時にはまだ「キャラ」というものがどこかに実体あるいは本質めいて措定されているが、「解釈不一致」だとあくまで無数の「解釈」が並行してあるだけ(本人の言動すら並列に置かれているところがおもしろい点だ)だし、より「解釈により人間性というものがある種フィクショナルに構築される」ということをよく捉えた言葉使いになっているとさえ言えるかもしれない。そのようなアングルでもって眺めてみると、本質主義的な考え方の強い言葉が溢れているのと、社会構築主義的な考えが強い言葉が溢れているのでは、形成されるアイデンティティや、他者との葛藤のあり方にも違いが出てきそうだとも思う。いう中での表現活動もまた、異なる在り方になっていく、あるいは今まさに変化の最中にあるかもしれない。願わくば、「表現活動たるものこうあるべきだ」みたいな凝り固まった視点を持った自分ではなく、その時起きている表現活動をいったんそのまま受け取って柔軟に楽しむことができる自分でいたいものだと思う。このような文章を書くぼくは、ぼくを知る人たちにとって、解釈一致だろうか、それとも解釈違いだろうか。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。