株式会社ログラスの5Daysサマーインターンに参加してきました
はじめに
2026年8月13日から17日にかけて行われた、株式会社ログラスの5Daysサマーインターンに参加してきたので、今回はその振り返りを書いていく。
.png){kind=small}
参加までの経緯
きっかけは1月18日に東京国際フォーラムで開催された「外資就活Expo」の横で同時開催されていた「Engineer Guild Fes(EGF)」まで遡る。 ちなみに、このイベントはAtCoder経由で知った。
このイベントで、会場内の企業ブースで株式会社ログラスのブースに立ち寄った際に、サマーインターンの案内を頂いた。
その後、2月末のエンジニア職向け人事座談会にて正式に応募し、スキルシート(書類選考)、コーディングテスト、技術面接を経て、参加が決まった。
日程は私が参加したお盆の時期のものが最後で、その前に3タームあったようだ。
インターン課題
今回のインターンシップで取り組んだ課題の概要は、以下の通り。
会社の経営企画部門を顧客として、「Excel で管理された仕訳データから、簡単な損益計算書と貸借対照表を自動計算したい」という課題に対して、これを実現するためのシステム「ミニログラス」を、ドメイン駆動設計とスクラムで開発する。
技術スタック:
- フロントエンド: Next.js / TypeScript / React / Tailwind CSS
- バックエンド: Kotlin / Gradle / Spring Boot / jOOQ
- データベース: MySQL / Flyway
なお、実装時は支給された Claude Code Pro プランを利用することができた。
5日間のスケジュール
全日程、都内の品川にある本社オフィスにて、オフラインで開催された。
業務時間は10時から19時までで、昼食は全てお弁当を用意していただいた。
1日目
- 会社概要・事業説明
- インターンシップ課題説明
- メンター紹介・自己紹介
- チームビルディング
- ジャーナリングマッピング
- 前提知識インプットのための講義
- 管理会計ドメインについて
- 簿記の基礎・損益計算書(PL)と貸借対照表(BS)の構造
- スクラムについて
- Claude Code ベストプラクティス
- ドメイン駆動設計(DDD)について
- 管理会計ドメインについて
- チームごとの作業
- 顧客課題の整理とプロダクト価値の定義
- 開発環境構築
- IntelliJ IDEA / Docker / GitHub リポジトリの整備など
2日目
- デイリースクラム
- モデリング作業
- システム関連図・ユースケース図・オブジェクト図・ドメインモデル図の作成
- プロダクトバックログ・スプリント1バックログの作成
- 顧客課題とプロダクト価値、モデリング作業、バックログの成果のフィードバック
- フィードバックをもとに修正
- スプリント1のプランニング
- メンターの方からのフィードバック
3・4日目
- デイリースクラム
- 今スプリントの開発作業
- 3日目はスプリント1、4日目はスプリント2の開発作業
- スプリントレビュー・レトロスペクティブ
- メンターの方が顧客役となって、スプリント1の成果物をレビューしてもらい、フィードバックをもらう
- 次のスプリントのプランニング
- 次のスプリントの開発作業
5日目
- デイリースクラム
- スプリント3の開発作業
- 並行して、EMとの1on1面談も実施
- 成果発表に向けたスライド作成
- 並行して、事前アンケートでの希望職種に応じた社員の方との1on1面談も実施
- 成果発表・質疑応答
- 講評・結果発表
- チーム内での振り返り
- 懇親会
チームの開発内容
結論から言うと、今回のインターンでは時間内に顧客の課題に対応したプロダクトを完成させることはできなかった。
それを踏まえたうえで、私のチームでは、顧客課題を解決するためにどのようなプロダクトを作ろうとしたのか、どのような開発プロセスを経て、何ができて何ができなかったのかを整理していく。
私たちのチームでは、「仕訳データが記録されたExcelファイルを取り込み、PLとBSを自動集計して確認できる」という一連の体験を提供することにプロダクトの価値を置き、開発を進めていった。
1日目と2日目では、まず顧客課題と上記の提供価値を言語化し、Figma 上でシステム関連図、ユースケース図、オブジェクト図、ドメインモデル図を作成した(講義内で紹介されたsudoモデリング)。 その後、プロダクトバックログを整理し、3日目以降はスプリントごとに開発と顧客レビューを繰り返した。
ドメインモデルでは、会計上の事実である「仕訳」を中心に置いた。 1つの仕訳は複数の仕訳明細から構成され、仕訳明細は勘定科目、仕訳は部署と関連する。 また、科目と部署を親子関係のある階層構造として扱うことで、上位の科目や部署へ集計できるようにした。
私が担当したこと
一連のモデリングが終わった後、実装時はチーム内で役割分担を行った。 私が実装で担当したのは、主に勘定科目と部署の一覧画面の機能と、それに関連する仕訳データ取り込み時の機能である。
勘定科目や部署は階層構造を持つため、一覧画面では親子関係を折りたたみ・展開が可能なツリー構造で表示するようにした。 また、一覧画面から画面遷移することなく、情報の変更や子要素の追加・削除・移動が可能になるようにした。
加えて、Excelファイルからの仕訳データ取り込み時に、システム上に登録されていない勘定科目や部署があった場合に、取り込み画面上でそれらを新規登録できるようにした。
その他の開発内容
仕訳データのExcelファイルは、会社や利用している会計ソフトによって、ヘッダーの位置や列名、列の並びが異なるであろうと考えた。 そのため、特定の形式だけを受け付けるのではなく、ファイルを登録した後に内容をプレビューし、ユーザーが各列の意味を指定できる画面を検討・実装した。
具体的には、ファイルごとに次の項目を対応付けられるようにした。
- 日付
- 仕訳番号
- 部署名(課名)
- 借方勘定科目
- 借方金額
- 貸方勘定科目
- 貸方金額
また、ユーザーが指定したヘッダー行の値を列の選択肢として表示し、設定結果をプレビュー上でも確認できるように複数のファイルを切り替えながら、それぞれのマッピング状態を保持する画面も作成した。
将来的には、一度確定した列の対応関係をテンプレートとして保存し、同じ形式のファイルを次回から自動で取り込める構想も考えた。 さらに、ヘッダー名だけでなく、セルのデータ型や借方・貸方の合計一致などを利用して、列の意味を自動推定する方法も検討した。
完成できなかった要因
一方で、管理会計ドメインの理解やモデリング、顧客課題の解像度を高めることに想定以上の時間がかかり、開発への着手が遅れた。
また、短いスプリントの中で実装を優先した結果、実装中に新しく分かったことをモデルへ反映する作業が後回しになり、モデルとコードの同期を十分に保つことができなかった。
さらに、レビューを通して顧客の反応を確認する中で、顧客が求めているのは「PLやBSを表示する画面そのものではなく、仕訳データの集計作業を減らしたうえで、会社の正確な経営状態を早く把握し、意思決定に使えるようにすること」であると分かってきたものの、最初に決めたプロダクト価値の修正が間に合わないまま、時間が過ぎてしまった。
本来は、PLやBSの表示を最終目的とするのではなく、その先にある予実管理や部署別の分析まで見据えたうえで、予実管理や部署ごとの集計など、顧客が求める体験の全体像を整理し、最も重要な体験から優先順位をつけて開発する必要があったと思われる。
インターンで学んだこと
DDDにおけるモデリングは「仮説」である
インターンの参加前、DDDについては、ドメインモデルに対して「十分に議論し、正しい形を見つけてから実装するもの」というイメージを持っていた。
しかし、実際の開発では、最初から完全に正しいモデルを作ることはできない。 開発者側が顧客が抱える問題の領域に十分な知識を持っていない場合、そもそも「何が正しいのか」の判断基準を設定すること自体が難しい可能性があるからだ。
初日に行われた、社員の松岡さんからのDDD講義の中でも、「初期設計の中で作成したモデリング図の良し悪しは、この段階ではわからない」ということが強調されていた。 モデリングはあくまで抽象的な解決策の仮説であり、仮説はその正当性を検証されるべきものである。 その検証のために、実装を行い、実際に動かしてみて(ときには顧客のレビューを受けて)...というフィードバックのサイクルを繰り返すことが重要なのだ。
そうして新たな情報を得るたびに、当初のモデルと現実との間にギャップがあることが分かる。 そのギャップを埋めるために、モデルを更新していく。
このように、モデルを固定された成果物として扱うのではなく、あくまでチーム内の認識を揃えるためのものとして、理解の変化に合わせて育てていくことが大切なのだと学んだ。
今回の開発では、短い期間の中で実装を急いだために、実装が先行してモデルの更新が後追いになる場面が多かった。 その結果、モデルが設計や議論のための道具ではなく、実装後の説明資料のような扱いになってしまった点が反省点である。
スクラムは「チーム開発のためのフレームワーク」である
私はちょうど大学の前期の授業で「ソフトウェア工学」という科目を履修しており、アジャイル開発の文脈で「スクラム」の概念については軽く触れていた。 当時の理解度としては、「短期間(スプリント)の目標を定め、短いフィードバックサイクルを回していくことで、効率的な開発を行う手法」くらいの認識だった。
ところが、チームの中で実践してみると、スクラムは単に開発の効率化を目的とした手法ではなく、主にチーム内の対立を軽減し、パフォーマンスを向上させるためのフレームワーク的なものだと感じた。 しかも、このフレームワークを順番通りにただこなすだけでうまくいくわけではない。
スクラムを機能させるためには、各サイクルでの進捗を報告するだけでなく、次の点も含めてチーム全体で共有する必要があると感じた。
- 今、何を検証しようとしているのか
- 何を基準に優先順位を決めたのか
- どのような課題や不確実性があるのか
- 次のレビューで何を確かめたいのか
このような点の認識をそろえ、仮説の検証と適応を繰り返すために、チームが主体的に使うフレームワークがスクラムなのだと学んだ。
価値のあるプロダクトとは何か?
今回、最も考えさせられたのが「価値のあるプロダクトとは何か」という問いである。
当初は、仕訳を取り込んでPLやBSを表示できれば、課題を解決できると考えていた。 実際、課題の説明にもそれが主な目的であるかのように書いていたし。
一方で、レビュー時に顧客が本当に求めていたのは、PLやBSを表示する画面そのものではなく、「仕訳データの集計作業を減らしたうえで、会社の正確な経営状態を早く把握し、意思決定に使えるようにする」ということだった。 具体的には、
- 予実管理のために、実績だけでなく予算のデータも取り込みたい
- 会社全体のPL・BSだけでなく、部署や期間ごとに売上高・費用・利益を集計して比較したい
- 利益率の高い部署や領域を把握して、経営資源の配分を最適化したい
といったようなことを求めていたはずだったと、振り返って思う。
機能を作ったとしても、それが顧客の業務をどのように変えるのかを説明できなければ、価値を提供できたとは言えない。 また、短い開発期間では、思いついた機能をすべて作ることはできない。
したがって、各プロダクトバックログについて「誰の、どの課題を、どのように改善するのか」を明確にし、最も重要な体験から完成させる必要があった。 その上で、レビューを通して顧客の反応を確認し、次に作るべきものを決めるというサイクルを何回も回していくべきであったと思う。
インターンシップを通しての感想
今回のインターンでは、DDDやスクラムについて講義で学ぶだけでなく、実際のチーム開発の中で試行錯誤しながら体験できたことが、何よりも大きな収穫だった。
参加前は、プロダクト開発において重要なのは、要求された機能を正しく、素早く実装することだと考えていた。しかし、今回の5日間を通して、実装する機能を決めるまでにも多くの難しさがあることを知った。
顧客はどのような業務を行い、どこに困っているのか。その課題を解決するために、どのような体験を提供すべきなのか。そして、限られた時間の中で何を優先して作るのか。これらについてチーム内で認識をそろえ、顧客から得たフィードバックに応じて修正し続けなければならない。
特に印象に残ったのは、機能を実装できたことと、顧客に価値を届けられたことは必ずしも同じではない、という点である。今回、私たちは個々の画面や機能を実装したものの、「仕訳データの取り込みから、経営状態の把握・意思決定まで」という一連の価値を完成させることはできなかった。
その結果には悔しさが残っている。一方で、プロダクトを完成させられなかった理由をチームで振り返ることで、顧客理解、モデリング、バックログ、実装を一連の流れとしてつなげることの重要性を実感できた。順調に開発が進んでいたら、これらの難しさをここまで深く考えることはなかったかもしれない。
チーム開発そのものについても、多くの学びがあった。各自が作業を分担するだけでは、チームとして同じ方向には進めない。自分が何をしているかだけでなく、どのような前提で、何を検証するために取り組んでいるのかを共有する必要がある。また、認識のずれや分からないことを早い段階で表に出し、チームで扱える状態にすることも重要だと感じた。
私は作業に集中すると、時間配分や全体の優先順位への意識が弱くなってしまうことがある。今回も、担当機能をよりよくしようと考える一方で、プロダクト全体として何を完成させるべきかという視点が不足する場面があった。今後の開発では、実装に着手する前に 「誰の、どの課題を解決するのか」「今回の時間内で、どの状態まで到達すべきか」を確認する習慣をつけたい。
社員の方々との1on1や懇親会も印象に残っている。現在住んでいる地元だけでなく、大学の学部まで同じだった先輩社員の方と話す機会があり、これまでの経験や今後のキャリアについて、身近な視点からお話を伺うことができた。
懇親会では、ある分野における自分の専門性をどこまで深めるか、その一つの指標として、
上司を飛び越えて、自分に直接相談が来るようになるか
という話を伺った。その状態になれば、その分野における能力や専門性が周囲から認められている証拠であり、そこを目指して学び続けるとよい、という内容だった。
AIの進化によって技術・知識の民主化が進んだことで、「広く・浅く」といったキャリアパスにはやや不安を感じている一方で、「この領域なら自分に任せてもらえる」と言えるほど深く学べている分野は、まだほとんどない。この言葉を、今後どの分野を専門として伸ばしていくか考える際の一つの指針にしたい。
プロダクトを完成させられなかった悔しさも含めて、開発技術だけでなく、顧客理解、チームでの意思決定、専門性の高め方についても考えるきっかけとなった、非常に密度の高い5日間だった。
おわりに
同期のメンバーやログラスの社員の皆さまには、お盆の時期にもかかわらず、5日間にわたって大変お世話になりました。開発中の相談やレビュー、1on1、懇親会など、さまざまな場面で丁寧に向き合っていただき、本当にありがとうございました！
