こんにちは！普段はClaude Code関連のブログをよく書いている、エンジニアの龍ちゃんです。 今日はいつもと少し趣向を変えて、サマーインターンのお知らせをさせてください。 サマーインターンとは 今回の対象は、 28卒（2028年3月卒）・理系・プログラミング経験1年以上の学生 さんです。 平日10日間のハッカソン形式のインターンで、時給1,500円、交通費と宿泊費は全額支給となっています。遠方からでも参加しやすい設計になっているのがポイントです。 実は、社内のインターン担当の方から「Tech Lab. のブログでも告知してもらえないかな？」と相談を受けたんですよね。 現在、大学経由でも参加者を集めているのですが、もう少し仲間が増えるとうれしいな、という状況のようです。 そこで、ただ募集ページのリンクを貼るのではなく、現場でコードを書いているエンジニアの目線から「ここが良いと思う」というポイントを正直にお伝えしたほうが伝わると思い、この記事を書いています。 最近、採用面接や入ってきたばかりの新卒社員と話す機会がよくあるのですが、皆さん学生の頃の自分よりはるかに能動的で、驚かされることが多いです。元学生として思うのですが、就活ってどうしても企業と学生がお互いを遠目に探り合う感じになりがちですよね。 「自分に何が足りないのか」「企業ならではの視点」「この会社が自分に合うのか」といったことは、外から眺めているだけではなかなか掴めません。 その点、インターンは一度中に入ってしまえば会社の雰囲気を肌で感じることができます。 外から探り合うより、よっぽど手っ取り早くて良い経験になると思っています。だからこそ、いつもブログを読んでくれている学生さんにぜひ届いてほしいです。 どんなインターン？ 正式名称は 「ITエンジニアの仕事がわかる！アイデアを形にする10daysインターンシップ」 です。 その名の通り、平日10日間、ハッカソン形式で手を動かしながら会社のことも知れる構成になっています。 中身を整理するとこんな感じです。 プログラム内容ざっくり言うとハッカソン形式の企画開発チームで企画から手を動かして開発します。インターンのメインです。 • 事業紹介 サイオスがどのようなビジネスを展開している会社なのかを知ることができます。 • AI活用勉強会 開発現場で生成AIをどう活用しているか。私が現在社内で担当している領域です。若手エンジニア座談会年次の近い先輩に、入社前のリアルな話を聞くことができます。 • ベテランエンジニアからのフィードバック 作った成果物に対して、現役のベテランエンジニアからコメントをもらえます。 現場の人間から見て「ここがいいと思う」 プログラムの全部が良いのですが、現場目線で特に魅力的に感じるポイントを3つだけ紹介します。 • ベテランエンジニアからのフィードバック 自分の作ったものに対して、経験豊富なエンジニアから具体的な指摘が入る環境は、独学だとなかなか作れません。せっかくの機会なので、普段気になっていることや行き詰まりがちなポイントを、ベテランに存分にぶつけてみてほしいなと思います。 • AI活用勉強会 手前味噌になりますが、私がまさに社内で生成AIの活用を推進している立場です。現在の開発現場でAIをどう使っているか、生で見られる機会はまだ少ないと思うので、興味がある方には面白い内容になるはずです。 • 若手エンジニア座談会 会社に入る前に「中の温度感」を知るのが一番難しいところです。年次の近い先輩に直接質問できる場は、求人票を何度も読むよりも参考になります。「入社前のリアル」が聞けるのは、かなり貴重な時間だと思います。 開催概要 日程や待遇などの詳細は以下の通りです。 日程 第1期　 2026年7月27日(月)〜8月7日(金) 第2期　 2026年8月17日(月)〜8月28日(金) 就業時間 平日 10:00〜17:00（休憩 12:00〜13:00） 開催形式 リモート / 出社のハイブリッド（初日と最終日は出社予定） 待遇 時給1,500円、交通費・宿泊費は全額支給 対象 2028年3月卒業予定の方（理系学部、情報系だとなお良し。プログラミング経験1年以上） 宿泊費も支給されるため、遠方にお住まいの方も参加しやすい環境になっています。 応募はこちらから ということで、サイオステクノロジーの28卒サマーインターンの告知でした。 会社への理解を深めつつ、実際に手を動かしてスキルも磨ける夏になると思います。 少しでも気になったら、ぜひ詳細ページを覗いてみてください。ご応募をお待ちしています！ ▼ 詳細はこちら（プログラムや待遇のフルバージョン） https://sios.jp/recruit/info/fresh.html ▼ エントリーはこちらのフォームから https://forms.gle/kZqik2pbzDZPNeUn7 【カジュアル面談のご案内】 「いきなり応募するのは少しハードルが高い」「対象に当てはまるか不安」という方には、インターンとは別に、エンジニアと気軽に話せるカジュアル面談（オンライン・30分前後）もご用意しています。現場の社員に直接聞いてみたいことがある方は、ぜひこちらからお申し込みください。 ▼ カジュアル面談の申込はこちら https://mk.sios.jp/casualvisit_entry.html それでは、また次回の記事でお会いしましょう！ The post 現場エンジニアがお勧めする、サイオスの28卒サマーインターン first appeared on SIOS Tech Lab .

はじめに はじめまして！株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」のQAを担当している柏尾です。 普段はQAチームで品質保証にかかわる業務を担当しています。 2025年5月ごろから品質保証の業務とは別で、カイポケ開発部内でのMonthly Win Sessionの運営をはじめました。 Win Sessionとは一般的に、メンバーそれぞれが「Win（成果や良かったこと）」を共有し、称賛し合う場です。 運営としての活動開始から約1年程度経過したので、今回はその経緯やどのような活動を実施しているかをご紹介します。 Monthly Win Sessionをはじめたきっかけ エス・エム・エスでは、過去に開発部内横断での情報共有の場や広報誌という良い取り組みをシェアするような場がありました。 いずれも非常に長く続いてきた取り組みで、取り組みが設計された時よりも組織が非常に大きくなっており、職能の多様化も進んできました。 そのため、その意義や良い点は引き継ぎつつ、現在の組織に合わせた再設計を行い、エス・エム・エスのプロダクト開発部が大切にしているバリュー「あなたがコミュニティ」（詳しくは コチラ ）をよりいっそう体現する新しい枠組みとして検討されていたのが「Win Session」という形でした。 Win Sessionのアイデアが持ち上がり、運営メンバーはマネージャー陣からの推薦で声をかけていただきました。 ただ、決して業務として強制されたわけではなく、「興味があるか」「やってみたいか」と丁寧に意思を確認してもらった上で、納得して運営チームへの参加を決めました。こうした個人の意志を尊重してくれるところは、今の組織のいいところだなと感じています。 集まったのは、開発エンジニア、デザイナー、プロダクトオーナー、そしてQAである私の6名です。所属チームもバラバラで、初対面のメンバーも多い中でのスタートでした。 Win Sessionをやろうという方向でスタートしたものの、場の設計などは全て運営チームの裁量に任されています。「やり方は自由に検討していい、予算が必要なら相談もOK」という、かなり自由度の高い状態です。 まずは「自分たちがどうしたいか」を考えるところから、運営チームの活動がはじまりました。 運営チームの熱い想い 運営チームは普段はあまり接点の無い人が多く、お互いの考え方や仕事のスタイルなど、何も知らない人もいる状態でした。 そのため、まずは全員がWin Sessionに期待することや想いを出し合い、考えのすり合わせを行いました。対話を重ねる中で、各メンバーが組織の課題解決に対して、高い当事者意識を持っていることがわかり、このチームで活動していくことへの期待感が高まりました。 この段階では、早くWin Sessionの開催までもっていったほうが良いのではないかと、焦りを感じることもありました。振り返ってみるとしっかり想いを出し合って、丁寧に目的意識をすり合わせたことはとても重要な時間だったと感じます。 1年近く運営してきて会の改善に取り組んでいる中で、意見が食い違うこともありました。しかし最初に方向性をしっかりすり合わせているため軸がぶれず、最終的にはみんなで納得しながら判断できていると感じます。 現在はWin Sessionを「お互いの理解を深め称賛し合うことで、開発部全体のパフォーマンスを高める交流の場」ととらえ、毎回の会を運営しています。 また、目指したい姿として、「取り組みと称賛のループ」「壁を薄く、重力を軽く」という2つを挙げて取り組んでおります。 称賛の場からさらに良い取り組みを呼び、称賛を受ける、そんなループを作りたいと思っています。 また、カイポケ開発部はいくつものチームに分かれ、更にいくつもの職種の人が存在しています。チームの壁、職種の壁を薄くし、お互いの交流を促すきっかけの場にしていきたいという思いがあります。 運営の進め方 運営の進め方として、現在は週1回の定例MTGを実施しています。それ以外の日は資料作成などタスクを持ち帰って進めることもあります。 メンバーの所属チーム・職種がバラバラである分、繁忙期のタイミングも異なるため、各自の業務状況を見ながら可能な人が積極的にタスクを引き受け、分担することができています。 定例MTG自体も業務状況を見て欠席してもよいというスタイルです。 メインの業務の傍らで継続的に運営するために、運営の負荷を減らすことも重要なテーマだととらえており、定例MTG自体の時間を短くできないか試行錯誤したり、テンプレ化できるものはテンプレ化するといった改善も重ねています。 Win Sessionの実際の会では、参加者からのアンケートも回収しており、そのフィードバックや会の盛り上がりをみながらより良い会にすべく模索を続けています。 例えば、Win Sessionをはじめた最初のころは、より多くの発表を聞きたいため、発表時間は5分縛りにする案が上がっていました。しかし実際にWin Sessionをやってみると、質問が盛り上がることもあり、時間を短く縛りすぎるのはかえって会を盛り下げることになるかもしれないという懸念が運営チーム内で生まれました。 そういった状況を鑑みて、現在は月に1時間の会の中で発表本数は2本のみに制限しています。発表自体は1本あたり最大20分程度で残りの時間を質疑応答や深掘りの会話の時間にあてています。 Monthly Win Sessionの発表例 現在はMonthly Win Sessionとしておよそ月に1回の頻度でオンラインで開催しております。参加者は毎回80人を超える会となっています。 様々なチーム・職種の方に登壇いただき、他の組織の活動を知るきっかけにもなることができています。 オンライン開催のため、感想や質問はSlackの実況チャンネルを用意していますが、毎回たくさんの感想や称賛のコメントで盛り上がっています。 実際の発表時のSlack 単に「すごいね」で終わるだけではなく、発表内容を他のチームで取り入れるなど、業務に役立った事例も多数あります。以下では実際の事例をいくつかご紹介します。 「スクラムチームでモブテストをやってみた」 こちらは記念すべき第1回の1発目の発表です。開発エンジニア、デザイナー、QAで集まってモブプログラミングのようなイメージでテストを実施した事例を実例とともに発表いただきました。 発表直後にはもう以下のようなSlackが流れ、他のチームに良い影響が広がっており、運営チームとしてもとてもうれしかったことを覚えています。 取り組みが波及した例 「生成AIを活用したデザイナー協業ワークフローの再構築」 AIを活用してデザイナーがVibe Codingでデザインを組むために、非エンジニアがAI活用するための環境整備を行った取り組みを発表いただきました。 AI活用は弊社内でもトレンドとなっており、他のチームでも同じような取り組みをしようとしていたと声が上がっていました。 とてもホットなトピックで、実況チャンネルがとても盛り上がっていました！ 「非エンジニアが​AIを​使って​開発環境で​開発した​話」 2例目にあげた「生成AIを活用したデザイナー協業ワークフローの再構築」のセッションをきっかけに実施された取り組みについて発表いただきました。 2例目の発表からわずか3か月後に発表までしていただいており、素晴らしい取り組みにとても驚きました。 私たちが目指している「取り組みと称賛のループ」に一歩近づいたことを実感できる事例でした。 課題とこれから目指したいこと Win Sessionは毎回アンケートでも好評をいただいており、良い影響も生み出せていますが、まだまだ課題はたくさんあります。 最も大きな課題はやはり「発表者集めの難しさ」です。 会をはじめてから1年間で、発表の立候補もいただきましたが数自体は少なく、立候補のみで継続して運営することはできていません。 そのため、現在はSlackを活用した他薦・自薦のネタ集めを中心に行っています。 Slackのリアク字チャンネラー機能 を使っており、Winだ！と思ったSlack投稿にWin Sessionスタンプを押すとWin Session用のSlackチャンネルへコピーされるようにしています。 Slackで使用しているスタンプ コピーされてきたものの中から、より関心がある人が多そうなネタを選んで運営チームから関係者に発表いただけないか声掛けを行っている現状です。 ありがたいことに発表の声掛けをして断られた事例は無く（時期が合わないため先の発表にしてほしいなどはもちろんありますが）、みなさん好意的に引き受けてくださり、運営としての心理的な負担もなく、継続していくことができています。 現在の状況でもそれほど負荷なく運営できている事実はありますが、運営から声掛けをして登壇者を募るフェーズは、あくまで自走に向けた準備期間だととらえています。 誰かに頼まれたから話すのではなく、日常の小さなWinを自然に発信したくなるような、そんな空気が醸成されて初めて、Win Sessionは組織の文化として根付いたと言えると思っています。よりカジュアルに、より気軽に参加できる場を目指して、これからも改善を重ねていく予定です。 運営チームに参加してみて ここまで運営の仕組みや課題についてお話してきましたが、最後に運営メンバーとして活動してきた感想にも触れさせてください。 運営を通して何より刺激を受けたのは、全員が常に目的意識をもって意思決定を進めている点です。ただ漫然とWin Sessionの会を開催するだけでなく、常に目的を達成するための会にできているか思考しながら運営を進めています。 私たちが日々取り組んでいるカイポケのシステム開発も同じで、業界の課題をどう解決するか、常に考えながら向き合うことが求められており、その姿勢がメンバーの習慣となっているように感じました。 本業の枠を超えた活動を通じて、「常に目的意識をもって課題解決をする」大切さを再確認できたことが私にとって大きな収穫でした。 また、チームや職能が異なる人と働く面白さも感じました。 弊社では日ごろの業務の進め方はチームの裁量に任せられているため、チームごとの特色があります。今回他のチームの方と長期間働いてみて、そのごく一端ですが知ることができました。 わかりやすい例だと、Miroの使い方ひとつとってもチームごとに特色があり、良いなと思った活用方法はチームに持ち帰って役立てています。 役割の面では、個人的にはデザイナーさんの考え方に触れることができたことが学びにつながりました。現在私が所属しているチームではすでに稼働中のシステムを担当していることもあり、デザイナーさんとお仕事する機会はほぼありませんでした。 今回デザイナーさんと何度も会話する中で、ユーザー目線、受け取り手目線の考え方がとても勉強になり、QAとしてプロダクト品質に向き合う中でも持つべき視点を学ぶことができました。運営チーム内の他のメンバーからも「Win Sessionでぜひデザイナーさんの話を聞いてみたい」という声が何度もあがっていました。 チーム、役割の異なる人と働くメリットを知ることができたので、こういった機会は今後も大切にしていきたいと感じました。 おわりに 私個人としてはこういった大きなイベント運営にかかわったことはほとんどなく、運営に参加することは大きなチャレンジでしたが、今では一歩踏み出して良かったと思っています。 自由に試行錯誤させてくれる社風や、意見を前向きに受け入れてくれるメンバーのリアクションに助けられて、楽しく活動を継続することができています。 この記事を通じて、Monthly Win Sessionの空気感や、エス・エム・エスの空気感が少しでも伝わればうれしいです。

はじめに 2025年新卒のブランドソリューション開発本部ZOZOMO部OMOブロックの東谷です！　私は筋トレが趣味なのですが、増量期（筋肉をつけるために体重を増やす時期）が終わろうとしています。早く痩せなきゃと思いつつ、つい揚げ物や甘いものを食べ、現実から逃げている今日この頃です。 早いもので入社からもう1年が経ちました。この1年を振り返って一番強く感じているのは、 スクラムは「アジャイル開発の手法」であると同時に、新卒にとっての最高の学習環境だった ということです。 配属直後の自分は、リファインメントの議論についていけず、実装中もどこから手をつけてよいか分からない状態でした。それでも1年後、チームの中でスクラムを一通り回せるようになりました。この変化は、研修や独学だけではなく、スクラムの各イベントそのものに大きく支えられました。 スクラムがよく語られるのは「ビジネス価値を最大化する仕組み」としての側面です。しかし新卒視点から見直してみると、これらはすべて先輩たちの思考プロセスを短時間で観察し、その場で質問できる場でもありました。書籍やドキュメントでは身につきにくい「思考の型」、つまり先輩がどんな問いを立て、何をよりどころに判断しているかという基準があります。これを学べる環境として、スクラムは新卒にとって非常に整った構造を持っていると感じています。 この記事では、「思考の型」を自分が新卒1年目に具体的にどう身につけたかを振り返ってみます。題材として取り上げるのは、プロダクトバックログリファインメント（以下、リファインメント）、スプリントプランニング（以下、プランニング）、モブプログラミングの3つです。前者2つはスクラムイベントで、モブプログラミングはチームで採用している開発プラクティスです。新卒エンジニアには「スクラムは新卒の最高の学習環境になりうる」という視点を、新卒受け入れを担う開発組織には育成設計のヒントを提供できればと思っています。 目次 はじめに 目次 配属直後の自分とチームの環境 スクラム開発で身についた3つの学び 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 先輩が立てる「問い」が、自分の視野を順に広げていった 議論を経て、機能の質と学びが見えた 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ Acceptance Criteriaで「実装の自由度」を制御する 見積もり精度はAC定義の解像度の問題に集約される 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた 先輩は事実から方針を決めていた 「事実から始める」という型を学んだ AI時代に、思考の型はどう活きるか おわりに 配属直後の自分とチームの環境 配属前の自分にとって「開発」とは、仕様が決まったタスクを実装することとほぼ同じ意味でした。 学生時代に長期インターンとして参加していたのは、ITベンチャー企業のBtoBプロダクト開発チームでした。そのチームのバックログには仕様まで書かれたタスクが並んでおり、エンジニアはその中から自分でタスクを取って作業する開発サイクルでした。タスクはリーダーが起票していき、起票時点で何を作るかは決まっています。自分の仕事は、それをコードに落とす精度と速度を上げることだと思ってました。 そんな自分が配属先の今のチームに入ったとき、まず驚いたのは開発サイクルの「広さ」でした。 リファインメントでは、プロダクトバックログアイテム（PBI）の目的や受け入れ条件を整理し、チームで認識を揃えながら実装可能な粒度まで要件を具体化します。プランニングでは、スプリントゴールを踏まえてチーム全員で作業内容を確認し、相対見積もりをしながらスプリント内で達成する内容を決定します。開発中はモブプログラミングを通じてリアルタイムに知識共有と意思決定を行います。スプリントレビューでは完成したインクリメントをステークホルダーとともに確認し、次の方向性を議論します。 この1週間のスプリントを、新卒の自分も初日からチームの一員として回すことになります。それまでの開発経験と決定的に違ったのは、バックログにタスクが並ぶ前の段階から、自分も議論に参加するという点でした。 もう1つの驚きは、議論についていくために要求される知識の量です。リファインメントやプランニングでは、複数の前提知識を踏まえた議論が当たり前のように展開されます。例えば、自分の担当しているサービスが他のサービスとどう連携しているか、CQRSで構築されたデータの流れはどうか、認証基盤との関係はどうなっているのかなどです。配属直後の自分は、議論の中で出てくる用語の半分も追えていない状態でした。 「自分が貢献できるだろうか」。最初の数週間、率直に言ってそう感じていたのを覚えています。 ところが、振り返ってみるとこの環境が、自分にとってこれ以上ない学習機会になっていました。スクラムの各イベントが、まさに知識、経験が足りていない新卒にとって最適な学習装置になっていたからです。 スクラム開発で身についた3つの学び ここからは、新卒1年目で身についた3つの学びを、具体的なエピソードとともに紹介します。 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 私が所属しているチームでは、ZOZOTOWN上でブランド様の店舗在庫を確認し、商品の取り置きができるサービス「 ZOZOMO店舗在庫取り置き 」を開発しています。複数のマイクロサービスが連携し、CQRSを採用しているため、イベントを通じたデータの流れを理解することが開発の前提になるプロダクトです。 配属されてしばらく経った頃、ブランド様の店舗情報をシステム上で更新できる機能を実装しました。それまでは開発チームが手動で対応しており、完了までに3営業日ほどかかっていました。ブランド様を待たせることになり、運用者の認知負荷や作業時間も大きいという課題がありました。 議論に参加する前、私の頭にあったイメージは簡単でした。「入力フォームを作って、POSTで更新するAPIを叩けば完了」。配属されたばかりの私は、機能を「実装するもの」として捉え、実装イメージが浮かんだ時点で完成像が見えたつもりになっていました。 ところが、実際のリファインメントの議論はまったく別の地点から始まりました。 先輩が立てる「問い」が、自分の視野を順に広げていった 最初に出てきたのは、システム構造に対する問いでした。認証基盤との関係、マイクロサービスごとの責務、そしてデータがどのサービス間をどのように流れるのか、といった内容です。私が「POSTを1つ作ればいい」と思っていた機能は、実際には複数のサービスにまたがってイベントを発行し、各サービスがそれぞれの責務でデータを更新していくものでした。CQRSやイベント駆動の設計は独学で吸収するには時間のかかる領域ですが、議論の場で出てくる用語や設計判断についてその場で質問できることで、認知負荷の高い情報を一気に吸収できました。 次に、システム設計が具体化してくると、想定していなかった論点が次々と出てきます。「店舗情報が更新されたことをどう確認するのか」「確認するためにはどのデータが必要か」。考えるべきことが膨らんでいくなかで、先輩から自然に出てきたのが「 この機能はそもそも何を解決するものだったっけ？ 」という問いでした。 そこから議論は、機能を実装する話からユースケースを実演してみる話に切り替わります。実際の運用者の動きを想像し、ときには運用者に直接ヒアリングしながら、ユーザー体験ベースで仕様が具体化されていきました。 例えば、「店舗情報として更新できるデータは何があるのか」を全部洗い出すところから始まりました。さらに「運用者が更新ボタンを押す前に、入力ミスがないと安心できる状態は何か」「更新した後、本当に意図通りに反映されたかをどう確認するか」など、ユーザー体験の細部にまで問いが続いていきます。これらに応える形で、機能の中身が具体化されていきました。 さらに出てきたのが、「この機能を実装した後の恒久的な運用フローはどうなるか？」という問いです。「今回のケース以外にも対応できる汎用性って必要だっけ？」「逆に今回のユースケースに限定すれば不要となる実装ってないっけ？」のように汎用化を考える問いと、削ぎ落とすための問いが、同じ場で同時に飛び交っていたことが印象的でした。 象徴的だったのが、ブランド情報の鮮度をめぐる議論です。ZOZOMOのシステム構成上、店舗が所属するブランド様の情報が変わったとき、システム側は正常に更新されますが、その変更がリアルタイムで運用ツールに表示されない仕組みでした。そのため運用上、「正確なデータを変更しているかどうか確認したい」と運用者から開発側へ問い合わせを受けるケースの発生も予測されました。今回の店舗情報の更新機能を考えるうえで、この運用上の課題へ手を入れる余地があると判断し、ブランド情報を最新状態として取得し直す機能を同じ画面の中で組み込むことになりました。この機能を実装した結果、関連する問い合わせは発生していません。目の前の機能要求だけでなく、運用される将来の状態まで含めて考えることで、機能の質が変わっていく瞬間でした。 議論を経て、機能の質と学びが見えた リファインメントの議論を経て、最終的な機能は、私が当初抱いていたイメージとは大きく違うものになりました。最終的にできたのは、店舗情報の更新作業だけでなく、その前後で必要になる作業まで1画面で完結できる機能でした。 1画面に統合したのは、更新前の確認（店舗IDから店舗名・ブランド名を表示）、更新後の確認（変更後データの表示）、そしてブランド情報の鮮度を保つための再取得機能の3つです。これにより、運用者は別ページに遷移したり、別件で開発側に問い合わせをしたりする必要がなくなりました。効率よく作業できる機能に仕上がっています。 この一件で体感したのは、機能の「核となる実装」は全体のごく一部にすぎないということでした。POSTのAPIとUIという核は確かにイメージできていましたが、それが実際のユーザーへ届きビジネス価値へとつながるまで、想像をはるかに超える議論と設計判断が積み重なっていました。 リファインメントに新卒のうちから参加できたことで、私は機能を「実装するもの」ではなく「課題を解決するもの」として見る視点を、議論の中で自然に身につけることができたと感じています。これは、先輩から受け取った最初の思考の型のひとつでした。 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ リファインメントで十分実装が可能だと判断されると、次はプランニングでスプリントの計画を立て、タスクの洗い出しやタスクの規模を見積もります。配属直後の私にとって、この時間はリファインメント以上に難しいものでした。 規模の見積もりには、チームごとに蓄積されるベロシティ（過去のスプリントでどれくらいの規模を消化できたかという感覚値）があります。「このくらいの規模の変更ならだいたい何ポイント」という相場が、過去の実装経験から自然と形成されていきます。配属されたばかりの自分にはそれがなく、対象機能の核となる変更部分の理解もまだ浅い状態で、規模を出すのは正直難しい作業でした。 では、先輩はどう見積もっているのかなと気になりました。観察して印象的だったのは、実装を頭の中で先取りして見積もるやり方でした。ZOZOMOではDDDやCQRSを採用しているため、これはコードベースを頭の中で走らせる形になります。例えば「Query側のStore集約のUsecaseでデータを整形して、Infra層に店舗集約をUpsertするクエリを書いて、UnitTestとE2Eを書いて…」といったイメージです。見積もりは「数字の当てっこ」ではなく、この工程をどれだけ正確に頭の中で走らせられるかなのだと理解しました。そして、その想像力を支えているのは、過去の実装を積み重ねてきた経験にほかなりませんでした。 Acceptance Criteriaで「実装の自由度」を制御する 想像力と経験がある程度身についた状態で、より規模を正確に見積もり、要件を満たすために考えるべき重要な指標があることに気づいたのは、1年経ってからでした。それが Acceptance Criteria（受け入れ基準、以下AC）の解像度 です。 ACとは、その機能が「完成した」と判断するための条件を具体的に言語化したものです。重要なのは、ACの粒度が実装の自由度をコントロールするということでした。 象徴的だったのが、ブランド様と店舗の紐付けを除外する設定を確認する機能の実装です。これはリファインメントの結果、ブランド様ごとに検索ができ、絞り込んだ結果をExcelとして出力する機能も追加するスコープに広がりました。Excelはメールで該当ブランド様に送り、店舗とブランド様の紐付きが正しいかを確認してもらうためです。 このときのACの一例は、「検索後、Excel出力ボタンを実行したタイミングでポップアップが表示され、絞り込みした店舗の属するブランド一覧がポップアップに表示されること」と定義しました。 このACは、自由度の制限の仕方が絶妙でした。検索のクエリや検索ロジック、Excel生成の方法そのものには制限がかかっていません。より良い実装方法があれば実装時に改善できる余地が残されています。一方で、出力時にポップアップで対象データを一覧表示するという最終的な体験の部分は明確に固定されています。これは複数ブランドを指定して検索できる仕様上、運用者が「どのブランド様のExcelを送ろうとしているんだっけ？」を実行直前に視覚的に確認できる状態を保つことで、ヒューマンエラーを抑えるためです。 ACが「実装の細部までガチガチに固定する文書」になっていると、開発者は工夫の余地を失います。逆にACが曖昧すぎると、実装中に判断を迫られる回数が増え、規模が大きくブレます。ACは、考えてよい部分と考えなくてよい部分を明確に切り分け、実装の自由度を意図的にコントロールするための装置なのだと、この実装を通じて理解しました。 見積もり精度はAC定義の解像度の問題に集約される ACの粒度をこの形でコントロールできていたから、実装中に時間をかけて考える部分と、考えずに型通り進めてよい部分の切り分けが明確でした。結果として、見積もった規模と要件の両方を、ある程度の確度で同時に守れる構造になります。 規模そのものを正確に当てに行くのではなく、ACの粒度をコントロールして実装中の判断回数を制御します。プランニングを1年続けた末に言語化できたのは、「見積もり精度の問題は、その手前のAC定義の抽象度に集約される」という知見でした。 数字を出すこと自体に意識を向けていた1年前の自分から、今は「ACで実装の自由度を制御することで、規模と要件の両立を狙う」ことに意識を向けるようになりました。プランニングの場の捉え方がこのように変わったことが、この1年で起きた最も大きな変化の1つです。ACの粒度を意図的に調整するという考え方も、私のなかに定着した思考の型のひとつです。 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた リファインメントとプランニングを経て、いよいよ実装フェーズです。私のチームでは実装の多くをモブプログラミングで進めます。複数人が同じ画面を見ながら、ナビゲーター役とドライバー役を交代しつつコードを書いていく形式です。 モブプロから学んだことは数多くありますが、今の自分に最も大きく影響しているのは「 事実ベースで実装する 」という姿勢です。 先輩は事実から方針を決めていた リファインメントやプランニングで要件をどれだけ詰めても、実装段階で「考慮しきれていなかったこと」は必ず出てきます。とくにマイクロサービス間でデータを連携している箇所では、外部要因も絡んで挙動が読みにくくなります。 ZOZOMOでも、他のマイクロサービスとイベントを通じたデータ連携をしています。しかし、さまざまな要因によりイベントの連携順序が入れ替わり、本来連携されるべきデータを正しく届けられないケースもありました。この問題に対処する仕組みを実装した際、モブプロで先輩のアプローチを間近で見たのが印象的でした。 先輩はまず、入れ替わりが起きたデータを全件出してくるところから始めました。一部ではなく全体を並べて共通項を探すと、どの経路の、どのタイミングで入れ替わりが起きているのかという事実が浮かび上がってきます。 そこから先輩が見出したのは、ZOZOMO側の開発基盤にデータが連携される箇所で、入れ替わりそのものを直すという根本的な解決策でした。全件のデータという事実から出発したからこそ見つけられた解決策です。 「事実から始める」という型を学んだ このやり方の何がすごいかというと、 実装の前に「何を解決すべきなのか」が事実として明らかになっている ことです。事実から始めれば「この具体的なケースを直すには何が必要か」という明確な目的が手元にあります。結果として、不要な処理が混ざらず、シンプルでビジネス価値の高い実装にたどり着きやすくなります。 このとき自分が何より学んだのは、「とりあえず動かしてみる」のではなく、手元の事実をしっかり集めてから設計に入るという姿勢でした。新卒1年目で身につけた中でも、実装に向かう前の心構えとして特に役立っている型です。 事実ベースで判断するという姿勢も、モブプロを通じて自分のなかに残った思考の型のひとつです。 AI時代に、思考の型はどう活きるか この1年は生成AIの普及によって「情報を知っていること」自体の価値が一気に下がった年でもありました。ドキュメントを読み込む、仕様を覚える、エラー文を検索する。こうした若手エンジニアの仕事の一部だった作業の多くを、AIがあっという間に肩代わりする時代です。 だからこそ、ここまで紹介してきた「思考の型」の価値が、以前より一段はっきり見えてきた気がしています。ACをAIに書かせることも、実装方針をAIに提案させることもできます。しかし出てきた出力が正しい方向に向かっているかを評価し、軌道修正の指示を出すには、自分の中に判断の物差しが必要です。 思考の型を自分の言葉で持っていれば、それはそのままAIへの的確な指示に変わります。たとえば、3つの学びはそれぞれ次のような指示につながります。 リファインメントで身につけた「これは何を解決する機能か」という問いは、「この機能の目的はこうだから、それに沿った実装案を出して」という指示になる プランニングで身につけた「ACで自由度を制御する」思考は、「実装手段は任せるが、最終的な体験はこう固定したい」という指示になる モブプロで身につけた「事実ベースで判断する」姿勢は、「推測で進めず、まず該当データを全件出してから方針を決めて」という指示になる AIに何を問いかけ、その答えをどう評価し、どこで意思決定するか。その一連の判断は、思考の型を自分の足場として持っている人間にしかできないと思います。 おわりに 1年を振り返って、スクラムは新卒にとって 先輩の思考の型を最速で学べる装置 として機能しました。リファインメントで問いの立て方を学び、プランニングでACの解像度を上げる感覚を掴み、モブプログラミングで事実ベースの実装の進め方を身につけました。一つひとつは技術書を読んでも身につかず、リアルタイムの観察と質問なしには手に入らないものでした。 スクラムは「アジャイルに開発するためのフレームワーク」として語られることが多いです。しかし新卒として配属された自分の視点からは、先輩たちの思考にアクセスする頻度を最大化する仕組みであり、かつAI時代に価値を持ち続ける能力を集中的に育てる仕組みでもありました。 これから配属を迎える新卒エンジニアの方には、配属先のチームがスクラムで動いているなら、それを「ただの開発手法」とは思わずに思考を盗む1年にしてほしいと伝えたいです。技術知識を吸収する場としてだけでなく、思考の型をコピーする場として向き合うと、得られるものの密度が大きく変わります。 新卒受け入れを担う開発組織の方には、スクラムを生産性の文脈だけで評価せず、新規メンバーの学習装置としての側面にも目を向けてもらえると嬉しいです。先輩の思考に高頻度で触れられる場が組織にあるかどうかは、人材の立ち上がりスピードに大きな差を生むはずです。 自分自身は、まだスクラムから学べることの入口に立ったところだと思っています。2年目以降は、観察する側だけでなく、自分の思考の型を他のメンバーに見せていく側にも回っていきたいです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com