◾️セッション概要
2023年のYAPC::Kyotoでは、「地方のエンジニアが作る日本のITコミュニティの未来」というタイトルで、地方の小さなコミュニティが誰かの人生を変えるという体験談や、リモート時代における地方のITコミュニティの可能性について発表しました。

当時の発表（旧）から2年が経過し、リモートワークの終焉や出社回帰、それに影響を受けて労働・採用市場の変化など、地方のエンジニアや、それに関わるITコミュニティを取り巻く環境は大きく変化しました。

私自身、6年間全国のプロダクト組織づくりに関わってきた経験や、また自身も前回の登壇時は地方に住んでいた状況から、首都圏に引っ越すなど、状況が変わった中で、今後の地方ITコミュニティや、企業、そしてそれを牽引している全ての人達にとって「どのようなあり方があり、どのような未来の可能性が待っているか」、今この状況で改めて問い（Q）、時系列を追い考察し発表します。

「地方 × ITに関わる全ての人」の未来を一緒に考える時間になれば幸いです。

◾️聴講者が得られること
・地方コミュニティの最新動向、2023-2025年の時代の流れを経て、希望や逆に課題など
・リモート時代を超えた現在の状況において、「地方にいるからこそできる」キャリアやITやプロダクト開発に関わることの可能性の示唆
・地方コミュニティを今後も継続的に盛り上げていく為のヒント
・地方と都市を越境してつながる新しいエンジニアのあり方

◾️想定対象者
・地方や地方都市で活動する、ITやプロダクト開発に関わっている全ての方
・上記を志している、学生の方
・ローカルコミュニティを日々盛り上げ、運営に関わっている全ての方
・地方開発拠点や、地方でプロダクト開発に関わる社員の方を持つ企業の方
・首都圏や関東圏から「地方ITコミュニティや人との関わり方」を模索している人

クラウドの利用が広がる中で、複数のプロダクトを横断して安定したインフラ基盤を提供することは、プラットフォームエンジニアリングにおける大きな課題です。

我々の組織hacomonoでは、1,000万人以上の登録ユーザーを抱えるサービスを提供しており、今後はさらに複数のプロダクト展開を計画しています。
これまでプロジェクトごとにAWSアカウントを発行し個別にリソースを管理してきましたが、組織の成長とともに、このやり方だけではスケールしていくのが難しいと考えています。

そこで現在、共通基盤をKubernetes上に構築する取り組みを進めており、その一つの施策として導入しているのが Crossplane です。
CrossplaneとはAWSやGCPなどのパブリッククラウドやKubernetesリソースなどをKubernetesの抽象で管理可能にするOSSのツールです。

Crossplaneによるリソースの抽象化は、開発者がより楽かつ安全にインフラを扱えるようにし、同時に基盤側も裏で進化を続けられる柔軟さをもたらします。
一方で、トラブルシューティング時の原因特定の難しさや、従来のIaCツールとは異なる運用フローへの適応、チーム全体での新たな技術スタックに関する知識共有などの課題も少しずつ見えてきています。

本セッションでは、Crossplaneの概要と、取り組みを通じて見えてきた可能性と難しさ、そして今後の展望を共有します。プラットフォームエンジニアや、Crossplaneの導入を検討している方にとって、参考になる話を届けられればと思います。

最近、スマートホーム分野で話題になっている SwitchBot というものがあります。
私はドア開閉を楽にするために自作の顔認証プログラム（ face_recognition ライブラリを使用）と組み合わせて使っています。

SwitchBot製品は、SwitchBotハブを使うことによってHTTP通信で操作できます。SwitchBotハブを購入せずに操作したい場合には、BLE(Bluetooth Low Energy)通信を用いることで操作できます。

このトークでは、BLE通信の概要とその通信の流れや仕様の詳細について、
"自作SwitchBotハブによる顔認証ロック"を題材にお伝えします。私たちソフトウェアエンジニアが慣れ親しんでいるHTTP通信との性能比較や身の回りで使われているBluetooth機器の仕組みにも触れながら詳しく説明します。

BLEについて知らない人も、BLE等の通信方式の詳細が好きな方にも興味を持っていただけるように、以下の流れでお話しする予定です。

• 今回作成した顔認証ロックのシステム構成の概要説明（SwitchBotハブを用いた場合の構成図との比較もあり）
  • face_recognitionを用いた顔認証の仕組み
  • SwitchBotをBLE通信で操作する自作ハブの仕組み
• ざっくりとしたHTTPとBLEの比較
• BLEの仕様の詳細解説
  • BLEの使用定義であるプロトコルとプロファイルについて
  • 接続待ちの仕組み(アドバタイズ)
  • GATT通信
  • BLEはなぜ低レイテンシーなのか？
• 通信を覗き見てみる（デモもしくは動画で実際に見せます）
• 自作してどれくらいのコスト（お金）削減になったのか？
• BLEとHTTP 経由で通信した場合のレイテンシー比較

とある組織で「フロントエンドエキスパート」というチームが2017年に立ち上げられました。

当時は社内にフロントエンドに特化したメンバーがおらず、
アーキテクチャのレガシー化を中心とした多くの課題が山積の状態であり、
それらを解決に導いていくために、最初は一人だけの状態から始まったチームでした。

「フロントエンドを最高にする」をミッションに掲げて、
支援・発信・啓蒙・探求を活動の柱に数年に渡り積極的な活動を続けた結果、
共感する仲間も増え、いまでは多くのフロントエンジニアが在籍しています。

それにより、フロントエンドエキスパートチームが関わらずとも、
技術的にフロントエンド領域をリードしていけるようになり、
情報発信や啓蒙活動も活発に行われるようになりました。

そして、チームは一定の役目を終え、2025年8月を持って解散を迎えました。

さて、これは「チームとしては目的を達成した上で解散したいい話」にも聞こえます。

しかし、実際のチームのメンバー視点では、必ずしも「いい話」だけではありませんでした。
実際に解散の決断に至るまでには、多くの課題や悩みを抱え、
一部メンバーは中年クライシスにも陥りかけていました。

プロダクトを横断する支援チームの立ち上げから、状況の変化に伴うチームの変遷、
解散に至るまでの経緯、それに伴うメンバーの葛藤、今後についてなど、
一つのチームが生まれて消えるまでのリアルな背景をお話できればと思います。

正規表現はPerlや多くの言語で重要な機能です。
しかし、正規表現は独特の文法から、自分の手で書くのは煩わしいです。
生成AIに書かせることもできますが、本当に期待しているものになっているのかという保証がありませんし、ReDoSなどの脆弱性を生んでしまう可能性もあります。

「正規表現をつくる」プログラム

そこで、「マッチしてほしい文字列」と「マッチしてほしくない文字列」を与えたら自動で、*や+を使ったいい感じの正規表現を作ってくれるプログラムがあったら便利だと思いませんか？
今回は、そういった「正規表現をつくる」プログラムについて話します。

オートマトンと正規表現のはざまで

「正規表現をつくる」プログラムといえば、PerlにはRegexp::Assembleがあります。
ですが、Regexp::Assembleでは単にマッチしてほしい文字列を|でつないだ正規表現のようなものが出てくるだけで、*や+を使った期待する正規表現にはなりません。

期待する正規表現についてはオートマトンを使うことで定義できます。
一方、オートマトンから人間の読みやすい正規表現を得ることは簡単ではありません。
この問題の解決ために、SATソルバなどを使って解決を試みます。

むすびに

この発表では、次のような内容を話します。

• 「正規表現をつくる」問題について
  • いい感じの正規表現とは何か？
• オートマトンの場合の解決方法
  • 受動的オートマトン学習
  • RPNIアルゴリズム
• 正規表現として求めるには？
  • 正規表現への変換の困難さ
  • SATソルバを使った探索

「正規表現をつくる」問題を、理論的な方法を用いながらも現実的に対処していくトークにご期待ください。

はてなアンテナは登録したURLの更新情報を定期的に取得し、更新内容をまとめるウェブサイト巡回サービスです。
サービス開始以来20年を越えたはてなアンテナでは、Perlで書かれたコードベースの置き換えを進めています。
最初の一手として、数百万件のページを効率よく巡回するクローラをGoで書き直しました。クローラをゼロからつくる中でおこなった実装の選択や、既存のクローラからの移行および運用、既存のバックエンドとのコミュニケーションなど、プロダクトを漸進的に新しくしている過程についてお話しします。

以下のような内容について話す予定です。

• モチベーション: PerlからGoへ
• 実装編
  • ストレージの選定
  • キューの実装
  • producer-consumer パターン
  • http.Transport
• 運用編
  • カナリアリリースと移行戦略
  • ローカル開発
  • テスト
  • 旧バックエンドとのコミュニケーション
  • 中間証明書の問題
  • 健全性の監視

皆さんもクレジットカードを使った際に、身に覚えのない決済が来て、不正に利用されてしまっていたという経験があるのではないでしょうか？
不正といっても、クレジットマスターアタック、スキミングといった外部からの攻撃、カード所有者による悪意のある決済など、多岐に渡り不正決済は年々増加しています。

本トークではカード事業者が不正を防止するために日々行っている攻撃の検知、分析、対策、評価といった一連の運用やそれらを支えるシステムの開発をどのように行っているかを技術的な文脈を元にお話しします。

具体的には以下のような内容をお話しする予定です。

• カード決済における代表的な攻撃とそのパターン検知、および対策をどうやっているか
• 不正決済を検知し防止、抑制するためのシステムをどのように構築しているか
• 不正対策を行っているチームの日常、どのようなKPIを設定して攻撃の予防や改善を行なっているか

本トークを聞くことで、皆さんのカード決済が安心に行えている一旦が垣間見れるかもしれません。

「チーム内のコミュニケーションをシミュレーションしてみたい」みなさん一度は思ったことがあるのではないでしょうか？
昨今見かけるAI Agentでチームを組んで協働させるアプローチに着想を得て、あえて口論をさせてチームが破綻していく様子をシミュレーションできるのではないか？と思ったことをきっかけに、このシステムを実装してみました。

• パワハラをする上司
• 反抗的な部下
• 事なかれ主義の部下
• 派閥を作ろうとする部下
  現実世界で起こり得ることをシミュレートしてみることで、どうなったかを発表します。（動画にて実際のシミュレーションをお見せする予定です。）

また、より人間的な動きを再現するために、Peer to PeerでAI Agentがコミュニケーションできる仕組みを整えました。
AI Agentに相互にコミュニケーションをさせることは一見単純そうに見えて、"キュー"を活用したファンアウトの制御やAgentのメモリ設計など、意外と複雑でいくつかの課題を乗り越える必要がありました。
このアプリケーションではMastra、Vercel、Inngestを使い、どのようにPeer to Peerのコミュニケーションを実現したのかについてもご紹介します。

タイパや効率が最優先されがちな現代ですが、あえて正解までの最短コースだけを目指さず、道のりそのものを味わうプログラミングの楽しみ方を探求し、共有します。
題材の一つとして、毎年12月に小さなパズル問題が毎日出題される「Advent of Code」を紹介します。同じ問題に対しても解法は無数にあり、用いるプログラミング言語もアルゴリズムも様々、まさにTMTOWTDI！ 素朴にコードを書いて正解を導出して終わりにするのではなく、美しく効率的なコードを目指してみたり、業務では絶対に書かないような難解で突飛なものを考えたり、色々な楽しみ方があります。正解とは関係なくパズル入力の可視化に注力している参加者もいて、他の人の取り組みを見るだけでも学びがあり、とても面白く刺激的です。
また、私は個人の趣味活動としても「Pentomino」や「だんご屋のひまつぶし」といったパズルを自ら題材として取り上げ、プログラムで解く取り組みをしてきました。効率的な解法を調査し検証し、また得られた解をWebブラウザ上でインタラクティブに可視化するなど、自分なりのこだわりを持ったやり方で楽しみました。正解だけを求めて一直線で終わらせないからこそ得られた経験や学びを紹介します。
「コードはAIに書かせるもの」になりつつある現在ですが、やっぱり自分でコードを書くのは楽しいものです。自分流のプログラミングの楽しみ方を広げるためのヒントを持ち帰っていただき、“自分も何かやってみよう”という最初の一歩を後押ししたいと思います。

ある日突然、あるサービスに急（きゅう）なスパイクアクセスがやってきました。その数、700並列。サーバーは悲鳴をあげ、DBは沈黙しました。

高負荷対策の定石といえば、キュー (Job Queue) を思い浮かべるかもしれません。しかし、安易にジョブを Queue に入れるだけでは、結局700並列の重い処理が非同期に実行されるだけ。そこから、いかにして本当に必要な処理だけを「間引く」かが本当の課題でした。

こうした処理の間引きには、一般的にスロットル (Throttle) が用いられます。では、なぜその一般的な手法である Throttle ではダメだったのか？ 本トークでは、似て非なる Throttle とデバウンス (Debounce) の違いを解説しつつ、サーバーサイドでの Debounce 実装に至るまでの道のりを赤裸々にお話しします。

単純な実装だったv1から、その改良版であるv2ですら対応できなかった現実の複雑なユースケース、そして最終的にたどり着いた動的な遅延制御ロジック(v3)まで――3度の再実装の過程を、v1からv3へと進化していく実際のコードを追いながら、その思考と共に解説します。

この実例で語る負荷制御の勘所と設計思想が、あなたの武器庫に加わる新たな一つになれば幸いです。

大規模なモバイルアプリやWebサービスの開発現場では、UI・バックエンド・複数マイクロサービス間の依存関係が複雑化し、機能追加や保守時の影響範囲把握が大きな課題となります。

本発表では、AI技術を活用して画面設計データやコードベースから依存関係を自動抽出・可視化し、エンジニアやPMが短時間で全体像を把握できるナレッジ基盤の開発事例を紹介します。

PoC開発を通じて直面した技術的・組織的な壁や、現場での実践から得られた工夫・知見、今後の展望についても具体的にお話しします。大規模サービスの開発・運用に携わる方や、依存管理・ナレッジ共有に課題を感じている方に役立つ内容です。

2025年6月、Cursor Meetup Tokyoを主催し、現地350名・オンライン5,800名、計6,000人規模の技術イベントを運営しました。
当初は100人規模を想定していたものの、SNSでの「Build in Public」型プロモーションやコミュニティの盛り上がりにより、想定を大きく上回る参加者が集まりました。

本発表では、受付オペレーション（1人40秒×4レーン）、Google Meetの1,000人上限をYouTube Live＋StreamYardで乗り越えた配信設計、イベントページのサーバーダウンやトラブル対応、現地誘導や会場設営の工夫、SNS活用による参加者拡大など、現場で得た具体的なノウハウと課題解決のプロセスを余すところなく共有します。
大規模イベント運営が未経験の方にも再現性のある実践知を提供し、コミュニティ運営や技術イベントの未来像についても考察します

ソフトウェアエンジニアとして、常に「エンジニアとしてどう事業に貢献していくか」を考え続けてきました。技術力を磨くことだけでなく、その技術をどう事業価値に変換するか。この問いに向き合い続けた結果、私は「半歩越境」という独自のキャリア戦略にたどり着きました。

エンジニアでありながら：

• プロダクトマネジメントの視点を持つ
• ビジネス戦略の基礎を理解する
• デザインやUXの原則を知る
• マーケティングの基本を押さえる

これは「フルスタック」とも「ジェネラリスト」とも異なります。あくまでエンジニアリングという軸足は動かさず、必要に応じて隣接領域の「共通言語」を獲得していくスタイルです。

生成AIの登場により、ソフトウェアエンジニアの役割は大きく変わり始めています。

従来のエンジニア像

• コードを書くことが主な価値
• 技術的な深さが競争優位性
• スペシャリストが有利

AI時代のエンジニア像

• AIを活用して事業価値を創出することが主な価値
• 技術と事業の橋渡しができることが競争優位性
• 複数の視点を持つ人材が有利

正直に言えば、私のようなキャリアは長らく「器用貧乏」と呼ばれ、キャリアとしては不利だと考えられてきました。深い専門性を持つスペシャリストと比べて、市場価値が低いとされることも多かったのです。

しかし、生成AIの登場により状況は一変しました。AIが基本的なコーディングを担当できるようになった今、求められるのは：

• AIに適切な指示を出せる広い知識
• 複数の領域を横断的に理解できる視野
• 技術的な実装と事業インパクトを結びつける能力

まさに「半歩越境」してきた経験が、強みとして活きる時代になったのかなと思っています。

また、飲食店を経営する経験もしっかりエンジニアリングに生きているのでそういった話をしていきます。

JSer.info・textlint・jsprimerというプロジェクトを通じて、私は「書くことは読むことである」という理解に辿り着きました。
この発表では、興味本位で始めた日々の情報収集がツール開発を経て大規模プロジェクトの設計技術へ発展するプロセス、
読む→書く→伝えるの段階的変化についてお話しします。

まず「読む技術」として、JavaScriptの情報サイトである JSer.info （14年間で750記事）の更新を支える情報収集システムを紹介します。

• 参考: https://jser.info/2021/01/16/jser-10th/

次に「書く技術」として、読むだけでは物足りず「書いてみよう」と思った経験から始ったPromise本執筆時の表記揺れ問題をきっかけに作った、textlintについて紹介します。
書くことで増える読む量や、AI時代における文章品質の自動化の進化についても、textlintのMCP対応のデモも交えて紹介します。

• 参考: https://efcl.info/2022/06/29/why-create-textlint/

最後に「伝える技術」として、jsprimer という JavaScript 入門書を継続開発する際の文章設計について紹介します。
Design Doc による文章の設計、Living Standard アプローチ、既知→未知の原則、書きやすさより読みやすさを優先する設計思想などを扱います。
また、オープンソースとして100人以上がコントリビューターと参加してもらった仕組みやGitHub Sponsors/Open Collectiveによる経済も触れます。

• 参考: https://efcl.info/2025/05/24/tskaigi-2025-jsprimer/

大規模なプロダクトでは、lintや、use漏れチェック、使ってないファイルの検出といった、静的解析を伴う開発支援ツールが重宝されます。
しかし、存在するすべての記法を扱う必要のある汎用ツールでは、どうしても実行時間が伸びてしまったり、プロジェクト固有のかゆいところに手が届きにくかったり、といった課題がつきものです。
発表者が携わる、開発期間約10年・数十万行規模のリポジトリでは、近年注目されている"vibe coding"の考えを下敷きに、プロジェクト専用の軽量なツールを開発して、開発支援に活用しています。
本発表では、プロジェクト固有の静的解析ツールをAIとともに開発し、レガシーコード改善に活用する「バイブス静的解析」を提唱します。

静的解析を用いたツールのこれまで

• PPI, PPRを使った汎用ツールのおさらい
• 汎用的がゆえに、いかなるソースコードも正しく解釈しなければならない宿命
• ツールの実行時間増加への利用者側の工夫

バイブス静的解析のアプローチ

• プロジェクトに合わせた専用の静的解析ツールを「バイブス」重視、すなわち、勢いで開発する
• 完璧を目指さず、コードベース上で必要な表現だけに対応する
• AIの力を借りて、誰でも保守でき、壊れても機能開発の片手間に短時間で直せるものを目指す

ゴール

• 「バイブス静的解析」の考えを使って、新たなツールを勢い重視で開発できるようになる
• お手元のリポジトリから、数秒以内にuse漏れや不要ファイルといったエラーを検出できるようになる

私はあるスタートアップ企業で業界特化型のSaaSをRuby on Railsで開発しています。そのSaaSには店舗に予約する機能があり、当初はシンプルな空き枠計算ロジックだったのですが、創業3年目に顧客ニーズに応えるため、より複雑なロジックが必要となりました。動的計画法などを用いることでニーズを満たす機能は作れましたが、そのままでは十分な速度が出ませんでした。

「マルチスレッド化すれば良いのでは？」と考えましたが、そこでRuby（CRuby）にはGVL（Global VM Lock）がある事を知りました。新しいロジックは、複雑な組み合わせを計算するCPUバウンドな処理であったため、マルチスレッド化してもGVLの制約により速度改善は期待できないと分かりました。

本セッションでは、私たちが直面したCPUバウンドな処理の問題とそれをどう解決したのかについてお話しします。Webアプリケーションは一般的にI/Oバウンドと言われますが、急に特定の機能でCPUバウンドな処理が必要になるかもしれません。同様の課題に直面した際の参考になれば幸いです。

最近、大規模言語モデル（LLM）が急速に普及していますが、すべての分野でLLMが万能というわけではありません。例えば、金融やセキュリティといった高い信頼性が求められる業界では、回帰やブースティング系の "古典的な" 機械学習の技術が、今なお第一線で活躍しています。

その理由は、旧来の機械学習では「この取引は不正利用の可能性が80%」といったように確率を使って物事を予測したり、「なぜそのように予測値が出たのか」という理由を人間が理解しやすい形で説明できる点にあります。身近な例では、金融での与信スコアリングやカード決済や送金等の不正利用の検知などの "予測タスク" に機械学習が今でも使われています。

このトークでは、機械学習のユニークなポイントと私が機械学習を好きな理由について、過去に熱中して作っていた "競馬" を題材にお伝えします。勘や経験則、あるいは人間が地道に作るルールだけでなく、機械学習という道具を手に入れると、競馬の収支を改善するためにどのようなアプローチが可能になるのか？ 最近話題のLLMに尋ねるのとは、何が違うのか？私の過去の実践経験を元に、詳しく説明します。

機械学習について初めて知る人でも楽しめるよう、以下の流れでお話しする予定です。

• 機械学習の基本
  • 機械学習とは何か？特に教師あり学習について
  • 機械学習が使われている分野
  • 機械学習の利点と欠点
  • 機械学習のシステム構築の流れ
  • 最近の機械学習の潮流
• 競馬と機械学習
  • 競馬の簡単な紹介
  • 競馬に適した機械学習手法の紹介
• 競馬の勝ち馬予測モデルの作り方
  • 予測の元になるデータを集める
  • 予測の精度を高めるための特徴量エンジニアリング
  • 予測モデルの構築方法と評価手法
• 勝ち馬予測モデルの実践
  • 予測値の活用方法
  • 実戦での評価検証

いかにして速いWebフレームワークを作るかのテクニカルな話をします。JavaScriptランタイムで動くバックエンドWebフレームワークです。Honoを例に挙げます。

• 対象ランタイム - Cloudflare Workers / Deno / Bun / Node.js
• HonoはAOTを使わない実用的なフレームワークでは一番速い
• サーバーを立ち上げないベンチマーク
• 立ち上げるベンチマーク
• ベンチマークソフト - abを使わない
• 何もしないのが一番速い
• ランタイムの実装によって速度が異なる
• awaitすると遅い？
• JSONのパースを速くするには？
• Perlの知恵
• TrieRouterが遅くてRegExpRouterが速い理由
• 5つのルーターと3つのプリセット
• 小さいは速い
• クエリパーサを書く
• GitHub Actionsで継続的に速度を測る
• 一番最後に一度だけインスタンスを作る
• Node.jsアダプタの挑戦 - 2.7倍速くする
• AOT最適化
• 速いとは何か？

生成AIでのコーディングが当たり前になってきて、
一番楽しいところをもっていくんかい！と思っているソフトウェアエンジニアの方も多いと思います。

私自身、かつてはコードを書くことが一番好きなソフトウェアエンジニアでした。(今も好きです)
15年のエンジニアのキャリアの中で、コードを書く以外にもプロダクトをユーザーに届けるためにさまざまなことをやってきました。
顧客先データセンターでヘルメットをかぶり一人きりでPoCをしたり、トイレの屋根裏にラズパイを設置したり、
工場の録音データを1日中聞いていて頭おかしくなりそうになったり、目の前の問題を解決するために何でもやってきました。
また、自身が企画・開発提案の中心だった1億円以上かけたプロダクトが一つも売れなかった経験もしてきました。

時にはもっとコードを書きたいと思うことも。
その欲のままにコードばかり書いていると、もっと他の課題に取り組むべきでは？という気持ちになることもあります。
さらに、なんでもやってきたからこそ、自分でも器用貧乏だなあ、得意なことってなんだっけと思うこともあります。

「これってエンジニアの仕事なんだっけ？」と思ったこともたくさんありました。
課題を前に進めるため、あるいは、問題を解決するために、役割の境界を越えてなんでもやるうちに、
曖昧な状況でもとりあえずやってみる力が身につき、今ではそれがエンジニアリングの幅やエンジニアとしての考え方を広げる結果にもなりました。

本トークでは、「なんでもやる」ことで広がったことと成長できたこと、
そしてそれが現在にどのようにつながったかをN1の具体的な経験をもとにお話します。
エンジニアとしてのキャリアに悩んでいる方に改めて考えるきっかけになると嬉しいです。

急に「この開発、いつできる？」と聞かれることがあります。
仕様はまだ固まっていない。 決めないと見積もれないのに、決める時間もないし、そもそも決めきれるものでもない。 根拠の薄い数字を出せば後で現場が苦しくなり、「分かりません」と返せば会話が止まってしまう。 そんな状況は多くの人が経験しているのではないでしょうか。

私も何度もこの問いに直面してきました。 その中で実践してきたのは、適当な数字でもなく、過度なバッファでもなく、現場として納得できる見積もりとスケジュールを素早く示すことです。 それは、不確実度の高いプロジェクト初期の状況を使える情報へ翻訳する作業でもあります。
プロジェクト初期の見積もりと実績のずれを検証し、経験を重ねる中で、不確実性の高いプロジェクトでも不確実性を扱えるようになってきました。

このセッションでは、

• 不確実性のコーンを前提に、初期見積もりの誤差をどう扱うか
• ターゲット/コミットメント/見積もりの違い
• 急な見積もり、スケジュール出しの事例
  を紹介します。

急な「いつできる？」に対して、根拠を持ちつつ納得できる答えを出す。 そのための実践知を共有します。