最近の近況
こんにちは、こばちえです。 こんにちは、たなけんです。
てくてくラジオは、仕事の合間にするような、ゆるい雑談を配信するポッドキャストです。
今週もよろしくお願いします。 よろしくお願いします。
はい、ではエピソード190、元気にやっていきたいと思います。
はい、やっていきましょう。
ちょっと近況的なネタから話したいんですけど、
最近私、引っ越しとかでね、あの住民票とか、そういう書類を手に入れなきゃいけない機会があったんですけど。
ああ、そうですよね。やっぱ引っ越すってなるとね、ありますよね。
そうそうそう。
で、取得するために市役所、市役所に行くパターンと、
あと最近だとコンビニで出力できるっていうパターンがあるじゃないですか。
はいはいはい。
コンビニの書類交付のサービスって使ったことあります?
ありますね。住民票出したかな、確か。
うんうんうんうん。
あのマイナンバーカードでね、シュッと出せるやつ。
あの、それがね、前、もう何年も前だと思うんですけど、使った時は300円とかくらいだったんですよ、かかったんですよ。
はいはいはい。
なんですけど、なんか今月、最近行ってみたら100円になってて。
お、安い。
そうなの、なんか行政サービスでお得感を感じれたっていう、そんな小ネタなんですけど。
はいはいはい。
普通もっと高いですよね。
うん、僕も300円くらいした記憶があるなぁ。
そうそう、そうなんです。
で、なんか安いなぁと思ったら、やっぱし安くなってて。
うん。
松本市のその証明書のコンビニ交付っていうのが、利用を促進するために減額してるらしくて。
利用を促進するために、なるほどね。
市役所の窓口業務を減らすために、コンビニで住民票とかを取得するっていう方にみんな使ってもらいたいっていう目的なのかな、意図なのかな。
なるほど。
うん。
そう、それで今年の4月から2年間安くなるらしいです。
期間付きなんだ。
うん、見たい。
えー。
今出すと、松本市の人は今出すとお得ですよっていう。
うん、なるほど。
住民、あれでも住民票ってなんか、あれいつまで有効とかあるんでしたっけ?発行してから。
楽観的な成長の気づき
あるよね、なんか使うときに何ヶ月以内に取得したものとかって、多分だいたい言われる気がする。
ありますよね。
うん。
なるほど。
そうだね。
まあちょっとそんな最近の気づきだったんですけど、今週は、先週、たなけんさんが最近ちょっと、最近の成長みたいなところの話をしてくださったんですけど、
今週はちょっと小鉢への成長を感じたっていう話をしてみたいなと思います。
お、いいですね、楽しみ。
でね、それが、自分が思っているより自分が楽観的かもしれないなっていうのに、最近気づいたっていうことです。
ほうほうほうほう、なるほど、なんかきっかけがあったんですか?気づいたのは。
なんかね、最近、会社の人と上司とワンオンとかをしている中で、
なんだろうな、その自分のチームのこととか、自分の携わっているプロダクトの話をしているときに、
まあなんかこの計画でいけばもうだいたいできたようなものな気がするんですよね、みたいな話をしてたんですよ。
もうなんかこれでいけると思うんですよね、とかっていう話をしてて、
そのときに、いやなんかその楽観的な部分って結構必要なんだよな、みたいなことを言われて、
あ、なるほど、なんかこれって楽観的ってことかって気づいた。
なるほどな。そうそう。で、なんかそれをきっかけにちょっと振り返ってみると、
なんだろうな、実装したものに対して機能をリリースするにあたって、
一通りミニマムでも動くのであれば、とりあえずマージしてお客さんに提供して、
それでフィードバックを受けて、何かあればそこで改善していこうとかっていうのって結構自分のムーブとしてこれまでもあったなとかっていうのを気づいて、
たぶんチームのメンバーの身長派の人だと、もうちょっとここまでやった方がいいんじゃないかとか、
コードベースはもうちょっと綺麗にしないと、これマージしない方がいいんじゃないかみたいなやつ、
結構ね、いろんな意見をいただくんですけど、それはそう、それぞれが正しいなとは思っているんですけど、
その中でも自分は結構、とりあえずやってみようみたいなところで、大丈夫だと思うからやってみようみたいな思考だなっていうのに最近気づいてきたって感じです。
なるほどねー、なんか僕もわかるな、なんかテンポが大事な時も結構あるし、
なんかどんどんまずは出していこう、前に進めていこうみたいな、なんかそういう楽観さが、
楽観さを出してるなーっていう時、自分自身でも感じる時あるなーって思いますね。
それ状況によって、なんかそういう時もあれば、慎重になっている時とかもあります?
慎重になっている時ありますね、なんか僕多分どっちかで言うと、ベースは慎重派だと思っているんで、
えー、そうなんだ。
そう、なので、あの、石橋を叩いて渡る派なんですよね、実は僕の自己認識はそうです。
だから、なんか細かい変更でもすごい各所に確認をとったりとか、
楽観的にやればすぐやっちゃえばいいでしょってやつも、結構丁寧にやったりするタイプ、本当は。
時間さえあればというか、基本の進め方はそうなんだけど、
まあ、状況によって、まあそこまで時間かけないという選択をあえてしようって思ってしているみたいな感じ。
なるほどね。
私もそう、もともと心配症だなって自分で思ってたから、
で、その部分はあんまり変わってない気がしてて、なんか動かなかったら困るからちゃんと動作確認しようとか、
これがうまく運用回らないと困るから、その運用が回るような事前に確認しなきゃいけない部分は確認する、
リリースするにあたって、オペレーションが明確になっているかどうかをちゃんとチェックするとか、
そこは引き続きだから、なんか部分的にその部分があるのは今もそうな気がしてて、
で、なんかね、その楽観的って言われた部分と、まあ慎重に進めている部分とっていうのがあるなぁとは思ってるんですけど、
それもちょっと自分で考えてみた感じだと、見えてることが多くなってきた結果、
ここはやっとかないといけないっていうことと、ここはまあこのまま行っても大丈夫だなみたいなところが、
なんとなく、なんていうの、土地勘みたいなやつ、なんていうんだろう、そういうのがなんとなく自分の中にできてきて、
それで、うん、なんだろう、正しく不安がれるようになったというか、
っていうのが、で、不安がらなくてもいいなぁみたいなところは、楽観的に進められるようになってきたっていうのが正しいかもなって思ってる。
はいはいはいはい、分かる分かる、ああ、そうそうそう、正しく不安を感じるっていうのはすごく感覚として分かりますね。
なんか、逆に極めようと思えば、完璧にしようと思えば、やるべきことってあるんだけど、
そこを100%にしなくて、そこで別に70%、60%でも、別に取り返しがつくでしょうというか、
あ、そうだね。
指したる問題にはならんだろうという部分は、まあまあいいでしょうという感じになって、それが見えるか見えないかっていうのは、
全く見えてない、慣れてないところだったり、知らない環境だと、本来60%ぐらいでもいいでしょうって思ってることに対して、
95%、98%、100%目指そうって思ってしまうみたいなのはあるんだけど、
でも分かってるから、まあまあここは60%でいいでしょうみたいな。
まさにそんな感じ。
そうだね、今田中さん言ってくれた取り返しがつくつかないの判断が結構、自分の中でできるようになってきたってことなのかもしれないな。
うん。
でも取り返しがつかないことってそんなないからね。
ないからね。
うん、って思うと、もうなんかこの先楽観的になってくる、だなきっと人間は。
リリースに関するコミュニケーション
うん。
そうね。
うん。
で、なんか、そうそう、そういえば今の取り返しがつかないとか、ここはちょっと不安もゼロじゃないんだよねみたいなところって、
えーと、それを自覚しておくこととか、チームに共有しておくことって結構大事だなと思ってて、
うんうん。
えーと、ここは100%じゃないんですよね。ここは正直80%で作ってますわ。
けど、別に、えーと、すごいレア検査では問題になるかもしれないけど、
概ねここは問題があっても許容しようと思ってるんですよっていうのを共有する、明確にしておくっていうので、
なんか今僕のチームだと、週に1回金曜日にチェックポイントっていうのをやってるんですけど、
うん。
そこで今週のリリースしたものを共有する、みんなで振り返るっていうのをやるときに、
なんか、今週のリリースで技術的に積んだ不採とか、制約事項とかありますかっていうのを共有するようにしてて、
うんうん。
そこでもしそういうちょっと懸念とか、あえてやろうと思えばできたけど、あえて、
えーと、あえてというか、その様々な費用対効果含めてやらない判断をしているもの、こと、
みたいなのを共有しておるみたいなのがあって、
へー、いいね。
そこの、うん、そう、それ結構いいなーって僕思ってて、そのフォーマットを見たときに、
あ、これちゃんと共有するのってすごいいいなーって入社したときに思って、
うん。
なので、なんかそういうのをチームで自覚しておく、で、みんなで許容する、受け止めるみたいなのは、
正しく不安があるみたいなところと近いというか、
うん。
認識するっていうのは大事そうだなーって思いましたね。
共有先ってどんなメンバーが参加してるんですか?そのチェックポイント。
は、エンジニアだけのやつです。
あー、なるほどなるほど。
うん。
そっかそっか。コード上の、なんかここら辺の80%の部分とかも、
うん。
できる範囲で共有していければいいですもんね。
そうそうそう。
うんうん。
で、なんかエンジニア以外のメンバーに向けては、
個別にリリースに、それぞれのリリースに対してリリースノートを社内向けに書いてるところの一番下に、
社内向け注意事項みたいな欄があるんで、
そこにこういうケースはちょっと対応してませんとか、
うん。
そういうのは一応書いてるんで、目を通してくださいっていうコミュニケーションはしてるって感じですね。
これは私のいる方もやってる。
そうですよね。
同じかな?テンプレート一緒かもしれない。
一緒な気がする。
うん。
えー、いいないいね。
そうだよな。何でもかんでも100%目指していくとスピードがなくなっちゃいますもんね。
そうっすねー。
コードの品質とバランス
なくなっちゃうというか、なくなっちゃわないほど、
ちゃんとスキルとかを身につけられればいいと思うんですけど、
なんか一般的にというかいうと、やっぱりちょっとそこって若干トレードオフになる部分がありますもんね。
そうだと思いますね。
なんか多分人によってとかチームによってとか状況によってとかで、
結構、何パーセントぐらいまでいかないと不安だなとかっていうところのグラデーションはある気がしてるから、
そこら辺の温度感っていうところをチームとかで揃えていくのが大切そうですね。
そうですね。
なんか僕結構思うのが、その辺の温度感、捉え方みたいなものって、
結構それまで経験してきたこととかに、経験してきたこととか働き方とかに結構依存しそうだな、
大きな影響を受けそうだなと思っていて、
例えば、プロダクトコードを書いて、それを納品するみたいな仕事をしていた場合に、
コードのクオリティとか、それによって発生した不具合とかで、責任の所在みたいな問われ方をすると思うんですよ。
確かにね。
そうなった時に、無責任なコードは書けないとか、コードに対する品質の高さにこだわりを持つっていうのはすごい自然なことだと思ってて、
そうだね。
なので、それで過ごしてきた、何年も業務をしてきた方とかだと、そこを重視して、
いや、こんなんじゃ出せないですよ、こんなんじゃマジできないですよっていう風になるのは、すごく自然だよねと思ってて、
で、一方で結構僕とかの、僕自身の経験だと、もちろんコードには綺麗に書きたいなと思ってるし、
クオリティも過読性も含めて、テストとかも含めて、ちゃんとやっていきたいともちろん思っているが、
最終的に責任を持つ先は、使ってくれてるユーザーさんが便利に使えるかとか、ユーザー視点で損失がないかみたいなところが大事で、
コードそれぞれ、個別のコード一行一行というよりかは、それによって生まれる価値だったり損失に対してどうしていこうかって話になるので、
コード自体に対するこだわりよりは、価値に対するこだわりの方が多分強いというか、
そうだね。
なので、いけるやつはいっちゃおうみたいな感じの判断がより傾きやすいというか。
そうだね。本当そう。
過読性だったりとか、そういうところで確かに本当にそれを正しい状態に常に保っていけたらめっちゃいいなと思ってるから、
それはできる範囲でやっていきたいとは思いつつ、
そうだね。それで例えば価値提供が遅くなってしまったりとか、
でなってくると、今これを待ってくれているお客さんがいるっていう状況で、
じゃあどっちを優先していこうかっていうところの判断になる気がするんだよな。
将来的に見るとやっぱり過読性上がっている方が新しい機能の追加とかもしやすくなって、
スピード落ちなくていいよっていうところはもちろんわかりつつ、
そこのバランスみたいなところは常に悩ましいと思ってる。
知識の必要性
そうなんだよな、悩ましいし、
なんかあと僕自身はやっぱスキル、その面でスキルが足りないなとも思ってて、
どういう高度の設計であるべきかとか、
そのあたりの自分自身の天井が結構近くにあるから、そんなに高く、
まだまだもっとクオリティ高められるぜ、あんな手段もこんな手段もあるぜっていう引き出しも別にそんなにないし、
僕の中で高度のクオリティを上げる天井みたいなのが割と近くにあるから、
そこにこだわれないという意味もあって、
そうなんだよな、あんまり議論もできない、
たぶんすごいその辺にこだわって知識を持っている方と話すと、
僕ちゃんと議論できないなって正直思っちゃってる部分があって、
いやーわかる、私もそう、
そう、わかんないからもうちょっと自分でもそこにちゃんと知識つけていかなきゃなって思って、
たぶん教科書的な、なんていうのかな、
例えばここがドライにしなきゃいけないとか、
それは今必要じゃないんだったら今はやらなくていいから、
ここはむしろ書かない方がいいとか、なんていうのかな、
クラスの設計はこうした方がいいとかっていうところ、
教科書通りの話としては、
わかるってなるんですけど、なんか聞いたことあるってなるんですけど、
なんだろうな、なんかすごい必要性みたいなところの理解度が身にしみてわかってないっていうか、
っていうのもあって、
たぶんその議論になった時に、
家族性の高い、
良い状態の行動にするっていうところの必要度っていうところが行き違ってしまうというか、
その議論にうまくたぶんいい感じに参加できない感じがする。
個人のこだわりの範疇と、
チームとしてこういうふうにしていきたいよね、だったり、
世の中のすごく大部分の設計がこれがベストプラクティスだって言われているよっていうものとの区別がすごく、
僕の中ではできないなって思ってて、
まさにそんな感じ。
僕は自分自身がコード書いてても、これは自分がただこだわりでこういう設計にしてるだけかもなって思う瞬間も結構あったりして、
たぶん大方針はベストプラクティスな方針で今書けてる気がするけど、
この部分に関してはちょっと自分のエゴというか、
自分がちょっと満足いくからこういう構造にしてよし綺麗でしょって思ってるみたいなところが多分あって、
そこの境界線すごく曖昧なんですよね。
なので他人が書いたコードに対して、
ここはちょっとその人の個人の思いが出てる部分だなとか、
ここは全体的にベストプラクティスに則っている部分だなみたいなの区別ができないしにくいから、
しにくいというかたぶん知識があればできるのかもしれないけど、
その知識はたぶん足りてないのでできなくて、
なんかレビューの時とかもそこまでやらなくてもいいかもねとか、
すごく都度微妙に悩ませながら判断してるかもなみたいな。
いやーわかる。そうですね。レビューの指摘内容もあんまりそういうところ指摘しなくて、
いやこれこのパターン考えとかないとまずいかもねとか、
その業務寄りの指摘になっちゃうんですよね。
それはそれで必要なんですけど、
行動をきれいに保つみたいな観点での指摘って、
あまり自信がないからしてない気がする。
いや面白い。でもこれはどこまでやるかみたいなところとは別で、
そこって知識としてやっつけていったほうがいい部分ではあるから、
ちょっと勉強していかないとな。
そうなんじゃよな。
そうなんじゃよ。
ありがとうございます。
ちょっと最初の話からコードの悩みの話になったけど、
たなけんさんも同じような悩みを持っててよかった。
そうですね。技術的なところとかは特に難しい。
難しい。やっていきましょう。
はい。
はい。ではでは、今回はこんなところで終わりにしたいと思います。
今回も最後まで聞いていただいてありがとうございました。
ありがとうございました。
バイバイ。
バイバイ。
