この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。 質問 #  うちのチームは既存システムの保守運用が中心です。不具合対応や改善要望への対応がメインで、大きな新機能をスプリントで計画的に作っていくような仕事ではありません。研修で習ったスクラムは新規開発が前提のように見えますし、うちは割り込みも多い。 うちにはスクラムは合わないのではないでしょうか？ 回答 #  合わないのは、スクラムではなく「スクラム解説の前提」のほうです。視点を変えると、保守運用はアジャイルにとってかなり自然な環境です。ウォーターフォール文化が身に染み付いた開発チームは、「最初にすべてを決めない」という考え方に慣れるのに苦労します。一方、保守運用の世界では「最初からすべて決めない」のは“当たり前”です。  さらに言えば、保守運用が向いているのはスクラムの「仕事の管理」の側面だけではありません。スクラムが定義していない、しかしアジャイルに不可欠なもう半分——テストや設計、リリースといった“モノづくりの技術”——を鍛える場として、保守運用はおそらく最良の舞台です。本稿の後半はそこに重心を置きます。  まずは、合う合わないを拙速に結論づける前に、「新規開発と保守運用は、本当に別物なのか」から考え直してみましょう。 「新規開発」と「保守運用」は、本当に別物か #  この質問の土台には、「新規機能の開発」と「保守運用の不具合対応・改善要望対応」はまったく違う仕事だ、という感覚があります。  スクラムを前提に、まずはここを疑ってみます。以下、前者を「新規開発系」、後者を「保守系」と便宜上呼び分けます。  バックログの視点で両者を並べてみると、こうなります。 新規開発系: 作りたい機能が並ぶ → 価値やリスクで優先順位をつける → 小さく完成させて届ける → フィードバックを得て次を決める 保守系: 不具合報告や改善要望が流れ込む → 影響度や緊急度で優先順位をつける → 直して届ける → 利用者の反応や再発状況を見て次を決める  　新規かどうかにかかわらず、価値のある作業項目が流入し、それらに優先順位をつけ、小さく完成させて届け、結果を見て次を判断する。一歩引いてみると、両者は構造的には同じです。スクラムが回そうとしているループそのものを、どちらの「系」も回しています。そしてどちらのバックログも、項目が後から流れ込むことを前提にしたリストです。全件が最初に揃っているべきというリストではありません。  では、何も違わないのかというと、差はあります。ただしそれは「種類の差」ではなく「程度の差」です。 項目のサイズと独立性 : 保守系の項目は小粒で、互いに独立していることが多い。新規開発系は大きく、項目間の依存が強くなりがち 流入の予測可能性 : 保守系は突発の流入が多く、来週何をやるかを今週決めきれない。新規開発系は（保守系と比べて）計画が立てやすい ステークホルダーの期待の形 : 新規開発系には「いつ、何が出るのか」が問われ、保守系には「どれだけ早く、確実に直るのか」が問われる  これらはスプリントの長さ、ゴールの立て方、キャパシティの配分といった「運用パラメータ（第1回参照）」を変える理由にはなりますが、「スクラムをやる/やらない」を分ける理由にはなりません。同じ考え方の上で、パラメータ＝調整のしかたが違うだけです。 スクラムが定義していない「もう半分」 #  もう一歩進めます。ここまでの話は、バックログと優先順位づけ、つまりスクラムが定義する「仕事の管理」の側面でした。しかしスクラムガイドを読み返すと、気づくことがあります。 スクラムは「どう作るか」を一切定義していません。 テストをどう書くか、設計をどう保つか、どの頻度で統合しリリースするか…これらはスクラムの外にあります。  アジャイルのこの「もう半分」を担ってきたのが、XP（エクストリーム・プログラミング）に代表される構築プラクティスです。自動テスト（そしてテストを先に書いてから実装するテスト駆動開発）、リファクタリング（動きを変えずに内部構造を整えること）、継続的インテグレーション（変更を頻繁に統合し自動でビルド・テストすること）、小さなリリース、シンプルな設計。スクラムだけを導入して「スプリントごとに動くものが出てこない」「スピードが落ち続ける」と悩むチームの多くは、この半分が欠けています。管理の枠組みだけあって、その中で回すモノづくりの足腰がない状態です。 保守運用は、その「もう半分」を鍛える最良の舞台だ #  ウォーターフォール文化に染まった開発チームがアジャイルに移行するとき、最大の障害はたいてい「全部決めてから作りたい」という習慣（いや欲求）です。線表を引き、要件を固め、設計を固め、実装へ…この習慣を捨てるのに、多くのチームが何ヶ月も、ときに何年も苦しみます。  ところが保守運用の現場を見てください。  来月どんな不具合が報告されるか、誰も知りません。半年先の対応計画を精緻に立てることに意味がないことを、全員が体で知っています。つまり、 「最初にすべて決めない」状態が、意図せずすでに達成されている のです。開発チームが苦労して手放す習慣が、環境としてそもそも成立しません。  そして、ここからが本題です。保守運用の日常業務は、XPの技術プラクティスの練習問題そのものです。 自動テスト : 不具合を直すとき、「まず再現するテストを書き、それを通す」のは最も自然な手順です。直した箇所が次の改修で壊れないよう回帰テストの網を増やしていくことも、保守の現場では「当然のこと」として受け入れられます。多くの未熟なアジャイルプロジェクトで「テストはリリース間際にやればよい」という誤解（開きなおり？）が平然と通っているのとは大きな違いです。 リファクタリング : 保守系の変更は小粒です。「触ったところを少しだけきれいにして戻す」を毎回やる習慣が、大規模な作り直しをせずにコードを健全に保つ唯一の現実的な方法であり、保守運用は開発者に練習する機会を多く与えてくれます。 継続的インテグレーションと小さなリリース : 項目が独立しているため、1件ずつ統合し、1件ずつ届けられます。「小さく完成させて届ける」サイクルが短く、ビルド・テスト・デプロイの自動化に投資する動機も見返りも、新規開発より明確です。 完成の定義 （何をもって「終わった」とするかのチームの合意）: スプリントごとに何度も「完成」を経験できるので、見積り・分割・「完成とは何か」の合意といった基本動作の練習回数を、新規開発案件よりはるかに多く稼げます。検査と適応のリズムも、障害の振り返りや再発防止という形で日常業務と地続きです。  このように見ていくと、「保守運用にスクラムは合わない」のではなく、むしろ「スクラムの管理の枠組みと、XP的なモノづくりの技術の両方を身につけるなら、保守運用は良い舞台である」という見方が、十分に成り立ちます。 でも限界も知っておこう #  ただし、限界もあります。保守運用で鍛えやすいのはモノづくりの側であって、スクラムの管理の側には練習しにくいことが2つあります。 スプリントゴールで仕事を「束ねる」力 。小粒で独立した項目をこなすだけなら、ゴールは「今スプリントの分を終わらせる」に退化しがちです。バラバラの作業を1つの目的に束ねる練習は、意識しないと発生しません。 価値の優先順位を巡る判断 。「直すのが当然」の不具合が相手では、「もたらす価値に基づいて何を作り、何を作らないか優先順位をつける」という、プロダクトオーナーの筋トレの機会が乏しくなります。  ほぼアジャイル初学者ばかりのチームが、いきなり本番開発に突撃して失敗している現場を少なからず見ていると、「まず保守運用でモノづくりの技術を身につける」→「新規開発でゴールやPOの筋トレに取り組みながら開発を進める」というアプローチは、十分に検討に値すると思います。  とりわけ日本では、この「モノづくりの技術」への投資が構造的に不足しがちです。経営層の中には、アジャイルを「早い、安い」という文脈で捉えている方が少なくありません。その結果、体制の編成は単価優先になり、育成への投資が省かれ、設計からコーディング、テストに至る“モノづくり”の能力がチームとして整わなくなります。スクラムの研修は受けたが、テストの自動化もリファクタリングも誰もやったことがない——そんなチームが「スクラムを始めた」と称して本番開発に突撃する光景は、珍しくありません。責めるべきは個々のエンジニアではなく、この編成と投資の意思決定です。  もっともこの意思決定も、コスト削減の制約の下では、その場その場では合理的な選択ではあります。合理的な選択の積み重ねが望まぬ結果に行き着く——この構造は、次回からの更改案件の話でも繰り返し登場します。  私見では、これがアジャイル開発の失敗の大きな要因のひとつです。保守運用を鍛錬の舞台にする提案は、この足腰を日常業務の中で鍛え直す提案でもあります。  経営層の方に、「早い、安い」の代わりに期待していただきたいのは、「変更1件のリードタイムが縮む」「切替やリリースの事故が減る」「見積の外れ幅が狭まる」という、測れる変化です。これらは、本連載の今後の回で採り上げようかと考えています。  そしてもちろん、開発チームを「価値の創造エンジン」という目で見ていただきたい。コストセンターとして単価を削る対象ではなく、 投資して育てる対象 として。 それでも現場で困ることへの処方 #  保守運用へ適用するとして、よく起こるだろう困りごとへの対処法もいくつか挙げておきましょう。 スプリントゴールが立てられない  前述したようにゴール設定はなかなか難しいかもしれません。スプリントを回し始めて数ヶ月のチームなら、ここでいっそのこと割り切って、ムリにゴール設定せず、まず「自動テストとリファクタリングを日常の手順に組み込む」といったモノづくりの基本動作に集中してもいいんじゃないかと思います。  もちろん、「ゴール決めを禁止する」意図はありません。ゴールを「機能のまとまり」で立てようとすると詰まります。改善・削減・安定化の観点で考えると立てやすくなるでしょう。「今月のアラート件数を半減する」「この手順書を廃止できる自動化を完成させる」「問い合わせ上位3件をFAQ化して問い合わせを減らす」。これらは立派なスプリントゴールであり、前述の「束ねる力」の練習にもなります。 割り込みで計画が壊れる  まず1〜2スプリント、割り込みの件数・時間・発生元を記録し、感覚ではなく実績の比率で「計画枠」と「割り込み枠」を分けてキャパシティを設計してください。詳しい運用（記録のとり方、当番制、受付の一本化など）は、第12回あたりでまとめて扱う予定です。 そもそもスプリントという区切りが実態に合わない  割り込みが恒常的に過半を占めるようなら、スクラムにこだわらず、カンバン（スプリントを区切らず、流れで仕事を管理する手法）の併用・移行を正面から検討してください。流れてくる仕事を順に引き取り、流れの速さと詰まりを改善するカンバンは、フロー中心の現場の実態に素直に合います。  スクラムは目的ではなく手段です。「スクラムをやめる」ことは「アジャイルをやめる」ことではありません。 なぜこの質問は30年繰り返されるのか #  理由は単純で、アジャイルの解説・研修・成功事例のほとんどが「新機能を開発するチーム」を暗黙の主人公にして書かれてきたからです。読者の多数派が保守運用に携わっているにもかかわらず、教材の主人公は常に新規開発チームでした。加えて日本では、新入社員研修でウォーターフォール型の開発はしっかり教えられる一方、アジャイルはほとんど扱われません。「教材がない」状態は、キャリアの入口から始まっているのです。  だから保守運用の実践者は、世代が替わるたびに「自分たちは例外なのではないか」「新しいアプローチに触れる機会が奪われているのではないか」という同じ不安を抱きます。  しかし本稿で見たように、例外なのは現場ではなく教材の前提のほうです。「先が読めない中で、小さく完成させ、学びながら進む」というスクラムの舞台装置は整っている。そのうえ、スクラムが定義しないモノづくりの技術を鍛える練習問題が、毎日流れ込んでくる。  保守運用は アジャイルの周縁ではなく 、むしろ その足腰を作る場所 だと考えてはいかがでしょうか？ 次回: 「アップグレード案件の『現行機能保証』にどう向き合う？」

連載をはじめるにあたって #  この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。  「豆蔵最後のアルバイト」という謎の肩書でお客様を煙に巻きながら、日々研修やご支援に従事している中で、同じような質問を何年にも渡って繰り返しいただいてきました。アジャイル開発が世に出て30年近い年月が経ち、実践者の世代交代が進んでいるので、かつて議論し尽くされた（かに見えた）質問が、打者一巡よろしく繰り返し話題にのぼるのも当然とも思います。  そうしたよくいただく質問を起点に、その背景にある構造的な問題や現場で使える対処法を、FAQの形で明文化しておこう、というのが、これから始める連載の趣旨です。  対象となる読者像は、以下のように設定しました。 研修や専門書での学習によって、「スプリントってなに？」という基本的な用語レベルは知っている 新年度になってスプリントを回し始めて数ヶ月、「これでいいんだっけ？」という引っかかりが溜まりはじめた 基礎を学んだ方がもう一歩…「知っているのに、現場でうまくいかないのはなぜか」…掘り下げて考える機会を作ろうということがねらいです。  実際にいただいた質問を起点にしているので、タイトルを見ると「開発者視点」と思われそうですが、「アジャイルに関わる人であれば知っておいたほうが良い内容」を意識しました。ですので、チームを率いるリーダーや、発注側・経営側としてスクラムのチームと向き合う立場の方もお付き合いください。  本題に入る前に、お断りを３ついれさせていただきます。 「正解」ではなく「選択肢」。 …課題への対処法は、プロジェクトが置かれた文脈（コンテキスト）に応じて、異なるアプローチを採ることも珍しくありません。本稿でも課題への対処法を提示することがありますが、それらは「正解」というよりも、「皆さんが採りうる選択肢」と理解してください。他の書籍やブログで提案されているアプローチとは異なることもあるでしょうが、「選択肢が増えた」くらいに捉えていただき、ご自身のチームの文脈で何をすればいいかを考えるきっかけとしてください。 「AIツールの具体的な使い方」の開設ではありません。 …昨今開発現場でAI利用に関する関心が高まっていますが、本連載でAIツールの具体的な使い方を解説することはありません。きっと別の人が別の記事で採り上げてくれるでしょう。 餅は餅屋、法的なことは専門家にまかせる。 …請負契約等の法的・契約実務上の論点も守備範囲外とさせていただきます。  少々前置きが長くなりました。初回のFAQには、いままさに研修や導入支援の場で受けることが増えている、この時代ならではの質問を選びました。 質問 #  AIがコードを書き、テストを書き、設計案まで出してくれる時代です。開発のスピードは桁違いに上がりました。正直なところ、いまさらスクラムの基礎を学ぶ意味はあるのでしょうか？　スプリントで区切って人間が見積りや振り返りをするのは、AIのスピードの前では、“儀式”に見えます。 回答 #  学ぶ意味はあるし、重要性はむしろ増しているとさえ思います。なぜなら、スクラムが管理しているのは「作るスピード」ではなく「進むべき方向」だからです。  AIが劇的に速くしたのは「どのように作るか」であって、「何を作るか」「作った結果から何を学ぶか」は人が主体的に行う活動であり、AIが助けにはなっても、AIに丸投げすることはできません。作るスピードが上がるほど、間違ったものも速く作れるようになる——この単純な事実が、検査と適応（作ったものとやり方を頻繁に点検し、次を調整し続けること）という地味な基礎活動の価値を、かつてなく高めています。 AIが速くしたもの、しなかったもの #  まず、冷静に仕分けをしましょう。生成AIが確かに変えたのは、実装・テストコード作成・定型設計・調査といった「どのように作るか」の領域です。ここが数倍（いやもっとかな？）速くなったという主張に異論はありませんし、私自身実感してもいます。  では、次の問いはどうでしょうか。 この機能は誰のどんな業務課題を解決するのか。 リリースした結果、狙った効果は出たのか。 出なかったとして、次に何を変えるのか。 チームの今のやり方は機能しているか…。  これらは、人が主体的に意思決定するテーマであり、AIは答えを持っていません。もっともらしい答えの文章は生成してくれますが、その検証責任は人に残ります。そしてお気づきの通り、「何を作るか」「作った結果から何を学ぶか」「チームでどう検査と適応を回すか」は、アジャイルがこの30年間一貫して問うてきたことそのものです。AIは、アジャイルが担ってきたこれらの問いを何ひとつ引き受けてくれていない。むしろ、問いに向き合わないまま作れてしまうスピードだけが上がったのです（少なくともこれまでのところは）。 “AIいいなり開発”という新しくて古い病気 #  その帰結として、現場で目にするようになった光景があります。AIの生成物を、十分な検証もせず、その意図を理解もせずただ丸呑みして積み上げていく開発…「それじゃぁ『 AIいいなり開発（AI-Dictated-Development） 』じゃないか！」と叫びたくなる姿です。本来の「 AI駆動開発（AI-Driven-Development） 」とは似て非なるものです。 イラスト左：AI駆動　　　イラスト右：AIいいなり  AIいいなり開発の特徴は、一つひとつの成果物がもっともらしいことです。コードは動き、テストは通り、ドキュメントは整っている。問題は、その全体が誰の何のために作られたのか、誰も満足に説明できないことです。検証されていない仮定の上に、検証されていない生成物が高速に積み上がっていく。従来なら数ヶ月かかった「間違った方向への行軍」が、数週間で再現できるようになりました。  しかし、これは新しい病気ではありません。「要件定義書に書いてあったから作りました」「言われた通りに作りました」——意図を問わない開発は昔からありました。AIはそれを高速化し、かつ「作った感」で覆い隠すのがうまくなっただけです。  診断が同じなら、処方も同じ系統です。 スクラムの基礎は、AIの出力に対してこそ効く #  この連載で扱う基礎を、AIの文脈に置き直してみます。 宛先と目的を問う習慣 は、「このコードは誰の何のためか」(fig002)をAIの出力に対しても問わせます。生成物がもっともらしいほど、この問いだけが人の仕事として残ります 小さく完成させて検査するリズム は、生成されたものを鵜呑みにせず、動かして・使わせて・学ぶ機会を強制的に確保します。スプリントは「人間が遅いから区切る」のではなく、「学習のリズムを設ける」ための仕組みなので、生成が速くなっても不要にはなりません。むしろ検証すべき生成物が増えた分、検査のリズムの価値は上がります 計測と記録の規律 は、「AIで速くなった気がする」を検証可能な事実に変えます。リードタイム（着手から届くまでの時間）は本当に縮んだのか、手戻りは増えていないか。道具の評価もまた、検査と適応の対象です  逆に、変わってよいものもあります。スプリントの長さ、見積りのやり方、ドキュメントの作り方…これらはスクラムの進行を調整する“運用パラメータ”であり、AIによって最適値が変わり得ます（この「基本」と「運用パラメータ」の区別は、次回以降の各論でも繰り返し登場します）。生成が速いなら、スプリントはもっと短くできるかもしれない。見積りの議論は、作って確かめる方が速い場面が増えるかもしれない。パラメータは大胆に見直してください。この技術の大変革の時代に、「批判精神なき前例踏襲は、“罪”」です。 これらパラメータの変更もチームで議論し合意し、その効果を検査する対象です。周囲を無視して現場で好き勝手やっていい話ではありません。  そして、ここまで説明した検査と適応のループそのものを外した瞬間、残るのは「高速ないいなり」です。 なぜ、新しい技術が生まれるたびに、似たような質問が繰り返されるのか #  「新しい道具が来たから、プロセスの基礎はもう不要では？」という問いは、実はAIが初めてではありません。CASEツール（設計図からコードを自動生成する1980〜90年代のツール群）が自動生成する、RAD（試作を繰り返して短期間で作る1990年代の開発手法）で開発が桁違いに速くなる、ローコードでプログラマーが不要になる…新しい道具が現れるたびに、同じ問いが再演されてきました。打者一巡どころか、これはもう何巡目かの打席です。  そして毎回、結論も同じでした。道具は「どのように作るか」を変え、ときに劇的に改善する。しかし「何を作るべきか」「作った結果から何を学ぶか」は道具の外に残り続け、そこを疎かにしたプロジェクトは、速い道具で速く失敗した…。  AIが過去の道具と規模の違う変化であることは認めます。だからこそ、と言うべきでしょう。道具が強力になるほど、ハンドルを握る側の基礎が問われます。本連載がこれから扱うのは、そのハンドルの握り方です。 今後の予定 #  次回以降の予定ですが、タイトルと順序を以下に列挙しておきます。 ただ、これらは仮のもので、断りなく変更される可能性があることをご承知おきください。 第2回: 保守運用チームにスクラムは合わないのでは？ 第3回: アップグレード案件の「現行機能保証」にどう向き合う？ 第4回: 更改案件の見積を、全機能を確定せずにどう出す？ 第5回: ドキュメントが信用できない現行システム、何を『仕様』にして検証する？ 第6回: デイリースクラムが進捗報告会になっています 第7回: レトロスペクティブが機能しません…同じ改善案の再放送と、ToDoの列挙会 第8回: スプリントレビューにステークホルダーが来なくなりました 第9回: ストーリーポイントの人日換算を上司に求められます 第10回: ベロシティが安定しません。計画に使っていいの？ 第11回: スプリント内に終わらないタスクが毎回出ます 第12回: 割り込み作業はどう計画に入れる？ 第13回: POが多忙でチームに来ません 第14回: スクラムマスターは何をする人？ 暇そうに見えます 第15回: 自己組織化と言われても、結局リーダーが全部決めています 第16回: 技術的負債の返済をPOが優先してくれません 第17回: ドキュメントはどこまで書けばいい？ 第18回: 最初は改善が進んだのに、最近チームが停滞している気がします 第19回（最終回）: 連載の総括  長い文章にお付き合いいただきありがとうございました。 次回: 「保守運用チームにスクラムは合わないのでは？」

株式会社スタンバイでフロントエンドエンジニアをしている藤澤です。 スタンバイでは27卒から新卒採用を実施しており、その一環として、来年度4月入社予定の内定者（学生）の方を対象に、任意で「内定者バイト」（本記事では以下「内定者エンジニア」と呼びます）を実施しています。 入社前に実際の現場業務を体験してもらうことで、入社後のスタートダッシュを円滑にすることが狙いです。 このたび、その内定者エンジニアの方をトレーナーとして約5カ月間受け入れるという経験をしました。 最初は「自分が誰かの成長に伴走するなんて、うまくできるだろうか」と正直ドキドキしていたのですが、振り返ってみると、受け入れる側の自分にとっても学びだらけの5カ月でした。 この記事のポイント 受け入れ前に「放置」「レベル」「質問」の3つの不安を先回りして解消する仕掛けを用意した 月を追うごとに任せる範囲を段階的に広げ、5ヶ月目には仕様策定から主導してもらうまでになった コーディング以外にも、スクラム活動や他職能との交流など幅広い経験を用意した トレーナーとして学んだのは「伴走」と「任せる」のバランス、少しずつ手を離していく設計の大切さ 1. はじめに：ドキドキで始まったトレーナー業務は、学びだらけの5カ月になった はじめにお伝えしておくと、スタンバイでは今年度だけで5名以上の内定者エンジニアを受け入れており、さらにトレーナー同士が毎月集まって受け入れ状況を共有する報告会も行っています。 つまり「個人がたまたま頑張る」のではなく、組織として内定者を迎える仕組みがあります。 この記事はそのうちの、私が担当した一事例です。 これから内定者エンジニアとして参加する方や検討している方に、「受け入れる側はここまで考えているんだ」という安心感が伝わり、入社前の不安が少しでも軽くなれば嬉しいです。 まず、この記事に登場する人たちの立ち位置を整理しておきます。 ▲ 内定者エンジニアに関わる人たちの相関図 稼働は基本的に週2日で、最初の1〜2ヶ月目は1日4時間、3ヶ月目以降は1日8時間に増えました。 曜日や時間帯は固定ではなく、内定者本人の大学の授業や他のアルバイトの予定に合わせて調整しています。 2. 受け入れる前にやったこと：「放置」「レベル」「質問」の不安を先回りして解消する3つの仕掛け 参加する側にとって、最初の不安は主に以下の3つに集約されるのではないかと思っています。 放置されないだろうか 分からないことを気軽に聞けるだろうか 自分のレベルで通用するだろうか そこで、受け入れ前〜序盤にかけて、この3つの不安を先回りして取り除く仕掛けを用意しました。 不安 用意した仕掛け ねらい 放置されないだろうか ①役割分担を明確にした受け入れ体制 誰か一人が忙しくても必ずフォローが入る状態にする 分からないことを気軽に聞けるだろうか ②進捗を毎日拾うミーティング設計 課題を次の出社日まで溜め込ませない 自分のレベルで通用するだろうか ③段階設計したオンボーディングタスク スモールスタートで実務フローに慣れてもらう ① 役割分担を明確にした受け入れ体制（＝放置しない） 私（トレーナー）一人だけで抱えるのではなく、3つの役割で受け入れ体制を組みました。 役割 主な担当 トレーナー タスクのアサイン、ペアプロ・コードレビューなど日々の伴走 PO（プロダクトオーナー） ビジネス観点のインプット レビュアー（TL） 目標設定や成果のレビュー、トレーナーの指導方法・環境についての評価と相談 レビュアーは、私が所属するチームのTL（テックリード）が担当してくれました。 トレーナーとしての自分の指導方法や、内定者にどんな環境を用意すべきかについて、相談に乗ってもらいました。 これに加えて、人事から現場とは異なる部署のメンターが1名つき、月1回、業務とは別の目線で近況や悩みごとを相談できる機会も用意されています。 ② 進捗を毎日拾うミーティング設計（＝つまずきを溜めない） 1日4時間という限られた稼働時間なので、出社日の朝と夕に15〜30分の進捗共有を設定しました。 さらに週次でのチーム定例、隔週でのPOとの1on1も用意しました。 「分からないことを次の出社日まで溜め込ませない」ためのコミュニケーションの仕組みです。 ▲ 朝会・夕会での振り返りボードのイメージ（実際の内容を再構成したものです） ③ 段階設計したオンボーディングタスク（＝スモールスタート） いきなり難しいタスクは渡さず、修正範囲が1〜2ファイルの軽微なスタイル修正やJavaScriptの記述修正から始めてもらいました。 狙いは実装スキルそのものより、「PR（プルリクエスト）作成 → レビュー → マージ」という一連の実務フローに慣れてもらうことです。 この軽量タスクを5件ほどこなしてもらううちに、Jiraでのチケット管理、影響範囲の動作確認、Preview環境の立ち上げ、CIやユニットテストの扱い、コードレビューでのやり取りまで、ひととおりのプロセスが自然と身についていきました。 また、受け入れ初週には関係メンバーで歓迎の懇親会も開催しました。 技術的なインプット以上に、まずは「歓迎されている」と感じてもらう心理的安全性を大切にしました。 内定者さんのコメント①｜受け入れ序盤の振り返り 配属した当初は不安でしたが、疑問点をすぐに相談できる環境だったので、安心して取り組むことができました。 3. 5カ月の成長の軌跡：できることが毎月一段ずつ広がったステップ設計 ここからは、月を追うごとに任せられる範囲がどう広がっていったかを紹介します。 受け入れ側として見ていて、毎月「一段上がったな」と感じる頼もしい瞬間がありました。 期間 主なタスク できるようになったこと 1〜2ヶ月目 環境構築、軽微なスタイル修正・JavaScript修正 デザイントークンの利用、影響範囲の特定、DevToolsでの確認 3〜4ヶ月目 ABテストの「お掃除」「100%反映」 本番リリース、スマホ実機での確認、難易度の高いバグ対応 5ヶ月目 仕様が未確定のバグ対応タスク トレーナー・POとの仕様すり合わせ、Jiraチケット作成、周囲を巻き込む提案 【1〜2ヶ月目】開発フローの習得と、実務ならではの「お作法」 環境構築やgit-flowは大きくつまずくことなくクリア。 CSSやJavaScriptの基礎知識を持っていたため、軽微な修正は問題なく実装できていました。 一方で、実務ならではの観点は、この時期、じっくり身につけてもらいました。 CSSに固定値を直書きせず、デザインシステムのデザイントークンを使う ファイルを直す前に使用箇所（import先）を調べて影響範囲を特定する DevToolsでスタイルの適用やログ送信を確認する 特に印象的だったのは、報連相の丁寧さです。 1日4時間という短い稼働の中で、退勤前には作業途中のコードであっても自主的にコミットして「進捗の見える状態」にしてくれていました。 課題を翌営業日に持ち越さない工夫は、受け入れるトレーナーとしても非常に助かりました。 【3〜4ヶ月目】本番リリースと「ABテスト」への挑戦 3ヶ月目からは、フロントエンドのメイン業務の1つであるABテストにチャレンジしてもらいました。 まずは過去のテストの「お掃除（後片付け）」タスクで全体の流れを掴み、慣れてきたところで、ABテストの「100%反映」も1件担当してもらいました。 この時期には計7件のリリースを経験しました。 オフィス出社日には、スマホ実機での動作確認作業や、難易度の高いバグ対応もこなせるようになっていました。 【ミニコラム】ABテストの「100%反映」の面白さと難しさ ABテストは、新しいパターン（B）が既存（A）より良い結果かを一部のユーザーで検証する仕組みです。 用語 意味 お掃除（後片付け） 終了したABテストの分岐コードを片付ける作業 100%反映 検証で採用が決まったパターンを全ユーザーへ正式展開する作業 本番の全ユーザーに直接影響し、かつリリース期限のプレッシャーもあるため、一段と責任の重い仕事です。 ここを任せられるようになったことは、実務の主戦力に近づいた大きな節目でした。 内定者さんのコメント②｜ABテスト挑戦時の振り返り リリースのときは緊張しましたが、その分「自分がやったことへの責任感」と「実装したコードが実際に動くやりがい」を強く感じました。 【5ヶ月目】仕様が未確定のタスクへ。上流から主導する「自走」への変化 直近の5ヶ月目には、仕様がまだ固まりきっていないバグ対応タスクに挑戦してもらいました。 これまでは「決まった仕様を実装する」のが中心でしたが、今回は以下のように上流から主導してもらいました。 トレーナーやPOと自ら仕様を擦り合わせる 自分でJiraチケットを作成する 実装する 受け入れ当初に課題だと感じていた「トレーナー以外への能動的なコミュニケーション」が見違えるように改善し、周囲を巻き込む動きが出てきたのが大きな変化です。 この頃には1on1の回数を減らし、チームの日常的なやり取りの中で自然に報連相が回るようになっていました。 内定者さんのコメント③｜能動性が出てきた頃の振り返り 当事者意識を持って取り組むことと報連相の大切さを学びました。 今後は、その施策が何のためにあるのかを見据えて、自分から改善案を提案しながら業務に取り組んでいきたいです。 4. 内定者エンジニアが体験したこと：コーディングタスク以外の学びの機会 ここまではトレーナーとして任せたタスクの話が中心でしたが、内定者エンジニアの方が体験したのはコーディングだけではありません。 体験 内容 チームのスクラム活動への参加 朝会やスプリントレビュー、レトロスペクティブなど、チームの各セレモニーに参加してもらいました 部署のイベントへの参加 月1の部会で、事業状況や会社全体の動きをインプットする機会を用意しました 他の職能との交流 エンジニア以外の職能のメンバーとも接点を持ち、視野を広げてもらいました 目標設定とフィードバック 受け入れ開始時に本人と目標をすり合わせ、月次で振り返り・フィードバックを行いました コードを書く力だけでなく、チームの一員としての動き方や会社全体への理解も、この5カ月間で少しずつ身についていきました。 5. トレーナーとして学んだこと：「面倒を見る」から「徐々に手を離す」へのフェードアウト設計 受け入れ側の私自身にとっても、大きな学びがありました。 一番考えさせられたのは「伴走」と「任せる」のバランスです。 ▲ トレーナーの伴走スタイルは、時間の経過とともに複数の観点で変化していきました 観点 最初（1〜2ヶ月目） 中期（3〜4ヶ月目） 終盤（5ヶ月目） 体制 ①の体制のもと、2時間おきに簡単な会話で進捗を確認 チームの活動に合流し、チーム全体の動き方に慣れていく チームの活動に混ざり、自分から進捗報告・作業連携をする タスクの位置づけ 内定者エンジニア用に用意したタスク 通常のエンジニアも担当する業務の中の、軽微な改善タスク 自ら提案した機能修正案が中心。仕様策定から関わる レビュー体制 トレーナーが担当 トレーナー以外のエンジニアメンバーも担当 チーム全体で担当 コミュニケーション トレーナーとのやり取りが中心 チーム内のSlackなどでオープンに相談できる 自分から報告・連携を働きかける 朝夕のMTG 30分。タスクの説明や困りごとの確認 30分。技術的な学びを深掘る時間に 15分に短縮。学びの定着の場として継続 最初は、トレーナーが近くで手厚くフォローすることが本人の安心につながります。 一方で、距離が近すぎると「自分で情報を取りにいく力（自走力）」が育ちにくいという側面もあります。 だからこそ中期以降は、あえて仕様の擦り合わせから任せたり、1on1を減らしてチームの中に溶け込んでもらったりと、少しずつ手を離していく設計を意識しました。 受け入れるということは、単に「面倒を見る」ことではなく、「自分で立てるように環境を整え、徐々に引いていく」ことなのだと身をもって学びました。 6. 最後に：不安は仕組みでカバーできます。安心して飛び込んできてください！ 最初は不安で当たり前です。 しかしスタンバイには、あなたのつまずきを毎日拾うコミュニケーションの仕組みがあります。 さらに、軽いタスクから本番のABテスト、上流の仕様策定まで、一段ずつステップアップして任せていく設計もあります。 ぜひ、安心して飛び込んできてください！ スタンバイのプロダクトや組織について詳しく知りたい方は、お気軽にご相談ください。 www.wantedly.com 新卒採用についてはこちらをご覧ください。 newgrads.stanby.co.jp