概要 「最近のアイドルは顔の見分けがつかない」という話をSNSでよく目にする。 で、逆に思うのだが、顔の見分けがつく昔のアイドルって誰なの？ 考察1 真っ先に考えられるのは松田聖子や中森明菜のような80年代のソロのアイドルだが、ソロアイドル同士の顔を見分けるのとグループアイドルのメンバー同士の顔を見分けるのとでは、そもそもタスクの内容が違うので比較にすらなっていないだろう。 グループのアイドルというのはそれぞれに多少の個性はあるにせよ、ある程度は同程度の属性でまとめられるものだ。 もしくは本来は異なる属性だったとしても、グループのコンセプトに合わせて属性をアジャストしていくことも往々にしてあるだろう。 例えば、自分が嵐の幻の6人目のメンバーだったとしたらどんな人間でも絶対に他のメンバーと見分けがつくはずだ。 だって顔面偏差値が違いすぎるから。 じゃあなぜ自分は嵐に入れないのだろうか？ それも顔面偏差値が違いすぎるからだ。 百歩譲って自分がイケメンだったとしても、例えば身長が150cmだったり200cmだったとしたら、やはり嵐に入ることはできないだろう。 百歩譲って自分がイケメンだったとしても、例えば髪型がアフロだったりモヒカンだったとしたら、やはり嵐に入ることはできないだろう。 グループアイドルはそもそも属性が似た人間を集めているのだから、ソロアイドル同士と比べて顔の見分けがつかないというのはある意味当然のことだろう。 考察2 少し昔のグループアイドルを考えてみる。 グループの存在自体は知っているが一人一人の顔を知らないアイドルとしてパッと今思いついたのがSPEEDだったので公式サイトから写真を引用してきた。 で、見た感想。 SPEEDファンがいたら申し訳ないが、初見だと左から1人目と3人目の区別が付けられる気がしないです…。 結局のところ、昔のグループアイドルであっても、個々の顔を見分けるのは難しいだろう。 結論 そもそも人の顔を見分けること自体がかなり難しいタスクだと思う。 自分も学生時代はクラス替えしてから3日間くらいは見分けを付けられないクラスメイトがいた。 宿題を返却する仕事を任せられた時に「〇〇さん、これ」と別人にノートを渡して、めちゃくちゃ変な空気にしたこともある。 人の顔を見分けるのって難しいのだ。 じゃあなぜ「昔のアイドルは見分けることができた」と言う人が多いのか？ そのアイドルに興味があったからだろう。 じゃあなぜ「最近のアイドルは見分けることができない」と言う人が多いのか？ 年齢を重ねて世の中全体のことに薄っすら興味がなくなったからだろう。 なんの根拠もないが割と筋の良い仮説だと思っている。

大学生の頃、研究発表のパワポを指導教官にレビューしてもらっていたときに、「例示やメリット・デメリットは3つずつ列挙すると説得力が増すよ」とアドバイスを貰ったことがある。 そのアドバイス自体は実際に有用なんだろうなと思いつつ、どこか非本質的に感じている自分がいた。 ドンピシャなものを1つご用意することができたなら、3つも列挙せずとも十分に説得力をもたせることは可能なんじゃないかと思っていた。 そこから数年の時が経ち、去年このブログを書き始めた時に心に決めたことがある。 それが『伝えたいことが最低限伝わるなら、たくさん列挙しなくてもオールOK、ウフッ(ローラ風)』だ。 たとえばリモートワーク推進派のポジショントークだなと思う発言2選という記事では、良い感じのポジショントークの例を3つも思いつかなかったので2つだけにした。 でも言いたいことは全然伝わる内容になっていると思う。 また、別の観点として「最低3つは例示やメリット・デメリットを列挙する」という縛りを無くしてから、ブログを書くのがすごく楽になった気がする。 飽き性の自分がなんだかんだ1年以上ブログを続けられているのも、そういう気楽なスタンスで書いているからかもしれない。 みんな適当に記事を書こう！

概要 いわゆるSIerに転職して1年が経過した。 入社してすぐに大規模案件にアサインされ、1年経った今も同じプロジェクトに所属している。 そのプロジェクトでは、全てのAPIについて詳細設計書が存在している。 で、1年間そんな現場で仕事をしていて「詳細設計書がある現場って関数分割いらなくね？」と思うようになった。 ちなみに、ここで関数分割いらなくね？と言っているのは1つのサービス層内のビジネスロジックを細かく複数の関数に分割しなくてもよいのでは？という話である。 責務を分割するためにコントローラー層やリポジトリ層を作るなという主張ではない。 複数のサービスで横断的に使われる機能を抽出してコンポーネント化するなという主張でもない。 そこのところをご理解ください。 というわけで、なぜ関数分割が不要だと思ったかの理由について以下に述べる。 1. 関数分割をすると実装と詳細設計書を照らし合わせるのが面倒になる 詳細設計書が上から下へと処理の流れが一方向に続いているのに対し、関数分割をされたコードでは処理が上に行ったり下に行ったりする。 基本的にAPIの改修をするときは詳細設計書を見て、実装と照らし合わせて、そこからようやく修正が始まるのだが、関数分割されたコードではこの照らし合わせの作業が非常に面倒になる。 2. 関数分割しなくても詳細設計書があるので可読性は落ちない 一般に関数分割のメリットとして可読性の向上があげられるが、これについては詳細設計書にどのような処理をしているかの記述があるので詳細設計がある限りにおいては関数分割をしなくても特に可読性は落ちないと思っている。 むしろ、前述したように関数分割していない方が詳細設計書とコードの対応が取りやすくて可読性が上がると思う。 3. 関数分割しなくても再利用性は落ちない(気がする) 次に関数分割のメリットとして良くあげられる再利用性だが、そもそもAPIを作っていて同一のサービスのクラス内でそんなに再利用する関数ってないのでは？と思っている。 一番再利用性の高い機能はDBとのやり取りだと思っているが、これはリポジトリ層に責務が分離されているのでサービス層側で関数を分割する必要はない。 次に再利用性が高いのはメール送信機能やビジネスルールの検証機能だと思うが、こういうのはサービス層内で関数分割するのではなく、新規にコンポーネントを作成してサービス横断的に利用できるようにしてしまう。 ちょっと考えてみてもサービス内でのみ繰り返し利用される関数があまり思いつかなかった。 まあこれは自分の経験が浅いだけかも。 4. 関数分割しなくてもテスト保守性は落ちない(気がする) 最後に関数分割のメリットとして良くあげられるテスト保守性だが、そもそもJava等で関数を分割する場合はprivateメソッドに処理を分割するはずで、privateメソッド単体のテストをすることはできないので、結局はビジネスロジック全体のテストをすることになると思う。 なので特にテスト保守性が落ちることもないのではないかと思う。 まあこれは設計書うんぬんの話ではなく、privateメソッドが存在する言語においては結局こうなっちゃうよね、という話だな。 まとめ かかってこいよ、リーダブルコード！！ #PR リーダブルコード 楽天

Konbuに新機能を追加した Konbuという勉強時間を記録するWebアプリを運営している（ちなみにユーザーは自分ひとりだけである）。 このアプリには勉強時間を記録する際に勉強した科目を選択するためのメニューウィンドウが存在する。 上の画像を見ていただければ分かるように、メニューウィンドウ内の科目はこれまでは50音順に並べられていた。 ただKonbuをドッグフーディングする中で、最近勉強した科目5つくらいが上位に表示される方が便利だなと思うようになってきた。 というのも、毎日ほぼ同じ科目を勉強しているだけなのに、毎回その科目をウィンドウ内から探すのが地味に面倒だなと感じ始めていたからだ。 キーワード検索で科目を絞り込む機能は搭載しているので、目当ての科目を探すこと自体は非常に簡単に行える設計になっているが、そんな簡単な作業も毎日のこととなると地味にダルい。 というわけで、直近で勉強した科目上位5つまでをメニューウィンドウ内の上部に表示する機能を追加することにした。 自画自賛だが、結構使いやすくなったと思う。 学生等は勉強する科目数が社会人と比較すると多いので、上位5件ではなく上位10件くらい表示した方がいいのかもしれないが、まあそういうのはユーザー数が増えてから考えればいいかな。 まとめ ドッグフーディング大事。

デフォルト原理主義 自分はデフォルト原理主義者である。 デフォルト原理主義とは、PCやアプリの設定を極力いじらず、デフォルトの状態で使うことを至高とする考え方である。 これからデフォルト原理主義の良さを紹介する。 1. 結局デフォルトが最適解であることが多い ソフトウェアの設定について一番時間をかけて考えているのは誰なのか？ 答えは当然ソフトウェアを開発している人間だ。 基本的には利用者よりも開発者の方がソフトウェアに対して理解が深いはずだし、悩んでいる時間も長いはずだ。 必然的にデフォルトの設定は洗練されていて最適解である可能性が高い。 新しいソフトウェアを使い始めた時はなんとなく使いにくいと感じる瞬間もあるかもしれないが、それは一時の慣れの問題に過ぎないこともしばしばだ。 個人的な経験則ではどんなソフトウェアも使っていくうちに手に馴染む。 2. 設定をいじるのが面倒 そもそも設定をいじるのが面倒だ。 デバイスを複数台持っている場合には各デバイスごとに設定をいじる必要があるし、ソフトウェアのアップデートで設定がリセットされることもある。 エンジニアになりたての頃は設定をいじることすら楽しかった記憶があるが、今では設定を変更する方法を調べるためにGoogleを開くことでさえ面倒だ。 以前、ある料理人がYouTubeで「休みの日はお湯を沸かすのすら面倒くさい」と言っていたのを見て、どの業界も似たようなもんだなと思った。 3. そもそも設定をいじれない環境がある これは自分がSIerで働いているからかもしれないが、そもそも設定をいじれない環境があったりする。 毎朝のセキュリティチェックでレジストリが変更されていたりすると怒られたりするのだ。 会社のPCと自宅のPCで利用しているソフトウェア自体は一緒なのに設定が違ったりするとコンテキストスイッチが大変だ。 ならば自宅のPCの方を会社のPCと同じ設定にすればいいのだ。すなわちそれがデフォルトだ。 まとめ 今朝起きてVSCodeを開いたら配色が変わっていた。 もちろん元の配色に戻す方法は検索しなかった。 経験でそのうち慣れるだろうと分かっていたからだ。 そして今VSCodeを使ってこのブログを書いているが、正直5分くらいで慣れたな。

概要 NBAMashというサービスをVercelでホスティングしているのだが、最近レスポンスが遅いなと感じていた。 色々と調査したところ、VercelのリージョンがデフォルトだとワシントンDCになっていることが要因の1つであることが分かった。 そこで今回はVercelのリージョンを変更する方法について紹介する。 方法 リージョンを変更したいプロジェクトを開く 上部のバーから「Settings」を選択する 左のサイドバーから「Functions」を選択する Function RegionsのAsia Pacificのアコーディオンメニューを開いてTokyoまたはOsakaにチェックをして、「Save」を押す ちなみにHobbyプランの場合はリージョンを1つしか選択できないのでデフォルトの「North America (Washington, D.C.)」のチェックを外す必要がある。 Saveを押すと右下にダイアログが出るのでそこから再デプロイをおこなう(手動で再デプロイでもOK) 結果 リージョンを変更した結果1リクエストのレスポンス時間が約30~40msに改善した。 ちなみに改善前のスクショを撮り忘れてしまったが1s以上かかっていた。

概要 2025年ももうすぐ終わりなので、今年1年を振り返ってみる。 仕事 転職をした。 前職は社員数4人の超小さな会社で、良くも悪くもヌルい環境だった。 納期という概念は事実上存在しなかったし、ぶっちゃけ仕事をしなくても怒られない環境だった(学生の頃はそんな企業が存在するとは思いもしなかった)。 ホワイトといえばホワイトなのだが、張り合いはなかった。 そんな中で「このままだとエンジニアとして成長できないんじゃないか？」とか「先輩たち全然仕事していないけど俺だけ頑張っても意味ないよな…」とか色々と考え込んでしまった。 環境を変えられないか自分なりには色々模索した(社長と話したり、先輩社員と話したりした)のだが、変化の兆しが見えなかったので、そこで転職を決意した。 そして10ヶ月ほどのフリーランス期間を挟んだ後に無事に現在の会社に転職することができた。 転職先は前職とは打って変わっての大企業だ。 納期は厳しいし、仕事量も多い。体力的には結構しんどい。 だけど、同時に成長実感もめちゃくちゃある。 技術的にやっていることが前職より高度だし、周囲に優秀なエンジニアがたくさんいる。 今のところめちゃくちゃ楽しい。 自分的にはこちらの方が合っていたんだろうなと思う。 今年リリースしたサービス konbuという学習時間を記録するサービスをリリースした。 詳しいことは勉強時間を記録するWebアプリを開発したという記事に書いたのでそちらを参照してほしい。 ちなみに今DBを叩いてみたらユーザー数は自分一人だけだった。 とても悲しいが自分自身が使いまくっているのでセーフということにしておく。 今年読んだ本 これ以上は特に書くこともないので、今年読んだ本を列挙して終わりにする。 #PR プロになるJava-仕事で必要なプログラミングの知識がゼロから身につく最高の指南書 楽天 【書評】プロになるJava #PR 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 楽天 【書評】体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 #PR プロになるためのSpring入門 - ゼロからの開発力養成講座 楽天 【書評】プロになるためのSpring入門 #PR Java言語で学ぶデザインパターン入門 第3版 楽天 【書評】Java言語で学ぶデザインパターン入門 第3版 #PR パスキーのすべて ── 導入・UX設計・実装 楽天 【書評】パスキーのすべて #PR ポストモーテム みずほ銀行システム障害 事後検証報告 楽天 【書評】ポストモーテム みずほ銀行システム障害 事後検証報告 まとめ 今年読んだ本は実務に直結するものばかりだな。

信じる力 小学生の時、『金色のガッシュベル!! 友情の電撃 ドリームタッグトーナメント』というゲームにハマっていた。 このゲームにはガッシュコレクションという収集要素があり、特定のミッションをクリアしていくたびにコレクションが解放されていくというシステムになっていた。 コレクションは全部で100個あり、そのうち99個までは簡単に解放できたが、1つだけどうしても解放できないコレクションがあった。 その最後に残ったコレクションの解放条件とは、とあるミニゲームでひたすら連打して50000点を超えろというものだった。 この条件が非常に難しく、ただ連打するだけなのにも関わらず、何度挑戦しても50000点を超えることができなかった。 「もうちょっとで50000点超えれそうだったのに〜」という感じにすらならなかった。全然余裕で50000点に届かないのだ。 工夫を凝らして攻略しようと思っても、なにせ連打するだけなので工夫のしようがない。 爪を立ててゲームボーイアドバンスのABボタンを擦るように連打しては親指の皮膚を無駄に消耗するだけだった。 あまりにもクリアできないので、なにか裏技みたいなものがないとクリアできないんじゃないかと途中から疑心暗鬼になり始めた。 結局、コレクションを全部集めることはできず、しばらくの間そのゲームは投げていた。 ある日、友人が家に遊びに来たので「どうしてもこのミニゲームがクリアできないんだよね」となんとはなしに話しかけてみた。 すると友人は「いや、俺これ行けると思うけどな」と返してきた。 内心、絶対ムリムリと思っていたのが、とりあえず友人に挑戦させてみることにした。 すると、友人はあっさりとそのミニゲームをクリアしてしまった。 友人が一体どうやってこのミニゲームをクリアしたのかというと、なんてことはない、ただただ本気で連打しただけだった。 自分と同じように爪を立てて擦るようにABボタンを連打しているだけだった。 友人が正攻法であっさりとクリアする様子を見て、自分でももう一度そのミニゲームに挑戦してみた。 すると不思議なことに、あれだけ苦しんだミッションをあっさりとクリアできてしまった。 今思い返すと、当時の自分は「裏技があるんじゃないか？」「擦って連打する以外のもっと良いやり方があるんじゃないか？」のような疑念がある状態でミニゲームをプレイしていて、無意識に連打に集中できていなかったのだと思う。 このときは運良く連打に自信のある友人が目の前でクリアしてくれたおかげで、そのような疑念を打ち消すことができ、「ただ純粋に連打すれば良い」という指針を自分の中に立てることができた。 でもこのときはたまたま運が良かっただけで、あらゆる事象において誰かが先人として道を切り開いてくれるとは限らないだろう。 自分達が選んだ方針が正解なのかどうか分からない中でも、「きっとこの方針は正しい」と盲信して全力で取り組むことで開ける突破口というのもこの世には存在しているんだろうな。 まとめ コレクションの「かいほう」って「解放」と「開放」どっちが正しいの？

フロントエンド技術の流行り廃りが激しい理由ってフロントエンドのほうがバックエンドよりも難しいからだよな。 バックエンドってイベント(リクエスト)とその結果(レスポンス)は一箇所に決まっているから、素直なコードになりやすい。 でもフロントエンドってユーザーの操作という複数種類かつ複数回のアクションがあって、それを正確に矛盾なく画面に反映させないといけない。 根本的にフロントエンドの方が処理がややこしいから、なんとか現状の問題を解決するために新しい技術が次々と生まれては消えていくんだろうな。 SPAを捨てたら複雑さはかなり減ると思うけど、それだとユーザー体験が犠牲になる…。難しい問題ですな…。 学生の時にIT企業でインターンを始めたときは、自分の書いたコードが分かりやすく即座に画面に反映されるフロントエンドの方が開発していて楽しいと思っていたけど、最近は考えること多くてダルいなーって気持ちのほうが強くなりつつある。 どこかの天才がフロントエンドの枯れた技術を作ってくれるまで、ほどほどに流行を追いかける感じでやっていこう。

概要 仕事で金融系のシステムに関わることになったが金融系の知識などまったくない。でも教科書的な書籍を読んで1から体系的に金融のことを勉強するのはダルい。 そんなおりに本書を発見した。 「これ読んだらシステム開発について理解を深めながら自然と金融の知識も学ぶことが出来て一石二鳥じゃん！」と思い即購入。 #PR ポストモーテム みずほ銀行システム障害 事後検証報告 楽天 感想 正直、途中で飽きた。 基本的には実際にあった出来事を淡々と追っていくスタイルの書籍なので、物語性は薄めで読み物としては面白さに欠ける。まあ、ノンフィクションって普通そういうもんなんだろうけど。 なんとなくシステム障害の裏には人間ドラマのようなものがあるんじゃないかと思いこんでいたが、実際には事前の準備の不足やビジネス層と技術層のコミュニケーション不足といった至って普通の問題が積み重なって起きた障害だった。 しかし、世の中で生じるシステム障害というのは大抵こんなもんなのかもしれない。明日は我が身ですな。 個人的には巻末にあるCIOのインタビュー記事が一番血肉の通った内容で面白かった。 あと「見逃し三振はOKだが、空振り三振はNG」（アラートをあげなくて良い場面でアラートをあげるのはOKだが、アラートをあげるべき場面でアラートをあげないのはNGの意）という標語は分かりやすくて良いなと思った。似たようなことは現場でもよく言われるが、こういう分かりやすい標語で言語化されると実践しやすい。 ちなみに本書は金融の知識とITの知識の両方がないと割と理解が難しいので専門外の方は安易に手を出さないことをおすすめする。