00:00
aozora.fm 第81回目。第81回目は、ゲストにおにぎりさんをお迎えしています。 おにぎりさん、よろしくお願いします。
お願いします。 じゃあ早速ですが、おにぎりさん、自己紹介をお願いします。
はい、おにぎりと申します。ツイッターではアットマークおにぎりアンダーバーでやってまして、 都内でソフトウェアエンジニアをやっております。
今は金融系の会社におりまして、 地方の銀行様向けにバンキングアプリ開発などをやっております。
得意状況はWebフロントエンドですかね。 その前はネットワークエンジニアとかやってましたね。
はい、ありがとうございます。 で、今回はおにぎりさん、ゲスト2回目ということで、特にトークテーマもないということなんで、
前回から今回にかけて、最近どう?みたいなところを話していければなぁと思うんですけども、
まずお仕事的なところからいくと、特に転職などはされておらず、 2020年の11月が前回で71回目だったんですけど、変わらずってことですよね?
そうですね。ちょうど多分転職したぐらいの時で、 その会社に3年ちょっといるので、まだ転職はしないですね。
はい、どうですか?3年働いてみて。
いやー、3年あるといくつかサービスをリリースできるんで、 考え深いものはありながら、逆にこの職場とかメンバーとか、
あとはドメイン知識も結構ついてきたりして、 慣れありつつも、自分って成長してるのかな?みたいなのを最近よく考えたりしますね。
あー、マンネリ化みたいな。
なんかこの、自分のポジションがガッチリできちゃうと、 そこに依存しちゃっていいんじゃないか?みたいなのが、私結構気にするタイプなんで、そこがすごい気になりますね。
あれですかね、コンフォートゾーンみたいな居心地がいい状態みたいな。
そうですね。
いやー、わかりますね。
生辞知ってるんで、なんか小誤答いうおじさんになってないかな? みたいなのがすごい気になりますね。
いやー、ちょっとわかるなぁ。
なんか、その役職にしろ経歴にしろ、その環境で長くなると、いろいろ気になっちゃうじゃないですか。
新しい人の振る舞いとか、実装されている行動とか、技術的不細とか、その辺に対してなんか、小誤答というか、思うことはあったりはしますよね。
03:00
その辺りはもう、普段は大っ広げというか、ちゃんとフィードバックする感じですか? 飲み込んで我慢する感じなんですか?
フィードバックしてずつ、じゃあどうやって一緒にやっていこうか、みたいな方向にはできる限り持っていくようにしてるんですけどね。
まあでも、それがやっぱりベストというか、ベターですよね。
なんか、まあ私最初からプロジェクトにいるんで、その不細作った一人でもあるんで、なんか全部お前らが解決しよう、みたいな感じになっちゃうのも、なんか雰囲気も良くないし、
なんていうんですかね。いや、お願いされている側もやる気ないと思うんですよね。
そうですね。なんか、よくその、スタートアップベンチャーの文脈で語られがちですけど、
汚くても、不細があるコードでも、お金を生み出していれば正義か否か、みたいな話もあったりするし、
その技術的不細を、じゃあ作った人が返すのか、今いる人が返すのか、もう既にいなかったりする場合もあるので、
その辺り、なんかプロダクトの成長に伴って、ソースコードの健全さっていうんですかね、みたいなところって難しいですよね。
そうですね。結構難しかったりします。
なんかその辺りは、例えば週に何%は技術的不細を返すとか、チケットとかタスクの何%はリファクタリングに使うとか、なんかそういうのはやってたりするんですか?
いや、やってないんですよね。なんか理由があって、プロダクトの想定の持ち主というか、知財は僕らが持ってなくてですね。
なんか会社全体で業務委託を受けてるみたいな感じなので、
初期のリリース終わってしまったら、その後、コードを修正してはいけないってことはないんですけど、
人のリリースをある程度回すお金の流れがなくてですね。
なので不細は不細のまま、次の開発が入ればそこで一緒に解決しようみたいな感じになっちゃってますね。
じゃあなんか自由にソースベースに触れるっていうよりも、次はこの機能をやるから関係するところだけ触るとか、新規追加するとか、そういう感じなんですね。
そうですね。
そうすると、あそこ気になるからついでに直しましたみたいなのは、ちょっと契約上というか大人の事情で難しいっていうのはありそうですね。
06:03
そうですね。なんかまぁ、デグレしないとか影響しないなら全然しれっとやっちゃってもいいと思うんですけど。
いじっちゃったらバグらないというか、デグレない、デグらないっていうのは保証できないから難しいですよね。
そうですね。あとはなんか、ここ実はこうだったからちょっと変えといてって言われたことが、
なんかどこのドキュメントにも落ちないけど、コードには実装されていると、これは要るのか要らないのかみたいなのがわからなくなるんですよね。
なんか僕も今の現場で、なんか毎週仕様定例会みたいなのやってるんですけど、
そこで漏れたとか、考慮できてなかったのは、メールかなんかでやり取りしてるっぽいんですよね。
うん。
で、その結果がスラックのチャットにしか残ってないっぽくて、お客様とのやり取りで使ってる設計書には反映されてないっぽいんですよ。
うんうん。
なので、ある時点の成果物、なんか詳細設計シーケンス図とか、ソースコードとか、テストだけ仕様が変わってて、
お客様とやり取りしてる原本の、例えばDB設計書とか、そこの補足欄に書かれてる、ここのカラムはこうこうこういう仕様で参出、参照するみたいな仕様と食い違ってる場合があって、
どっちを信用すればいいのかわからないみたいな、ありがちですよね。
うん。
なるほど。最近はじゃあ、どっちかっていうと、マネジメントとか、もともとテクリードだったと思うんですけど、今もそんな感じですか?
そうですね。もともと前職では新規事業のテクニカルリードっていう感じですね。
現職はプロジェクト自体のだいたい一人目みたいな感じだったんで、業務委託の人を含めプロパーの人も一緒に採用していって、チーム作りつつプロダクトリリースするみたいな両輪で回してる感じですね。
じゃあ、プレイングマネージャーに近いんですかね?
そうですね。なんか、明確に会社からの権限がないけど、実質そんなことやってるみたいな感じですね。
ああ、それって評価に反映されてたりするんですか?
うーん、なんか、それをやってるから評価されてるかわかんないけど、なんか評価されてるんじゃないかなっていう感じはします。
09:07
まあ、特に評価とか給料の面で不満はそこまではないみたいな感じですかね?
そうですね。ただ、もともとチャレンジングなことをやったんで、もう少し自分の市場がわかんないんですけど、
なんか、新しいことをやったことに対して、なんか給料がちょっとでも上がるといいなっていうのは思っていますけど。
会社的には企画して、その計画立ててやったことだから、できて当たり前みたいな評価になりがちなんですかね?
そうですね。まあ、どうなんでしょうね。会社自体がそんなに長くないので、評価体系ができてないっていうのが多分一番大きいと思います。
結構そういう会社多いですよね。
うん。あとはソフトウェア開発だけやってるわけじゃなくて、いろんな事業を一つの会社でやっているので、
なんか、それを踏まえて最大約数的な評価体制を作るのが難しいのかなと思ったりしてるんですよね。
うーん、そうか。確かに。よく営業とエンジニアと、あとはカスタマーサポートとか、そういった複数の部署の評価とか給料のランクというんですかね。
まあ、つけた方がいいっていうのはあるんでしょうけど、つけすぎるのもモチベーションに響くので、そのあたりの評価制度って難しいですよね。
うん。あとはある程度人が今揃っちゃったんで、結構技術責任者的なコードを書く機会が徐々に増えて、今は言ってるので、なんかそういった面もありますね。
あー、逆にコードを書く機会が増えたんですね。
そうですね。
それはなんか、ペアプロとかモブプロとかではなくて、個人でコードを書いてっていう、いわゆる一開発者として参加してるっていう側面ですかね。
そういう側面もありますし、あとは技術責任者、テックリードなので、メンバーのある程度育成のためにモブプロやったりとか、あとはメンバーが8人ぐらいいるんで、ある要件定義を8人全員で聞き抜くのって結構無駄だったりするんで、
1人、自分が誰かが仕様を聞いてきて、その人と一緒にモブプロやるみたいなのはよくやりますね。
なるほど。
うん。
じゃあ結構、テックリードというかリーダー的な振る舞いというか役割を本当にこなせるって感じですね。
12:08
そうですね。チームの連動が結構上がってきたんで、ゴリゴリこれやってあれやって言わなくても、ある程度プランニングでタスクが細分化されてたら、優先度に従ってタスクをやって実装はメンバーしてくれてますけどね。
あと分かんないことがあれば自主的に聞くとかなってるんで。
じゃあもうチームとしては安定域というか、実装できる状態になっている。3年も経てれば人の出入りはあるにしろそうなっていくものかもしれないですね。
そうですね。
さっき話題に出たモブプロはどうですか?結構やってみて効果とか効率とか話題にされがちだと思うんですけど、おにぎりさん的にはどうです?
どうなんでしょうね。結構3年ぐらい経っちゃうと長く、分かんないことあれば分かんないことありますって手を挙げて、その人とその時間に手を挙げている人が一緒にモブプロをやるみたいな形式が多いんですね。
それは一定効果を上げているというか、一人で問題をかけてスタックしないっていう問題に対しては非常に有益かなと思ってます。
やっぱり銀の弾丸ではないので、使い所というか、何でもかんでもモブでやればいいってものでもないだろうし、何でもかんでもシングルがいいってことでもないと思うので、そこはやっぱりケースバイケースというか、それに適したものを使うっていうのは基本ですよね。
そうですね。なので、私たちはチームの活動をスタックしている人が一人で悩まないための方法としてモブプロを使っている感じですね。
なので、逆に言うとよく語られるのが、教育、育成とかナレッジシェアとか、技術的なナレッジをシェアしたりするのにはそんなに効果は出ていないかなって、目的をチームのスタックしないっていうことに置いちゃってるんで、育成観点ではあんまり効果は出ていないかなっていう感じはありますね。
なんかよくモブプロの文脈で語られる、あの本番障害が起きたから人が集まってきて、ここが原因じゃないかとか、このメッセージならあの機能じゃないかみたいなのをわーっと一式でやった後、解決するとなんかバッと元に戻っていくみたいな、
そういう感じで誰かの困りごとを集まって解決して、解決したらまた戻っていくみたいな、そっちがモブに近い感じですか?
15:12
そうですね、はい。
全然いいと思います。なかなか今、僕の会社だとモブとかペアをやる機会がないので、そういうチームを持てるの羨ましいですね。
一方、ただチームとしては非常に良いんですけど、各個人フォーカスあった場合、将来的にというか、一人で解決できる力を持ってほしいっていう気持ちもあるんで、その辺がどう醸成していこうかみたいのは結構悩んだりしますね。
うーん、確かに。なんか言い方があれかもしれないですけど、分かんなくなったら聞けばいいやとか、モブで解決すればいいやみたいなのになると、ちょっと足利き本願というか、結局モブって他の人の時間使ってはいるわけなので、その辺のリソース効率とフロー効率みたいなところの考え方はありますよね。
そうですね。やっぱり一回聞いたことは、なかなか一回では覚えれないんですけど、次は引っかからないようにするとかいう営みがあると、よりみんな成長するかなと思いますね。
うーん、なかなかその辺りは難しいですよね。
そうですね。なんかチームとしていい感じなのと、それでもお前一人でできるようになるよっていうので、なかなかこの意図が相反するというか、悩ましいです。
そうですよね。なんかチームとしてのアウトプット、アウトカムみたいなところと、個人としての成長みたいなところで、別に相反するものでもないんですけど、じゃあ比例して一緒に上がっていくかっていうと、そうでもない時もあるので、意外と両立させようとすると難しいなみたいなところはありますよね。
そうですね。
なるほど。興味深いです。
最近お仕事で、これは差し支えない範囲でいいんですけど、お仕事で書かれているプログラミング言語としては何がメインなんですかね。
もう原則に入って、JavaScriptというかTypeScriptしか書いてないですね。BackendもTypeScriptなんで。
そうなんですね。TypeScriptはそうか、でも別にバージョンがそんなに変わって劇的にあれってこともないから、JavaScript、TypeScriptっていう感じですよね。
18:02
そうですね。チームもそんなに8人くらいなんで、同じ言語の方がナレッジシェアもしやすいですし、コードがある程度読めるんでお互いに。
Web、フロントエンドとバックエンドのコードが一応レポジトリ分けてるんですけど、と言いながらもコードをお互いに読めた方がいいと思うんで、っていう意図はありますね。
やっぱりフロントとバックで言語が違うと、それぞれ採用とかになったりして、フロント側でこういう値が欲しいとか、こういうリクエストを飛ばしたいみたいなのがあった時に、いちいち濁らないとできないみたいなのはちょっと効率悪いと思うので、
フロントとバックで同じ言語で同じ技術スタックでできるっていうのは結構重要。効率面から言うと重要っていうのはありますよね。
はい。
で、お仕事でJavaScript、TypeScriptやられてるわけですけど、ご自身、おにぎりさんご自身が興味あるのもJS、TSって感じですか?
最近ずっと書いてるんで、別の言語をやりたくて、去年ぐらいからラストを少しずつ勉強してますね。
ラスト流行ってますもんね。
そうですね。フロントエンドのフレームワークとかエコシステムの内部実装がラストだったりすることも結構増えていたので、そういった意味でちょっと興味が引かれてるというか。
やっぱり速度が重要な、特に最近は開発者体験みたいなところで、サーバー、ローカルサーバーの立ち上げだったりとか、ビルドだったりとか、
あとはトランススクリプト、あとはもうバンドルサイド自体が小さいみたいなところも重要視され始めていると思うので、ラストで書いて速度が速いっていうのは大きいメリットかなぁとは思いますね。
あとはJSというかブラウザーだと良い感じでガベージコレクションされちゃうんで、メモリー管理とかもう少し厳格なというかレイヤーが低いところを考える気概があんまりなくてですね。
エンジニアの自分のレベルとしても危機感があるので、そういった意味でラストは良いサンプルというか課題だなと思ってますね。
確かにGCがある言語だとあんまりメモリーした実装ってしないですし、じゃあ今からC言語、Cプラって言われるとちょっとひどいものがあると思うので。
21:00
まあやっぱラストとかあとはなんだろうな、ジュリアとかもあんのかなという感じ。あの辺が良いんですかね。
じゃあ言語としてはその辺りでどうしようかな。フロントエンドの話に行くとリアクトとかビューとかアンギラとかいろいろライブラリだったりありますけど、その辺りはどうですか。興味あるのはどの辺ですか。
そうですね。もうここ4年ぐらい仕事ではリアクトしか書いてないですね。なので今のところはリアクトにしか興味がないです。
実際NPMのダウンロードランキングとかでも飛び抜けてリアクトが多くて、確か数億か十数億リアクトで、次がビューで3億とかみたいな数だったと思えているので、やっぱりリアクトかなーっていうところはありますよね。
ただなんかリアクトだけだと、あれらが目指しているメカニズムというかが、もちろん一つの理想に向かってやってるので、その理想の上でしか乗っかれないから、エンジニアとしてどうなのかなと思ったりするんですけど、じゃあどれ勉強しようかなみたいなのはまだ考えてないですね。
なんかRuby on Rails使ってるとRailsっぽいものにしかならないというか、そういう感じですよね。
最近はちょっと名前忘れちゃいましたけど、スベルトとかでしたっけ?いろんなフロントエンドのライブラリいっぱい出てるっぽい。そのあたりもなかなか業務で導入するのは敷居が高いかもしれないですけど、まあいろいろまた出てきますよねっていうのはありますよね。
じゃあ現状はだいたい聞いたので、ちょっと未来の話というか、これからやりたいことみたいなところをちょっとお聞きしていくと、今テックリードとかフロントエンド、バックエンドもやられてるってことだったと思うんですけど、どうですか?なんかこれやりたいとか、もっとこういうことやってみたいみたいなことあります?
そうですね。なんか全然関係ないことやりたいですね。何て言うんですかね。なんか割と飽き性なんで、あとは物事しないタイプなんで、なんか待遇さえ変わらなければ全然違うことをやらせてもらえるとすげー嬉しいなっていうのは常々思ってますね。
それはもういわゆるドベイン知識というか、業界が違うとか、そういうビジネスレベルで違うっていう感じですか?
24:06
いや、なんかエンジニー、業種ですね。どっちかっていうと。
その…
業種、職種か。ごめんなさい。
フロントエンド、バックエンドみたいなじゃなくて、例えばインフラとか、カスタマーサクセスエンジニアとか、デブリングとか、エヴァンジェリストとか。
そうですね。
はいはいはい。
はい。
まあ、エヴァンジェリストとかは結構旗から見てて面白そうだなーとかは思いますけどね。
まあ何が面白いんですかね。面白いと言ったら似合うかもしれないですけど。ということで。
まあ確かに、何が面白いかはやってみないとわからないっていうのはあるかもしれないです。
逆に何かあります?ホルテさん。やってみたい。
僕、そうですね。1回はやっぱり、役職ってか役割なんですけど、スクランマスターをしっかりやってみたいなっていうのはあって。
僕はせっかく認定スクランマスターを持ってますし、なんだかんだ更新も続けていて、勉強もやってるので。
1回現場で試してみて、まあ死ぬほど大変だっていうのはわかってるんで。
どんなものかっていうのは、1回やってみたいなっていうのがあって。
で、去年の年末ぐらいに、実はスクラムで開発やってたんですよ。
あー、はい。
それは開発者として入ったので、スクランマスターではなかったんですよね。
はい。
で、スクランマスターがいないスクラムだったんですよ。
でもその時点で、これやべえなって思ってたんですけど、案の定大炎上して、スクラムではない何かになり下がってしまったので、
もうちょっと上手くいくというか、ちゃんとしたスクラムをやってみたいなっていうのが。
そういう場合では、スクラムの選挙士兼開発エンジニアみたいなのが頑張ったりするのがよくあるかなと思ったんですけど、なかなか大変ですよね、それも。
そうですね。いくつか理由があって、そうすべきというか、それができるのをわかっててやらなかったっていうのはあるんですけど、
まず思って、スクラムの理念というか考え方上で、兼任ってNGなんですよね。
スクラムマスター兼開発者とか、スクラムマスター兼プロダクトオーダーみたいなのは良くないっていうのがあって、
開発者としてジョインした以上は開発者としてやる、まずはそこを全うすべきっていうのがあったんで、あまりスクラムマスターっぽいことはやってなかったっていうのが一つ。
27:02
2つ目がビジネスの問題っていうのがあって、自社サービスとかでスクラムとかやるんだったら、いわゆる越境みたいな組織に働きかけるみたいなことは全然できると思うんですけど、
今回自宅で開発者として入っちゃったので、そこの職域というんですかね、求められてる、もう言っちゃえば契約上のものを逸脱して、このスクラムのやり方おかしいみたいなことを言ったところで、
お前1回開発者じゃんっていう話にしかならないし。お客様もそれを望んでるかっていうと、多分望んでないというか、まずはコード書いてほしいと思うので。
雑談レベルで、スクラム今回やってますけど、スクラムガイドとか読んだことあります?とか、振り返りの際にこういうのもありますよみたいな話はちょこちょこしてはいたんですけど、抜本的に腕まくりして書いてやるぜみたいな感じはあまり出さなかったですね。
さっき、建物の話をされてたんですけど、この会社3年やってみて、このプロジェクトに2割、このプロジェクトに8割みたいな仕切りがよく見かけるんですけど、全然そうはならない。建物って不可能だなと思ってます。
めっちゃわかります。SIRの文脈で言うと、人月方式みたいのがあって、このプロジェクトに0.1人月とか0.05人月とかアサインされてて、なんかあると質問とか有識者としてなんか喋るみたいな感じはあるけど、何もなければ何もないみたいなのはよくあって。
それぐらいだったら名前だけで済むんですけど、朝会議には出てくれとか会議に参加が必須になってくると結構建物ってきつくなってきますよね。
特にやっぱりこれだけリモートワークが進んでくると、大体オンラインのやり取りがメインなんで、分割するのが無理だと思うんですよね。仕事を。だってお前スラックにいるやんってなりますからね。
いやそれはわかるなぁ。なんかオンラインかオフラインかぐらいのステータスしか見えないじゃないですか。その人が今どれぐらい忙しいかとか、どれぐらいまあ言い方あれですけど炎上している案件なのかとかってわからないので、
30:13
リモートワーク上のお作法というか仕事のやり方でいくと、まずは依頼してみるとか振ってみるみたいなやり方になりがちじゃないですか。
ちょっといいですかみたいな感じにはなかなかならないと思うので、いきなりチャットが飛んできて、これこれこういうのお願いしますとかできますかとかになっちゃうから、その辺なかなか難しいですよね。
なんか依頼されたり何か聞かれてる側が兼務してると、じゃあこのレスポンスをしないことによるプロジェクトの影響はどれぐらいなのかってわからないんで、なんかもはやこのレスポンス返さないといっても2割8割はキーブできるかって計算できないじゃないですか。
時間じゃなくて、提供する価値を多分2割と8割とかにしたいと思うんですけど、本来は。それが不可能に近いというか、それを見越して行動することができないはずなんで。
まあそうですよね。なんか保守運用じゃないですけど、どれぐらい問い合わせが発生するかとか、どれぐらい障害が起こるかみたいなことを予測するのと同じだと思うので、
それを予測して2割8割で予算というか時間分配するのは不可能ですよね。もう来たらやるしかないですもんね。
そうですね。来たらやるしかないと思うんですよね。
今日というか、これで5回目なんで、もう店じゅうまいです。ガラガラってわけにいかないじゃないですか。
そうですね。なんか今日月曜日なんで、チャンネル抜けますみたいなことはできないですからね。
そうなんですよね。やっぱりマルチタスクが良くないっていうのと同じで、兼任とか兼務って本当に良くないと思うんですよね。
その分、後輩だったり部下だったりメンバーを育成して権限以上をしていくっていうのがあるべきというか理想の姿なんでしょうけど、なかなかそれをやれる、まず個人としてやれる人も少ないですし、
それを組織でやれるっていうのも難しいというか少ないと思うんですよね。だって今回ってるんだったらそれでいいじゃんっていう考えになりがちだと思うので、
33:03
わざわざ混乱期というかコストを払って、権限以上して、また上手く回るまでにちょっと助走期間を設けるみたいなのを判断というか実行に移すのは難しいですよね。
そうですね。でも当て先が欲しい。例えば人が辞めたときに、その人にやってた領域に対して質問したりお願いしたりする立場の人が一旦投げ下げがないとたぶん仕事が回らないんで、だいたいそういう結果、兼務ってできると思うんですよね。
なんで、兼務は良くない、仕事は回らないと思いながら、なんかしょうがないかなみたいな瞬間があったりするんで、悩ましいですね。
そうですね。他のポッドキャストでも兼務について喋っておられる方がいて、結局解決策がないんで、何かいい案があればみたいな感じだったんですけど、正直もうだいたいの人を用意するしか根本的な解決にはならないそうもんね。
そうですね。採用を早くするしかないと思うんですね。
言うて採用も難しいですもんね。
だいたいこれで現状とやりたいことと今ある課題みたいなところを聞けたと思うんですけど、なんか他にエンジニア話しへ話しておきたいことってあります?
リアクトずっとやってるんですけど、OSSってみんなが抱えてる課題を頭のいい人がOSSに落とし込んで解決してくれてると僕は思ってるんですね。
はいはいはい。
僕らの現場よりもう少し先のことを考えて、ライブラリーとかOSSとかのリリースをやってると思うんですよね。
それとは別の世界で、僕らって機能のバグとかライブラリーのバグとか解決するためにバージョンアップとかしないといけないじゃないですか。
うーん。
そうした場合、メジャーのバージョンアップ上げた時から介護感がないとまでは言わないけど、このメジャーバージョン上げたら急に思想が変わったなみたいな、解決する問題が変わったなみたいなのがあるんですけど、
メカニズムとかが変わっちゃうと、書き方とかプラクティスとかも変わっちゃうんで、そういうのってプラクティスをみんなに教育し直さないといけないのって結構コストだなって最近特にリアクトとかを触ってて思いました。
36:06
いわゆる破壊的な変更だったりとか、方向性ですよね。
ビューだとビュー2からビュー3に上がった時とか、あとはリアクトだとちょっと前ですけどリアクトフックスとか、あの辺のパラダイムシフト的なところもありますよね。
最近だとリアクトだと18からコンカレントレンダリングみたいな並列にレンダリングできるようなメカニズムが追加されて、そういうのがあったりしますね。
今までルートからツリー構造で状態に応じて仮想DOMを生成して前後の仮想DOMの差分を実際のHTMLに反映するみたいな大体メカニズムだったんですけど、
そうすると、これリアクト18のリリースとかに書いてあるやつなんですけど、重い処理を一気にやっちゃって、ブラザーシングルスレッドなんで、その計算のうちユーザーの操作が受け付けないみたいになるんですね。
そこに対するパフォーマンス的な課題解決として、ツリー構造で一気にやるんじゃなくて、ここの枝の下に関しては遅延させるみたいな、そうするとその計算部分だけ分割されるんで、その間にユーザーの操作が受け付けるみたいなんですけど、
そういうメカニズム、こういう便利機能を追加したぜみたいなメカニズムの追加があったときに、このメカニズムを使うプラクティスに従われ終わりないんで、そういった場合、そこから一から教育するとか、自分もキャッチアップしてるしかないといけないんで、キャッチアップしたのもメンバーに言っていくみたいなのが大変だなと思って。
僕らはただバグを解決したいのに、すごい交渉の話をしないといけないのが大変だなって最近。
セキュリティとかもあるんで、バージョンを上げないっていう選択肢は、よほどのウェブ上に公開されているアプリである上はないと思うので、上げるしかないけど、上げるに伴う苦痛というか、コストが重いってことですよね。
なんかね、その辺り機能バージョンアップとセキュリティとかバグフィックスのパッチ的なバージョンアップと分けてやってくれると導入者としては嬉しいですね。
39:01
とはいえ、ライブラリーとかミドルウェアとか提供する側からしたら、せっかく作った新機能だし、わざわざ分けて管理するのも手間じゃないですか。一緒に入れたくはなりますよね。
なりますね。
同じ開発者として立場はよくわかりますもんね。お客様に機能開発とバグは別で管理してくれって言われたら結構しんどいですもんね。
なんかその辺り解決策考えるとしたら、チーム全員でキャッチアップしていくとか、ハッカソンじゃないですけど、新機能とか新バージョンを入れるってなったら手を動かして触ってみるみたいなのをやっていくしかないんですかね。
そうですね。とりあえずメジャーバージョンアップのリリースされた時のブログとか読むとか、そこにフィロソフィー哲学とか書いてあるので、それをみんなで読んで議論するとかやっていかないとなーとは最近思いますね。
その辺りってなかなか開発コストというか費用として表に出しづらいじゃないですか。
そうですね。あとは何か各々のエンジニアとしての目指したい方向とかにするポイントも違ったりするんで。
やっぱりとりあえず機能追加して難忘症みたいな、バグだったらとりあえず直すみたいな、フィロソフィー知らんがなみたいな、そこまでは極端なんですけど、その辺の方向性というか、人によって結構違うなーっていうのはありますよね。
なのでリリースノートをみんなで見よう会しても、どれだけみんな興味を示してくれるのかがまだちょっとわかってないですね。
まあそうですよね。僕も会社のスラックにカンファレンスの資料の共有とかやったりはしますけど、どれほどの人が興味を持って読むところまでやってくれてるのかって言われると、
計測の仕様がないですし、なかなか人によって違うっていうのもさっきおっしゃられた通りなので難しいですよね。
どこかの、別にGoogleに限った話じゃないんですけど、GoogleとかNetflixとかその辺の進んだ企業がそういうのはどうしてるか公開してくれるとありがたいんですけどね。
今ちょうどGoogleのソフトウェアエンジニアリングのライリーの、結構重厚なんですけど、それをちょくちょく読んでたりしますね。
やっぱりその辺の悩みって万国共通だと思うので、そういう事例が知れると勉強になっていいですよね。
42:00
そうですね。
じゃあエンジニア話としてはこんな感じで良いですかね。
じゃあ最後に軽く最近の趣味というか、なんかハマってることの楽しい話があればお聞きしたいなと思うんですけど、最近は何にハマってる感じですか。
最近ハマってるというか、家にやる趣味が多いんですけど、Netflixとかでやるのが、アニメとか見るのが唯一の趣味と言っていいやつかなと思ってます。
最近見てこれは面白かったっていうアニメなんかあります?
最近ですか。でもこの前、先行のハサヤ見たんですけど、面白かったですね。映像というか戦いシーンとか面白かったですけど、
その前がガンダムシードとか見てたんで、正規の歴史があるじゃないですか。なんていうのか忘れたんですけど、そこの線に乗った話を久しぶりに見たんで、思い出すことがいっぱいあったりとか。
ハサウェーって誰だっけみたいな。シャアって名前と顔は覚えてるけど、どういう思考の人なんだっけみたいな。思い出したりしてました。
まあそうですよね。フランチャイズというかシリーズというか、長く続いている作品の一つを切り取ったところを見てる感じなので、前後に繋がりがあるって言われると、なかなか見てる見てないもありますけど、見てたとしても覚えてないとか。
しかも名前も同じガンダムじゃないですか。ちょっと外からしたらわかりづらいですよね。
特に先行のハサウェーは彼の持っているビジョンみたいなのがあるじゃないですか。そうした時にシャアとかって何を目指してたんだっけみたいなのが逆に気になったりするんですよね。
なんか結構比較で見ないとわかんなかったりするんで。 そうですよね。どっちかっていうとハサウェーはシャアとかアムロとか、あの辺りに影響を受けてマフティとして活動しているみたいなところがあると思うので、
じゃあ逆襲のシャアっていう作品でやってたアムロとかシャアが言ってたこと、やってたことっていうところがわからないと、ハサウェーの行動原理というか、感情を引入しづらい部分はあるかもしれないですね。
そうですね。シャアは最終的に地球をゼロにしてとしたかったんでしたっけ。
45:06
そうですね。シャアは地球上に住んでいる人々を全員宇宙にあげたかったっていうのがあって、そのために地球に人が住めなくする。
いわゆる、かつての冬とかそういう言われ方をしている現象を引き起こそうとして、小惑星アクシーズを地球に落とそうとしてたっていうのが、逆襲のシャアの表向きというか、ネオジオンのシャアの目的の一つですね。
よかったです。それ聞けて。
何なんだっけなと思って。地球管理化作戦とか。
住めなくするってことですよね。
そうですね。要は地球上にいる一般人はともかく、地球連邦の好感とか利権に群がる人々を粛清したかったっていうのが、表向きの正義というかそういう部分だった。
先人類が住めないけど好感だけ地球に残るとしてるって、他を打ちにあげようとしてたんですかね。
その好感を粛清したかったっていう、どっちかっていうと、あまり一般人の動向は気にしてなかったと思います。
なるほど。
で、それを見てたハサウェイがマフティで連邦の好感の粛清というかテロで殺害とかをやってたのはそこから来てるって話ですね。
なるほど。ありがとうございます。
あとはあれですね。ネットフリックスの進撃の巨人アニメがいよいよ最終章の最終話みたいなのが今年やったんですよね。
1年越しに終わったんですけど、やっぱ面白いなと思って見てました。
進撃もだいぶ長かったし、かなり評判いいんで良かったというか、終わって本当に良かったですよね。
そうですね。原作は結構前に終わってるのに、アニメだけでもすごい人気なんですごいなと思いました。
結構伏線というかその辺の改修の仕方が評判になってて、ネタバレなしで見たくなる作品ではありますよね。
そうですね。私も結局ネタバレ見たかな。ちょっと見てなくてアニメ見たんで良かったです。
それは良かった。もう最近はネタバレにいつ出会うかわかんないんで、もうその辺の自衛は大変ですもんね。
でも大体大悪は知ってたかもしれないですね。てか避けるのは不可能に近いんでしたね。原作だいぶ前に終わってるんで。
ああそうか。原作終わってますもんね。アニメ勢とかで原作読んでないとかだったらあれかもしれないですけど、とはいえ原作の話が流れてきちゃうのはあるんで、まあ難しいですよね。
48:14
そうですね。原作の画像とかコーラとかツイッターで回ってきた時点でなんかわかっちゃうことあるんで。
いやーわかるなー。なるほど。じゃあ時間的にもちょうど1時間ぐらいでちょうどいい感じなんで、そろそろ締めようかと思うんですけど、最後に何か言っておきたいこととかあります?
そうですね。特に宣伝することはないんですけど、ツイッターでアットマークおにぎりアンダーバーでツイッターやっていて、技術的なこともたまにつぶやいてるんで、もしなんか興味がある人はフォローしてもらえると嬉しいです。
はい。じゃあ毎回貼ってるんですけど、視聴者のところにツイッターへのリンク貼っておく。あ、もう今Xですね。XQツイッターへのリンク貼っておくので、ぜひぜひ何々していただけるとありがたいです。
じゃあこのポッドキャストアウザラFMの告知をやって締めていきたいと思います。
連絡方法はツイッターのDMなど何でも大丈夫です。アウザラFMではご感想やご意見をお待ちしております。
ツイッターでハッシュタグシャープアウザラFMシャープAOZORAFMをつけてツイートしてください。配信ページのお便りボタンからお便りを送ることもできます。ぜひよろしくお願いします。
さらにお願いですが、アウザラFMではご支援を募集しております。PIXIVファンボックスかOFFICEで支援できますので、支援してもいいよという方は配信ページのリンクから支援可能ですので、何卒よろしくお願いします。
それしてゲストの告知ということで、先ほどあったツイッターのアカウントの方よろしくお願いしますということなので、興味がある方はおにぎりさんのアカウントぜひぜひ覗いてみたりフォローしてみたりよろしくお願いします。
じゃあ最後に久しぶりのポッドキャスト収録ですかね。どうでしたってところを聞きたいんですけど、どうでした?
そうですね。なんか淡々と喋りすぎてて、コンテンツとして大丈夫かなってすごい不安になりました。
51:08
まあでも雑談系のポッドキャストなんて大体そんなものだと思うし、仮になんかゲームとかテック系とかトークのテーマを設けてたとしてても、喋ってる時はそれについて喋ってるか否かの違いでしかないと思うので、普段の会話を聞きたいっていう人にとっては全然アリだと思います。
よかったです。
ありがとうございます。じゃあ第81回目はゲストにおにぎりさんをお招きしてお送りしました。おにぎりさんどうもありがとうございました。
ありがとうございました。
