プロポーザル

2025年春、毎日noteを100日間連続で書いてみました。
目的は「アウトプットの習慣化」でしたが、やってみると気づきがたくさんありました。

・承認欲求との向き合い方
・書き続ける中で見えてきた自分の「軸」
・誰かのために書くことの意味と限界
・noteという“半分パブリック”な場所が持つ絶妙な距離感

「100日書く」という行為そのものよりも、その過程でどう気持ちが揺れ動き、何が残ったのかを中心に話します。
今まさに情報発信やアウトプットに迷っている人、自分の声の届け方を模索している人に、ちょっとしたヒントになる話ができればと思っています。

日常でコミュニケーションを取らない日はない、と言っても過言ではありません。
一方、コミュニケーションで「言っておきたいこと」を適切に伝えるのは難しいと感じることはありませんか？
例えば、ミーティングで「コレ、聞いてええんかな？」と躊躇したり、ふりかえりの場で「アレを言いたかったのに…」と後悔したり、あるいは、ネガティブなことを伝えるにはどうすればいいんだろうか？と悩むこともあるのではないでしょうか。

このトークでは、そうした「言っておきたいこと」を、どのように考え、どうすれば伝えられるようになるのか、そのための「技術」についてお話しします。

アジェンダのイメージ

• 「言っておきたいこと」は何のため？
• 自分が言うべきなのか？
  • 自分が言わなきゃ誰が言う？
  • 代打依頼、悪魔の代弁者
• 何をどのくらい伝えるのか？
• どうやって伝えるのか？

2025 年 6 月某日。
「条件付き書式で色を塗りたいんだけど」
そんな軽い相談をきっかけに聞き出した要件は、結合セルだらけの “人間にはやさしいが機械には地獄” なスプレッドシートから、予定・人物・イベントが複雑に交差する三次元構造のスケジュールを可視化したいというものでした。

二次元の表に三次元の情報を押し込むという、物理的に無茶な要件を前に、他称スプレッドシート職人の私は腹をくくることになりました。

この発表では、2025 年の今、もはや業務でも趣味でも避けて通れない道具となったスプレッドシートの限界と付き合いながら、Google Apps Script、QUERY 関数、MAP 関数、LAMBDA 関数、スピル、条件付き書式などを駆使して、依頼者の求めるものにたどり着いた過程を、実際に使った関数や考え方とともにお話しします。

10年代初頭より「プログラマが知るべき97のこと」をはじめ"97"をキーワードとする名著が出版されてきました。

2011年頃「IT勉強会」の人たちが「ぼっちが懇親会でするべき97のこと」 大喜利を当時Twitter #97bocchi ハッシュタグで行っていました。 https://togetter.com/li/140804 としてまとめを読むことができます。

それから10数年...令和に入り、エンジニアたちもその取り巻く環境も変化したものの、未だ交流の場における"ぼっち"不安は人々の間にあり続けています。例えば「登壇すればぼっち回避」などのハックが人口に膾炙していますが、実感として確実ではありません。

わたしは当時の大喜利参加者として、また登壇・運営・主催・スポンサーなどのロールを持ってきた経験から、懇親会や交流の場で得るものを最大化するためのカンファレンス参加戦略をお話します。

昨今、「テクニカルPdM（プロダクトマネージャー）」というロールが注目を集めています。

私自身、新卒から10年以上にわたり独立系中堅SIerのリードエンジニアとしてキャリアを重ねてきましたが、2025年4月に突如として事業会社のテクニカルPdMへと転身しました。

この「大吉祥寺.pm 2025」が開催される頃には、転職から約5ヶ月が経過したところ。
まだまだ駆け出しPdMではありますが、エンジニアからテクニカルPdMへロールチェンジしたリアルを、等身大でお伝えできればと思っています。

想定しているアジェンダ

• 簡単に自己紹介
• SIerと事業会社の働き方の違い
• PdM / テクニカルPdMってどんな仕事？
• 転職活動について
• エンジニアバックグラウンドだからこそ活かせる強み
• 逆に弱み、苦労していること
• まとめ（これからPdMを目指す人に伝えたいこと）

入社80日で取締役に就任し、組織コンディションに難のある状態からの建て直しに挑んだ1年間で得た結論は「会社経営の8割は兵站」でした。本セッションでは『戦略は兵站を磁化し、兵站は戦略を作る』を軸に、企業文化の再設計、Valuesの見直し、採用・オンボーディング・評価制度を貫く磁化ループの構築等、兵站のケイパビリティ向上に向き合った「HARD THINGSがブッつづく」1年をみなさんと振り返りたいと思います。B面タイトルは『人のHARD THINGSを笑うな』。

ClaudeCodeの性能はすさまじく、ついつい大袈裟に驚いてしまいそうです。
一方で、ある程度コードベースが育ってくるとなんの工夫もなしにはうまく動かず、「当てずっぽう」の変更を繰り返して、
tokenをもりもり食べながらガンガンコードを壊していく、パンクスのような挙動をすることもあります。

わたしは、ClaudeCodeを使い、「自分でコードは一切書かない」縛りで、20,000行を超える（プロポーザル提出時点）コードベースを開発/機能追加/保守しています。
「タスクの一部をやってもらっている」「小規模なアプリをVibeCodingした」という例はたくさんありますが、この規模をすべてAgent Codingしている例はまだ少ないのではないでしょうか。

このトークでは、事例を通じて得た発見を共有します。エモい未来予想や煽りはなるべく排除した、実際的な話を目指します。

CTOの仕事に定義はありません
定義のない仕事にまつわるナレッジをお話します

多くの職種では「何をどのようにするか」といった業務内容はある程度決まっています
だからこそ組織は具体的な業務を指示できます
しかし、組織のトップに立つと状況は一変します

私は今年4月にCTOに就任しました
組織の規模は300人を超え、一般的には推奨されない着任の仕方です

着任当初は苦労の連続です
右も左もわからない中、どんどん埋まるスケジュール
バリューを発揮できない自分への葛藤
何を誰に聞けば答えが見つかるかはわからない模索
「自分が何をすべきか」を誰も知らないという現実

CTOに求められる役割は組織によって大きく異なります
そして、求められるバリュー（未定義）の発揮には組織の仲間のサポートが必要です
本トークではCTOに限らない定義のない仕事を進めるノウハウや考え方、必要な組織の支援をお話しします

初めまして。モブエンジニアです。

ライトニングトークと言われて「稲妻のように素早く話す」イメージを持たれるかと思います。
もちろん、ライトニングトークを山のようにこなしてきたベテランであれば本当の意味での「ライトニングトーク」を行ってもうまく盛り上げられます。

ただし、初心者の方がいきなりベテランのやり方を真似すると「なんかうまく話せないな」といった課題に直面してしまいます。その断面から、初心者の方だからこそ「うまくライトニングトークを取りまわせる方法」についてお話ししたいと思います。

【対象者】
1.ライトニングトークに対して苦手意識を持っている方
2.これからライトニングトークへチャレンジしていきたいと考えている方
（3.私の句を聞いてみたい方）

【持ち帰ってもらいたいこと】
1.ライトニングトークは自己を知ってもらうためのツール
2.ライトニングトーク前の準備ですべてが決まる

初めまして。モブエンジニアと申します。

ChatGPT、Claude含む生成AIサービスを通じて、コーディング・設計含むさまざまな業務が効率化していっています。
そのうえで、「技術者として生き残っていくために何を行わなくてはいけないのか」といった課題に直面していると思います。その断面から、「セルフブランディングの視点」から技術者の生き残り戦略について、15分のトーク内でお話ししていきたいと思います。

【ターゲット層】
1.SNSでのセルフブランディングに悩んでいる方
2.AI時代に技術者として生き残る方法を模索している方
（3.私の句を聞きたい方）

【持ち帰ってもらいたいこと】
1.セルフブランディングはツールであり目的でない
2.キャラ付けは日々ブラッシュアップさせていく
3.X・勉強会をうまく活用していく

今年、今までの畑であるエンジニアの世界から距離を置き、営業組織やCSなど、様々な組織と連動して事業を推進する「事業推進」といった役割に転生しました。

日常的な会話が横文字中心の世界から一転、「事業数値」や「原価」、「販管費」など、数字と漢字だらけの日常へと変化しました。

昨今、AI が世間を賑わせ、より職能越境のニーズが高まっています。
今回はその一例として、私が全く畑違いの業務で途方に暮れた数ヶ月と、そこから Cursor を相棒に構築した下駄履き戦略をお話します。

2025年の今、AI Agentは開発だけでなく、職種転換の強力な補助輪にもなります。
「技術は好きだが事業数字はさっぱり」という方、「AI活用で新しい領域に挑戦したい」という方に、具体的な手法と勇気をお届けします。

この技術変遷の激しい時代、借りれる下駄はどんどん履いて、新しい挑戦への切符を手にしましょう！

某エンタープライズ子会社で情シスをしているフクイです。
クラウドからアジャイル、SaaSからプロジェクトマネジメントといろいろなコミュニティに顔を出しているおじさん（もうすぐじいさん）です。

2022年の登場以来、生成AIの進化は凄まじい限りです。
最近ではエージェントとかリサーチなどの新しい機能がいろいろなところで人々の仕事を変えていっています。
先日DeepResearch機能を使用して競馬の宝塚記念を予想してもらったら、ものすごく緻密に情報を集め、集めた結果の情報から緻密な予想を立ててくれました。しかも穴馬のメイショウタバルが来て見事的中！

ここで考えてみたら、競馬の予想をする人の仕事の「価値」の大きなひとつである「一般の人よりも時間を掛ける事によって産んだ価値」が生成AIによって失われてしまったことを意味していることに気が付きました。そこからの考察です。

納期や品質のプレッシャー、大きな責任、はじめての挑戦。

こういったものは、人によっては辛くて、楽しくないかもしれないです。

一方で、諸条件さえ整えれば、結構楽しめるものです。成長すればするほど、そうしたプレッシャーのかかる場面が増えます。

自分自身のメンタルを健全に保ち、継続して仕事を楽しむために、責任とプレッシャーとどう向き合うといいか、を語ります。

ITエンジニアにとって、人に話を聞かせることは大事だと思う。
どんなにスキルが高くても、話を聞いて貰えなければスキルを役立てることは難しいです。

実際に話を聞いてもらうにはどうすればいいか。
これを、ヘルプデスクの経験とデータ解析の視点から実践できるノウハウとしてお伝えできればと思います。

......という建前のもと、ただ壇上に立って話たいだけです。
みんな！オレを壇上に立たせてくれ！！

私は去年の4月にプレイングマネージャーとしてEMになり、今年の4月からはEM of EMsとして専任EMになりました。この1年間で経験したロールチェンジは、思っていた以上に「持つべき視点」や「こだわりポイント」、「得られる喜び」を大きく変えるものでした。例えば、かつては「一つ一つの機能を作ってリリースする楽しさ」を感じていた自分も、今では「半年や一年などの期間を通じてどれだけアウトカムを作り出せたか」ばかりを気にして、個々の開発へのこだわりやそこから得られる喜びが薄れてしまい、少し寂しく感じています。

この考えも揺れ戻しで1年後には違うことを考えているかもしれませんし、今の考え方に染まってしまい寂しさすら感じなくなるのかもしれません。このトークではロールチェンジの真っ只中な今だからこそ感じる変化を、リアルなエピソードを交えてお話しします。キャリアに悩んでいる人への参考になれば嬉しいです。

本トークでは「技術を磨きつつ、長く豊かなキャリアを築く」ための指針を提示します。
特定の技術習得だけでなく、「心のあり方」と「学びの姿勢」に焦点を当て、「足るを知り、流れに身を任せ、循環を意識し、自分軸を持つ」という考え方を軸に、持続可能で充実した働き方を提案します。

おもな内容

• 「満ち足りる心」でコードと向き合う
  • 完璧主義を手放し、「ちょうどいい」価値を届け、心の豊かさを感じる開発姿勢。
• 「流れに身を任せる」学びと成長
  • 情報過多に疲弊せず、自身の興味やプロジェクトに合わせた「自然な学び」を追求。
• 「恵みへの感謝」と「循環」の精神
  • チームやコミュニティへの貢献を通じ、知識や助け合いの「良い流れ」を生み出す。
• 「比較を手放し」、自分だけの価値を見出す
  • 他者との比較から解放され、あなた自身の「情熱」を原動力とするキャリア形成。

開発が思うように進まず、チームに閉塞感が漂う。そんな経験はありませんか？
「誰かがやってくれるだろう」と感じてしまう時、その根底にはチームから「自分ならできる」という自己効力感が失われているのかもしれません。

本セッションでは、かつて停滞していた私たちのチームが、小手先のプロセス改善では越えられなかった壁をいかにして乗り越えたか、その「軌跡」をお話しします。

転換点は、技術的な特効薬ではなく、チームの「オーナーシップ」を再構築することでした。
一度立ち止まってUI/UXから要件を再定義し、「動くもの」を囲んで対話する。
そのプロセスを通じて、メンバー一人ひとりの「自分がやる」という思いがチームの推進力に変わっていきました。

この「軌跡」の共有が、皆さんのチーム、そしてあなた自身の「次の一歩」を踏み出すための具体的なヒントと勇気になれば幸いです。

心のどこかで最後は自分が何とかすると抱え込み、気づけばプロジェクトのボトルネックになっていた私。メンバーからも頼りにされていないと感じられてしまうこともありました。

そこで、私はチームメンバーへ「みんなを頼らせてください」と宣言しました。

ここに至るまで非常に葛藤がありました。リーダーが頼ることは、弱さをさらけ出すことだと思っていたからです。
しかし、頼ることは決して弱さではなく、むしろ強さであると気づきました。

当セッションでは、この決断に至るまでの経緯、その結果どのような変化が自分やチームにあったのかをお話しします。
「自分が頑張ればなんとかなる」と思いがちな方、リーダーとしての重圧に悩んでいる方などに、抱え込みを減らすヒントとなれば幸いです。

話すこと

• なぜ抱え込むリーダーになるのか
• 決断までの葛藤
• 決断後に起きた変化
• 頼ったうえでリーダーとしてやるべきこと

「トム・デマルコ」という名を、もしくは「ピープルウェア」の書籍名をご存知ではないですか？
多くのクラシックを生み出し、様々な影響を与え続け、氏の記述が引用されている場面は数知れません

そんなデマルコの書籍から、日本語で読めるものを「8選」紹介します！
初めてのデマルコに、あるいは知らなかったデマルコに出会うきっかけになれば幸いです

動機

プロジェクトの成功を探求する中で
「構造化分析」に始まり、昨今は「やる気」「ゆとり」と、主題や切り口が変遷してきたのがデマルコです
そうした変化を辿るのは、ますます変化が激しくなる今日を生きる我々のヒントになるのではないでしょうか

触れる書籍

• 構造化分析とシステム仕様
• ソフトウェア開発プロジェクト技法
• ピープルウェア
• デマルコ大いに語る
• デッドライン
• 熊とワルツを
• アドレナリンジャンキー
• ゆとりの法則

先日開催されたJJ〇G CCC 2025 Springにて、「イベントストーミングから始めるドメイン駆動設計」というテーマで45分間の登壇をしました。…が、結果は壮絶な時間配分ミス！
準備万端のはずが、核心部分を大幅に端折り、伝えたいことの半分も伝えられず不完全燃焼で幕を閉じました。
なぜこんな悲劇が起きたのか？本LTでは、この苦い経験を赤裸々に語り、敗因分析と、そこから得た教訓を共有します。「話したいこと」と「伝えられること」のギャップ、リハーサルの重要性など、登壇者なら誰しもが直面する可能性のある問題を、笑いと涙（主に私の）と共にお届け。この失敗談が、皆さんの今後の登壇活動、そして不測の事態への心の準備の一助となれば幸いです。そして宣言します、このリベンジはブログで果たす！…予定です！