SESでエンジニアをお探しの方へ
SESでエンジニアをお探しのシステム開発会社様・事業会社様・SaaS等のプロダクトを運営している会社様・スタートアップ企業様向けの、弊社の要員とスキルについてです。
WebアプリはTypeScript / Python
- 言語は上記だけ対応しており、自走できるメンバーが揃っています。テックリードもメンバーによっては可能です。
- TypeScriptは、バックエンドも書いています。React, ReactRouter v7、Conform, Shadcn/ui, Drizzle / Kysely あたりのキーワードがおわかりの方、嬉しいです。特にRRv7に力を入れています。Next.jsはあまり力を入れていません。かけることはかけますが、というレベルです。
- 関数型プログラミングを意識してコードを書いています。エラーハンドリングはNeverThrowを使ってます。
- クラスはネームスペースとして使うぐらいで、クラスの中身は全部staticの関数で作る方式になっています。関数が第1級オブジェクトの言語の場合、クラスにデータを保持してそれを書き換えるようなコードを書く必要がないためです。コードが純粋ではなくなります。
- Pythonは、Flask / FastAPI / SQLAlchemy / Peewee あたりを使っています。TypeHint必須のコードを書くようにしています。SQLAlchemy以外のORMがほとんどない。すごい「厚い」ORMなので、もう少しライトなORMでもいい気がします。FastAPIがasync推してるから、難しいかもだけど。
ネイティブアプリはFlutterのみ
- 2021年からFlutterをやっています。自走できるメンバーが揃っています。テックリードもメンバーによっては可能です。
- Riverpod, flutter_hooks, dio, freezed, Retrofit, GoRouter, GoRouterBuilderあたりのキーワードがおわかりの方、嬉しく思います。
- flutter_hooksはあまり使わないです。useController, useAppLifeCycle, useEffectぐらいです。それ以外は利用しないことが多いです。
- Riverpodは登場人物が多いので直感的ではありません。Hooksより自由度も下がります。しかし、Riverpodに慣れるとコードがHooksより均一化されるので、Riverpodで統一しています。
- 「Riverpodはグローバルの状態管理をするものでWidget単位の状態管理に利用しない」という誤解があります。TextContollerをグルーバルで引き回す意味がないだけです。
- Widgetにも、状態を管理すべきものとそうでないものがあります。後者は、Propsを公開してStatelessWidgetにすればいいだけです。
- Riverpodで気をつけているのは、RiverpodでDIするのは、Viewがアタッチするデータだけにしている所。レポジトリレイヤー・API通信などのI/OをするコードはDI不要。
- レポジトリやAPIが含む処理はなんぼでもありますが、それらをRiverpodのNotifierのメソッドの中にラップして、DIする時はNotifierのメソッド自体をMockするだけで充分だと思います。外部I/Oの成功可否をテストする理由もないでしょう。
- それに、RiverpodのWidgetRefはBuildContextですので、非同期処理を挟んだ時が面倒です。context.mountedをチェックして、あーでもないこーでもないやるのは、不毛です。
- テストをどこまで書くかが悩みです。E2Eで正常系一本回す、Widgetにロジックがあるもの、JSONからモデルをパースする、それぐらいのテストケースで良い気がします。
- アプリはFirebaseを始めとした外部サービス連携が極めて多く、そこが動かないと機能を担保できないことが多いです。かと言って手動テストは・・・、と。E2E回すにしても、pumpAndSettleがflakyになりやすく、悩ましい所です。テストを書けば書くほど品質が上がるわけでもないので、どこで線を引くか、議論させてください。
- WidgetのBuildメソッドでRiverpodでDIしたオブジェクト「以外」で、外部I/Oしている変数や関数の初期化は一切禁止したいんですが、やり方がわからないのが悩みです。レビューで弾くしかないのかな? Claudeに言えばやってくれる? AIでカスタムLintつくる時代?
- アーキテクチャはFeature-Firstで、以下の構成が基本です。
- page: ユーザーが実際に操作する画面
- components: ページを構成するWidget群で、基本StatelessWidgetでProp公開
- state: RiverpodのProviderを定義する所
- model: APIのインターフェイスのモデル(UIで読み書きする対象のデータ)
- 微妙に画面をまたぐComponents,state,modelは、
core
というフォルダに入れています。ECだと商品やセールが該当します。ユーザー/認証は言わずもがな。
- GraphQLは経験がないです。RESTのみです。
- DeepLink対応できます。国内最大級のフラッシュセールのECアプリ構築で、散々やりました。GoRouterでDeepLinkを捌くのは得意です。AppsFlyerのDefered DeepLinkもさばけます。
クラウドやインフラはGoogle Cloud Platformのみ
- AWSが苦手なので、Google Cloud Computingのみを使っています。AWSわかりにくいですよね?
- Dockerは大丈夫です。k8は作れないです。ごめんなさい、マネージドに甘えています。
- Cloud Runが好きで、ついCloud Runに何でも乗せてしまいます。Cloud Buildからの連携が主ですが、CIでテスト回してArtifact RepositoryにイメージPUSHからのデプロイもやります。
- RDBMSはもっぱらMySQLです。PostgreSQL、あんまり触ってないです。SQLは中級レベルだと思います。
- Firebaseは、以下のサービスと連携した経験があります。
- Firebase Cloud Messaging(FCM) プッシュ通知に使うやつ
- Cloud Functions (FaaSってやつですね、Web上に任意のエンドポイントを持った関数を作って公開するものです。)
- Firebase Authentication ( 電話、メール、Apple認証、Google)対応済
- Firebase Analytics (アプリの導線解析)トラッカー仕込んで自動レポート生成等
- Firebase CrashLytics(アプリのクラッシュレポート)
- Firebase Remote Config(A/Bテスト、FeatureFlag、強制アップデート等)
- Firestore (KVSのデータストア、チャット構築などに利用。セキュリティルールの設計もOK)
- よくわかんないErrorが出るのも、Firebaseです。CrashLyticsの例外の半分はFirebase由来だった気がするな。といっても、1万台に10件程度ですが
要件定義などの上流対応
- 代表の湯本のみ、対応できます。システムのディレクション業務全般対応できます。
- Schooで講義を持ったり、SpeakerDeckにITプロジェクトの運営ノウハウを網羅した資料を公開しています。
- ITシステムの運用設計、情報セキュリティルールの設定などの業務は対応できないです。システム構築・導入に関するプロジェクトの上流工程のみ、対応できます。
- PMO案件もお断りしています。PMOの経験は浅いため。
稼働と単価
- リードして欲しい or メンバーで構わないで、ロールが変わるため、単価も変わります。
- リードの場合は120万/月〜です。メンバーの場合は90万固定となります。
- 当社の社員のみ派遣します。ウチから別の人を使っていれることはありません。
- コンサルタントとしてITプロジェクトの運営支援に回る場合も、120万/月〜となります。
- リードやコンサルタントで入る場合、フルタイムで入れないこともありますので、ご了承ください。メンバーとして入る場合は、週4〜で対応します。
- 原則、出社は致しません。毎日の出社が必須の案件は、お断りしてます。この時だけ来て欲しい等のスポットはもちろん対応しますが、通常稼働はリモートワークのみとなります。
- 商流は、エンド⇔弊社、エンド⇔貴社⇔弊社の2パターンのみです。2次請以降はすべてお断りしています。
- 別途強い指定がない限り、作業PCは弊社のPCを使わせてください。
- 40時間だけチャージさせて、あとはその都度相談させて、というやり方も歓迎しています。チャージ方式をする場合、最低稼働時間は40時間とさせて頂いています。貴社都合でタスクが用意できなくても、ご請求させて頂きます。
- 最低契約期間は1ヶ月です。3ヶ月縛りなどはやってないです。解約の場合は、前月の10日までにお願いします。意思表示がない場合、自動更新とみなします。
- スタートアップ企業様からのご依頼の場合、1ヶ月で資金がショートして解約になったという事例があり、初回面談時に失礼ながら運転資金のお話をさせて頂いています。資金調達の目処が立たない場合は、お断りさせて頂くこともございます。
- 当社は小さな会社のため、SESでメンバーが入るときは、トップとメンバーが入る構成です。トップの工数は0.2です。トップが手を動かすことはありませんが、弊社メンバーのコードのレビュー、進捗確認、プロジェクトの会議体参加、課題の共有、実装の提案などを行います。
クライアント様の期待値に寄り添う
- どんな案件も、何かしら課題を抱えています。重要視しているのは、クライアント企業様の技術者の受け入れ体制と、体質です。それによって、提供できるバリューが大きく左右されるため。
- 何をつくるかというより、クライアント様がどういう体制でチームを組み、何が出来ていて、何が苦戦していて、どんな問題があって、何を経営や上のレイヤーから求められているか。
- チームのケイパビリティ、欠けているコミュニケーションはどこか、会議体や報告内容は何が必須なのか、理想のアウトプットと当社への期待値をどこでフィットさせるのか。最も重要だと考えています。
上記の内容に興味を持って頂ける方は、ぜひ、お問合せください。
良いプロジェクト・良いプロダクトにしていきましょう!