なにをやっているのか

Java案件の必須要件を見ていると、「基本設計から参画できること」という一文がよく入っています。詳細設計や実装から参画する案件と比べると、この条件が付く案件は求められる経験の質がはっきり違います。

基本設計の工程で決まるのは、機能をどう分割するか、画面と帳票の仕様、テーブル構成、外部システムとの連携方式、非機能要件といった、システムの骨格そのものです。Javaの業務システムでSpring Bootを採用する場合、どの層にどの責務を持たせるか、JPAでエンティティをどう組むかは、この工程での判断が土台になります。OracleとPostgreSQLのどちらを選ぶかによってもER図の書き方や制約の掛け方は変わりますし、外部システムとの連携をREST APIで都度呼び出すのか、バッチ処理でまとめて渡すのかも、基本設計の段階で決めておく事柄です。

私たちは2022年に大阪で創業し、2026年から東京でSES事業を立ち上げています。案件の紹介は日に複数件入ってきますが、お願いできる方が追いついていない状況です。その中でも「基本設計から」という条件が付く案件は、単に参画時期を早めたいのではなく、判断ができる人を探しているという性質が強く出ます。

なぜやるのか

基本設計が固まっていないまま詳細設計や実装に進むと、その歪みは後工程で表面化します。機能分割が曖昧だと、実装の途中でクラスの責務が重なり合い、修正の影響範囲が読めなくなります。画面と帳票の仕様が甘いと、結合テストの段階で表示項目の抜けが見つかり、手戻りが発生します。テーブル構成を詰め切れていないと、正規化のやり直しやマイグレーションの追加が続き、開発期間の後半ほど作業が重くなります。連携方式が固まっていない状態で実装に入ると、REST APIで同期的に呼ぶ想定だったものが、実際にはバッチ処理で夜間にまとめて連携する必要があったと後から判明し、作り直しになる場合もあります。

こうした手戻りは、実装力の高さだけでは防げません。防げるのは、基本設計の段階でどこまで決めておくべきかを判断できる経験です。

どうやっているのか

このため私たちがスキルシートと客先面談の想定質問を一緒に詰める際は、設計書を書いた経験があるかより、設計判断をどこまで自分でしたのかを確認しています。テーブル構成やAPIの区切り方をレビューしていたのか、決めた本人だったのかで、面談での答え方は変わってきます。既存の設計書をなぞって詳細化した経験と、白紙の状態から機能分割やER図を組み立てた経験は、どちらも書類上は「基本設計を経験」と書けてしまうため、面談の中で掘り下げて確認するようにしています。

もう一つ意識しているのが、商流の浅い案件を優先して取る方針です。間に入る会社が多い案件では、基本設計の判断はすでに発注元側で固まっていることが多く、参画するエンジニアには実装寄りの役割しか回ってきません。商流が浅い案件では、設計書のレビューを任される場面や、決まっていない仕様をこちらから提案する場面が実際に生まれやすくなります。

こんなことやります

契約形態は準委任です。稼働形態は案件によって異なり、常駐が前提のものもあれば、フルリモートで完結するものもあります。求める経験は、基本設計の工程で機能分割やテーブル構成、外部システムとの連携方式について、自分で判断した実績があることです。設計書のレビューを任された経験がある方も歓迎します。

カジュアル面談では、その日の案件在庫から合いそうなものを3件、その場でお見せしています。合うものがなければ、その旨を正直にお伝えします。基本設計から任せられる案件を探している方は、まずお話しできればと思います。