SESでエンジニアをお探しの方へ

SESでエンジニアをお探しのシステム開発会社様・事業会社様・SaaS等のプロダクトを運営している会社様・スタートアップ企業様向けの、弊社の要員とスキルについてです。

WebアプリはTypeScript / Python

  • 言語は上記だけ対応しており、テックリードも対応できます。少なくとも、自走できるメンバーが揃っています。
  • TypeScriptは、バックエンドも書いています。React, ReactRouter v7、Conform, Shadcn/ui, Drizzle / Kysely あたりのキーワードがおわかりの方、嬉しいです。特にRRv7に力を入れています。Next.jsはあまり力を入れていません。かけることはかけますが、というレベルです。
  • 関数型プログラミングを意識してコードを書いています。エラーハンドリングはNeverThrowを使ってます。asyncResultの取り回し，もうちょっとなんとかならないかと思います。
  • クラスはネームスペースとして使うぐらいで、クラスの中身は全部staticの関数で作る方式になっています。関数が第1級オブジェクトの言語の場合、クラスにデータを保持してそれを書き換えるようなコードを書く必要がないためです。コードが純粋ではなくなります。
  • Pythonは、Flask / FastAPI / SQLAlchemy / Peewee あたりを使っています。TypeHint必須のコードを書くようにしています。SQLAlchemyを辞めたいんだけど、それ以外のORMがあまりない。

ネイティブアプリはFlutterのみ

  • 2021年からFlutterをやっています。テックリード可能です。メンバー育成も可能です。
  • Riverpod, flutter_hooks, dio, freezed, Retrofit, GoRouter, GoRouterBuilderあたりのキーワードがおわかりの方、嬉しく思います。
  • flutter_hooksはあまり使わないです。useController, useAppLifeCycle, useEffectぐらいです。それ以外は利用しないことが多いです。
  • Riverpodは登場人物が多いので直感的ではありません。HooksのようにカスタムHookがかけるわけじゃないので、自由度も下がります。しかし、Riverpodの自動リビルド検知の仕組みに慣れるとコードがHooksより均一化されるので、Riverpodで統一しています。
  • 「Riverpodはグローバルの状態管理をするものでWidget単位の状態管理に利用しない」という誤解があります。TextContollerをグルーバルで引きます意味がないだけです。Widgetにも、状態を管理すべきものとそうでないものがあります。後者は、ふつーにPropsを公開してStatelessWidgetにすればいいだけです。
  • Riverpodで気をつけているのは、RiverpodでDIするのは、Viewがアタッチするデータだけ。レポジトリレイヤーのコードはDIしない。RiverpodのWidgetRefはBuildContextですので、非同期処理を挟んだ時が面倒です。context.mountedであーでもないこーでもないやるのは、不毛です。
  • レポジトリやAPIが含む処理はなんぼでもありますが、それらをRiverpodのNotifierのメソッドの中にラップして、DIする時はNotifierのメソッド自体をMockするだけで充分だと思います。
  • WidgetのBuildメソッドでRiverpodでDIしたオブジェクト「以外」で、外部接続する可能性がある変数や関数の初期化は一切禁止したいんですが、やり方がわからないのが悩みです。レビューで弾くしかないのかな？ Claudeに言えばやってくれる？ AIでカスタムLintつくる時代？
  • アーキテクチャはFeature-Firstで、以下の構成が基本です。
    • page: ユーザーが実際に操作する画面
    • components: ページを構成するWidget群で、基本StatelessWidgetでProp公開
    • state: RiverpodのProviderを定義する所
    • model: APIのインターフェイスのモデル(UIで読み書きする対象のデータ)
  • GraphQLは経験がないです。RESTのみです。
  • DeepLink対応できます。国内最大級のフラッシュセールのECアプリ構築で、散々やりました。GoRouterで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万/月〜となります。
  • リードやコンサルタントで入る場合、フルタイムで入れないこともありますので、ご了承ください。メンバーとして入る場合は、週４〜で対応します。
  • 原則、出社は致しません。毎日の出社が必須の案件は、お断りしてます。この時だけ来て欲しい等のスポットはもちろん対応しますが、通常稼働はリモートワークのみとなります。
  • 商流は、エンド⇔弊社、エンド⇔貴社⇔弊社の2パターンのみです。2次請以降はすべてお断りしています。
  • 別途強い指定がない限り、作業PCは弊社のPCを使わせてください。
  • 40時間だけチャージさせて、あとはその都度相談させて、というやり方も歓迎しています。チャージ方式をする場合、最低稼働時間は40時間とさせて頂いています。貴社都合でタスクが用意できなくても、ご請求させて頂きます。
  • 最低契約期間は1ヶ月です。3ヶ月縛りなどはやってないです。解約の場合は、前月の10日までにお願いします。意思表示がない場合、自動更新とみなします。
  • スタートアップ企業様からのご依頼の場合、1ヶ月で資金がショートして解約になったという事例があり、初回面談時に失礼ながら運転資金のお話をさせて頂いています。資金調達の目処が立たない場合は、お断りさせて頂くこともございます。
  • どんな案件でも、弊社のメンバーが入る場合、弊社トップの人間が0.1〜0.2の工数を頂戴しています。
  • 当社はメンバーを一人だけ派遣することは一切しておらず、弊社の場合は、トップとメンバーが入る構成です。トップが手を動かすことはありませんが、コードのレビューやプロジェクトの立ち振舞、質問事項などがあれば、こちらから突っ込みますので、どうぞよろしくお願い致します。

クライアント様の期待値に寄り添う

  • どんな案件も、何かしら課題を抱えています。うまくいってないこと、多かれ少なかれ、ございます。
  • 重要視しているのは、クライアント企業様の技術者の受け入れ体制と、体質です。
  • 何をつくるかというより、クライアント様がどういう体制でチームを組み、何が出来ていて、何が苦戦していて、どんな問題があって、何を経営や上のレイヤーから求められているか。
  • チームのケイパビリティ、欠けているコミュニケーションはどこか、会議体や報告内容は何が必須なのか、理想のアウトプットと当社への期待値をどこでフィットさせるのか。最も重要だと考えています。

上記の内容に興味を持って頂ける方は、ぜひ、お問合せください。

良いプロジェクト・良いプロダクトにしていきましょう！