a1yamaの2025年のcommitment

社内共有したものを少し公開できる形にしてインターネットの世界に残しておく プレッシャー駆動ですね 👍

zennにも転載した

zenn.dev

これはa1yamaの2025年頑張るぞいという意思表明です 個人的にやりたいことも、チームとして課題に感じていることの解決など、とりあえず2025年にやることを書いていく

はじめに

いつも来年の目標は決めているけど、達成できなかったり頑張ったからいいかぁとかなり甘い評価をしていることに気づきスマホのメモに「2025年のcommitment」という題材でなぐり書きしていました
これは目標ではなくマニフェストのようなものです
ある程度周りの人を巻き込んで自分にプレッシャーをかけて課題解決等を行っていこうと思います
a1yamaのエゴな部分もありますがお声がけさせていただいた際は優しくしてください

自己紹介

Kyashでサーバサイドエンジニアをしているa1yamaです
a1yamaと書いて「あいやま」と読みます
入社当時同じ名字が何名かいたためハンドルネームで呼んでもらっています

ファシリテーターの積極請負

以前ファシリテーターを外部の人に依頼して課題出しから新規プロジェクトの案を考える会を開催した経験からファシリテーターに興味はあり少し勉強をしていました
ファシリテーションをする際はある程度事前準備することも大事だし、全く準備しないことも大事という完全に自分の力量を試される分野だと思いビビってきていました
2024年はそれなりにファシリテーターをする機会があり、また頑張ってみようと思いいろいろと試してきました
その経験をもっと活かせるように積極的にファシリテーターをやります
全然違う部署やチームのファシリテーターもしたいです
誰がファシリテーターやるの？ローテーションにしましょうか！ということでしたら私がやります
上手くないからやっぱりいいやっていうフィードバックでもいいです
いつでもwelcomeなので私の全然関係ないMTGでもファシリお願いしてもいいですか？と声をかけてください
最初はお願いしづらいと思うので私からお声がけします

サーバーサイドのチームビルディング

モバイルチーム良いよね！Kyashのアドベントカレンダーでも紹介があったようにいい感じに回っているように思う
https://blog.kyash.co/entry/2024/12/19/110248
Kyashは事業部制になったもののサーバーサイドという横の繋がりはなければいけないし、それぞれがそれぞれの動き方というのはいい面もあれば悪い面もある
そういったペインを解決するように動いていきます
サーバーサイドのメンバーのほうがどうしても多くなってしまうので全員の意見を反映することは難しいと思うけど、目線だけでも合わせられるようにしたいです
まずはみんなのことを教えて下さい
アンケートを取ってその結果を共有しつつペインポイントの解消を進めていきたいです
今いるメンバーも新しく入社するメンバーも開発しやすくなるような仕組みを考えていきます

越境

これも以前からやろうやろうと思って積極的に出来ていなかったことです
今は事業部ごとやチームごとにある程度担当する機能が決められています
現在はCredit事業部としてスポットマネーやBNPLを良いものにしていくように日々楽しく開発していますが、専門知識や能力というところを越えて幅広く自分の力を発揮できるようにします
同僚氏が不定期報でコンフォートゾーンを越えるという記事を書いていたけどそれに似ているなぁと感じています

⁠ドメイン越境

今はCredit事業部でスポットマネーやBNPLの開発を行っているが、元々はFundsチームで銀行入出金を担当していました
Fundsチームにいたので、銀行の入出金についてはある程度のドメイン知識はあるがKyashのドメインはまだまだあり、特にPaymentについてはほとんどないと言っても過言ではないです
Visaとのやり取りや電文の読み方などは知識がないのでまずはそこからやっていこうと思います
他の事業部やチームが現在行っている開発領域にも興味があるので、開発が落ち着いてきたら色々と教えてほしいし、コントリビュートしたいです
採用も進んでいてエンジニアの体制も変わってくるけど、自分のポジションはもちろん他のチームの領域にもガンガン入っていきたいです

職能越境

エンジニアとしての職能越境になりますが、元々Android開発も行っていたのでAndroidにもコントリビュートしたいです
と言っても2017年くらいの知識なので今の技術にアップデートする必要があります
KMPも分からないので覚えることは多そうだけど、ちょっとしたことをモバイルメンバーに依頼するまでもなく自分で対応してレビューでボコボコにされたいです

iOSはやってこなかったから無知だけど、余裕があったら教えを請います 🙏

ドキュメントの充実

やるぞやるぞと言って十二分には出来ていなかったドキュメントたくさん書くぞはちゃんとやります

越境をするからには得た知識はアウトプットしてどんどんと残していくぞ！

特に日々の業務の中で調べながらやっていることや聞かれることがあることはちょっとしたことでもドキュメント化していこうと思います
アラート対応やリリース手順、問題が起きた際のトラブルシューティングなどドキュメントがあると何か困った際に役に立つものがたくさんあると思います
特に年に1回や、不定期にやってくるような対応については過去のドキュメントを探して、そこから手順を調査・精査して行うことが多いです
kibelaやslackを探して対応すると時間がかかるので色んなところに書かれているドキュメントを綺麗にまとめておけるようにしたいです

さいごに

書いてみたものの書いていたらいくつも出てきてしまい、4つに絞ったものの、4つも多いなと感じています
「ドキュメントの充実」については色んな方にお願いすることもあるかと思います（30％くらいまで書き上げるので80%くらいまで持っていってくださいなど）
その他についても自分ひとりでは実行することが困難な内容があります
急にいろんなことをお願いすることになるかもしれないですが、助けていただけると嬉しいです
皆さんからの依頼もどんどんと投げてもらえると嬉しいです！何でもは出来ないけどやれることはやります！

ここまで読んでくれた方ありがとうございます
a1yamaやってんなって感じで暖かく見守ってくれると幸いです
それでは2025年もよろしくお願い申し上げます

Kyashに入社して1年が経った

Kyashに入社して1年が経ちました 思ったよりもあっという間という感覚だけど、ここ1年を思い出すといろいろありました

今までと違ってGo言語の環境だしFintechだし色々と不安があったけど、普段使っているサービスに携わりたいという気持ちで飛び込んで良かったと思っています 一緒に働いているメンバーはみんないい人で楽しいし頼りになるし日々成長しているという実感を感じています チームのリードを任せてもらったりとチームメンバーと一緒にバックエンド側だけではなくていろんな方とコミュニケーションを取りながら楽しくやっています やはりどの会社でも課題はたくさんあって1年間で感じてきた課題をまたこの1年でどうにか改善していきたいと思い目標設定をして頑張っているところです Go言語頑張らねば！と思っていたけどどちらかというとドメイン知識をしっかりと培うことが大事で今でも四苦八苦しながら開発運用をしています そもそもGo言語はそんなに頑張らなくても覚えられるので大丈夫だった（今までの知見も役に立っていると思うけど）

プライベート的なところでは今までは邦ロック等のライブやフェスに行くことが多かったけどコロナを堺に完全になくなり、今はクラシックコンサートに多ければ月1くらいで行っている ライブ大好きなので出不精だし面倒くさがりだけどいくつかライブのチケット買って3月4月5月くらいは予定が出来ている テックイベントやカンファレンスなどにもオフラインで顔を出し始めているので会場でお会いした方とは色々とお話したいです キャンプにも月1くらいでは行っていてスパイスカレーにハマったり割と充実した日々を過ごしています

色々あった1年ですが常にモチベーションは保たれているような気もするし、メンバーのモチベーションを保たせる存在にもなりたいし、奮い立たせる存在でいたい 尊敬する人が増え、大変と感じることはあるけどやりがいは感じているし、新しい目標・なりたい自分というのも見つかった One Teamでやっていっている感が楽しい会社でワクワクしたものを作っているのでこれからも頑張ろうと思う

技術的問題へのアプローチを考える

これは Kyash Advent Calendar 2023 の16日目の記事です。

Kyashでバックエンドエンジニアをしている @a1yama です。

Kyashに入社して本日で9ヶ月が経ちました。

思っていたよりも時間が経つのが早く、充実しているのだと実感している次第です。

また、技術的問題へのアプローチを考えるというタイトルですが、入社9ヶ月で感じたことを綴ったものです。

はじめに

Kyashに入社してから様々なプロジェクトに携わってきました。

Kyashで働いているメンバーは個々人の問題解決能力も高く、提案もたくさん出してくれます。

こういうときどうしたら良いだろう、どうしたら良かったのだろうという悩みは話し合いで比較的早く解決できるように思っています。

その中で技術的な問題やリリース時の問題をどのように解決してきたかを簡単に紹介できればと思います。

パフォーマンスに対するアプローチ

Kyashではサービス開始時からのトランザクションデータを大量に保持しています。

そのため機能追加や改修の際にパフォーマンスや負荷問題について気にしないといけない場面があります。

期間も短い中でどこまでパフォーマンスを考えながら開発ができるか話し合い、パフォーマンス計測を行いその結果から何かできないか話し合うことになりました。

パフォーマンス計測を担当したメンバーが事細かにドキュメントにまとめてくれて、ボトルネック部分をシーケンス図に書いたり、テーブルのレコード数を算出してくれたりとかなり分かりやすいドキュメントになっていました（見せれないのが悔しいくらい）

その中からパフォーマンス改善案をチーム内で話し合って、総意を得た後にマネージャーやその処理に詳しいメンバーに展開していきました。

結果的にそのプロジェクトでは今のままでも耐えうるという判断となりましたが、今までボトルネックになっていた部分ではあるから改善案の中から一つの対応を行う運びになりました。

まだパフォーマンス改善の対応は完全には出来ていないですが、対応する際には有益なドキュメントがあるのでやることは明確になっています。

また、他のチームからの意見としてもパフォーマンス、負荷問題についての話はたまに出てくるので、その際にも説明として使える資料になっているので大変助かっています。

プロジェクトの開発が始まる前にパフォーマンスの問題に着目して計測をして改善案を提示できる良いチームだなと感じた瞬間でした。

Cacheに対するアプローチ

KyashのCache問題についてもエンジニアメンバーから度々話が出てくることがあります。

大量のデータを捌くためにCacheを使っているので、Cacheを保持するタイミング、消すタイミングを気にする場面がいくつかあります。

入出金、決済、送金などトランザクションデータが多い中で集計をしないといけないのですが、その中で更に家計簿機能が追加になり、集計期間がユーザごとに変わるようになりました。

その機能を加えていざリリースを行ったのですが、正しく集計ができておらず間違った表示になっていました。

リリースは取り下げて原因を調査した結果、Cacheが原因ということが判明しました。リリース後にCacheを削除しようという判断になり、手動でCacheを削除することで想定通りの表示となり無事にリリースを行うことができました。

リリース後の振り返りの際にCacheの話になり、チーム内でどうしたらよかったのか話し合った結果、CacheのKeyをちゃんとバージョン管理して異なるリリースのデータが混ざらないようにしていればよかったという結論に至りました。

もちろんCacheを削除するという対応も間違いではないと思いますが、Cacheのバージョン管理をしていたらそもそもリリース時の問題も起こらなかったと思います。

もしくは先に表示がおかしくなるので、Cacheを消す手順をリリーススケジュールに加えておくべきだったかと思います。

何か問題が起こった際にすぐに原因を調査して、振り返りができているのでチームとしての成熟度は上がってきているなと実感しています。

最後に

Kyashに入社して9ヶ月が経ちましたが、チームメンバー、エンジニアメンバーが素敵な方ばかりだなぁと感じています。

Kyash自体の文化もそうですが、エンジニアだけではなく他の部署の方々も素敵な方が多く楽しく過ごしています。

今まで好きだったサービスに関われていることも嬉しいですが、それ以上に素敵なメンバーに出会えたことを嬉しく思っています。

もし興味がありましたらKyashの求人から応募してください。

目標と継続

1月の更新を忘れたのとキリが良いので毎月更新はやめようと思う。 最近書きたいこともなくなってきたし、結構時間がかかるからさっと書きたいときに書くもので良いと思う。

恐らく今月か来月くらいにババっと更新することありそうなので。そんな案件があるので。

書くこと出来たり書きたくなったら書く。

雑記はほどほどに

教育の効率

なにかのプロダクトではないけど、勉強という意味で Laravel + Vue.js でアプリケーションを作成しようとした。

複数メンバーで開発（勉強）を行っていく中である程度の設計、教育をする予定でした。

最初は Laravel + Vue.js + Vue Router + Vuex で構築をしたのだが、Vue Router が理解できない。元々LaravelのRouterに書いていたのにAPIのRouterしか書かなくて実際のパスってどこ？みたいな状況になった。

教え方が悪かったというのもあると思うけど、Laravelを少しでも触ったことがある新人からすると、急にVue Routerを使うと分からないらしい。

かと言って、個人的にVueを使うならVueで全部書きたい思ってしまうのでVue Router、Vuexも使いたいところだったけど、実際の業務でもそこまでは使わないかもとのことだったので、Vue RouterとVuexは不採用となった（結局最初に作ったところでは使っているけど）

例えば管理画面の作成で一覧画面の表示をコントローラーでテーブル参照して、bladeで行う
追加画面などの処理はAPIで行うといった要所要所でAPIだったりそうじゃなかったりとソースが散らかるのが嫌だったり、結局Vue使う意味とかなくなりそうで怖い

目的がLaravel + Vue.jsの勉強なのでそんなことはないと思うけど、そういうことは大いにありそうで、そこだけは結構懸念しているところではある

何かを勉強する前に、どのように勉強をするのが効率的なのかなどを教えるほうが先だったなと少し後悔しているけど、それはまた教えればいいので、とりあえずやりたいようにやらせてみようと思った。

勉強でもアプリケーションを作成しようということですべてをきれいにやろうと思ってしまった僕がいけないので、きれいにやるところとそうではないところをちゃんと決めてやっていこうと思う。

リモートだし、最初からgitきれいに管理しようとしないで、途中でもレビューするために途中のものをコミットしてもらうとか。rebase教えるのはあとにしてログが汚いままで進めて、ソース書けるようにするところを目標にするとか。

教育も効率よくって思っていたけど、あまり良くないのかもしれないと思う今日このごろ。

windows で npm コマンド実行するといろいろ失敗する

windowsでnpmコマンド使わないほうがいいです。

めんどくさいです。

きっとmacがいいんだろうね。

mac book pro買ってください。

npm install

npm installすると共有フォルダとかいろいろの関係もあってなのかそもそもwindowsでダメなのかちょっとちゃんと理解していないけどシンボリックリンク等の関係でエラーになる

--no-bin-linkオプション付けて実行しましょう

npm install --no-bin-link

ちなみにvagrantとかで共有しているなら仮想環境からでもオプションつけないと怒られる

それでもダメなときがあるから基本的にnpmコマンドはwindowsで実行しろが鉄則

npm run dev

cross-envがないって怒られる

これに関してはpackage.jsonいじれとかあるけど邪道すぎでしょ

gitで管理しているファイル変更するのはさすがに良くないのでないならちゃんとグローバルにインストールしましょう

npm install --global cross-env

Laravelでvueとかいろいろあるから（そうじゃなくてもコンパイル前提のフロントエンドの時代だからね）この辺は流石にやっておかないといけないよね

クリーンインストールしてから久々にvagrant環境でLaravel Mix使ったから忘れていた

Laravelの開発ならdocker使わせて～！

せめて環境はキレイにプロジェクトに含ませておいて～！

GitHub Actionsで複数サーバにデプロイする

事前準備

以下のところで（githubのsecrets）秘密鍵を登録する 名前は適当なものをつける 今回はSSH_KEYにした

https://github.com/{ユーザ名}/{リポジトリ名}/settings/secrets

実装

ルートの .github/workflows/deploy.ymlに以下を記載 ymlファイルの名前は適当なものをつける

name: deploy

on:
  push:
    branches:
      - master

jobs:
  deploy:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: composer install
        run: composer install
      - name: ssh key generate
        run: echo "$SSH_KEY" > key && chmod 600 key
        env:
          SSH_KEY: ${{ secrets.SSH_KEY }}
      - name: rsync deploy for remote1
        run: rsync -rptgDvz -e "ssh -i key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" ./ www@ホスト名:デプロイ先
      - name: rsync deploy for remote2
        run: rsync -rptgDvz -e "ssh -i key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" ./ www@ホスト名:デプロイ先

masterブランチにプッシュされたら仮想のubuntu環境でcomposer installして、secretsのSSH_KEYからkey作ってrsyncするってだけです。 普通に1箇所にデプロイするだけでも十分なのでこれでやってみるといいかも ただrsyncしているだけなので、ドットファイルとかデプロイ時に作成したkeyファイルも一緒にデプロイされているので、削除する処理が必要 rsyncのdeleteとかでも良いのかな？

参考になったところがいくつか記号をわざとなのか全角にしていてコピーしづらかったのでちゃんとしたやつです。

Laravel6.*でvue環境構築の準備

プロジェクト作成

composer create-project --prefer-dist laravel/laravel vue-laravel "6.*"

2020.10.31現在で6.20.2が降ってくる

$ php artisan --version
Laravel Framework 6.20.2

laravel/uiインストール

composer require laravel/ui:^1.0 --dev

laravel/ui vueインストール

php artisan ui vue

## フロントエンドパッケージインストール

npm install

Vue Routerインストール

npm install --save vue-router

フロントエンドビルド実行

npm run dev

参照 qiita.com Laravelの開発よって一部変わっていたところがあるのでメモ 多分しばらく8とかは使わないと思うので

僕らには選択する権利がある

技術ブログとはなんなのか。最近ほとんど雑記ばかりで申し訳ない。 誰に対して書いているわけでもなく自分の記憶を文字にしてあとで思い出すものだから気にしないけど。

フリーランスになってからいろいろと仕事をしてきた。 ほとんどが昔の知り合いとの仕事だけど、それで生きているんだけど、たまに全く別口からの仕事もある。 結論としては素人とは仕事したくないなのだけど、細かいことは以下の通り。

まぁその仕事が酷いという愚痴なんだけど、SIer上がりだからとか、個人仕事が自社開発のゼロ構築とかそういう話ではなく、単純に仕事として、一人のシステムエンジニアとして、話したい。 基本的に顧客はITに疎いとしても少なからずビジョンをもって仕事を依頼してくるものだと思う。 中には「ITよく分からないけど、エンジニアってなんかそこそこお金出せば全部やってくれるんだよね」みたいな感じで接してくる人いるけど本当にそういう顧客が一番めんどくさい。

サービスのアカウント作成も出来ないとか普通にいるし、いい感じにサイト作ってとか、参考資料も何もないし、素材も使えそうなものが全く無いとか。 そのくせ作ったものに対しては文句ばかりで変更の連続。 最初からそのイメージがあるならちゃんと共有してほしい。 イメージどおりに作っているのに、イメージをこちらが提供するなら別にエンジニアに頼まなくても自分たちでやったほうがいいとか言い出すし。 それならまずデザイナーとでも話し合って作りたいもののイメージ作れば良いのでは…そういう手順の話もしたのに。

素人とは仕事したくないんだけど、全部こちらに丸投げでイメージもなく、何も出来ないような人とは仕事したくないという感じですね。 IEでしか動かなCMS作っていた会社とか、勉強するからとりあえず作ってくれたらあとはやるよ（結局今サイト放置されている）って言ってきたおじさんとかいたけど、少なくともパソコン触れたし、最低限のことは出来ていたけど、それでもそのレベルでも一緒に仕事することでストレスは溜まっていくし、その結果他の仕事に支障が出る。 お金の問題ではなく単純に人としてやITリテラシーの問題ではあるんだけど、そういう人とはいくらお金を積まれても仕事はしないと心に誓った。

せめてやりたいことがしっかり固めて、必要な使える素材なりをちゃんと揃えてからお話ください。

あとワクワクしない仕事は義理でもやらないってことかな。 生活できるお金は稼いでいるのでとりあえず精神的に不利益になることはしない。

投資でもして生きていこうかな。

HHKB HYBRID Type-Sについて

HHKB Professional BTを買ったのが2016年12月22日だったので、それから約4年経って新しいHHKBを購入した。 HHKBは恐らく何十年も使えるキーボードだと思うので、HHKB Professional BTはそのまま別のところで使うことになると思う。

まずType-Sの静音性については普通のHHKBと比べるとかなりすごい。 これはもう普通のHHKBには戻れないかもしれない。 この打鍵感と静音性は癖になる。

キー配列は今までと同じでUSなので、なんの問題もないです。 キーマップの変更があるけど、AutoHotKeyでカスタマイズしている関係で場所によって、前のキーボードを使うなどすることを考えると、わざわざ変えなくてもいいかなと思う。 MacライクでAltの空打ちでIMEの変更しているので、どうしてもAutoHotKeyは必要だし、今までの運用で良いかなと思う。

正直静音感以外は何も変わったところは無いけど（これは僕の使い方の問題でHYBRIDは様々な変更点があるので素晴らしいです）、もう一台欲しくなるほど打鍵感が良いのでおすすめしたい。

ぺちぺちキーボード使っている人からするとうるさいって言われそうだけど、個人的にはかなり静かだと思う。 これで通話しながらキーボード打っていてもうるさくないと思う。

今までのHHKBの打鍵音もキーボード叩いているって感じがして好きだったけど、今はこの静かなスコスコ感の虜になっている。