自己紹介とインターン参加理由 自己紹介 はじめまして。日本工学院八王子専門学校 ITスペシャリスト科 AIシステム専攻3年の松本康太郎です。 学校ではAIを用いた機械学習や、Kotlinを使ったモバイルアプリ開発など、幅広い分野の学習に取り組んでいます。 最近は運動不足が気になり、ジムでの筋トレを習慣にしようと心がけています。 なぜ数ある企業からここ（サイオス）のインターンシップを選んだのか サイオスのインターンシップを選んだ理由は大きく2つあります。 1つ目は、 Claude Codeを用いたAI駆動開発を経験できる点 です。授業でAIを活用した開発を行うことはありましたが、要件定義や仕様書の作成といった、実際の業務で求められる工程までは触れたことがありませんでした。現役のエンジニアの方からフィードバックをいただき、実務で重視されるポイントを学びながらAI駆動開発に取り組める点に強く惹かれました。 2つ目は、 Git/GitHubを活用したバージョン管理を実践できる点 です。IT業界を目指すうえでGit/GitHubの知識は必要だと認識していたものの、授業で使う機会がなく、学習を始めるきっかけを掴めずにいました。今回のインターンシップはハッカソン形式で、成果物をGit/GitHubで管理すると伺い 、実務に近い形で学べる貴重な機会 だと感じ、参加しました。 インターンシップでの成果物 成果物の紹介 私たちは10日間で、目標（資格取得や就職イベントなど）に対する自分の現在地と、次にやるべき行動を可視化するWebアプリ 「CheckPoint」 を作成しました。 想定通りに計画をこなせず挫折してしまう人向けに、目標達成のサポートをすることを目的 としています。 自分の役割 チームでは、担当を固定せず、そのときに必要な作業を分担しながら進めていました。私は 開発を担当しつつ、チーム内の意見や決まったことを整理する役割 を担っていました。 前半の仕様を固める段階では、メンバーから出たアイデアや懸念を書き出して論点を整理し、 「何を作るのか」「何は作らないのか」をチームの共通認識にすること を意識していました。開発が始まってからは実装に加わり、詰まっている箇所があれば手が空いている人に共有して、 作業が一箇所で止まらないよう 気を配りました。 中間発表以降は、いただいたフィードバックと自分たちで見つけた改善点を洗い出し、優先順位をつけて割り振る作業にも関わりました。10日間という限られた期間の中では、決まった役割をこなすことよりも、 その時手が足りていないところに動くことのほうが大切 だと感じ、臨機応変に立ち回ることを心がけていました。 成果発表までの道のり 私たちのチームは仕様書を固めることに 時間をかけた結果、開発に着手したのは中間発表前日の6日目 という、かなりハードなスケジュールになってしまいました。 中間発表以降は、いただいたフィードバックを基にした機能追加と、自分たちで改善点を洗い出して修正する作業を中心に進めました。 成果発表の感想・気づき 10日間という、私にとっては短い期間でしたが、チームメンバーの協力もあり、なんとか形にすることができました。披露した成果物はまだまだ追加したい機能や修正したい点も残っており、完成イメージに向けて手をかける十分な時間を取ることができなかったことは少し心残りです…！ 成果発表後の社員の方々からのフィードバックでは、 全体の伝え方（プレゼンテーション）に課題がある というご指摘を多くいただきました。長年エンジニアとして働かれてきた方々から、 ビジネス視点で相手に伝わることを意識したコミュニケーションについてフィードバックをいただけたこと は、大きな学びになりました。 チーム開発を通じて感じたこと 開発中は、雑談含めコミュニケーションをよく取っているチームだったため、 分からないことをその場で聞き合える空気感 が常にありました。 例えばGit/GitHubが未経験だった私にメンバーが丁寧に教えてくれ、他にもちょっとした質問にもすぐ反応してくれたおかげで疑問によって手を止めることはありませんでした。 10日間のチームでの作業を通じて、作業が停滞した際に中心となって話を進めてくれたAくんや、バグ修正、発表資料・台本作成といった大変な作業を率先して行ってくれたBくんにはとても助けられました。 新規企画開発に魅力を感じて参加したインターンシップで、メンバーの尊敬できるところを見つけられるほど関係が築けるとは思いませんでした。 気兼ねなく声をかけ、耳を傾け合えたことが、10日間開発を止めずに進められた一番の理由だと確信しています。 インターンを通しての最大の学びと今後の目標 インターンシップ参加前の私は、エンジニアを「技術力で課題を解決する仕事」だと捉えていました。10日間を終えた今、その認識は 「技術を使うかどうかを含めて、判断を積み重ねる仕事」 に変わりました。 きっかけは、仕様を詰める中で交わした「何を作らないか」の議論です。私たちが作成したプロジェクトでは 、目標達成に向けての他のユーザーとの比較表示（「同学年の○%が開始済み」など）を実装しない方針を取りました。 その理由は技術的に難しいからではなく、他者と比較する仕様にしてしまうと、時間の少ない中でこのアプリを使うユーザーを焦らせ追い詰めてしまうからです。同じように、データベースの構造を変更する際も、「進捗を消さずに済む方法」を優先しました。 このように「作ることができるものすべてを作るのではなく、ユーザーにとって良いかどうかで線を引く」。プロの現場では、この判断が実装そのものと同等に重い意味を持つのだと知りました。 エンジニアの仕事は、コードを書く前と後にこそ本質がある のだとサイオステクノロジーのインターンシップに参加したことで理解ができました。 これからインターンを受ける後輩へ向けたアドバイスや応援の一言！ 「分からないことはその場で聞いて解消する」こと を意識するとよいと思います。 私はGit/GitHubを使った経験がまったくない状態で参加しました。それでも10日間を走り切ることができたのは、 メンバーやメンターの方に遠慮せず質問できた からです。 メンターの方はとても優しい方だったので臆することなく質問することを心掛けるとよいと思います！ 今後の目標 今後の目標は3つあります。 1つ目は、 要件定義から関われるエンジニアを目指すこと です。 与えられた仕様を実装するだけでなく、「何を作るべきか」「何は作らないべきか」から考えられるようになりたいと考えています。学校の制作課題でも、いきなりコードを書き始めるのではなく、まずは設計を固めるところから意識していきたいと思います。 2つ目は、 Git/GitHubを日常的に使い続けること です。 インターンで初めて触れたバージョン管理を、一度きりの経験で終わらせないために、個人開発でもリポジトリを作って運用していきます。 3つ目は、 伝える力を鍛えること です。 成果発表でいただいた指摘を活かし、作ったものを説明する機会を意識的に増やしていきます。READMEを丁寧に書く、学内の発表の場に手を挙げるなど、小さな実践を積み重ねていくつもりです。   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Git初心者でも大丈夫！「遠慮せず聞く」ことで完走できた10daysインターン体験談 first appeared on SIOS Tech Lab .

「あ、こっちのリポジトリにスキル移植してなかったや。コピペしとこ」 Claude Code を使っていると、一度はやりますよね。 新規リポジトリに新しくハーネスを移植する際など、あまり良くないとわかりつつ、やりがちだと思います。 そこで今回は、株式会社エブリー Android チームでの、ハーネスの一元管理方法について紹介します。 3 つのリポジトリでコピペしていたハーネスを 1 か所にまとめ、合計 5,254 行の設定を消せました。 「本当は一元管理した方が良いのだろうな」と思っているあなたの一助になれば幸いです。 1. まとめ コピーした設定はズレていくため、一元管理した方が良い。 リポジトリごとの技術スタックの違いにより、単純な共通化は難しい リポジトリごとの大きな技術スタックの違いは、読み込む plugin を変えることで対応する リポジトリごとの小さな技術スタックの違いは、読み込むファイルを変えることで対応する 2. 背景 エブリーには、ネイティブで開発されている Android アプリが 4 つあります。 私がメインで触っているのは、そのうち 2 つと、Kotlin で書いた社内ツールの計 3 つのリポジトリです。 delishkitchen.tv www.docomo.ne.jp Issue を拾って Claude Code に PR まで作らせる、JVM で動く社内ツール 同じ Kotlin ですが、前提条件は違います。 デリッシュキッチン dバリューパス版 社内 JVM ツール 動く場所 Android Android JVM（Android SDK なし） UI XML View + Compose Android View なし DI Hilt + Koin 古い版の Koin のみ なし ビルド定義 Kotlin DSL + 共通ビルドロジック Groovy Kotlin DSL（単一モジュール） version catalog あり なし なし ktlint CI と hook で実行 なし CI で実行 この 3 つに、とりあえずハーネスをコピペしました。しばらく経ったころ、資産がいちばん多いデリッシュキッチンと社内ツールで、同じ名前のファイル 5 本を比べてみました。 同名のファイル デリッシュキッチン 社内ツール 差分（追加 + 削除） 実装手順のコマンド 591 行 530 行 977 行 セキュリティのレビュー用エージェント 151 行 72 行 202 行 Kotlin のレビュー用エージェント 113 行 77 行 174 行 コメントの点検スキル 81 行 75 行 141 行 レビューのコマンド 66 行 77 行 138 行 合計 1,632 行 行数が近いファイルでも差分は大きくて、両側でそれぞれ勝手に書き換わっていました。 ただ重複しているだけなら一方を消すだけで良いのですが、実際は リポジトリごとに中身が分岐 していました。 従って修正のたびに、どちらが正しいのか・どこまで反映すべきなのかを判断する必要が出てきました。 3. 原因 ではコピーした設定は、なぜ書き換わっていくのでしょう。 結論から述べると、 各々がよりハーネスを効かせようとした結果、コード分岐が進む ためです。 あるリポジトリに対して一番よくハーネスを効かせようとすると、具体的な記述が必要になります。 例） Manifest の exported を見る Compose の再コンポジションを見る 実際、Kotlin のレビュー用エージェントを比べると、デリッシュキッチン版には Compose の観点が、社内ツール版には「依存を増やさない」「JVM 17 で動く」など固有の観点が足されていました。 これらのファイルは当然、 技術スタックが違うので流用ができません 。 従って、各々がよりハーネスを効かせようとした結果コード分岐が進んでいくのです。 4. 解決策 DRY 原則に従い 1 つにまとめて配れば良い と、解決策として真っ先に思いつきます。これは正しいと思います。 ただ原因に記載した通り、技術スタックが違うので流用できないという問題を解決する必要があります。下記は私が考えた解決策です。 案 結果 共通部分のみ一元管理し、それ以外は各リポジトリ固有で持つ [不採用] 管理が簡単だが、共有できる箇所が少なく根本的な解決にならないため 技術の組み合わせごとに配布物を分ける [不採用] Compose 用のスキル、Hilt 用のスキル……と組み合わせの数だけ作成するため、配布物が膨大になる 共通の部分を層にして配り、技術ごとの知識はリポジトリの設定を見て読み分ける [採用] 具体的な記述は技術ごとに分けて持ち、どれを読むかをリポジトリごとに選ぶ 配布に関しては Claude Code の plugin を前提としました。 採用案は、大きな関心ごとは plugin を多層で分けます。その層の中で、詳細に関しては capability gate という仕組み (後述) を用いて選択させます。 切り替え 何で決めるか 例 層 どのリポジトリが使うか Kotlin 共通 / Android 共通 / ドメイン固有 capability gate そのリポジトリがどの技術を使うか Compose / Android View / ktlint の有無 4.1 層 どのリポジトリが使うかで、層を分けます。今回の場合、層は Kotlin 共通・Android 共通・ドメイン固有の 3 つで分けました。依存の向きは「ドメイン → Android 共通 → Kotlin 共通」です。 層の境界は、次の基準だけで決めました。 そのハーネスは、 その層を使うリポジトリのうち、使っている技術がいちばん少ないところ でも成り立つか。 層 前提にしてよい 前提にしてはいけない Kotlin 共通 Kotlin、Gradle、git / GitHub など Android SDK、宣言的 UI、DI コンテナ、ビルド定義の書き方、特定の lint ツール Android 共通 Android、Activity / Fragment / ViewModel など 宣言的 UI、特定の DI、ビルド定義の書き方、version catalog ドメイン固有 自社ドメインの業務知識 あらゆる技術スタック これで Android SDK の採用など、大きな技術スタックの違いによる分岐に対応できます。 例えば Android SDK 非採用の JVM ツールでは、Kotlin 共通の plugin を入れることで、Android 関連のコンテキストを無視できます。 それだけでなく、JVM ツール開発時に行ったハーネス修正の知見が、より深い層の plugin を使用するリポジトリにも適用されるのです。 しかしながら、これだけではまだ分岐に対応しきれていません。 例えば Android の UI に関してのレビュースキルを考えます。リポジトリ A では Compose を、リポジトリ B では XML View を使用している場合、それぞれに同じスキルを使用すると、お互いにノイズとなるコンテキストが含まれてしまいます。 ここで 4.1 と同じやり方で Compose 層、XML View 層と分けてしまうと、層の数が膨大になり、依存関係が複雑になることで、管理が難しくなります。 この層の中の違いを吸収するのが、次の capability gate です。 4.2 Capability gate capability gate は、層の中の違いを吸収し、分岐に対応する仕組みです。 使用ライブラリなどの細かい技術スタック (capabilities) を、リポジトリ内に設定ファイルとして持ちます。 実行時にこの設定ファイルを読み、AI コンテキストを切り替えます。 ディレクトリ構成は、下記を想定しています。 技術ごとの観点を SKILL.md 本文から丸ごと抜き出し、 reference/ 配下へ保存します。 SKILL.md の description に分岐条件を記載することで、コンテキストの分岐に対応します。 ui-layer-review/ ├── SKILL.md # 手順と、技術に依らない観点だけ └── reference/ ├── compose.md # Compose の観点 └── xml-view.md # XML View の観点 設定は独自の json ファイルとして保持しています。 { " capabilities ": { " platform ": " android ", " ui ": [ " xml " ] , " di ": [ " koin " ] , " versionCatalog ": false , " lint ": [] } } capabilities.ui の値と、読む reference の対応は次のとおりです。 capabilities.ui 読む reference 振る舞い "ui": ["compose"] compose.md Compose の観点でレビューする "ui": ["xml"] xml-view.md XML View の観点でレビューする "ui": ["compose", "xml"] 両方 差分のファイル種別で当てる観点を決める "ui": [] なし UI レイヤーを持たないリポジトリとして指摘せずに終わる 未設定 なし 未適用としてレビューする 5. 結果 リポジトリ + - デリッシュキッチン 183 2,129 dバリューパス版 446 2,032 社内 JVM ツール 255 1,093 合計 884 5,254 足した行に関しては、主に下記です。 CLAUDE.md の修正 技術スタックの設定ファイル追加 リポジトリ固有ハーネスの書き直し そのリポジトリ固有の情報を持つファイル以外は、一元管理できるようになりました。 これで Claude Code のハーネスを別リポジトリからコピペすることは、ほぼ起きなくなったと思います。 6. おわりに エブリーの Android チームでは、今後 Loop Engineering を導入し、真剣にプロダクト開発速度 10 倍を目指しています。 このハーネスの一元管理化も、その一環として行いました。ハーネス自身の開発速度も向上したため、一歩前進です。 道のりはまだまだ、大変厳しいと思いますが、高い目標に向けて駆け抜けたいと思います。 この記事は、株式会社エブリーで Android アプリ開発を担当している岡田が書きました。 エブリーでは、ともに働く仲間を募集しています。 corp.every.tv

自己紹介とインターン参加理由 自己紹介 はじめまして日本工学院八王子専門学校の百瀬優太と申します。 普段は国内外問わずサッカー観戦を楽しんでおり、 Jリーグの試合を現地まで観に行くほどのサッカー好きです。学校では、主にKotlinを使ったモバイルアプリを中心に開発しています。 なぜ数ある企業からここ（サイオス）のインターンシップを選んだのか 学校の先生からいくつか紹介を受けた中で、このインターンを選んだのは、 自分の抱えて いた2つの課題を解決できる実習内容 だったからです。 1つ目の課題は 「AIの活用」 でした。 個人開発でClaudeを使っているものの、プロンプトの精度が悪かったり高度な機能を使いこなせていなかったりと、独学での限界を感じていました。そのため、 インターンシップ内容にClaudeを用いたAI活用勉強会がある点 に強く惹かれました。 2つ目の課題は 「チーム開発の経験不足」 です。 普段は個人開発ばかりで、特にチームでのGit操作などに苦手意識がありました。だからこそ、 チームでのハッカソン形式の企画開 発の体験ができること は、自分の弱点を克服するための最高の環境だと感じ、参加を決めました。 インターンシップでの成果物 成果物の紹介 チーム開発は、学生3人とメンターの社員さん1名という体制で進めました。 ハッカソン形式での企画開発を主としたプログラム内容で、テーマは 「大学生活における不便、不満、無理を、AIを使って解消する」 でした。 何を作るかの決定は、事前のインターン課題として各自が考えてきた「学校生活で感じる課題」と「そのAIによる解決案」を共有し合うところから始まりました。 話し合いの中でメンバーから挙がったのが、「忙しすぎて就活や資格勉強の何から手をつければいいかわからない」「意気込んで計画を立てても、計画倒れして自己嫌悪に陥ってしまう」という大学生のリアルな悩みでした。 これを解決するため、 「最終的な目標と期日を入力すると、AIが最適なロードマップを提 示してくれるアプリ」 を開発することに決定！ 開発自体も、事前の「AI活用勉強会」で学んだ知識をフルに活かし、 AI駆動開発 で進めました。 自分の役割 チームでは基本的に都度分担しながら業務を進めていきましたが、中でも私が担当したのは、 フロントエンド周りの実装・テスト と 発表に向けた資料および台本の作成 でした。 成果発表までの道のり インターンシップ初日のスケジュール説明を受け、最初は「7日間も使えるなら長いな」と思っていました。しかし、社員さんとの座談会があったり、午後しか開発できない日があったりと、実質的な作業時間は予想以上に短く、終盤はかなり焦る結果になってしまいました。 チーム開発において、使える時間を把握し、チームでタイムマネジメントするこ とがいかに重要か、 身をもって痛感しました。 ただ、企画段階、具体的には 仕様書を固めることに時間をかけたのは、結果的に開発作業 を進めるにあたって優先度の確認や取捨選択する上で良い基準をつくること ができました。 成果発表の感想・気づき 一番印象に残っており、かつハッとさせられたのは、 社員さんからいただいたビジネス視 点に関するフィードバック です。 これまでの個人開発や学校の課題では、自分が学んだ技術を使って、自分が満足するものを作ることに重きを置いていました。しかし、実際の企業では 「ビジネス視点を持ち、ユ ーザーに期待感を持たせるプロダクト（そして発表）にしなければならない」 と教わりました。 「技術的にどう作ったか」だけでなく、「ビジネスとしてどう価値を届けるか、どう魅力 的に見せるか」 という自分にとって新しく、重要な視点に気づかされ、大きな学びになりました。 チーム開発を通じて気づいたこと、学んだこと 今回の開発では、個人開発では得られない多くの学びがありました。 1つ目は、 深掘りした要件定義の経験 です。 詳細な画面遷移図を作成し、「ペルソナにとって本当にこの機能は必要か？逆にこれは不要ではないか？」と徹底的に議論しました。 作る前に「誰に何を届けるか」をすり合わせる工程 は、これまでの個人開発にはなかった経験で、非常に新鮮でした。 2つ目は 実務レベルのAI活用術の習得 です。 チームでのAI駆動開発は初めてでしたが、メンターの社員さんから「実際の業務でのAI活用法」を直接教わったり、勉強会で学んだ「Skill」を活用したりと、自分の知らない知識を得る機会が多くあり、開発に活かすことができました。 インターンを通しての最大の学びと今後の目標 今回のインターンを通して技術面以外で最も大きな収穫だったのは 、「自分が就職したい 理想の会社像」が大きく変わったこと です。 実はこれまで、私は出社が基本の会社に就職したいと考えていました。「リモートワークだと、わからないことを質問するハードルが高そう」「一人だとついサボってしまうのではないか」という不安があったからです。 しかし、 今回のサイオスでのリモートでの作業がメインとなるインターンを実際に経験し、社員さんからリアルな働き方のお話を伺ったことで、その印象は180度変わりました。 リモートでも気軽に質問し合える環境や、メリハリをつけて働く仕組みを肌で感じたこと で、現在ではリモートワークという働き方に非常に大きな魅力を感じています。 これからインターンを受ける後輩へ向けたアドバイスや応援の一言！ もし、このブログを読んで今後のインターンに参加しようか迷っている方がいたら、ぜひ参加することをおすすめします！ 技術的な学びはもちろんですが、それ以外にも得られるものがたくさんあります。 エンジニア目線・ビジネス目線での鋭いプレゼンフィードバック、就職してからのリアルな「ぶっちゃけトーク」、AIを活用したチーム開発のリアルな空気感など ネットで調べる だけではわからない、働くことへの解像度がグッと上がる 、本当に良い機会になるはずです！ 今後の目標 将来的には、 幅広い分野の技術に携われる「フルスタックエンジニア」 になりたいと考えています。 ただ広く浅くこなすだけでなく、「この分野なら自信がある！」と思えるような、 自分の強力な武器（得意分野）を一つ併せ持ったエンジニア を目指します。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 「作って満足」からの脱却。AI活用とチーム開発で変わった僕のエンジニア像（サイオスインターンシップ2026【1期Bチーム】） first appeared on SIOS Tech Lab .