https://github.com/bannzai/personalhistory
My programmer personal history.
https://github.com/bannzai/personalhistory
Last synced: 11 months ago
JSON representation
My programmer personal history.
- Host: GitHub
- URL: https://github.com/bannzai/personalhistory
- Owner: bannzai
- Created: 2017-11-13T10:59:53.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2025-06-16T04:10:03.000Z (about 1 year ago)
- Last Synced: 2025-07-19T08:27:12.739Z (11 months ago)
- Size: 131 KB
- Stars: 56
- Watchers: 1
- Forks: 3
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# About Me
|key|value|
|---|-----|
|Name| 廣瀬 雄大|
|GitHub|[bannzai](https://github.com/bannzai)|
|SpeakerDeck|[bannzai](https://speakerdeck.com/bannzai/)|
|Qiita|[bannzai](http://qiita.com/bannzai)|
|Zenn|[bannzai](http://zenn.dev/bannzai)|
|Twitter|[@\_bannzai\_](https://twitter.com/_bannzai_)|
|Facebook|[yudai.owata.hirose](https://www.facebook.com/yudai.owata.hirose)
|Wantedly|[廣瀬 雄大](https://www.wantedly.com/users/4069053)
## 求職中。 since: 2025-06-16
条件が少し特殊ですが、それでも私を雇ってくれる会社があればお声がけください。職種は「iOSアプリのモバイルアプリエンジニア」になります
これ以降に書かれていますが、子供がいて、もう少し大きくなるまでは時短での勤務を希望したいと考えています。
連絡は: [Xでbannzaiまで](https://x.com/_bannzai_) DMしてください
### 本人の状態
健康面や環境面について
- 健康面。 心身共に健康です。強いて言うなら低気圧に弱いです
- 1歳と3歳の2児の父です
- Mac Book Pro M1 Max で開発しています
### 希望条件
- フルタイムでの稼働ではなくて4時間程度での勤務可能。短時間正社員か、業務委託契約だけどインボイス登録してない人を雇用可能な場所
- 雇用形態に関わらず、1日の稼働は4-5時間、稼働は週に4日希望です。なので週16h-20h前後の勤務が希望です。水曜日も休みをもらえたら助かります
- 地方在住なので、フルリモートになります
- PC支給の場合はM1 Max以上でお願いします
- 子供達が体調不良などで病院に連れていく。といったことが発生する可能性があります。なので、勤務時間がフレキシブルだと嬉しいです
- AIを積極的に使用する環境・取り組みがある場所が良いです。コーディングはClaude Codeを特に愛用しています。そのほかも使用しています
- 給料・報酬について。参考にしてください
* 業務委託: 稼働形態によって時給に幅があります。5000円 - 10000円。今回も同じ程度で考えています
* 正社員: 年収400万円からでお願いします
### 提供できる価値
`PersonalHistory` の後半部分も参考にしてください。「やったことあること、得意なこと、まあできるだろう」 x やりたいこと。で書きます
- モバイルアプリ開発で、特にiOSのアプリケーション開発が得意です。経歴も10年選手になります
- フルSwiftUIの経験が業務で2年。個人開発も合わせたら5年くらいあります
- クロスプラットフォームの中ではFlutterが得意です。
- 個人のアプリケーションで5年程度開発。3ヶ月ほどスタートアップで技術顧問をしました。ただし、Widgetにめちゃくちゃくわしいとかじゃないです。例えば、Sliverをスムーズに使えたりしません。
- モバイルアプリの CI/CDの整備もできます。Androidも単純なものであればできます
- AIを使った開発についても積極的に早期に導入しており知見もあります
- Firebase,Supabase などの(m)BaaSを利用したアプリ開発もやっています。あくまで一例なので他にも使用経験あります
- GraphQLでのAPI設計(GraphQLは好みではあるがこれじゃないと嫌というわけではないです)
### 提供できない価値
- SwiftUI: 標準の状態管理以外のコーディング
- Flutter: Sliverみたいな低級なWidgetをガツガツ組み合わせる
- GoやGCPを使っていた経験もそこそこにはありますが、現在バックエンドに障害が起きた時に瞬発力高く対応できないです
### 思想
主にコーディングについて。あくまで思考の前段階の基本的な方針であり、自分でもこの思想に則ってない選択はします。チームで開発する上でミスマッチしているようなら見送ってください
- 標準原理主義。標準にあるAPIや機能をうまく使っていくことをまず考えます。とはいえ標準でもいけてない点はその都度良い仕組みや工夫を凝らせば良いと思います
- 工夫が凝らしてある・コードジャンプが多いコードより <<<< 工夫しない愚直なコード。その言語・フレームワークを知っていれば通常は知っている機能の組み合わせで十分だと考えています
- 凝集度は高く、冪等性を保って関数は設計したいですね
- 開発中のデザインデータは中間成果物なので、採用しているUIのフレームワークでどうしても実現できない or 他に自然な手段があり明らかに楽な場合は、代案を提案しちゃいます
-------------------------------------------------------------------------
# PersonalHistory
株式会社ナチュラル スタイル (2012/7 〜 2015/10)
ゲームアプリ開発 (2012/07 〜 2012/12)
## 概要
- 初めてのプログラマーとしてのお仕事
* その直前はお惣菜屋さんの副店長
- 横文字の職業。かっこいいと思って面接してもらったら採用された
- 最初1週間はひたすら違う人が開発したゲームのデバッガ
- 入社して2日目で社長に これ を机に置かれる
* 冒頭が面白かったが、あとはほとんど理解できてない
- 作ったものとしては黒ひげ危機一髪のカジュアルゲームと一つ実装はしたが企画が潰れてしまったもの
## 開発について
- cocos2d-xを使ったクロスプラットフォームのゲーム開発
- iOS
- Android
## 使った言語
- C++
- Java
- Objective-C
## ツール
- Xcode
- Eclipse
## 工夫していた点
- C++の本を読んでもイマイチパッとしないことがわかったのでとりあえず手を動かして覚えることにした。
* というかそういう学び方しかできないことを悟った
* 早めに自分の頭脳に見切りをつけてこの習慣をつけたのは良かったと思ってる
- とりあえずわからないところだらけだったので、何がわからないかちゃんと把握してから聞こうと思った
* 心がけてはいたが今思うとできてなかったな
- いくつか存在していたプロジェクトがあったのであったコードを全部読んで動かして、ゲームの概要を理解して自分の引き出しへと入れた
- 先輩にペアプロをすきあらばお願いして、デバッグの仕方やコードの書き方・考え方を学んだ
## 悩んだ点
- Xcode・Eclipse・iOS・Android・cocos2d-x・C++・Objective-C・Java
- 試用期間無事に終わるかな。。。
- 悩んだところというか、わからないことが多すぎて、毎日**しゅ、しゅごい**となっていた
* 最初にしてハードル高かったと思ってる
ZOZOTOWN ECサイト開発 (2013/01 〜 2013/12)
## 概要
- Windows server
- 注文システムの大きな仕様変更を体験
* DBの設計
- **LA BOO**というガールズマーケット向けのECサイトの立ち上げに関わる
* サービスは終了している
- チューニングを専属的にやっていた時に社内にシステムデータベースのノウハウだったりツールがなかったので、これを継続的に改善するツールをいくつか提案、書き残す
* [システムデータベース](https://docs.microsoft.com/ja-jp/sql/relational-databases/databases/system-databases)
* DBがどこまでのことができるかっていうことを深く知れた(気がしている)
- フロントエンド << バックエンド
## 使った言語
- VBS
- Javascript
- HTML/CSS
- (MS)SQL
## ツール
- 秀丸
- SQL Management Server
- VSS
- IIS
- Git
## 工夫していた点
- 注文システムの大きな仕様変更を体験
* `DB` の追加やカラムの追加において論理的な意味を持つかどうかを考え抜いた
- チューニングを専属的にやっていた時
* SQL management studioについてわからない機能があれば片っ端から調べてみた
* sys.xxというスキームを発見し、DBの足りないインデックスを監視する目的等で大いに役立つことを発見
## 悩んだ点
- `DB` のスキームを考えた時に初めて真剣に「名前何にしよう」と悩んだ
* ソースコードの変数名とかだとある程度コンテキストもあるし少しいい加減になっていた(今思うとこれはダメですね)が、利用頻度の高い誰からいつでも見られる`DB` の場合名前が大事だなということはわかっていたので悩んだ
* 同時期に同僚があくまで社内向けにリーダブルコードを布教してきて、「あ、名前大事。」と学んだ
- 根本的に実装を直したほうがいい気がする場合に、`Diff` を見やすく小さな変更に留めるか、根本的に大きく回収するかで悩むことが多かった
* この時は小さな変更に留めた。規模も大きく影響範囲も確実に決定づける実力もなかったのでその選択をした
WEAR iOSアプリ開発 (2014/12 〜 2015/10)
## 概要
- iOSアプリ開発
- リリース後1ヶ月後くらいに参加
- 半年くらいiOSアプリのリードエンジニア経験
## 使った言語
- Swift 1.0
- Objective-C
- Apple Script
## ツール
- Git
- mitmproxy
- Vim
- XVim
- SourceTree
- Xcode
- Google spread sheet
- Slack
- Photoshop(画像のマージンを測るのにデザイナーと一緒なツールを使っていた)
## 工夫していた点
- ネストは浅く
- 一つのメソッドには一つの意味だけ書くようにする
- `View` の共通化できるようにする
- ローカライズや、@2x, @3x の画像の生成は自動化する
## 悩んだ点
- 設計
* リーダブルにするには
* DRYを意識したいが、どういうクラスを作るか
* 保守がしやすくするためにどう書けばいいか
- 退職が決まっていて、人数を入れてもらったが`iOS`の経験者じゃなかった、その場合に今のアプリの設計や`iOS`アプリの開発の方針。開発のノウハウをどうやっておいていくべきか悩んだ
* 一部ドキュメントで残す
* `iOS`の基本的なことについては口頭で教える
* 非同期処理等に**Promise** を全体的に使っており、内部的な理解や使い方を教えたり
- `UI` についてこだわりが強かったので、どう実現していくか悩んだ
- デザイナーが物理的に離れ場所におり、マージンの測る時にどうするのがいいんだろうと悩んだ。`Photoshop` で作ったものを PDF or PSDでデータをもらっていた
* Interface Builder等の使い方を覚えてもらい微調整は任せられないだろうか
* これは断られた
* 結局エンジニアも`Photoshop` を使ってマージンやフォントを測るようにした
株式会社マネーフォワード (2015/12 〜 2018/03)
MFクラウド経費iOSアプリ開発を担当 (2015/12 〜 2016/3)
## 概要
- マネーフォワードに入社してから初めて入ったチーム
- GitHubの使用やGitHub上でのコードレビューはこのチームで初めて経験した
- Sketch・Zeplinを使うのも初めて。しゅしゅごい、便利と思った
- チームにjoinした時にはまだサービスが立ち上がっておらず、申請目標の3週間前くらいにチームに加わった
## iOS
- Swift
- Xcode
- Cocoapods
- Carthage
## チーム共通
- Git
- GitHub
- コードレビュー
- Zeplin
- Sketch
- trello
- Google Calendar
## ライブラリ
- Realm
- R.swift
- SwiftBond
- SwiftTask
- SwiftDate
## 工夫していた点
- 申請直前だった時はサービスの理解も早くする必要があったが、どちらかというと細かいコーディングのミスを拾うことに注力した
- 勢いで書いたコードも存在していたので、共通化だったり、リファクタリング
- super.viewDidLoad等の予備忘れ
- メモリリーク
- 後半から仕様も把握したので機能的なものも開発。Appleのクリスマス休暇前に一度目の申請が間に合った(リジェクト発生しちゃったが)
- コードレビューでは解決策やその理由まで書くことを考え発言しました
- チームでのコードレビューの目的がバグを生んでないか、可読性の向上が目的でした
- よく使われる機能についてテストを書いたりしました
* 正直なところあまりコードが綺麗だと思わず、ちょっと書き換えたい気持ちもあった
* が、まずは品質の保証も大事だと思い、テストを書いて効果がありそうな場所を書くことに決めました
* その時に勢いで買った本 [レガシーコード改善ガイド](https://www.amazon.co.jp/s/?ie=UTF8&keywords=%E3%83%AC%E3%82%AC%E3%82%B7%E3%83%BC%E3%82%B3%E3%83%BC%E3%83%89%E6%94%B9%E5%96%84&tag=googhydr-22&index=aps&jp-ad-ap=0&hvadid=217432896196&hvpos=1t1&hvnetw=g&hvrand=8543339438788022144&hvpone=&hvptwo=&hvqmt=b&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=kwd-29907084729&ref=pd_sl_1np2uq4wvb_b)
## 悩んだ点
- コードレビューの目的を何に置くべきなのか、ということで今もだが悩み続けている
* 品質保証？可読性？仕様確認？
- コードが煩雑になっていたので品質を保つために何からすべきかを悩んだ
- 「経費」というものにあまり関心を抱いたことがなかったので、どうサービスをよくしていこうか悩んだ
* 会社で行う経費精算を雑談で聞いてみたり今までの経験も振り返って、「確かにこれ面倒臭いわ。。。」って改めて認識して、何が課題かを実感しサービスづくりに望んだ
家計簿アプリマネーフォワードサービス開発 (2016/3 〜 2017/3)
## 概要
- 自動家計簿サービス
- 主にiOSアプリの機能追加や改修を担当
- バックエンドもたまに
- `Rails`で`API` を書いたり必要であればコード読んだり
- [アカウントアグリゲーション](https://moneyforward.com/engineers_blog/2015/08/25/toward-the-future/)開発に3ヶ月ほど携わったり
## iOS
- Swift
- Objective-C
- Xcode
- Cocoapods
- fastlane
- mitmproxy
## Rails
- Ruby
- gemは色々
- Vim
- tmux
## アカウントアグリゲーション
- Java
- lombok
- jooq
- etc...(ライブラリの名前覚えてない)
## チーム共通
- Git
- GitHub
- Zeplin
- Sketch
## 工夫していた点・悩んだ点
- iOSアプリにおいていわゆる技術的負債が大きく溜まっていた。その負債を返すために奮闘しました
* チームでのアーキテクチャの選定・理解
* CIの導入・自動化
* DRYなコードを書く・リーダブルなコードを書く・テスタブルなコードを書く
* 積極的にObjC -> Swift化
- データ構造が複雑だったため、バックエンドのコードも読めるようになりたいな、と思って`Rails`の開発も携わった
* 自分の発言にも説得力を持たせるためにもまず理解が必要だと考えた
* さらにアカウントアグリゲーション開発もチームの意向で僕が参加することになった。サービスのデータ構造について理解がさらに深められた
* クライアントサイド・サーバーサイドのことがわかるようになり、より俯瞰的なエンジニアとしての目線を持つことができ、構造を理解した上で開発することはやってよかったと感じている
- デザイナーとのコミュニケーションの問題意識
* WEARのiOSアプリ開発から課題に感じていた意識
* デザイナーがiOSアプリを作るわけではないのでUI`の実装上の特性をデザイナーが理解しきれていない
* 共通の言葉がないから
* 代替案は発案できるが、何が難しいか説明できてないからお互いわだかまりできそう
* プログラマーはわかりやすい説明やデザインの意図を理解しきって汲み取って代替案を発案するスキルが必要だと感じた
* お互い歩み寄りが必要だなと感じた
- 新しいメンバーの補助
* 狙っていた効果としてはチームとして最大限の効果が発揮できるようにしたかった
* READMEの整備・開発のtips紹介・適切なタスク振り
しらたま立ち上げ (2017/03 〜 2018/03)
## 概要
- サービスの企画・要件定義から携わる
- iOSアプリ開発について一人で立ち上げる
* ちょっと嘘ついた。他のチームから人を借りて2画面くらいPRあげてもらった
## iOS
- Objective-C
- Xcode
- Cocoapods
- fastlane
- Firebase
* Analytics
* Notification
* User Property
## チーム共通
- Git
- GitHub
- Zeplin
- Sketch
- 新規サービスで新しい技術や方法・設計についての検討を積極的にやっていきました
* ReactNative
* 検討して実際に小さなアプリを作ってみた結果導入はしないことに
* プロコン並べた時にあえてRNを選ぶ理由が少なかった
* もともと検討していた`UI`の構造が複雑になることがわかっていたのでそこも少し不安ということもありネイティブで行くことに
* Atomic Design
* 前々から課題に感じていたデザイナーとのコミュニケーションについての解決策として導入
* `Swift` コードで`DSL`っぽく書くようにしたことでデザイナーもコードを読んで何が定義されているか把握できている
* ガチガチに定義することはしていない
* デザイナーとペアプログラミング
* 共通の言葉を持つことによりコミュニケーションが円滑に
* デザイナーが実装の都合を意識しすぎないか、という懸念はあったが今のところそこは課題に感じていない
* まだ継続的にやっているので最終目標はデザイナーが1アプリを作れるところまで
* Sketch ファイルをGitHubで管理して、Diffを表示してデザインレビューができる実績を解除
* [RxSwift](https://github.com/ReactiveX/RxSwift)
* RxCocoaは含まない
* なんだかんだ便利
* `RESTful` APIということもありクライアント`join`や、直列・並列で`API`を複数叩くこともあり導入
* [QarzhCode](http://www.quartzcodeapp.com/), [CoreAnimator](http://www.coreanimator.com/#animate-anything-anywhere), [lottie](https://airbnb.design/lottie/)の検討
* アニメーションにもっと簡単に実装したいと思い上記のいずれかのツールを検討している
* [QarzhCode](http://www.quartzcodeapp.com/)が今の所第一候補
* No Storyboard, No Xib
* `Diff`を見やすく
* `Swift`ファイルのみで管理できる
* Atomic Designでの`UI`コンポーネント共通化においてもコードで実装する方が都合がいいと思い選択
* MVC → MVP → Clean Architecture
* MVCと言いながら実際はない
* 上が意味することは最終的には細かくレイヤーを分割して、各役割の疎を心がけるが、簡単な画面ならもっと平易なアーキテクチャにしている(簡単な設定画面みたいなやつとか)
* 保守のしやすさも意識しつつスタートアップのスピード感も失わないように
* `View`の役割ととそれ以外の役割が`Presenter`によっていれば以降のレイヤー化も比較的に簡単
- 企画や要件定義について
* 仕事では企画からやるのは初めてだったので下記のことを意識したり、またチームに引っ張ってもらって頑張ったことや評価されたことを書きます
* 発言は根拠を持って発言する
* 事前調査や事実に基づくことで発言することを心がける
* が、単純に好みをぶつけることも普通にした。なぜそう思うのかはちゃんと納得いくよう説明する
* ユーザー像を見失わない
* メンバーの意見を最後まで耳を傾ける
* デザインについても、サーバーサイドについてもキャッチアップする
* お互い事情を把握しながら進めていきたかった
## その他
- wantedly記事にいくつか掲載してもらいました
* https://www.wantedly.com/companies/moneyforward/post_articles/79522
* https://www.wantedly.com/companies/moneyforward/post_articles/85150
- iOSアプリのフロントエンドエンジニアをやっていてデザイナーとのコミュニケーションの壁の課題解決で積極的に挑戦していきました
* https://www.wantedly.com/companies/moneyforward/post_articles/106133
* https://moneyforward.com/engineers_blog/2018/01/24/
* https://moneyforward.com/engineers_blog/2018/01/25/
Asobica, Inc (2018/03 〜 )
Fever (2018/03 〜 )
## 概要
- コミュニティ支援サービス
- iOSアプリの開発
- GolangでGraphQLのサーバー立ち上げる
- Web Railsアプリの改修
- ほぼリモートワークで働く
## iOS
- CollectionView
* 一部(設定画面)を除いてCollectionViewを前提とした作りにした
* [Conv](https://github.com/bannzai/Conv)を開発
- Architecture
- RoutingはApplicationCoordinatorを採用
- Layered Architecture を採用して、主に画面の作り方を3パターンに分けることで誰が書いても似たようなコードになるようにした
- [kuri](https://github.com/bannzai/kuri)を使用してテスト含めて大幅に書くコードを削減
- Atomic Design(が、デザイナーがいない中やってしまったのでオーバーテクノロジーだったかもなと思っている)
- Sourcery
- Stubの自動生成
- Mockの自動生成
- Lensの自動生成
- Initializerの自動生成
- [DifferenceIdentifier](https://github.com/bannzai/Conv#usage)の自動生成
- Equatableの自動生成
- Bitrise
* UnitTest
* Deploy to DeployGate
* Deploy to TestFlight
- Testちゃんと書く
- ReSwift
* が、これは技術選定中に採用するのは辞めた
- GraphQL クライアントサイド
* [Apollo](https://github.com/apollographql/apollo-tooling)を使う
* Apollo+Swiftを前提としたSchema設計・テスト設計・抽象化
### iOS技術選定の振り返り
いくつかpickupして書いていく
#### CollectionView
* CollectionViewにしておけば後からレイアウトどうとでもなるだろうと思った狙い
* 特に失敗したと思っていない。概ね狙い通り
#### GraphQL
`GraphQL` が思った以上に良いものだった。
- `introspection` の結果からクライアントサイドのコードを履いてくれる `Apollo` が良かった。楽
- `Apollo` 自体にはまだもう少し改善がある気もするが今は特にめっちゃ困っているってことはない
悩んだところとか今後やっていくこと書いてこ
* エラーの設計で悩む → Errorを `kind` ごとにEnumにして型をつけることにした。switch 分で網羅的にエラー処理ができてクライアントもわかりやすくなった
* 画像のUploadどうするかな → 画像のUploadだけ別パスを切ったentrypointを用意してそこに上げてから `Mutation` を実行するようにした。
* ちょっと重たい気もするから改善策が思いつけば実行していこう
* ローカルキャッシュ
* Realm(RDB)でID使ってmappingするのは違う気がするんだよな。jsonで保存とかになる気もする
* Apolloのデータ構造の抽象化が結構悩んだ
* Fragmentの設計等で回避するが、Fragmentを編集すると他のQueryにも影響する可能性を考慮するので多少めんどい
* 仕方ない気もしている
#### Sourcery
- メタプログラミング最高
- テストデータ等を用意するにはもってこい
- これのおかげでテスト書くときも気持ちが楽になった
#### ReSwift
- Mobile App において以下の特徴があるなと思って採用をやめた
- State管理が`ViewController` 単位に縛られがち
- 特によくある感じのタブ構成において、同じクラスの`ViewController`のインスタンスが複数存在するときもある。そういう場合のState管理が結局`UUID`を発行して管理するくらいしか思いつかない。そうした場合に結局ほとんどのStateに`UUID`で識別する機能をつけることになりそうだったのでやめた
- データの流れを単方向にする目的もわざわざこれを採用しなくて良いなと思った
## Go・GraphQL・GCP
- インフラはGCP採用
* GAE・Flexible
* GCS
* Cloud SQL
* StackDriver Logger
* Google Container Registry
- dev・stg・prod全てDockerで運用
- と言いつつ普段の開発はローカルでしがち
- multistage build で docker image すごく軽くなるからGoとの相性いいなと思った
- APIの指針はGraphQLを採用
- 認証はJWTを採用
- 段々好きになってきた
- これは業務委託の人にお願いして先行して開発はしてもらったが仕様は理解した
- CIはCircleCIを採用
* Test
* Deploy
- Goの構成としては `Layered Architecture` にした
* `interface` を通して抽象化した
* `DI` をすることで `Stub・Spy` と入れ替えやすくテストも書きやすいように
* テストめっちゃ書いた
* WebのRailsAppとのDBのスキーマのズレをなくすために[sqlboiler](https://github.com/volatiletech/sqlboiler)を採用した
- Clientサイドとして[OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator)を使っている
* 更新系の処理(Mutation)はRailsのActiveRecordのvalidation等使えた方が便利なので、更新系の処理はGraphQL→Rails(OpenAPI)経由で実行することにした
### Go・GraphQL・GCPの技術選定の振り返り
#### GraphQL
- 採用したライブラリは[graphql-go](https://github.com/graphql-go/graphql) → [gqlgen](https://github.com/99designs/gqlgen)にした
* やっぱり型がある方がいいなと思ってほとんどできている状態から `gqlgen` 移行
* 悩みは減ったが、nullをポインタで表現しちゃっているのが好きじゃない
* あとたまにバグっている(graphql-goだとどうとか知らないが)
* ドキュメントも結構変わるので使う時は注意が必要そうな気配
- APIとしての実装の仕様を定めているのではなく、インタフェースとして定まっている。って点がとても助かった
- データの更新に関してはRailsと(というかDB)仕様を合わせたい。そのためにActiveRecordの機能を利用するために`GraphQL`を通してリクエストされたものから別のAPIを叩くことに抵抗なく解釈できたのが良かった
- [GraphQL Playground](https://github.com/prisma/graphql-playground)のUIかっこいい
- GraphQL PlaygroundでインタラクティブにQueryの確認できるの個人的には好き。確認もしやすい
- が、これはサーバーサイド・クライアントサイド一人で実装した場合だからチーム開発の時はどうなんだろうな。って疑問がある
#### OpenAPI
- OpenAPIのspecからクライアントサイドでコールするコードが吐かれるの最高
#### テストめっちゃ書いた
- GolangのASTから `Stub・Spy` を自動生成するコードを書いたが、これは失敗だった気がする
- 素直にGoMockとか使っておけば良かった。。。
- まとめて `hogehoge_generated_test.go`みたいなファイルが吐かれて`hogehogeMock`という `Stub・Spy` パターンを作ったが、ユースケースに合わせて挙動を変えられる設計にしていなかったため。Aのテストでは使えるけど、Bのテストでは使えないってことが発生してしまった。
## Rails
- Webアプリの改修もたまにやった
- これAPI作るときに設計できないな。って部分は問題点を洗い出して修正したりした
- OpenAPI
* ActiveRecordのvalidation等の機能に頼りたいためにAPIを作った
* 更新系の処理に主に利用したかった
* [Grape-Swagger](https://github.com/ruby-grape/grape-swagger)というライブラリで開発
### Railsの技術選定の振り返り
#### Grape
- GrapeというかRuby全体に言えることだが、ドキュメント読まないと漠然とした挙動も見えないのが少し大変だった
- Grape自体は簡単にかけて次作るときはもっとシュシュっと作れる感はあるなと思った
#### OpenAPI
- OpenAPIのUI部分は自動生成されるのは助かる
- 反面履歴とか残ってくれると嬉しいのになあ。とGraphQL Playgroundと比較しちゃっての感想を持ったり
OTOBANK (2018/後半 〜 )
audiobook.jp
## 概要
- 耳で聴いて読書するサービス
- 副業で携わる
- ReactNativeでiOS・Androidの開発
## Mobile Application
- ReactNativeでiOS・Androidの開発
- TypeScriptでよかった
- 知らない・使ったことない外部サービスとかを使っていて面白い
* Sentry
* Buddybuild
* Microsoft AppCenter
### 振り返り
フルリモートでの副業の関わりが初めてだったので慣れないことも多かった。
最後の方には業務に慣れた。かというとそれも微妙だったが反省点としては「ReactNativeという自分にとっては新領域をリモートワークで初の副業でやってしまった」というチャレンジにチャレンジにチャレンジを重ねてしまった結果少しお互いにとって満足いく結果に出来なかったのだろうな。と反省している。ReactNative自体は楽しくて得られるものも大きかった。
AppBrew (2019/2 〜 2019/3)
LIPS
## 概要
- コスメ‧メイクのクチコミアプリ
- 副業で携わる
- iOS専任でissue消化や開発効率改善をおこおなう
元々転職ドラフト経由で転職活動中に転職先の候補として週2日のペースで業務委託としてまずは雇ってもらった。
その時の職歴。
## iOS
直接出社してスピード感ある中で副業をすることができたと感じる。
また自分の好きな業務改善系の開発を一つ完遂することができてチームに喜ばれた。
具体的にはデバッグ時のA/Bテストの出しわけを効率的に行えるというもの。
### 振り返り
個人的には正しいことをやっている・やろうとしているスタートアップに携われて良かった。
データドリブンでの振り返りや機能をリリースした後に振り返りを残す文化に触れられて良かった。
個人的にも稼働時間が週2日で成果を出すことを考え、それを大いに評価されたことが良かった。
特異分野であるiOSだったということも大きいが前述した副業の携わり方として少し失敗だったかもな。と思ったOTOBANKの場合で感じていた反省点もある程度払拭できたと感じている。
DeNA (2019/5 〜 2020/3)
Mangabox
## 概要
- [令和最初の入社ブログ](https://bannzai.hatenadiary.jp/entry/2019/05/01/143751)
- Go でサーバーサイドを書くことを主業務として入社
- iOSでのコードレビューや自動化も行う
- Perl→Goへアプリケーションの言語移行案件
* ついでにAPIのアーキテクチャもJSONRPC → Go に移行する
- バックエンドの方ではあまり自動テスト等が走っていなかったので、Goでは積極的に投下して文化を根付かせようとしている
## Go
AsobicaというスタートアップでGoでMobile app 向けのAPIを書いていた文脈でサーバーサイドを主業務としてやるか。と思ったのがきっかけ。主業務を変えた一番の大きなきっかけは気分転換。
チームとして開発する場合のバックエンド開発についてやってみたかった。というのもある。
JSONRPCをAPI仕様として定めていたが、クライアントサイドからの不満や周辺サポート自体があまりリッチではなかったりしたので変えてしまおうかと思って、アーキテクチャもGraphQLにすることに。
### 振り返り
DeNAという組織とチームに関しての2点思うことがあった。
良かった点は社内にエンジニアが多くて、例えば社内勉強会みたいなので横のつながりや他の部署のノウハウが共有されることもありそこは大変楽しかった。
やっぱり技術が好き。という点もあるので他の人がチャレンジしている内容や知識を共有する場を設けるという機会は大変良かった。
合わないな。と思った点は一つは大きな組織ならでは(かつ請負で開発しているってこともあったとは思う)が主に使うツールに対しての独自ルール等が多くてそこは合わなかった。
とはいえ会社全体で改善しようとはしているところもあり時には嬉しい改善もあった。が、自分は組織というものに対してから末端のツールまでしがらみ無い方が明らかに良いのだな。
いわゆるベンチャーやスタートアップの方が楽しく働ける傾向にありそう。ということに気づいた
マンガボックスチームに関しては色々な技術的な挑戦もさせてもらえた。正直レガシーな環境からのリプレイスは想像以上に大変だった部分もありましたが、これはこれで見識が広がったと思っているし実際やっているうちもわりと楽しめた。
あと初めて形式に沿ったスプリントみたいなこともしたりした。これについては良し悪しはあるな。と思ったけど持った感想が一般論と大差なく、何を大事にして何を諦めるか。という問題な気がしているので特に明言はしない。
合わないな。と思った点と反するがチームでEnterprise版のソフトウェアを使うという体験は楽しさもあった。というか知らない制限が色々とあるんだなー。と知れることは良かった。
Cookpad (2020/4 〜 )
クックパッドマート
## 概要
- 初めてのフリーランス
- 週4勤務
- [Twitterで雇ってもらう先を募集して](https://twitter.com/_bannzai_/status/1219125320764125184?s=20)、クックパッドに努めている友人経由で紹介してもらう
- iOS専任
- RailsはリーディングとちょっとしたPRくらい
## iOS
仕事でiOSのネイティブアプリ開発専任は結構久しぶりでしたが、得意分野でもあったので書いてて楽しくチームにもすぐに受け入れられたと感じています。
やっていることがUIKitベースのアプリケーション開発なので懐かしさはありましたが、新鮮さ等はなかったかも。とは言え工夫するのが好きなので UIKitベースのXcodePreviewsや、CIのjobや開発便利スクリプトをを5~10個くらい作ったりして楽しんでます。
全員ではないのですが会社もチームのエンジニアもなにか作ると反応があったりしてそういった意味でも楽しくやりやすい場所ですね。
## 働き方
フルリモート。 初めてのフリーランス。初の週4労働。と働き方について述べる点がいくつかありますが、総じて全部「良い」って感想です。強いて言うなら出社は必要があればしても良いかも。とは思っていますが僕の場合家で集中できないって状態が出社して集中できない。って状態よりも多いということは無いので通勤時間が無く自分の生活を調整しやすいリモートワークは肌にあってますね。強いて言うなら通勤じゃなければ出かけたり美味しいご飯食べるの好きなのでそういう機会は減っているかも知れませんね。コロナ禍な特殊な状態でしたが、以前にもリモート中心の働き方をやった経験もあったのと、常駐先の対応がちゃんとしていたのでフルリモートだから特に困ると行ったことはほぼなかったと思います
### 振り返り
前述したとおり、 なにかツール等を作ったときの反応があることは嬉しいですね。
プロダクトも成長させてくぞ。っていう気概をみんな持っているのでそういった点はやはり楽しいし僕もこういうの好きなんだな。と改めて思いました
ただクックパッドのサービスで使われている[API Schema](https://github.com/cookpad/garage)のようなツールがありこの存在が少し「ウッ」となった。クライアントのライブラリも社内にあってそれを使えば最低限の機能が使えるようになっているが、GraphQLやOpenAPIのようなエコシステムの広がりもあまり無い状態だったりする。こういったものを作る。作っていく文化は好きだけど現状最低限(手で書いて http request) くらいのことしかできないので、更新頻度が低い社内共通基盤・ツールみたいなのにロックインされて、同じ目的をしているより成熟したOSSなどよりも開発効率を上げにくい・トレンドなライブラリい触れれない状態になっているなあ。と思ったのがネガティブな感想。反面そういった環境だからこそ工夫できたりツール作ったりする余地もあるのでそういった点は楽しかったです
自動化が積極的にされていたり、開発のスピードや勢いがありそういった点はとても参考になったし刺激になっています。
Stack Inc (2020/4 〜 )
Appify
## 概要
- 色々と経験させてもらいました
- 作業量が多い順で、 SwiftUI, Go(GraphQL, Shopify API) & GCP(GAE→Cloud Run, Firestore(Datastore mode)... etc), React, Jetpack Compose,
- CI/CD環境についても整備してました
- 週4勤務。だいたい一日6時間稼働
### 開発
99% SwiftUI でiOSを開発。Goでのバックエンド部分の開発。Shopifyのエコシステムに則った開発をさせてもらいました。とても優秀な方が多く色々させてもらって自分の中で成長を感じられて楽しかったです。また、ReactによるWebフロントエンドの簡単な回収。こちらも Jetpack Compose で構成されたAndroidアプリの開発も担当させてもらいました
### 振り返り
フルリモートでやりました。創業者や創業メンバーがエンジニアの方たちだったのでうまく仕事を割り振ってもらったり、相談時のコンテキスト共有も最低限でよかったのでありがたかったです。時期も関係するかもしそうですが、対話のコストを低いとやはりやり易さを感じました。
一方、この時期に子供の出産や引っ越しなどの環境の変化が重なりイマイチパフォーマンスが出づらい状態でした。逆にいうとStack社みたいに創業メンバーがやりやすいからなんとか成り立っていたというラッキーな面があったなと感じています。
ということもありここからしばらく「子供が小さいうちは育児に専念するか」と思い思い切ってクライアントワークを辞めることにしました。 [この記事](https://bannzai.hatenadiary.jp/entry/2023/07/20/111551)にその時の近況報告が書かれています
## 職場選びで大事にしたいこと
いろいろな要素がありますが思いつく限り書きます。順位はなくて総合点ですね。ただベースとしてはエンジニアとして雇われるなら、その方面で成長が感じられる場所が良いです
### 希望
- Slack等のディスプレイネームをbannzaiにしたい
### 技術
- 飽きたら他のこともできる余地がある
- 比較的新しい技術に触れたいですね。そういった点に理解があると嬉しい
- 例えば昔のiOSのバージョンを頑張ってサポートするような場所は向いてない
### 働く人
- 自分よりも優秀であるのはもちろん、こうなりたい、ここを盗みたいって思える人がいたら最高ですね
### 文化
* オープンな文化がいいですね
* 必要な情報がすぐに出てくる環境が良い
### サービスに興味が持てるかどうか
* 必ずしも自分がユーザーである必要もないと思っている
* 解決したい課題について共感できるか
* ただ言われて作るよりも自分もサービスについて携わっていった方が面白い
### 好み
* 自分の好きな技術・そのサービスにふさわしい技術でサービスを立ち上げたい
* 新しい技術さわりたい
* 技術的負債や上のビジネス的な都合とかいうものに邪魔されずにユーザーフレンドリーな選択を取りたい
### 働きやすさ
* 労働基準を守っているっていうのはあえて書いておく
* もっというなら複数の会社にまたがって働きたい
* 平たくいうと自由度の高い会社がいい
* backup: 東京にいる時(昔)
* 時間や空間で縛られない働き方がベスト
* リモートでも可能くらいがちょうどいい。オフィスいくときは必要性、都合や気分で決めたい。
* 料理と運動が好きでプログラミングの合間に気分転換を取りたい。そう思うと自宅とかの方が都合がいい
* あと旅行も好き。旅先でコード書いていいとかいう会社がいたら最高
* 時間については裁量労働がいい。メリハリをつけて働きたい
* 慢性的に忙しいのも暇な状態があるのも嫌
*
### 働く場所
- 現在(2025年6月)は地方在住と1歳児の育児中なのもあり、リモート勤務になります
### 給料
- お金好き
## 他のスキル
プライベートや業務でちょっと触ったことあるやつ箇条書き。話題の種にでもしてください
- cocos2dx
- Unity
- Flutter
- React Native
- Expo(React Native)
- Firebase
* ハッカソンや適当なアプリ作るときによく使う
* Cloud Functions
* Firestore
* BigQuery
- Rails
* かんたんなHP
- Arduino
* キーボード作ってたりしてました
- Android(version 2 ~ 4)
- React
- Next.js
## 業務以外で個人的にやってきたことや経歴
- [Designer X Engineer Lovers（DXEL](https://engineers-x-designers.connpass.com/)の運営
- iOSの勉強会で年に10~20くらい登壇している
* よく行く [Swift愛好会](https://love-swift.connpass.com/)
* ちょっと大きめのカンファレンス
* [iOSDC2017](https://iosdc.jp/2017/node/1364)
* [iOSDC2018](https://fortee.jp/iosdc-japan-2018/proposal/9aada1a8-029a-4b66-aa68-ffe53161adf5)
* 2年連続でなぜかObjective-Cのネタで登壇している
* たまに勉強会でもメンターをやっている
* 主にiOS・Swiftの勉強会
- スター乞食というあだ名がついた
* 自作OSS作るの好き。
* Blog
* https://github.com/bannzai
* https://qiita.com/bannzai
* https://bannzai.hatenadiary.jp/about
* https://zenn.dev/bannzai
* 勉強会で発表する内容はOSS作って公開してスターください
* [死を願われるまでになった](https://anond.hatelabo.jp/20170830165611)
- 個人開発
* [Pilll](https://pilllapp.studio.site/)
* [#100日後に](https://twitter.com/_bannzai_/status/1554631238119350272?s=20)
* [DigitalDetox: デジタルデトックス](https://apps.apple.com/jp/app/digitaldetox-%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%87%E3%83%88%E3%83%83%E3%82%AF%E3%82%B9/id1663997320)
* [NotificationHub](https://apps.apple.com/jp/app/notificationhub/id1484099869)
* [Focus](https://apps.apple.com/jp/app/id1663997320)
* その他のiOSアプリ: https://apps.apple.com/jp/developer/yudai-hirose/id1062610569
* 解約.com: https://zenn.dev/bannzai/articles/1eda9a5158b3d9
*
- ハッカソン
* MAのハッカソンで企業賞
* SPAJAMハッカソンで本戦出場
* [try! Swift Tokyo 2017 Hackathon Firebase賞受賞](http://dev.classmethod.jp/event/try-swift-tokyo-2017-hackathon/)
* [SPAJAMハッカソン2020で本選最優秀賞獲得](https://spajam.jp/final-result)
* blog: https://bannzai.hatenadiary.jp/entry/2020/11/10/004028
## おまけ
- blog: https://bannzai.hatenadiary.jp/
- 人生が漫画になった: https://twitter.com/_bannzai_/status/1293140133026267138?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1293140133026267138%7Ctwgr%5E&ref_url=https%3A%2F%2Fbannzai.hatenadiary.jp%2F