# のんちゃんの奮闘記 ノンちゃんと ともの ボイコード ボイシーエンジニアの声と出会えるチャンネルボイコード このチャンネルではボイシーエンジニアの日々の活動をお話ししています。 はい すみませんグダグダしてしまって いいよいいよ あれ、ちなみに新年入って初っ端? あ、私は初めて あ、ですよね 僕もそうなんでちょっとここから温めていきますか 温めていきましょう あれ、ともさん個人チャンネルとかやってます? 個人チャンネル、年末までは撮ってて 年始撮ろうと思ったんですけど なんか家の空調、空調じゃないですけど なんか撮ったら雑音みたいなのがすごい入ってて なんかこれダメだなと思って ちょっと出せずに終わってるんですけど ちょっとさすがにもうそろそろ出さないとやばいみたいな もう1ヶ月終わりそうみたいな感じなんで ちょっと個人チャンネルも頑張ってやります やっていきましょう、いいですね で、今日はですね はい、何について 今日のテーマは最近格闘したこと、奮闘したことみたいな はいはいはい もう私はいつも奮闘するので そう、なんかのんちゃん大体なんか奮闘機描いてるイメージあるっていう そう、私はいつもバタバタしています やっぱりなんかですね、いろんなところをチャレンジしてますからね じゃあ他の人からしたら本当にそんなことをやってるんですか? みたいなレベルの低いことなんですよ いやいやいや 低いことではあるんですが ちょっとね、他の人よりスタートが遅いっていうところで いつも奮闘をさせていただいております でもいいですね いろいろなんかそこまでやっちゃうみたいな感じなのはあるんで ちょっとこの後詳しく聞いていきたいですね はい、じゃあ私の最近の奮闘を はい、お願いします 2つあって 1個はLTまた参加してますみたいな感じなんですけど 奮闘というか あーってちょっとなんか悲しいじゃないんですけど 準備したんだけどなーみたいな え? ところで言うと LT参加して 前同じLTの第2回だったんですよ 1回目が30人くらい参加されてたんで ちょっと気合い入れてくぞと思ったら5人でした 今回は人数が少なかったんだ せっかく発表しようって意気込んでいたのに ちょっと残念ながら集まらなかった回だった 軽め奮闘 いやでももうなんかその辺慣れてますよね もうなんか人数がいないことにちょっと もうなんか何かを感じられるぐらい LTに参加して頑張って発表しなきゃしなきゃ みたいな感じがやっぱり多いのかな 僕結構そういう感じなんですけど でも知ってましたもんね そうですね 年末ぐらいからにLTしたんですけど 何話そうかなーとか当日大丈夫かなーみたいな そっちの方にばっかり意識いってるんですけど もうキャパのこと考え始めちゃっている 次のステップ行っちゃってました 行っちゃってますね ちなみに去年って何回くらいLTされてましたっけ? でも3回か4回 いやでも多いですよね それまでだって確かやったことない やったことなかったですよね なのでいきなりチャレンジしようと思ってから もうなんやかんや4回くらいやってる そうかも しかもあれですね 下期からなんてやり始めたの 夏ぐらいから 全然1年まだ経ってない 割とほぼ月1ペースぐらいの勢いですよね すごい そうですねこれは奮闘というか 奮闘かな?奮闘してますね そうですね結構やっぱり技術発信みたいなところで エンジニアって求められるから 僕もやんなきゃやんなきゃと思いつつ 自分の好きなアウトプットはするけど ちょっとLTとかだとちょっと肌高ぇなみたいな まあそうですよね って感じになるんですけど そこらへんちょっとどんちゃんは 気づいたらどんどん応募してるから これ俺やばくない?みたいな 差付けられてるぞみたいな 慣れていかなきゃいけないなと 多分そこのマインドですよね ムチを打ってますね でも別にそんなものすごく得意なタイプだったとか そういう感じじゃないですよね めちゃくちゃ苦手ですね 外で喋るのもううううってなります おっしゃってましたけど とりあえず締め切り駆動で 一旦申し込んでからね 申し込んでなんかちょっとダウンタイム ダウンタイムみたいなの入ってますよね なんかちょっと あー終わっちゃったみたいな 申し込んじゃったー みたいな そこももう回数で どうです? ちなみに最近そんなに LTに応募することに対するハードルって そんなないかも なくなってきてる? そうなんだ これ逆に 半年とか空けたら また同じぐらいのエネルギー必要なんで やり始めるのに ちょこちょこ出してこうみたいな そこのハードルを回数打って慣らしていくっていう 感覚絶対空けないみたいな 確かに それは確かに奮闘ですね 怒涛の勢いのLT もう一個の奮闘は ギットなんですけど はい来ましたね ちょっと最近私 練習の成果が出たみたいなタイミングがあって 不具合を見つけて チームでね 見てるときに あれこれ いけんじゃん あれこれ文字間違えてない みたいなのを 5年前とかの 確かにあの文字5年越しに発見するっていうね ちょっと直してみますって言って まともさんのレビューもめっちゃ早くて 多分全部でトータル30分ぐらいで マージまで終わったりして すごい私いけるかもしれないみたいな いや早かったっすよねびっくりしました だからこれいけるかもと思って 他のレビューしたり見てもらってるぐらいあったので これもこの調子で流れでやってもらおうと思って レビュー出して いけますと これでOKですってレビューOK出て じゃあ最後動作確認というか 本業のテスト しようと思ったら 全然配布できなくて どうしようみたいな 何がおかしいんだろうと思って すっごい時間かけてたら 通りすがりのともさんが これ配布してるの違いますよ その前に不具合修正をやっていたんだけど 作業を開始した時点が結構遅くて それでコンフリクト起きてたんですよね最初は 上手く配布できなくて それをレビューの方に指摘してもらって 新しく作り直して それでやったらいいんじゃないのって話で やってたんですよね だから2個あったんですよこの世の中で コンフリクト起きてるやつの方を ずっと配布できない 新しいものだと思って ともさんからめっちゃ初心者の 作るたびに番号が新しくなるので 2個あったら番号多い方が新しいですって まじでそうですよね ちょっと考えたら分かりますね でもあれは 初心者のミス 慣れてないと難しいですし 僕も正直GitとかGitHubあんま得意じゃないんですよね エンジニアなんですけど あんまり得意じゃなくて めちゃくちゃボンミスしたっていう ただ数字を見間違えたという ボンミスをしました 奮闘というかバタバタします いやーそれ焦りますよね 僕もだって一瞬見せてもらったとき なんでこれコンフリクト起きてんだろうってなって そうですよね そんな感じで最近のバタバタでした でもなんとか解決した よかったよかった じゃあ次はともさんバタバタ じゃあ行きますか 次のチャプターで行きます # ともの奮闘記 では、最近のトモさんの奮闘というか、なんかこれ難しかったなぁとか そうですね。2つくらい、なんか最近ちょっと難しいなと思うことがあって 1個は既存のコードを安全に回収していくことが意外と自分が思ってたより難しいなっていう風に感じていて アプリのコードというと、もともと使われ、今動いているアプリの中身だけ変えるみたいなことですか? そうですね。ソースコードは変えるけど挙動を変えないということ よくエンジニアってリファクタリングしましょうとかって言われるじゃないですか 実際、自分も業務しててここのコードちょっと直したいなとかって思うことは全然あるんですけど いざやろうと思うとそんな簡単にやっちゃいけないよねみたいなことも結構あって 無邪気にソースコード変えてリファクタリングしましたって言いたいんですけど そもそもテストコード書かれてなかったりとか なんか自分の感覚ではこれちょっとコードを別の場所に移しただけだから 実際読んでるもの同じだが大丈夫なんじゃないとかと思っても 意外となんかそれはちょっと微妙かもねってなんかしてきたれることもあったりとかして 安全にコードを変えるってことは思ってる以上に難しいし リファクタリングってものがあんまり自分わかってなかったなっていうか なんとなくコードを直すことぐらいの感じだったんですけど 意外とそこって難しいなっていうか 中身をより開発しやすくするような変更を加えるけど 動きは変わらない 動き変えちゃうとユーザーさんがこれ壊れてるんですけどみたいな感じになっちゃうので そこは変えないで基本的にはロジックとかを変えるだけにしたいんですけど 結構いろんな要因でリファクタリングが難しかったりして 例えばどういう要因があるんですか テストコードが書いてないとか書けないとか テストコードが書いてないっていうのはどういうことですか ちょっと難しい話になってるんですけど イメージはあって プロダクトコードの横にテストコードありますよね ファイルは違うんですけど それに対応するプロダクトコードとそれに対応するテストコードっていうのが ある程度基本的には一致するような形で 基本的には対になって同じ行数分ぐらい この部分の実装されたものの別ファイルで同じ部分のテストが入ってるぐらいの感じで 理想としては入ってる そうですね テストってそもそもロジックのあるものだけテストするんですけど コードって のんちゃんも名前ぐらいは聞いたことあると思うんですけど ストラクトとかクラスとかって言われる入れ物 オブジェクトみたいなものがあって それ単位だったりとか あとはその中に書いてある関数単位でやるんですよね なのでこの動作をするみたいなものに対して その関数があって それに対応するテストが存在するみたいな そんなイメージになるんですけど ポチって押したら再生が始まるみたいなぐらいの そうそうそうそう そういうのに対して再生が始まるっていうことを どういう風に中で処理をしているのかってことをテストしてあげるみたいな このケースだったらどういう挙動になるべきなのか みたいなことをテストコードで書いていくっていう感じなんですけど そもそもそのテストコードが全部書ければいいんですけど 現実的にいろんな理由で書けないところがあったりとかして ちょっと複雑になりすぎてるところとかは もちろん頑張ってもテスト書けないとか テストが書けないと その動きが正しくリファクタリングできてるかわからないから リリースできないみたいな リリースできないというよりかは どこかしらで別の担保をしてあげなきゃいけなくなるって感じですね エンジニア的には単体テストが通ったら 既存の動きをちゃんと網羅してますよって言えるのが一番安心感がある もともとと同じ動きだなって テストが書いてあるとテストが落ちなければ それはちゃんとコードとしては機能してますよってことを 一応単体テストレベルでは保証できるので そうなってくると単体テストが通るようにコードを変えれば 絶対に大丈夫でしょって言えるみたいな そこの安心感みたいなのがあって でもテストコードがないと 自分が考慮漏れてたパターンの処理がうまく通らない 既存の動きと変わっちゃうみたいなこととかが起こりうるので そうなってくると じゃあ主要で全部テストするんですかとかってなってくると 結構大変だよねっていう それがやっぱり一個自分が思ってたより難しいなと思って どうやってリファクタリングを進めていくのかみたいなところも もうちょっと自分で勉強していかないといけないな みたいなのが思ってたより難しいなって 最近奮闘しているところです じゃあ2個あるんですか? 今の話の流れでよく覚えてる 2個目は最近僕結構UIの修正をしてるんですよ 見た目を変える あれが意外と難しくて イメージ、中身を変えるよりも 確認しやすそうなイメージはあるんですよね 中身のロジックを変えるよりも 見たら分かるから 動作しながら変えたりとかできそうなイメージなんですけど そうなんですけど なんでそうなってるのかを確認しづらい 例えばロジックに関して 正しい動きかどうかって いわゆるプリント文みたいなログを挟んだりとかして ここを通ってるからこういうロジックになってて ここが間違ってるんだよねとかが わりと分かりやすい なんでその挙動になってるのかは わりと突き止めるのがロジックの方が簡単で UIはなんでそういう見た目になってるのかが分からない 例えば自分の思ってた挙動にならない 例えば今回僕が触ってたところで 本来であればiPhoneの上の方って ステータスバーって言われる 充電の残量とか あそこに背景色を付けたくないなって思ってたんですよね 全画面にやりたい修正があったの そこの部分だけ色を特定の色にしたいとか したくないみたいなのがあって それをやろうと思った時に 下の色が上に広がっちゃってたみたいなのが起きてて それが起きた時に なんでそうなってるのかを突き止めるのが結構大変 なんでそれほど複雑じゃないビューに関しては そんなにビュー作るの大変とかってことはないんですけど やっぱりプロダクトコードぐらいの複雑なものとか もう一種のアプリだと ホームの画面とか結構作りが難しい部類にはなると思うんですけど そこら辺とかを触ってると あんまり直感的な挙動にならないというか なんでこうなってるのかがパッと分かんなかったりすることもあって しかもAIは割とそっちはそんなに得意じゃない傾向が どちらかというとある 見た目の方が 見た目を思い通りに動かす方が難しい そうですね なんでそこはもうちょっと自分の経験値つけないと スムーズに変更みたいなのが難しい場合が結構あるなとか思って 最近はそこで それこそ普段最近の開発って 1個の機能に対してそんな時間かけないんですよね 長くても1日ぐらいなんですけど 今回その諸々の修正やるのに2日ぐらいかかってて もうなんか本当にAIとラリーしまくって そうなんですか 全然なんかああでもないこうでもないって色々やってたんですけど なかなか自分の思った通りにできなくて みたいなところは結構苦労しましたね そのAIじゃなくて自分の手でやるみたいな方が 簡単だったり難しかったりする時もあるんですか 場合によりきりですけど でも今だと結構AIに頑張って直させる方が早かったりする その方が多いですね なるほど そんな感じでちょっと 2人の奮闘 奮闘してました ありがとうこれからもよろしくお願いします こちらこそお願いします # コメント返し 最後にコメントの返信をしていきたいと思います。 放送が勉強法について語ろう会ということで、 コメントが全部で4件。 ありがとうございます。 これ私ですね、1個。 面白いテーマ、技術者を例えがちは分かるということで、 たまたま自分がコメントした回を読み上げることになりました。 アサミさんから頂いてます。 ありがとうございます。 一番最初に作ったのはデルファイというものかな。 ちょっと自信ないですけど。 電卓です。 読み方が合ってないかもしれない。 電卓? 電卓を作ったらしいですね。 最初は変数も分からず、 イコールを押しても値が空っぽで、 え?となりました。 私今も分かってないです。 多分電卓アプリなんで、 足し算してイコールって押したら、 値が出て欲しいんだけど空っぽになってたみたいな、 多分そういうこと。 そうなんだ。 本来デルファは表示されるんだけど、 自分がアプリを作った時に、 そのロジックをちゃんとうまく含めてなくて、 多分そういうことですね。 難しいですよね。 そうなんだ。 でも身近に使うものを作ってみるの面白いですね。 確かになおちゃんも作ってましたよね。 私も確かに計算する系のアプリを作りました。 あらあら。 じゃあそこら辺は似てますね。 似てますね。 続いてキングダムさんからいただいてます。 ありがとうございます。 ありがとうございます。 たかまてぃさん、ささん、いつもありがとうございます。 先週のついてるさんのコメントは、 1日中ボイシュー聞いてたという意味ではなく、 24時間ボイシュー、 いいのかな、というイベントに参加してました。 我々もオープニング参加させてもらいました。 聞いてみてくださいということでいただいてます。 先週の放送のところのコメントのリプライということですね。 ありがとうございます。 ありがとうございます。 24時間ボイシューすごいですよね。 ちょっと聞きました、私。 全部聞いてなくて。 僕もまだ聞いてないんですけど、 これあれですか、24時間ボイシュー。 いろんなパーソナリティさんがつないで、 リレーみたいな形でつないで、 すごい。 私たちもボイシュートークリレーで、 リレーでつなぐのをやってたので。 確かにあれすごかったですよね。 ちょっとびっくりしました。 いや、すごい。 24時間だから、 深夜3時の担当の方とかっているってことですよね。 あれですよね。 24時間テレビみたいな感じのボイシー版って、 すごいなと思ってちょっと見てましたね。 しかもやっぱりキングダムさん、 プロリスナーとして、 オープニング。 確かにね。 オープニング参加してるのすごいですよね。 すごいですね。 Pの方のつながりじゃないですけど、 結束の強さを感じるようなイベントでしたよね。 素敵。 ありがとうございます。 ありがとうございます。 今後もお願いします。 お願いします。 最後、ついてるついてるついてるさん。 はい。 コメントいただいてます。 ありがとうございます。 ありがとうございます。 ボイシー聞いてコメントするのが、 今の勉強法です。 嬉しい。 嬉しい。 ちょうど今日は結構技術技術した話を。 確かに技術技術の話かもしれない。 しましたね。 確かに。 いや、そうなんですよね。 私も結構ボイコードを聞いたり、 ボイシーの、 私はQAという品質の仕事をしてるので、 関連のパーソナリティさんの放送を聞いたりとか、 ボイシーパーソナリティさんの本を読んだりとか、 結構勉強になるので。 確かに。 技術に限らず、 いろんな分野のプロフェッショナルの方が発信してるから、 結構知りたい情報とかは結構知れるっていうのは。 勉強法ってあんまり自分が捉えてはいなかったですけど、 確かに。 勉強にはめちゃめちゃなりますよね。 それで言うと、 新木マスターの失敗、世界失敗図鑑でしたっけ? 何でしたっけ? はいはいはい。 あのあれですよね。 のんちゃん買ってたやつですよね。 買って私は個人チャンネルで放送もしたんですけど、 あれはね、 めっちゃ品質に関わる人みんな読んだらいいっていう。 そんな良かったんですね。 ちょっと気になるな。 しかもそこから何を学んだかみたいなところの 学びがすごくたくさんあって、 これはいいなと。 そこ繋がるんですね。 そう繋がるんだと思いながら、 日々勉強だなと思っています。 コメントありがとうございます。 ありがとうございます。 今日も聞いていただきありがとうございました。 ありがとうございました。 次はどの声と繋がりますか? 引き続きボイシーでお楽しみください。