はじめに
この記事はSchoo Advent Calender 2025の22日目の記事になります。
こんにちは！株式会社Schoo基盤開発チーム内定者インターンの@takishun_schooです。
現在大学院に通いながら週4ほどSchooで開発インターンをしています。
本記事では、これまでハッカソンなどで 「とにかくコードを書いて形にする」ことばかり重視していた自分が、Schooの実務開発で「業務理解の壁」 にぶつかり、盛大な手戻りを経験した失敗談について書きます😇
概要
- 内定者インターンに参加した理由
- ハッカソンでの経験とSchooとの出会い
- 現在の業務内容
- 失敗談：スプリント内に開発が終わらなかった話
- 失敗の原因と対策
- 学び：価値あるエンジニアの定義とは
内定者インターンに参加した理由
背景
自分は元々「高専」という学校に所属し、ハッカソンや競技プログラミング、ゲーム開発等を行っていました。当時の開発スタイルは、とにかく成果物発表に間に合わせるための「スピード重視」でした。
「動けば正義」というマインドで、期限が近くなると夜通しコードを書き続ける日々でした。もちろん、その経験で培った瞬発力や実装力は自分の武器になりました...が、徹夜続きの限界開発が生み出すのは、その場しのぎのコードばかり...
当時の開発風景はまさにこんな感じ
ある日、ハッカソンで作ったサービスを高専の寮で使ってもらいたく、事務の方々に提案しました。しかし、返ってきた言葉は「No」でした。
「学生が作った、質の担保されていないサービスを使うのはセキュリティリスクが高い」
寮生の間ではそのサービスの評判が良かったので、断られた事実が非常に悔しかったのを覚えています。
そこで、今までの自己満足、あくまで自分用の開発から、多くの人に使ってもらえるシステムの開発、質の高い成果物の製作をしたいと思うようになりました。
Schooとの出会い
そんな思いを抱いていた時、Schooと出会いました。Schooは個々人の「学習」と「変化」を非常に大切にしている会社です。
- 入社前の技術力よりも「成長しようとする姿勢」を重視
- リプレイスを通じた「設計思想」の学習
- 特定の技術領域にとどまらず、インフラを含めた基盤構築からアプリケーションの新規機能実装まで、幅広い開発レイヤーへ挑戦できる
単にコードを書くだけでなく、「リプレイス」という変化の激しい環境にも身を置くことで、「ビジネスとしての価値」と「それを支える強固な技術基盤（アーキテクチャ）」の両面を学べる環境だと感じました。
「ここなら、自分に足りない『品質』や『チーム開発のノウハウ』を吸収し、エンジニアとして次のステップへ進める」と確信し、入社、そして内定者インターンへの参加を決めました。
インターン参加の狙い
上記の環境に身を置き、これまでのハッカソン（スピード重視・動けば正義）での経験をアップデートするために、以下の3点を重点的に学びたいと考えています。
-
「気合い」に頼らない、予測可能な進捗管理
- タスクを適切に分解・見積もりし、計画通りに遂行する能力（個人のマネジメント力）
-
「変更に強く、他人が読める」アーキテクチャの理解
- リプレイスの現場で設計思想を学び、スパゲッティコードではなく、将来にわたって保守性の高いコードを書けるようになる
-
ビジネス要件と実装の「整合性」を担保する力
- 領域横断でシステム全体を見渡し、要件定義から実装、テストまで一貫性のある開発ができるようになる
まもなく開発チームでの内定者インターンは4ヶ月目を迎えますが、日々この目的を念頭に業務に邁進しています。
現在の開発環境
チーム横断での挑戦
現在は、既存サービスのリプレイス（最新アーキテクチャの学習）と、基盤開発チームに所属しながらユーザー向け機能開発チームの新規プロジェクトにも携わっています。
これは単に手を広げているわけではなく、「実際の開発業務を通じて、既存システムの構造や複雑に入り組んだ仕様を"体感"として深く理解してほしい」という意図でアサインしていただきました。
具体的には、BackendやBFF (Backend For Frontend) のAPI設計・実装を担当しています。 「どう設計すれば既存システムと整合性が取れるか」悩みながら手を動かす毎日ですが、内定者のうちから色々なチャレンジの機会を頂けて、本当に刺激的な環境です（アサインしてくださった @junichi_fukushima_schoo さんに感謝！🫡）。
開発技術だけでなく、チーム開発フィードバックのための指標 "Doraメトリクス"を新規プロジェクトへ導入することを担当させていただいています。デプロイまでの期間などを計測してチーム開発の良さを評価する指標ですね。
自分はインターン中に初めて聞いて「なんだこれ？」という感じだったので、チーム開発の進捗管理について、自分がまだまだ知らないことって沢山あるんだなー...と改めて感じましたね。
開発スタイル（スクラム）
チーム開発はスクラム体制で行っており、1スプリントの中で密にコミュニケーションを取りながら進めています。具体的には以下のサイクルを回しています。
- デイリースクラム（毎朝 15~30分）：日々の進捗確認と課題の共有
- リファインメント（毎スプリント 1~4時間）：タスクの具体化と見積もり
- スプリントプランニング（毎スプリント 1~2時間）：次スプリントの計画策定
- スプリントレビュー（毎スプリント 1~2時間）：成果物のデモとフィードバック
また、メリハリをつけるために毎週水曜日は「作業集中デー」として原則MTGを入れない運用になっています。
フルリモート環境ですが、基盤チームでは毎週金曜夕方に「コーヒーブレイク」という雑談タイムがあり、肩の力を抜いて話せる良い関係性が築けています。
しかし——。 そんな充実した環境の中で、自分は「ハッカソン時代の癖」が抜けず、ある失敗をしてしまいます。
失敗談：スプリント内に開発が終わらなかった話
ここからは、自分がインターン中に経験した最大の失敗についてお話しします。 その失敗とはズバリ、「スプリント（開発期間）内にタスクが終わらなかったこと」です。
エンジニアなら誰しも、「これならすぐ終わるだろう」と思っていたタスクが沼にハマり、期限ギリギリになって冷や汗をかいた経験があるのではないでしょうか？ 自分もまさに、その「見積もりの甘さ」と「見切り発車」で痛い目を見ました。
甘すぎた見積りと、ハッカソン脳の代償
当時振られたタスクは、Backend側で「ある表示条件の変更」を行うというものでした。
タスクの概要を見て、直感的にこう判断しました。
「編集すべき箇所さえわかればこのタスクはすぐ終わるだろう」
これが大きな間違いでした。自分は実装対象の仕様を曖昧にしか理解していない状態で、「とりあえずコードを変更、動作確認した方が仕様を理解できる」という、まさにハッカソン時代の "走りながら考えるスタイル" で着手してしまったのです。
いざコードを読み始めると、変数の意味やテーブル間の依存関係が自分の想像していたものよりも難しく、全く内容がつかめませんでした。
「技術的にコードを追えば分かるはずだ」と意地になって読み解こうとしましたが、そもそも「なぜこういう実装になっているのか」という業務的な背景を知らないため、コードが何を意図しているのか翻訳できなかったのです。
締め切り前日のレビュー依頼
業務メンターや先輩社員に質問してサポートしてもらえる環境があるので、本来であれば相談しながら進めるのが筋でした。しかし、当時の自分は「自分がどこまで分かっていないのか」すら分かっていない状態に陥っていました。その結果、不明点をクリアにしないまま、「なんとなくの自分の理解」だけで実装を進めるという行動をとってしまいました。
さらに、時間の使い方にも大きな間違いがありました。 早めにコードレビューに出して方向修正すべきだったのに、それをせず、その手前にE2Eテスト（動作確認）に時間を費やしてしまったのです。
背景には、ハッカソン時代の「バグがあっても、デモで動けば勝ち」の癖が残っていました。自分は論理的な正しさ（設計）よりも、現象としての正しさ（動作）を優先してしまっていたのです。「正しく動作するかわからないコードを人に見せるのは失礼だ」という思い込みもあり、レビューの前にデモ環境での確認に執着してしまいました。
その結果、火曜日がスプリントの締め切りであるにも関わらず、コードレビュー依頼を出せたのは月曜日（締め切り前日）。 しかも、そこで「仕様を完全に満たせていない」ことが発覚し、実装前の仕様理解フェーズまで戻ることになりました。当然、スプリント内でのリリースは間に合いませんでした。💣
分析：なぜ失敗したのか
なぜ、単純に見えたタスクでここまでの失敗をしてしまったのか。
それはエンジニアとしてのスタンスの勘違いにあったと思っています。
価値あるエンジニアの定義
自分はこれまで、「すごいエンジニア ＝ 高い技術力（コーディング力）がある人」だと思っていました。だからこそ、分からないことがあったときに「コードを読んで（技術で）解決しよう」としてしまったのです。
しかし、今回の失敗を通じてメンターの方から教わった「価値あるエンジニア」の定義は違いました。
今回の自分の失敗は、まさにこの「業務理解力」が欠落していたことが原因です。
-
要件の背景(Why)を知らなかった
- 「コードはどうなっているか」ばかり気にして、「なぜこういう実装がされているか」、「なぜ変更が必要なのか」、「どんな影響が起こるのか」を理解しきれていなかった
-
課題の特定・調整を怠った
- わからない箇所がどこかわかっていない状態で、独りよがりな実装を進めてしまった
「仕様を理解していないコード」は、どんなに動いていてもそれはただの「動くゴミ」になりかねません。単に技術力の不足で失敗したのではなく、「作る前に解決すべき課題を理解していなかった」から失敗しました。
どうすべきだったか（反省と対策）
前述の「価値あるエンジニア」になるためには、以下を適切に行うことだと思いました。
-
「どう書くか」の前に「何を作るか」を把握する
- コードエディタを開く前に要件定義書を読み込み、「分からない場所が分からないまま」次の行動に移らない
- コードを読んでも分からない時は、ドメイン知識（業務知識）が足りていない可能性がある
- 分からないことはすぐに有識者にヒアリングを行う
-
各段階でレビューを挟む
- 実装のみならず、各ステップで認識合わせのためにレビューで合意をとる
-
レビューや手戻りを含めた見積もりをする
- 「自分が作業する時間」だけでなく、「レビュワーに見てもらう時間」「修正する時間」を含めてスケジュールを引く
今後どうしていきたいか
今回のインターンでの失敗を通じて、自分のエンジニアとしての目標（目指す姿）の解像度が大きく上がりました。
これまでは「どんな機能でも爆速で作れるつよつよプログラマー🔥」になることこそが正解だと思っていました。勿論それも大事ですが、今は技術力を武器にしつつも、それ以上に「業務・課題を深く理解し、チームで最大の価値を生み出せるエンジニア」になりたいと思っています。
- 言われた通りに作るだけでなく、「なぜ作るのか」から一緒に考えられる
- 技術的な難易度だけでなく、ビジネス的なインパクトやリスクも考慮して開発を進める
技術力は、価値を届けるための「手段」であって「目的」ではありません。 この失敗で学んだ「業務理解力 × 技術力」を胸に、残りのインターン期間、そして春からの社会人生活でも、全力で開発に向き合っていきたいと思います！
最後に
直近の開発での生々しい失敗を、そのままAdventCalenderの記事にさせていただきました。
失敗はしましたが、Schooはこういった失敗を「次の成長の糧」としてポジティブに受け入れてくれる環境です。入社前にもたくさんのことにチャレンジしてこれからもっと成長していきます！💪
ここまでお読みいただき、ありがとうございました🙌
Schooでは一緒に働く仲間を募集しています！