90分間の研修で、自発的にチケットの記述量が40%増加。テレビ朝日メディアプレックスの属人化を打破した「ドキュメント研修」の裏側とは。
90分間の研修で、自発的にチケットの記述量が40%増加。テレビ朝日メディアプレックスの属人化を打破した「ドキュメント研修」の裏側とは。
目次
目次を読み込み中...
「この機能の仕様、○○さんしか知らない」「前任者が退職してシステムの全体像がわからない」。複数のプロジェクトが並行する開発・運用現場で構造的に発生する「知識の属人化と断絶」。テレビ朝日グループのシステムを担う株式会社テレビ朝日メディアプレックスもまた、情報が複数ツールに分散し「どれが正なのかわからない」という長年の課題を抱えていました。
その転機となったのが、2026年3月に実施した「90分のドキュメント文化推進トレーニング」です。研修からわずか数週間後、現場ではマネージャーの指示を待つことなく、メンバーが自発的に口頭の議論をチケット化し始めるなど、ボトムアップでの劇的な行動変容が起きていました。
なぜ、たった90分の研修が現場のカルチャーを変えたのか。本記事では、CTO岐部嗣哲氏とデータディビジョンマネージャー井上善貴氏に、属人化解消に向けた取り組みの背景と、研修がもたらした具体的な組織変化についてお伺いしました。
プロフィール
岐部 嗣哲さん 株式会社テレビ朝日メディアプレックス CTO（最高技術責任者）
SIerやベンチャー企業を経て、2011年に同社に入社。動画配信プレイヤーや視聴データ基盤など多岐にわたる開発を牽引し、クラウド・ビッグデータ領域のR&Dチームをリード。2023年4月よりCTOに就任し、全社の技術戦略やエンジニア組織のマネジメント（採用・育成等）を統括する。
井上 善貴さん 株式会社テレビ朝日メディアプレックス データディビジョン マネージャー
2022年1月に同社に入社。データエンジニアとして現場の開発業務を経験した後、現職に就任。現在は、データエンジニアやデータサイエンティスト、アナリストが集うデータ専門組織の開発とマネジメントを担う。
講師情報
高橋 裕之さん ファインディ株式会社 CTO室Staff Engineer (Engineering Excellence),
SPI Coach, Agile Coach
1989年より組込みエンジニアとして国産OSのスクラッチ開発等に従事し、ソフトウェア開発の最前線で16年にわたり泥臭い現場を経験。そこで直面した数々の構造的課題を根本から解決すべく、2005年にSPI（ソフトウェアプロセス改善）の専門家へと転身する。
以降、ソニーデジタルネットワークアプリケーションズ、ウイングアーク１ｓｔ、ビズリーチなどのテクノロジー企業にて、アジャイルコーチやプロセス改善部門の責任者を歴任。2024年よりファインディ株式会社に参画し、エンジニア組織への新技術・方法論の導入（イネーブルメント）を牽引。
現在の組織体制と、担っているミッション
—— 組織のミッションと、チームの規模感を教えてください。
岐部：私たちが所属するテクノロジーソリューション事業本部のミッションは、一言で表すと「変化し続ける放送メディアサービスの進化をテクノロジーの力で継続的に支援すること」です。インターネット基盤システム、データ基盤、コンテンツ管理、動画配信、分析基盤など、テレビ朝日グループのデジタル側を広く支えています。規模については、全社員約250名のうち、技術部門は約50名で、年齢層は20代後半〜30代前半が中心です。マトリックス型の組織構造で、プロジェクトに応じて各部門から横断的に人員がアサインされる形で動いています。業務の大半は既存システムの改修や運用保守で、複数のプロジェクトが常時並行して動いているのが日常です。
—— そういった環境の中で、現場ではどのような課題がありましたか。
井上：一番わかりやすいのは「情報がどこにあるか分からない」という問題です。ドキュメントのフォーマットも保管場所も統一されていないので、引き継ぎの際に毎回「どこに何がある？」という状況になってしまう。同じ内容のファイルが複数あって、どれが最新なのか判断できないケースもありました。
岐部：ドキュメントがGoogle Drive、Backlog、GitHubの3箇所に分散していて、それぞれの内容に乖離が生じているという問題もありました。どこが「正」なのかが明確でないので、古い情報を参照してしまうリスクが常にある。書く人と書かない人がいて、更新が徹底されない。協力会社のメンバーが何も残さずに契約終了するケースも多発していました。複数のプロジェクトが常時並行して動く中で、過去の情報を探す手段がSlackをさかのぼるか、知っている人に聞くかしかない。受託・運用保守をやっている組織なら、程度の差こそあれ、共感してもらえる話だと思っています。
ドキュメント文化推進トレーニングを実施した背景と、Findyを選んだ理由
—— なぜガイドラインではなく、トレーニングという形を選んだのでしょうか。
岐部：ルールをバンと出しても、人は納得して動いてくれないんですよ。自分自身で「確かにそれが必要だ」と腹落ちした上で動いてほしかった。今回の内容は「あなたはそれで本当にいいですか？」という問いかけから始まる構成になっていて、参加者が自分ごととして考えられる流れになっていました。その納得感のある進め方が、トレーニングという形を選んだ最大の理由です。
—— Findyを選んだ決め手は何でしたか。
岐部：生成AI活用の方針策定とドキュメント整備をちょうど社内で検討していたタイミングで、Findyさんからご提案をいただいた形です。加えて、講師の高橋さんが組み込みエンジニア出身で8社を渡り歩いてきた方だったことも大きかった。外部から伝えてもらう時って、やはり実務経験が豊富な人の言葉の方が説得力がありますから。現場のエンジニアにとっても「この人は実際に開発をやってきた人だ」という安心感があったと思います。
—— 事前に複数回ヒアリングがあったそうですね。そこでどのようなやり取りがあったのでしょうか。
岐部：最初にFindyさんが用意していたプログラムのベースは「ドキュメントを使わずに開発サイクルを回す」という内容でした。ただ、私たちの現場の課題はその前段にある。ドキュメントをまず作らないことには始まらないし、若手エンジニアには生成AIを活用していく上でコンテキストを残すことの重要性を理解してほしかった。そこを高橋さんに相談したところ、「Whyを残す文化を根付かせる」という方向でうまく組み直していただきました。
井上：私たちの現場は、プロジェクトの8〜9割をGitHubで管理し、タスク管理にはBacklogを併用しています。また、Gemini Code AssistやNotebookLMといった生成AIが既に利用可能な環境にありました。
今回、そうした具体的な技術スタックを踏まえた上で、「コードが先行する現場で、AIを活用してドキュメントを逆生成するデモが見たい」というリクエストを出したのですが、それを見事にカリキュラムへ盛り込んでいただけました。自分たちの環境に即して内容を高度にカスタマイズしてもらえたことは、非常に大きな価値があったと感じています。
—— 全員の工数を投資するという判断に、社内での抵抗はありましたか。
岐部：割とスルッといきましたね。ルールを押し付けるよりも、納得感を持ってもらった上で動いてもらう方が結果的に定着する。そこは私自身が確信を持っていたので、判断自体は迷いませんでした。年度末の忙しいタイミングではあったんですが、それでもこのテーマに時間を取る価値があると判断しました。
共感から始まった90分。AI時代にこそ人間が残すべき「Why」とは
—— 研修冒頭から、参加者の反応はいかがでしたか。
井上：最初に高橋さんが「こんな経験はありませんか？」と5つの属人化の症状を挙げて、「何個当てはまりましたか？数字をチャットに打ってください」と投げかけたんですよ。そうしたら「5」「5」「5」って流れていって。全部当てはまるという人がたくさんいた。
続いて「仕様に関わるバグの70%は変更漏れが原因」という話が出て、「間に合わないモンスター」という言葉も出てきた。開発期間が短いから見積もりや仕様書を省いてしまう。結果として手戻りが発生して、かえって時間がかかる。みんな身に覚えがあるんですよ。
どれも自分たちの日常そのものだったので、「これは自分たちの話だ」という空気が一気に広がりましたね。
——２章の「Whyを残す」というパートでは、どのような内容が届きましたか。
井上：ドキュメントをWhat（何があるか）・How（どう動くか）・Why（なぜそうしたか）の3層に分けて考えるという整理が腑に落ちました。WhatやHowはコードから後から復元できる。でもWhyだけは、その時の文脈を知っている人間にしか書けない。一度失われたら永遠に復元できないという話です。プログラマーであれば「リーダブルコード」などを通じて似た考え方に触れたことがある人も多いと思います。ただ、知識として知っていても、自分の現場のこととして捉え直す機会はなかなかない。アンケートでも「ドキュメントに対する考え方が変わった」という声が複数出ていました。
岐部：高橋さんが「わかったというのは、その人がわかったと思った範囲だけわかったに過ぎない」という話もされていました。口頭での「わかりました」には、伝えた側と受け取った側の認識のずれが必ず生じる。書き出すことで初めて、漏れや矛盾が可視化されるという話は、受託・運用保守の現場では特に刺さります。お客さんから「この機能を追加してほしい」と言われた時に、そのWhyを聞きに行けるかどうかで、その後の仕様の精度が大きく変わってきますから。
—— 3章のではClaude CodeとNotebookLMを使った実際のデモがあったそうですね。
井上：Claude Codeのデモでは、誰が作ったか分からないTypeScriptのコードを読み込ませて「設計意図を推定して」と投げるだけで、システムの全体像がすらすらと出力されました。コードしかない現場でも、ここまで手がかりが作れるのかと驚きましたね。
ただ、その直後に講師の高橋さんが「今のAIの出力に、何が足りなかったですか？」と参加者に投げかけたんです。答えは明確で、「Why（なぜそう設計したか）」ですよね。AIはWhatやHowはコードから読み取れますが、設計の背景までは推測できない。「もし書かれていたら、それはAIが作った嘘（ハルシネーション）だ。人間が補完すべきはここだ」というメッセージが、デモを通じてリアルに伝わりました。
NotebookLMのデモでは、散在するドキュメントをまとめて読み込ませると、マインドマップが自動生成され、横断的な質問に答えてくれました。「既存の資産がゼロでなければ、AIが地図を作ってくれる時代」という言葉が印象的でしたね。私たちもすぐに使える環境なので、アンケートでも「概要把握に明日から使いたい」「Markdown形式で書くことがAIのトークン消費を抑えると知った」と、具体的な学びの声が多く上がっていました。
「全体満足度100%」という結果の裏側。「自分ごと化」が引き出した現場のポジティブな熱量
—— 研修後のアンケート（回答者31名）では、全体満足度100%。ここまでの数字が出た理由はどこにあると思いますか。
岐部：正直、予想以上の数字でした。ここまでの評価を得られた最大の理由は、事前のヒアリングを通じて私たちの現場の状況を深く理解し、研修をカスタマイズしていただいた点にあります。参加者が最初から「自分たちのための研修だ」と当事者意識を持てたことが大きいですね。 アンケートにも「ドキュメントを残すよう昨日先方から言われたばかりなので、Whyを踏まえて記載したい」という声があり、まさに現場が今抱えている課題に直撃したのだと思います。エンジニア以外の経理や案件管理のメンバーからも「業務の姿勢として活かせる」と反響があったのは嬉しい誤算でした。
井上：一方で、リアルな結果も出ています。実は「自信がついた（Confidence）」というスコアだけが相対的に低かったんです。「理解できた」が約97%だったのに対し、「自信がついた」は約90%とギャップがありました。 アンケートでも「ハンズオンで実際に手を動かしたかった」という声が複数上がっています。これは「頭ではわかったけれど、自分で実践できるかは不安」という状態です。ただ、裏を返せば「もっと時間をかけて深く掘り下げたい」「次はやってみたい」という高い学習意欲の表れでもあります。不満ではなく、次のステップに向けたモチベーションが生まれた証拠だとポジティブに捉えています。
—— FigJamを使ったワークショップでは、どんな光景が印象に残りましたか。
井上：「明日から始めること」「明日からやめること」「Whyが残っていないと感じる場面」の3エリアに付箋を貼るワークでしたが、「始めること」のエリアに付箋が集中していました。「やめること」はそこまで多くなかった。モチベーションが低ければ、あれだけポジティブな付箋は集まりません。参加者が前向きなエネルギーを持って臨んでいたことが、そのまま可視化された光景でした。
8分ごとにアクションを挟む設計も効いていたと思います。リモート勤務がメインの組織では、オンライン会議だと発言する人が固定化されがちです。最初はチャットの反応が薄かったものの、投稿やFigJamへの付箋を繰り返すうちに徐々に全員のリアクションが見える状態になっていきました。「この人はこういう考えを持っていたんだ」という気づきが、その場でリアルタイムに共有されていく感覚がとても良かったと思っています。
指示ゼロでBacklogの「詳細付きチケット」が40%増！現場が自発的に動き出した「たった一つの工夫」
—— 研修後、具体的にどんなアクションが生まれましたか。
井上：私が研修の後すぐに動いたのは、GitHubのIssueテンプレートの変更です。Issueというのは、「こういう課題があります」「この機能を作りたい」といった開発上のタスクや問題を登録するチケットのようなものです。これまでは何も書かれていないまっさらな状態で起票できたんですが、そこに「なぜ作るのか」「依頼者は誰か」という項目をテンプレートとして追加しました。書く欄を作ることで、Whyを残すことが自然と習慣になっていく。研修で学んだことをすぐ仕組みに落とし込めた形です。
岐部：私が直接目にしている変化として、Backlogのタスク記述量が明らかに増えました。Backlogというのは私たちがプロジェクト管理に使っているツールですが、以前はタイトルだけ書いて終わりのタスクが多かった。それが今は、背景や変更の理由といった文脈の説明がちゃんと書かれるようになっています。研修直後の段階ではありますが、言い切っていいレベルで変わっています。
—— 行動が変わった理由はどこにあると思いますか。
岐部：研修を通じて「なぜ残すのか」という納得感が先にあったからだと思っています。ルールを上から押し付けられた変化ではなく、自分たちで「そうしなきゃいけないな」と腹落ちした上での変化なので、自然に続いていく。研修が終わった後、私の方から部会で「文脈を残していくことは大事、少しずつみんなでやっていきましょう」と改めて話はしましたが、それ以上の指示は特にしていません。先に現場が動き始めていたという状況でした。
井上：アンケートの自由記述に「わかったと安易に言わない、という点が普段上司からも指摘されていることなので改めて意識したい」という声があって。知識として知っていたことが、研修を通じて「自分ごと」として再接続された感じがありますね。マインドセットレベルで何かが変わったというのは、定量的には測りにくいですけど、日々の行動の変化として少しずつ現れてきていると思います。
—— 今日のインタビュー直前にも、変化を感じる場面があったそうですね。
岐部：実はこのインタビューのほんの30分前にも、Slackで印象的なやり取りがありました。若手と中堅メンバーが、口頭で済ませかけていた議論に対して「ちゃんとチケット化して残そう」と自ら指摘し合っていたんです。誰かに指示されたわけではなく、研修を経てマインドセットが変わった結果だと思います。
現在、開発部門全体でのドキュメントのルール設計はまだ整備中の段階です。しかし、ガイドラインを作って従わせるよりも、現場が「なぜ残すべきか」に納得し、自発的に動き始めているこの状況が何より嬉しいですね。
ドキュメントをAIの外部記憶として捉え直した先に、この組織が目指す姿とは。
—— 今後、ドキュメントとAI活用をどうつなげていく考えですか。
井上：私たちはすでにGemini Code AssistやNotebookLM、AWS Kiroなどを活用しています。AIがない世界にはもう戻れないというのは、エンジニア全員が感じていることだと思うんですよ。コードを書くという作業がどんどんAIに代替されていく中で、人間の仕事は仕様を決めること、設計の意思決定をすること、コードレビューをすること、そして設計判断をきちんと残しておくことにシフトしていく。その比重がどんどん高くなっていくはずで、だからこそ今のうちにドキュメントを残す文化を根付かせておくことが重要だと感じています。
AIが出した結果に対して責任を取るのは人間ですし、AIが責任を持ってくれることはまずない。だとすれば、人間としてどういう役割を担わなきゃいけないのか。その答えの一つが、判断の根拠をきちんと残しておくことだと思っています。
—— 最後に、組織のアピールポイントと、一緒に働きたいエンジニア像を教えてください。
岐部：私たちが担っているのは放送やメディアといった領域のシステム開発と運用保守で、「止められない」という制約の中でスピード感を持ってリリースしていく必要があります。開発の速さと正確性を同時に求められる環境で力をつけたいエンジニアには、非常に刺激的な場だと思っています。
加えて、今まさに組織として知識の属人化を解消し、ナレッジを蓄積・再利用できる体制へと変わっていく途中にいる。その変化に主体的に関わっていきたいという人には、とても面白いフェーズだと感じてもらえると思います。私たちは、単にコードを書くエンジニアではなく、サービスの価値や課題の本質を理解し、自分で考えて、提案し、実行できるエンジニアと一緒に働きたいと思っています。
大規模で、しかも止められないシステムを支えているからこそ、一人ひとりの判断や設計の質がそのままサービスの価値に直結します。そうした環境の中で、自分の技術や意思をシステムにしっかり反映していきたい方にとっては、とてもやりがいのある環境だと思います。
井上：技術的なスキルはもちろん大事ですが、それと同じくらい「なぜそうするのか」を言語化して残せる人と働きたいと思っています。コードを書くだけでなく、判断の背景を伝えられる。そういうエンジニアが集まれば、組織としての知識の蓄積スピードが全然違ってくる。今回の研修を通じて、そういう文化を作っていけるという手応えを感じています。
テレビ朝日メディアプレックス株式会社のエンジニア求人一覧
https://findy-code.io/companies/643
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
AI戦略支援SaaS「Findy Team+」のサービス詳細はこちら
「この機能の仕様、○○さんしか知らない」「前任者が退職してシステムの全体像がわからない」。複数のプロジェクトが並行する開発・運用現場で構造的に発生する「知識の属人化と断絶」。テレビ朝日グループのシステムを担う株式会社テレビ朝日メディアプレックスもまた、情報が複数ツールに分散し「どれが正なのかわからない」という長年の課題を抱えていました。
その転機となったのが、2026年3月に実施した「90分のドキュメント文化推進トレーニング」です。研修からわずか数週間後、現場ではマネージャーの指示を待つことなく、メンバーが自発的に口頭の議論をチケット化し始めるなど、ボトムアップでの劇的な行動変容が起きていました。
なぜ、たった90分の研修が現場のカルチャーを変えたのか。本記事では、CTO岐部嗣哲氏とデータディビジョンマネージャー井上善貴氏に、属人化解消に向けた取り組みの背景と、研修がもたらした具体的な組織変化についてお伺いしました。
プロフィール
岐部 嗣哲さん 株式会社テレビ朝日メディアプレックス CTO（最高技術責任者）
SIerやベンチャー企業を経て、2011年に同社に入社。動画配信プレイヤーや視聴データ基盤など多岐にわたる開発を牽引し、クラウド・ビッグデータ領域のR&Dチームをリード。2023年4月よりCTOに就任し、全社の技術戦略やエンジニア組織のマネジメント（採用・育成等）を統括する。
井上 善貴さん 株式会社テレビ朝日メディアプレックス データディビジョン マネージャー
2022年1月に同社に入社。データエンジニアとして現場の開発業務を経験した後、現職に就任。現在は、データエンジニアやデータサイエンティスト、アナリストが集うデータ専門組織の開発とマネジメントを担う。
講師情報
高橋 裕之さん ファインディ株式会社 CTO室Staff Engineer (Engineering Excellence),
SPI Coach, Agile Coach
1989年より組込みエンジニアとして国産OSのスクラッチ開発等に従事し、ソフトウェア開発の最前線で16年にわたり泥臭い現場を経験。そこで直面した数々の構造的課題を根本から解決すべく、2005年にSPI（ソフトウェアプロセス改善）の専門家へと転身する。
以降、ソニーデジタルネットワークアプリケーションズ、ウイングアーク１ｓｔ、ビズリーチなどのテクノロジー企業にて、アジャイルコーチやプロセス改善部門の責任者を歴任。2024年よりファインディ株式会社に参画し、エンジニア組織への新技術・方法論の導入（イネーブルメント）を牽引。
現在の組織体制と、担っているミッション
—— 組織のミッションと、チームの規模感を教えてください。
岐部：私たちが所属するテクノロジーソリューション事業本部のミッションは、一言で表すと「変化し続ける放送メディアサービスの進化をテクノロジーの力で継続的に支援すること」です。インターネット基盤システム、データ基盤、コンテンツ管理、動画配信、分析基盤など、テレビ朝日グループのデジタル側を広く支えています。規模については、全社員約250名のうち、技術部門は約50名で、年齢層は20代後半〜30代前半が中心です。マトリックス型の組織構造で、プロジェクトに応じて各部門から横断的に人員がアサインされる形で動いています。業務の大半は既存システムの改修や運用保守で、複数のプロジェクトが常時並行して動いているのが日常です。
—— そういった環境の中で、現場ではどのような課題がありましたか。
井上：一番わかりやすいのは「情報がどこにあるか分からない」という問題です。ドキュメントのフォーマットも保管場所も統一されていないので、引き継ぎの際に毎回「どこに何がある？」という状況になってしまう。同じ内容のファイルが複数あって、どれが最新なのか判断できないケースもありました。
岐部：ドキュメントがGoogle Drive、Backlog、GitHubの3箇所に分散していて、それぞれの内容に乖離が生じているという問題もありました。どこが「正」なのかが明確でないので、古い情報を参照してしまうリスクが常にある。書く人と書かない人がいて、更新が徹底されない。協力会社のメンバーが何も残さずに契約終了するケースも多発していました。複数のプロジェクトが常時並行して動く中で、過去の情報を探す手段がSlackをさかのぼるか、知っている人に聞くかしかない。受託・運用保守をやっている組織なら、程度の差こそあれ、共感してもらえる話だと思っています。
ドキュメント文化推進トレーニングを実施した背景と、Findyを選んだ理由
—— なぜガイドラインではなく、トレーニングという形を選んだのでしょうか。
岐部：ルールをバンと出しても、人は納得して動いてくれないんですよ。自分自身で「確かにそれが必要だ」と腹落ちした上で動いてほしかった。今回の内容は「あなたはそれで本当にいいですか？」という問いかけから始まる構成になっていて、参加者が自分ごととして考えられる流れになっていました。その納得感のある進め方が、トレーニングという形を選んだ最大の理由です。
—— Findyを選んだ決め手は何でしたか。
岐部：生成AI活用の方針策定とドキュメント整備をちょうど社内で検討していたタイミングで、Findyさんからご提案をいただいた形です。加えて、講師の高橋さんが組み込みエンジニア出身で8社を渡り歩いてきた方だったことも大きかった。外部から伝えてもらう時って、やはり実務経験が豊富な人の言葉の方が説得力がありますから。現場のエンジニアにとっても「この人は実際に開発をやってきた人だ」という安心感があったと思います。
—— 事前に複数回ヒアリングがあったそうですね。そこでどのようなやり取りがあったのでしょうか。
岐部：最初にFindyさんが用意していたプログラムのベースは「ドキュメントを使わずに開発サイクルを回す」という内容でした。ただ、私たちの現場の課題はその前段にある。ドキュメントをまず作らないことには始まらないし、若手エンジニアには生成AIを活用していく上でコンテキストを残すことの重要性を理解してほしかった。そこを高橋さんに相談したところ、「Whyを残す文化を根付かせる」という方向でうまく組み直していただきました。
井上：私たちの現場は、プロジェクトの8〜9割をGitHubで管理し、タスク管理にはBacklogを併用しています。また、Gemini Code AssistやNotebookLMといった生成AIが既に利用可能な環境にありました。
今回、そうした具体的な技術スタックを踏まえた上で、「コードが先行する現場で、AIを活用してドキュメントを逆生成するデモが見たい」というリクエストを出したのですが、それを見事にカリキュラムへ盛り込んでいただけました。自分たちの環境に即して内容を高度にカスタマイズしてもらえたことは、非常に大きな価値があったと感じています。
—— 全員の工数を投資するという判断に、社内での抵抗はありましたか。
岐部：割とスルッといきましたね。ルールを押し付けるよりも、納得感を持ってもらった上で動いてもらう方が結果的に定着する。そこは私自身が確信を持っていたので、判断自体は迷いませんでした。年度末の忙しいタイミングではあったんですが、それでもこのテーマに時間を取る価値があると判断しました。
共感から始まった90分。AI時代にこそ人間が残すべき「Why」とは
—— 研修冒頭から、参加者の反応はいかがでしたか。
井上：最初に高橋さんが「こんな経験はありませんか？」と5つの属人化の症状を挙げて、「何個当てはまりましたか？数字をチャットに打ってください」と投げかけたんですよ。そうしたら「5」「5」「5」って流れていって。全部当てはまるという人がたくさんいた。
続いて「仕様に関わるバグの70%は変更漏れが原因」という話が出て、「間に合わないモンスター」という言葉も出てきた。開発期間が短いから見積もりや仕様書を省いてしまう。結果として手戻りが発生して、かえって時間がかかる。みんな身に覚えがあるんですよ。
どれも自分たちの日常そのものだったので、「これは自分たちの話だ」という空気が一気に広がりましたね。
——２章の「Whyを残す」というパートでは、どのような内容が届きましたか。
井上：ドキュメントをWhat（何があるか）・How（どう動くか）・Why（なぜそうしたか）の3層に分けて考えるという整理が腑に落ちました。WhatやHowはコードから後から復元できる。でもWhyだけは、その時の文脈を知っている人間にしか書けない。一度失われたら永遠に復元できないという話です。プログラマーであれば「リーダブルコード」などを通じて似た考え方に触れたことがある人も多いと思います。ただ、知識として知っていても、自分の現場のこととして捉え直す機会はなかなかない。アンケートでも「ドキュメントに対する考え方が変わった」という声が複数出ていました。
岐部：高橋さんが「わかったというのは、その人がわかったと思った範囲だけわかったに過ぎない」という話もされていました。口頭での「わかりました」には、伝えた側と受け取った側の認識のずれが必ず生じる。書き出すことで初めて、漏れや矛盾が可視化されるという話は、受託・運用保守の現場では特に刺さります。お客さんから「この機能を追加してほしい」と言われた時に、そのWhyを聞きに行けるかどうかで、その後の仕様の精度が大きく変わってきますから。
—— 3章のではClaude CodeとNotebookLMを使った実際のデモがあったそうですね。
井上：Claude Codeのデモでは、誰が作ったか分からないTypeScriptのコードを読み込ませて「設計意図を推定して」と投げるだけで、システムの全体像がすらすらと出力されました。コードしかない現場でも、ここまで手がかりが作れるのかと驚きましたね。
ただ、その直後に講師の高橋さんが「今のAIの出力に、何が足りなかったですか？」と参加者に投げかけたんです。答えは明確で、「Why（なぜそう設計したか）」ですよね。AIはWhatやHowはコードから読み取れますが、設計の背景までは推測できない。「もし書かれていたら、それはAIが作った嘘（ハルシネーション）だ。人間が補完すべきはここだ」というメッセージが、デモを通じてリアルに伝わりました。
NotebookLMのデモでは、散在するドキュメントをまとめて読み込ませると、マインドマップが自動生成され、横断的な質問に答えてくれました。「既存の資産がゼロでなければ、AIが地図を作ってくれる時代」という言葉が印象的でしたね。私たちもすぐに使える環境なので、アンケートでも「概要把握に明日から使いたい」「Markdown形式で書くことがAIのトークン消費を抑えると知った」と、具体的な学びの声が多く上がっていました。
「全体満足度100%」という結果の裏側。「自分ごと化」が引き出した現場のポジティブな熱量
—— 研修後のアンケート（回答者31名）では、全体満足度100%。ここまでの数字が出た理由はどこにあると思いますか。
岐部：正直、予想以上の数字でした。ここまでの評価を得られた最大の理由は、事前のヒアリングを通じて私たちの現場の状況を深く理解し、研修をカスタマイズしていただいた点にあります。参加者が最初から「自分たちのための研修だ」と当事者意識を持てたことが大きいですね。 アンケートにも「ドキュメントを残すよう昨日先方から言われたばかりなので、Whyを踏まえて記載したい」という声があり、まさに現場が今抱えている課題に直撃したのだと思います。エンジニア以外の経理や案件管理のメンバーからも「業務の姿勢として活かせる」と反響があったのは嬉しい誤算でした。
井上：一方で、リアルな結果も出ています。実は「自信がついた（Confidence）」というスコアだけが相対的に低かったんです。「理解できた」が約97%だったのに対し、「自信がついた」は約90%とギャップがありました。 アンケートでも「ハンズオンで実際に手を動かしたかった」という声が複数上がっています。これは「頭ではわかったけれど、自分で実践できるかは不安」という状態です。ただ、裏を返せば「もっと時間をかけて深く掘り下げたい」「次はやってみたい」という高い学習意欲の表れでもあります。不満ではなく、次のステップに向けたモチベーションが生まれた証拠だとポジティブに捉えています。
—— FigJamを使ったワークショップでは、どんな光景が印象に残りましたか。
井上：「明日から始めること」「明日からやめること」「Whyが残っていないと感じる場面」の3エリアに付箋を貼るワークでしたが、「始めること」のエリアに付箋が集中していました。「やめること」はそこまで多くなかった。モチベーションが低ければ、あれだけポジティブな付箋は集まりません。参加者が前向きなエネルギーを持って臨んでいたことが、そのまま可視化された光景でした。
8分ごとにアクションを挟む設計も効いていたと思います。リモート勤務がメインの組織では、オンライン会議だと発言する人が固定化されがちです。最初はチャットの反応が薄かったものの、投稿やFigJamへの付箋を繰り返すうちに徐々に全員のリアクションが見える状態になっていきました。「この人はこういう考えを持っていたんだ」という気づきが、その場でリアルタイムに共有されていく感覚がとても良かったと思っています。
指示ゼロでBacklogの「詳細付きチケット」が40%増！現場が自発的に動き出した「たった一つの工夫」
—— 研修後、具体的にどんなアクションが生まれましたか。
井上：私が研修の後すぐに動いたのは、GitHubのIssueテンプレートの変更です。Issueというのは、「こういう課題があります」「この機能を作りたい」といった開発上のタスクや問題を登録するチケットのようなものです。これまでは何も書かれていないまっさらな状態で起票できたんですが、そこに「なぜ作るのか」「依頼者は誰か」という項目をテンプレートとして追加しました。書く欄を作ることで、Whyを残すことが自然と習慣になっていく。研修で学んだことをすぐ仕組みに落とし込めた形です。
岐部：私が直接目にしている変化として、Backlogのタスク記述量が明らかに増えました。Backlogというのは私たちがプロジェクト管理に使っているツールですが、以前はタイトルだけ書いて終わりのタスクが多かった。それが今は、背景や変更の理由といった文脈の説明がちゃんと書かれるようになっています。研修直後の段階ではありますが、言い切っていいレベルで変わっています。
—— 行動が変わった理由はどこにあると思いますか。
岐部：研修を通じて「なぜ残すのか」という納得感が先にあったからだと思っています。ルールを上から押し付けられた変化ではなく、自分たちで「そうしなきゃいけないな」と腹落ちした上での変化なので、自然に続いていく。研修が終わった後、私の方から部会で「文脈を残していくことは大事、少しずつみんなでやっていきましょう」と改めて話はしましたが、それ以上の指示は特にしていません。先に現場が動き始めていたという状況でした。
井上：アンケートの自由記述に「わかったと安易に言わない、という点が普段上司からも指摘されていることなので改めて意識したい」という声があって。知識として知っていたことが、研修を通じて「自分ごと」として再接続された感じがありますね。マインドセットレベルで何かが変わったというのは、定量的には測りにくいですけど、日々の行動の変化として少しずつ現れてきていると思います。
—— 今日のインタビュー直前にも、変化を感じる場面があったそうですね。
岐部：実はこのインタビューのほんの30分前にも、Slackで印象的なやり取りがありました。若手と中堅メンバーが、口頭で済ませかけていた議論に対して「ちゃんとチケット化して残そう」と自ら指摘し合っていたんです。誰かに指示されたわけではなく、研修を経てマインドセットが変わった結果だと思います。
現在、開発部門全体でのドキュメントのルール設計はまだ整備中の段階です。しかし、ガイドラインを作って従わせるよりも、現場が「なぜ残すべきか」に納得し、自発的に動き始めているこの状況が何より嬉しいですね。
ドキュメントをAIの外部記憶として捉え直した先に、この組織が目指す姿とは。
—— 今後、ドキュメントとAI活用をどうつなげていく考えですか。
井上：私たちはすでにGemini Code AssistやNotebookLM、AWS Kiroなどを活用しています。AIがない世界にはもう戻れないというのは、エンジニア全員が感じていることだと思うんですよ。コードを書くという作業がどんどんAIに代替されていく中で、人間の仕事は仕様を決めること、設計の意思決定をすること、コードレビューをすること、そして設計判断をきちんと残しておくことにシフトしていく。その比重がどんどん高くなっていくはずで、だからこそ今のうちにドキュメントを残す文化を根付かせておくことが重要だと感じています。
AIが出した結果に対して責任を取るのは人間ですし、AIが責任を持ってくれることはまずない。だとすれば、人間としてどういう役割を担わなきゃいけないのか。その答えの一つが、判断の根拠をきちんと残しておくことだと思っています。
—— 最後に、組織のアピールポイントと、一緒に働きたいエンジニア像を教えてください。
岐部：私たちが担っているのは放送やメディアといった領域のシステム開発と運用保守で、「止められない」という制約の中でスピード感を持ってリリースしていく必要があります。開発の速さと正確性を同時に求められる環境で力をつけたいエンジニアには、非常に刺激的な場だと思っています。
加えて、今まさに組織として知識の属人化を解消し、ナレッジを蓄積・再利用できる体制へと変わっていく途中にいる。その変化に主体的に関わっていきたいという人には、とても面白いフェーズだと感じてもらえると思います。私たちは、単にコードを書くエンジニアではなく、サービスの価値や課題の本質を理解し、自分で考えて、提案し、実行できるエンジニアと一緒に働きたいと思っています。
大規模で、しかも止められないシステムを支えているからこそ、一人ひとりの判断や設計の質がそのままサービスの価値に直結します。そうした環境の中で、自分の技術や意思をシステムにしっかり反映していきたい方にとっては、とてもやりがいのある環境だと思います。
井上：技術的なスキルはもちろん大事ですが、それと同じくらい「なぜそうするのか」を言語化して残せる人と働きたいと思っています。コードを書くだけでなく、判断の背景を伝えられる。そういうエンジニアが集まれば、組織としての知識の蓄積スピードが全然違ってくる。今回の研修を通じて、そういう文化を作っていけるという手応えを感じています。
テレビ朝日メディアプレックス株式会社のエンジニア求人一覧
https://findy-code.io/companies/643
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
AI戦略支援SaaS「Findy Team+」のサービス詳細はこちら
90分間の研修で、自発的にチケットの記述量が40%増加。テレビ朝日メディアプレックスの属人化を打破した「ドキュメント研修」の裏側とは。
「この機能の仕様、○○さんしか知らない」「前任者が退職してシステムの全体像がわからない」。複数のプロジェクトが並行する開発・運用現場で構造的に発生する「知識の属人化と断絶」。テレビ朝日グループのシステムを担う株式会社テレビ朝日メディアプレックスもまた、情報が複数ツールに分散し「どれが正なのかわからない」という長年の課題を抱えていました。
その転機となったのが、2026年3月に実施した「90分のドキュメント文化推進トレーニング」です。研修からわずか数週間後、現場ではマネージャーの指示を待つことなく、メンバーが自発的に口頭の議論をチケット化し始めるなど、ボトムアップでの劇的な行動変容が起きていました。
なぜ、たった90分の研修が現場のカルチャーを変えたのか。本記事では、CTO岐部嗣哲氏とデータディビジョンマネージャー井上善貴氏に、属人化解消に向けた取り組みの背景と、研修がもたらした具体的な組織変化についてお伺いしました。
プロフィール
岐部 嗣哲さん 株式会社テレビ朝日メディアプレックス CTO（最高技術責任者）
SIerやベンチャー企業を経て、2011年に同社に入社。動画配信プレイヤーや視聴データ基盤など多岐にわたる開発を牽引し、クラウド・ビッグデータ領域のR&Dチームをリード。2023年4月よりCTOに就任し、全社の技術戦略やエンジニア組織のマネジメント（採用・育成等）を統括する。
井上 善貴さん 株式会社テレビ朝日メディアプレックス データディビジョン マネージャー
2022年1月に同社に入社。データエンジニアとして現場の開発業務を経験した後、現職に就任。現在は、データエンジニアやデータサイエンティスト、アナリストが集うデータ専門組織の開発とマネジメントを担う。
講師情報
高橋 裕之さん ファインディ株式会社 CTO室Staff Engineer (Engineering Excellence),
SPI Coach, Agile Coach
1989年より組込みエンジニアとして国産OSのスクラッチ開発等に従事し、ソフトウェア開発の最前線で16年にわたり泥臭い現場を経験。そこで直面した数々の構造的課題を根本から解決すべく、2005年にSPI（ソフトウェアプロセス改善）の専門家へと転身する。
以降、ソニーデジタルネットワークアプリケーションズ、ウイングアーク１ｓｔ、ビズリーチなどのテクノロジー企業にて、アジャイルコーチやプロセス改善部門の責任者を歴任。2024年よりファインディ株式会社に参画し、エンジニア組織への新技術・方法論の導入（イネーブルメント）を牽引。
現在の組織体制と、担っているミッション
—— 組織のミッションと、チームの規模感を教えてください。
岐部：私たちが所属するテクノロジーソリューション事業本部のミッションは、一言で表すと「変化し続ける放送メディアサービスの進化をテクノロジーの力で継続的に支援すること」です。インターネット基盤システム、データ基盤、コンテンツ管理、動画配信、分析基盤など、テレビ朝日グループのデジタル側を広く支えています。規模については、全社員約250名のうち、技術部門は約50名で、年齢層は20代後半〜30代前半が中心です。マトリックス型の組織構造で、プロジェクトに応じて各部門から横断的に人員がアサインされる形で動いています。業務の大半は既存システムの改修や運用保守で、複数のプロジェクトが常時並行して動いているのが日常です。
—— そういった環境の中で、現場ではどのような課題がありましたか。
井上：一番わかりやすいのは「情報がどこにあるか分からない」という問題です。ドキュメントのフォーマットも保管場所も統一されていないので、引き継ぎの際に毎回「どこに何がある？」という状況になってしまう。同じ内容のファイルが複数あって、どれが最新なのか判断できないケースもありました。
岐部：ドキュメントがGoogle Drive、Backlog、GitHubの3箇所に分散していて、それぞれの内容に乖離が生じているという問題もありました。どこが「正」なのかが明確でないので、古い情報を参照してしまうリスクが常にある。書く人と書かない人がいて、更新が徹底されない。協力会社のメンバーが何も残さずに契約終了するケースも多発していました。複数のプロジェクトが常時並行して動く中で、過去の情報を探す手段がSlackをさかのぼるか、知っている人に聞くかしかない。受託・運用保守をやっている組織なら、程度の差こそあれ、共感してもらえる話だと思っています。
ドキュメント文化推進トレーニングを実施した背景と、Findyを選んだ理由
—— なぜガイドラインではなく、トレーニングという形を選んだのでしょうか。
岐部：ルールをバンと出しても、人は納得して動いてくれないんですよ。自分自身で「確かにそれが必要だ」と腹落ちした上で動いてほしかった。今回の内容は「あなたはそれで本当にいいですか？」という問いかけから始まる構成になっていて、参加者が自分ごととして考えられる流れになっていました。その納得感のある進め方が、トレーニングという形を選んだ最大の理由です。
—— Findyを選んだ決め手は何でしたか。
岐部：生成AI活用の方針策定とドキュメント整備をちょうど社内で検討していたタイミングで、Findyさんからご提案をいただいた形です。加えて、講師の高橋さんが組み込みエンジニア出身で8社を渡り歩いてきた方だったことも大きかった。外部から伝えてもらう時って、やはり実務経験が豊富な人の言葉の方が説得力がありますから。現場のエンジニアにとっても「この人は実際に開発をやってきた人だ」という安心感があったと思います。
—— 事前に複数回ヒアリングがあったそうですね。そこでどのようなやり取りがあったのでしょうか。
岐部：最初にFindyさんが用意していたプログラムのベースは「ドキュメントを使わずに開発サイクルを回す」という内容でした。ただ、私たちの現場の課題はその前段にある。ドキュメントをまず作らないことには始まらないし、若手エンジニアには生成AIを活用していく上でコンテキストを残すことの重要性を理解してほしかった。そこを高橋さんに相談したところ、「Whyを残す文化を根付かせる」という方向でうまく組み直していただきました。
井上：私たちの現場は、プロジェクトの8〜9割をGitHubで管理し、タスク管理にはBacklogを併用しています。また、Gemini Code AssistやNotebookLMといった生成AIが既に利用可能な環境にありました。
今回、そうした具体的な技術スタックを踏まえた上で、「コードが先行する現場で、AIを活用してドキュメントを逆生成するデモが見たい」というリクエストを出したのですが、それを見事にカリキュラムへ盛り込んでいただけました。自分たちの環境に即して内容を高度にカスタマイズしてもらえたことは、非常に大きな価値があったと感じています。
—— 全員の工数を投資するという判断に、社内での抵抗はありましたか。
岐部：割とスルッといきましたね。ルールを押し付けるよりも、納得感を持ってもらった上で動いてもらう方が結果的に定着する。そこは私自身が確信を持っていたので、判断自体は迷いませんでした。年度末の忙しいタイミングではあったんですが、それでもこのテーマに時間を取る価値があると判断しました。
共感から始まった90分。AI時代にこそ人間が残すべき「Why」とは
—— 研修冒頭から、参加者の反応はいかがでしたか。
井上：最初に高橋さんが「こんな経験はありませんか？」と5つの属人化の症状を挙げて、「何個当てはまりましたか？数字をチャットに打ってください」と投げかけたんですよ。そうしたら「5」「5」「5」って流れていって。全部当てはまるという人がたくさんいた。
続いて「仕様に関わるバグの70%は変更漏れが原因」という話が出て、「間に合わないモンスター」という言葉も出てきた。開発期間が短いから見積もりや仕様書を省いてしまう。結果として手戻りが発生して、かえって時間がかかる。みんな身に覚えがあるんですよ。
どれも自分たちの日常そのものだったので、「これは自分たちの話だ」という空気が一気に広がりましたね。
——２章の「Whyを残す」というパートでは、どのような内容が届きましたか。
井上：ドキュメントをWhat（何があるか）・How（どう動くか）・Why（なぜそうしたか）の3層に分けて考えるという整理が腑に落ちました。WhatやHowはコードから後から復元できる。でもWhyだけは、その時の文脈を知っている人間にしか書けない。一度失われたら永遠に復元できないという話です。プログラマーであれば「リーダブルコード」などを通じて似た考え方に触れたことがある人も多いと思います。ただ、知識として知っていても、自分の現場のこととして捉え直す機会はなかなかない。アンケートでも「ドキュメントに対する考え方が変わった」という声が複数出ていました。
岐部：高橋さんが「わかったというのは、その人がわかったと思った範囲だけわかったに過ぎない」という話もされていました。口頭での「わかりました」には、伝えた側と受け取った側の認識のずれが必ず生じる。書き出すことで初めて、漏れや矛盾が可視化されるという話は、受託・運用保守の現場では特に刺さります。お客さんから「この機能を追加してほしい」と言われた時に、そのWhyを聞きに行けるかどうかで、その後の仕様の精度が大きく変わってきますから。
—— 3章のではClaude CodeとNotebookLMを使った実際のデモがあったそうですね。
井上：Claude Codeのデモでは、誰が作ったか分からないTypeScriptのコードを読み込ませて「設計意図を推定して」と投げるだけで、システムの全体像がすらすらと出力されました。コードしかない現場でも、ここまで手がかりが作れるのかと驚きましたね。
ただ、その直後に講師の高橋さんが「今のAIの出力に、何が足りなかったですか？」と参加者に投げかけたんです。答えは明確で、「Why（なぜそう設計したか）」ですよね。AIはWhatやHowはコードから読み取れますが、設計の背景までは推測できない。「もし書かれていたら、それはAIが作った嘘（ハルシネーション）だ。人間が補完すべきはここだ」というメッセージが、デモを通じてリアルに伝わりました。
NotebookLMのデモでは、散在するドキュメントをまとめて読み込ませると、マインドマップが自動生成され、横断的な質問に答えてくれました。「既存の資産がゼロでなければ、AIが地図を作ってくれる時代」という言葉が印象的でしたね。私たちもすぐに使える環境なので、アンケートでも「概要把握に明日から使いたい」「Markdown形式で書くことがAIのトークン消費を抑えると知った」と、具体的な学びの声が多く上がっていました。
「全体満足度100%」という結果の裏側。「自分ごと化」が引き出した現場のポジティブな熱量
—— 研修後のアンケート（回答者31名）では、全体満足度100%。ここまでの数字が出た理由はどこにあると思いますか。
岐部：正直、予想以上の数字でした。ここまでの評価を得られた最大の理由は、事前のヒアリングを通じて私たちの現場の状況を深く理解し、研修をカスタマイズしていただいた点にあります。参加者が最初から「自分たちのための研修だ」と当事者意識を持てたことが大きいですね。 アンケートにも「ドキュメントを残すよう昨日先方から言われたばかりなので、Whyを踏まえて記載したい」という声があり、まさに現場が今抱えている課題に直撃したのだと思います。エンジニア以外の経理や案件管理のメンバーからも「業務の姿勢として活かせる」と反響があったのは嬉しい誤算でした。
井上：一方で、リアルな結果も出ています。実は「自信がついた（Confidence）」というスコアだけが相対的に低かったんです。「理解できた」が約97%だったのに対し、「自信がついた」は約90%とギャップがありました。 アンケートでも「ハンズオンで実際に手を動かしたかった」という声が複数上がっています。これは「頭ではわかったけれど、自分で実践できるかは不安」という状態です。ただ、裏を返せば「もっと時間をかけて深く掘り下げたい」「次はやってみたい」という高い学習意欲の表れでもあります。不満ではなく、次のステップに向けたモチベーションが生まれた証拠だとポジティブに捉えています。
—— FigJamを使ったワークショップでは、どんな光景が印象に残りましたか。
井上：「明日から始めること」「明日からやめること」「Whyが残っていないと感じる場面」の3エリアに付箋を貼るワークでしたが、「始めること」のエリアに付箋が集中していました。「やめること」はそこまで多くなかった。モチベーションが低ければ、あれだけポジティブな付箋は集まりません。参加者が前向きなエネルギーを持って臨んでいたことが、そのまま可視化された光景でした。
8分ごとにアクションを挟む設計も効いていたと思います。リモート勤務がメインの組織では、オンライン会議だと発言する人が固定化されがちです。最初はチャットの反応が薄かったものの、投稿やFigJamへの付箋を繰り返すうちに徐々に全員のリアクションが見える状態になっていきました。「この人はこういう考えを持っていたんだ」という気づきが、その場でリアルタイムに共有されていく感覚がとても良かったと思っています。
指示ゼロでBacklogの「詳細付きチケット」が40%増！現場が自発的に動き出した「たった一つの工夫」
—— 研修後、具体的にどんなアクションが生まれましたか。
井上：私が研修の後すぐに動いたのは、GitHubのIssueテンプレートの変更です。Issueというのは、「こういう課題があります」「この機能を作りたい」といった開発上のタスクや問題を登録するチケットのようなものです。これまでは何も書かれていないまっさらな状態で起票できたんですが、そこに「なぜ作るのか」「依頼者は誰か」という項目をテンプレートとして追加しました。書く欄を作ることで、Whyを残すことが自然と習慣になっていく。研修で学んだことをすぐ仕組みに落とし込めた形です。
岐部：私が直接目にしている変化として、Backlogのタスク記述量が明らかに増えました。Backlogというのは私たちがプロジェクト管理に使っているツールですが、以前はタイトルだけ書いて終わりのタスクが多かった。それが今は、背景や変更の理由といった文脈の説明がちゃんと書かれるようになっています。研修直後の段階ではありますが、言い切っていいレベルで変わっています。
—— 行動が変わった理由はどこにあると思いますか。
岐部：研修を通じて「なぜ残すのか」という納得感が先にあったからだと思っています。ルールを上から押し付けられた変化ではなく、自分たちで「そうしなきゃいけないな」と腹落ちした上での変化なので、自然に続いていく。研修が終わった後、私の方から部会で「文脈を残していくことは大事、少しずつみんなでやっていきましょう」と改めて話はしましたが、それ以上の指示は特にしていません。先に現場が動き始めていたという状況でした。
井上：アンケートの自由記述に「わかったと安易に言わない、という点が普段上司からも指摘されていることなので改めて意識したい」という声があって。知識として知っていたことが、研修を通じて「自分ごと」として再接続された感じがありますね。マインドセットレベルで何かが変わったというのは、定量的には測りにくいですけど、日々の行動の変化として少しずつ現れてきていると思います。
—— 今日のインタビュー直前にも、変化を感じる場面があったそうですね。
岐部：実はこのインタビューのほんの30分前にも、Slackで印象的なやり取りがありました。若手と中堅メンバーが、口頭で済ませかけていた議論に対して「ちゃんとチケット化して残そう」と自ら指摘し合っていたんです。誰かに指示されたわけではなく、研修を経てマインドセットが変わった結果だと思います。
現在、開発部門全体でのドキュメントのルール設計はまだ整備中の段階です。しかし、ガイドラインを作って従わせるよりも、現場が「なぜ残すべきか」に納得し、自発的に動き始めているこの状況が何より嬉しいですね。
ドキュメントをAIの外部記憶として捉え直した先に、この組織が目指す姿とは。
—— 今後、ドキュメントとAI活用をどうつなげていく考えですか。
井上：私たちはすでにGemini Code AssistやNotebookLM、AWS Kiroなどを活用しています。AIがない世界にはもう戻れないというのは、エンジニア全員が感じていることだと思うんですよ。コードを書くという作業がどんどんAIに代替されていく中で、人間の仕事は仕様を決めること、設計の意思決定をすること、コードレビューをすること、そして設計判断をきちんと残しておくことにシフトしていく。その比重がどんどん高くなっていくはずで、だからこそ今のうちにドキュメントを残す文化を根付かせておくことが重要だと感じています。
AIが出した結果に対して責任を取るのは人間ですし、AIが責任を持ってくれることはまずない。だとすれば、人間としてどういう役割を担わなきゃいけないのか。その答えの一つが、判断の根拠をきちんと残しておくことだと思っています。
—— 最後に、組織のアピールポイントと、一緒に働きたいエンジニア像を教えてください。
岐部：私たちが担っているのは放送やメディアといった領域のシステム開発と運用保守で、「止められない」という制約の中でスピード感を持ってリリースしていく必要があります。開発の速さと正確性を同時に求められる環境で力をつけたいエンジニアには、非常に刺激的な場だと思っています。
加えて、今まさに組織として知識の属人化を解消し、ナレッジを蓄積・再利用できる体制へと変わっていく途中にいる。その変化に主体的に関わっていきたいという人には、とても面白いフェーズだと感じてもらえると思います。私たちは、単にコードを書くエンジニアではなく、サービスの価値や課題の本質を理解し、自分で考えて、提案し、実行できるエンジニアと一緒に働きたいと思っています。
大規模で、しかも止められないシステムを支えているからこそ、一人ひとりの判断や設計の質がそのままサービスの価値に直結します。そうした環境の中で、自分の技術や意思をシステムにしっかり反映していきたい方にとっては、とてもやりがいのある環境だと思います。
井上：技術的なスキルはもちろん大事ですが、それと同じくらい「なぜそうするのか」を言語化して残せる人と働きたいと思っています。コードを書くだけでなく、判断の背景を伝えられる。そういうエンジニアが集まれば、組織としての知識の蓄積スピードが全然違ってくる。今回の研修を通じて、そういう文化を作っていけるという手応えを感じています。
テレビ朝日メディアプレックス株式会社のエンジニア求人一覧
https://findy-code.io/companies/643
伴走型支援サービス by Findy Team+のサービス詳細は、以下よりご覧いただけます
https://jp.findy-team.io/consulting/service/
AI戦略支援SaaS「Findy Team+」のサービス詳細はこちら
