はじめに
23新卒が新規事業プロジェクトで3~4ヶ月間リードエンジニア経験したという記事。
ほぼ読み物。マインド多め。技術的なお話は後半にします。
これから新卒入社する人、新規事業をする人に刺さって頂けたら幸いです。
自己紹介
株式会社Relicでエンジニアをしております。23年4月新卒入社。
学生時代、Web系はほぼ未経験(GETってなんすか)
ロボティクス系の学部で機械学習の研究をしておりました。
なぜ新卒が？
まず気になるのはここからだと思います。
- ストレッチアサインメントという文化
- 新卒というポテンシャル
ストレッチアサインメント
自分の現状の能力以上の責任を要求されることです。もちろん、同意の上でのアサインなので受動的ではありません。例えば、グレード1のエンジニアに求められる工数が1としたら、1.2ぐらいの負荷が要求されるといった感じで、スキル向上や仕事に対する当事者意識が芽生えるアサイン方法です。
通常の企業では、能力以上の責任を任せるためには、社内試験の合格や資格取得が必要であり、それが社内規定でガチガチに定められていることが一般的だと考えられます。しかし弊社では、特別な手続きを経ずとも、能力を伸ばして1.2の負荷を1でこなせるようにサポートすることでストレッチアサインを実現し、社員の成長を促進しています。
新卒のポテンシャル
社内での新卒に対する責任委託の動きがあります。実際、新卒が成長するためには、座学よりも実践形式の学びが効果的であるとの考えが広まっていて、新卒のポテンシャルを引き出す動きが活発になっています。
せっかくポテンシャル採用したので、なるべく早くその能力を最大限伸ばしたい、価値を最大化したいという感じですね。
実際そのアサインのお話に対してどう思ったか。
「ストレッチアサインというより、オーバーアサインでは」
「自分を追い込むことが苦手でめっちゃ不安！」
「しかし、これは成長と昇給のチャンス。とりあえず受けるかぁ」
今では、
「貴重な機会をいただきありがとうございました」
プロジェクトを通して学んだ点、参考になった点について
- 個の成長を促進する組織の特徴
- プロジェクト運営
- プロダクト開発
組織の特徴
- 「個」を最大限の考慮いただいたこと
- 「個」あってのチーム、組織という考え方
- 「個」を適切に「チーム」に組み込む体制が整っていること
アサイン時には、個人の現時点だけでなく将来を見越した志向性や考え方の部分が最大限考慮されます。
組織によってはトップダウンで「君来週からこのチームね」と言われ「あ、はい」となることが多いと思いますが、しっかり上長と1on1で相談をいただける場がありました。
プロジェクトの運営
- プロジェクトはチーム全体の力で成果を上げるものという考え
- 個々のメンバーが持つ能力や志向性を最大限活かせるチーム体制
- プロジェクトのメンバーは意思決定のプロセスにも積極的に参加
プロジェクトのメンバーは単なる「リソース」としてではなく、意思決定のプロセスにも積極的に参加し、自らの専門知識や視点を活かしてプロジェクトに貢献していました。
自分も学生時代に培った専門性を活かすことができました。「新規事業は専門家が集まってできる総合格闘技」と社内で比喩されることもありますが、まさにそのことを体感いたしました。
また、プロジェクトの進行管理においても、透明性と柔軟性が重視されていました。デイリー、ウィークリーのミーティングを設けることで、メンバー間のコミュニケーションを促進し、進捗や課題に対する共通認識を形成します。そのため、変化に柔軟に対応しながら目標達成を目指すことができたと思います。
プロダクト開発
- ユーザのニーズに泥臭く向き合う姿勢
- アジャイルな開発手法の採用によるスピード感と適応性
- チーム全体でのコラボレーションによる創造性の発揮
常にユーザについてキャッチアップしていました。Relicは新規事業の専門家集団ではあるが、ドメイン知識は無いです。ミーティング毎に顧客のユーザ像に耳を傾け、常に提案できる状態で開発を進めていました。
設計は変更容易性の高いものにし、一旦動くものを作ろうと動いていました。また、プロダクトの主要素であるロジックを先方と伴走して整えるという経験もしました。柔軟性とスピード感を持ってプロダクトを改善していくことができたと思います。
チーム全体が協力し合い、アイデアを出し合いながら創造的な解決策を見つけることができました。これらの経験を通じて、コミュニケーションの重要性や自分の成長を感じることができました。
プロジェクトの詳細な流れ
以下二つのシーンで話します
- 要件定義
- 設計＆開発
要件定義
- 機能要件
- 非機能要件
機能要件
一言で言うと実際に顧客が求めてくる「こういうの欲しい！」をまとめたものです。
開発するシステムやアプリケーションがどのような機能を持つべきかを具体的に記述します。これには、ユーザが行いたい操作やシステムが提供すべき機能を含みます。機能要件を明確に定義することで、開発プロセスの方向性を明確にし、開発者が目指すべき目標を把握しやすくなります。
非機能要件
一言で言うと、アプリケーションを世に出すにあたって、品質や適応性を担保するためのものです。自動テストや、可用性のためにAZを増やすみたいなやつです。
システムが持つべき性能や品質に関する要求を示します。例えば、セキュリティ、パフォーマンス、信頼性、使いやすさなどが非機能要件に該当します。非機能要件は、システムの品質や適用性を保証するために重要です。これらの要求を明確に定義することで、開発者はシステムの設計や実装においてこれらの要件を適切に考慮することができます。
要件定義の過程では、顧客との密接なコミュニケーションを欠かさないこと。
- 開発者と顧客(発注者)との認識のズレはよくある話
- 要件を正確に把握し、プロジェクトの成功に向けた基盤が築かれる
- 不明瞭な部分や矛盾点を事前に発見し、解決することが重要
そうはいっても開発の途中で不明点が出てきて変更なんて話は良くあるので、これだけは絶対に押さえておきたい本質的な部分を捉えて、変更しやすいように定義する動きが望ましかったりします。
要件定義はプロジェクトの成功に向けて不可欠なステップであり、リードエンジニアはその過程で的確に要件を把握し、開発チームに明確な方針を与える役割を果たします。
要件定義の参考になる神記事
設計&開発
開発プロセスでは、要件定義で明確に定義された機能要件と非機能要件に基づいて、システムやアプリケーションの実装が行われます。以下に、開発プロセスにおけるいくつかのポイントを示します。
- 機能要件の実装
- 非機能要件の考慮
- 継続的なテスト
機能要件の実装
機能要件に基づいて、システムやアプリケーションの機能を実装します。この際に、ユーザが期待する動作や操作に合致するように機能を実装することが重要です。
DBを設計(後述)、定義して、バックエンドでゴニョゴニョして、フロントエンドにJSON渡してやる一連の処理の連続で楽しく実装しました。実際に動くものができた時は感動しましたね。422いる？空で返すから200にしません？みたいな話も楽しかったですね。
非機能要件の考慮
非機能要件に基づいて、システムやアプリケーションの品質や性能を確保します。例えば、セキュリティやパフォーマンスなどの要件を考慮して、適切な設計や実装が行われます。また、可用性や拡張性などの要求に応えるための構成や設計も重要です。
パフォーマンスでいうとEager Loadingでn+1対応をすることはもちろんですが、Lazy Loadingにしていい場面が生じるのか考えたりする部分でもかなり頭を使って楽しかったなと思います。
(参考)
https://stackoverflow.com/questions/31366236/lazy-loading-vs-eager-loading
継続的なテスト
開発プロセスでは、継続的なテストが行われます。ユニットテスト、統合テスト、システムテストなどの段階で、実装された機能が要件に準拠していることを確認します。また、テストを通じて発見された不具合や改善点に対するフィードバックも重要です。
正常系、異常系で各画面やファンクションごとにテストコード書きました。変更点出てきてもテストのおかげで修正箇所がすぐ分かったりするので、とりあえず書いておくのがおすすめだったりします。
(参考)
結局、新卒リードエンジニアに求められる力は何だ
- 事業推進力
- マネジメント力
- 開発力
-
事業推進力：
事業をこうしていきたい、こうしていきましょうよと要件も含めて提案できること -
マネジメント力：
チームとして期限までにする目標を立てて達成することができること -
開発力：
要件をコードに落とし込むぞ。
弊社内では上記3つが求められてくるかなと思います。技術は手段で、事業を推し進める。そのための開発やマネジメントという位置付けになっております。「要件決まってないから、できません！」ではなく「要件を一緒に決めていきましょう！」という姿勢です。
実際に互いに議論し合って落とし込んだものを実装するのは楽しいです。動くものができた時はさらに楽しいですね。やったね。
上記の「力」について、もう少し粒度を上げてまとめてみる
仕事をする上で本質的に求められる力とは、「個」と「チーム」が互いに尊重し合いながら、協力し合い、相乗効果を生み出すことができる能力です。
自己の責任を全うし、リスクや挑戦に果敢に立ち向かうことができる「個」としての力が重要です。同時に、「チーム」としての協力や共創が不可欠であり、個々の力を結集し、目標達成に向けて努力することが求められます。
まとめると、
１ 絶対的な当事者意識を持って責任を全うする力
リスクと正しく向き合って構想を描いて挑戦する力
２ リーンにシコウ(志向、思考、試行)を続ける力
３ インテグリティを持ち、仕事に向き合う力
Co-Creation(共創)できる力
１の力は、「個」としての力
２の力は、分類できませんが、あえて言うなら「コミュニケーション」としての力
３の力は、「チーム」としての力
と考えています。
ざっくり言えば、「個」と「チーム」はトレードオフではなく、正しく摩擦を起こしながら成長し合えますよっていう考え方です。
新規事業のプロジェクトを通じて上記の考え方が理解できました。
自分もまだまだ途上ですが、仕事をする上で本質的に求められてくると考えているので、引き続きこの辺りの力をどう伸ばしていくか考えていきたいと思います。
(参考)
プロジェクトで難しいと感じた技術的なお話
- DB設計
- 顧客の強みであるビジネスロジックの数式化
DB設計の難しさ
データの正確性と効率性の両立
-
データの正確性: データベースは企業の重要な情報を保管するため、データの正確性は非常に重要です。正確なデータがなければ、システムの信頼性や機能性に問題が生じる可能性があります
-
データモデリングの適切性: 適切なデータモデルを設計することは、データの関連性や整合性を保持する上で重要です。適切な正規化や関係性の設計が必要です
(初心者特有の悩みかもしれませんが)このテーブルが持つ役割はこうで、このカラムに役割を別で持たせたいのであれば、分けてやるみたいな考えの切り替えが難しかったです。どこまで正規化していいか、正規化しすぎたから非正規化するかとかですね。
(参考)
パフォーマンスとスケーラビリティの確保
-
パフォーマンスの最適化: データベースのパフォーマンスは、システム全体の効率性に直結します。適切なインデックスやクエリの最適化など、データベースのパフォーマンスを最適化する技術が必要です
-
スケーラビリティの考慮: データベースの設計は、将来の拡張性やスケーラビリティを考慮する必要があります。システムが成長してもデータベースが追随できるような設計を求められます
どこまでインデックスを持たせるかという部分で結構悩みました。各カラムにインデックス持たせるのはいいけど、持たせすぎるとなぁみたいな部分です。
(参考)
DB設計で参考にした本や記事
ビジネスロジックの数式化の難しさ
顧客が持つ独自のビジネスプロセスやアルゴリズムを数学的な形式に落とし込むことを指します。これには、業界や企業に固有の複雑なロジックやアルゴリズムを理解し、それを設計＆実装可能な形で表現する必要があります。
- ドメイン知識の理解
- 複雑なアルゴリズムの抽象化
- コミュニケーションの課題
ドメイン知識の理解
顧客の業界やビジネスプロセスに関する深い理解が必要です。業界特有の用語や手法、ルールなどを理解し、それを数学的な表現に落とし込む必要があります。
実際に顧客とのコミュニケーションを通じて業界特有の考え方や計算方法などをご教示いただきました。それに対してもっとこうすればいいのではないかと、チームで提案することができました。
複雑なアルゴリズムの抽象化
顧客が持つ複雑なアルゴリズムやロジックを、数式やアルゴリズムに変換することは容易ではありません。アルゴリズムの抽象化や数学的なモデル化には高度な技能が必要です。
前歴があり、自分の「個」としての強みが発揮できた部分です。〇〇を計算するために必要な変数としてみたいなことをひたすら仮説検証してました。
コミュニケーションの課題
顧客やビジネスエキスパートとのコミュニケーションも難しい側面があります。ビジネスの専門家と技術者との間で、ロジックや要件に関する誤解や意見の相違が生じることもあります。
実際に顧客から「〇〇という変数はそういう考え方では無いです。こういう考え方で〜」とご教示いただく部分も結構ありましたが、最終的に擦り合わせることができました。
相手との距離、心理的な距離だけではなく、ドメイン知識の差異によりロジックの見え方が全く異なっているという意味での距離も理解し、どうすれば縮められるのかを考えていく必要もありました。
これからの新卒エンジニアへ
新卒の皆さんへのメッセージとして、自分の経験から得たことをシェアしたいと思い、今回の記事を投稿いたしました。自分は未経験からスタートし、リードエンジニア(１段階)としての成長を遂げることができました。
その過程で、常に以下の意識を持つことが重要だと気づきました。
- 仕事は単なる業務遂行ではなく、自己成長と新たな挑戦の場という側面も持ちます。適切な組織や環境があれば、成長することは可能です。自分自身の強みや弱みを正直に見つめ、努力と学習に取り組む姿勢が大切です
- チームワークと相互サポートも成長に欠かせない要素です。自己犠牲、他者犠牲することなく、相互に理解し合う姿勢が大切です
- 自らの夢や目標を持ち、それを追求することをお勧めします。未経験からでも、目標に向かって努力することで、自らの可能性を広げることにつながります
「自分の能力が足りない。価値が無い。もっと勉強しないと」で終わるのではなく、
「今自分が提供できる価値は何か。
中長期にわたって、どうすれば自分が提供できる価値を最大化できるか」
です。
誰もが何かしら価値を持ってます。大丈夫です。相対的な価値だけではなく、絶対的な価値も見つけていきましょう。
最後まで読んでいただきありがとうございました。
よきエンジニアライフを。