2025年の振り返り（yy_yank）

2025年の総括

今年の総括をすると もがいたけど、いろんなことがうまくいかなかった1年だったかなと思う。 まぁ、それでも死なずに生きてこれたから良いかなと思う。それに、別に何も成果がなかったわけではない。だけど、自分の力不足は痛感したような1年だった。

1月:仕事がソフトウェアエンジニアではなくなった

今年からエンジニアではなく、ビジネス職で働いていた。 1月からマーケティングを本業としつつ、営業活動の支援をするというような立ち位置だった。あと、事業の立て直しの全力サポートみたいな、名前の無い活動もやっていた。

このブログの名前が「プログラマのはしくれダイアリー」なので、エンジニアではない自分がブログを書くことが気持ち悪く 「ソフトウェアエンジニアやめました」を書いた。 これが予想外の反響で、はてブとかTwitterとかの反応があり驚いた。 実際は、たぶんタイトルほど衝撃的な内容じゃなくて、キャリアの振り返りみたいなものだったんだけども。 1月に書いたブログ：ソフトウェアエンジニアやめました

2月：キツい案件とツイ廃

あまり記憶がないがX（Twitter）では、いつも通りダジャレを呟いてたらしい。 仕事で2025年で一番キツい案件があり、結構心身ともに辛かったが、周りの助けもあって、なんとか収まったというのは印象残っている。 2月に書いたブログ：ケント・ベックは水を飲む

3月：大変な案件

ここもあまり覚えていない。ここも仕事ででかい山場があったのでそれを乗り越えるのに必死みたいな感じだった。 3月に書いたブログ：仮claspぐらしのアリエッティ

4月：燃え尽き気味

2月と3月の仕事の山が大変だったので、一瞬燃え尽きた。 4月に書いたブログ：どれ使えば良い？たくさんの生成AIに囲まれたおれたちは

5月：協働する難しさ

ここもあまり覚えていない。若干の余白が生まれたタイミングだったので、各チームと連携していろんなことをやろうとしたが、色々うまくいかなかった。そのあたりは多分自分のブログのコミュニケーションに関する部分とか、組織に関する部分とかに現れてるかもしれない。 5月に書いたブログ：リモート前提のまま変わらない組織

6月：忙しすぎたのでAIや自動化で遊ぶ

「誰のための自動化？」というブログを書いたりしてた。Selenium/Playwrightの自動化と格闘しながら、AIエージェント（Copilot Agentモード）にGASを書かせてで遊んだりしていた 6月に書いたブログ：誰のための自動化？

7月：引き続き大変な案件続き

ここもあまり覚えていない
しかし、今年は6月からずっと暑かったのが異常だったのだけ覚えている。とりあえずマーケティング職で大変な案件続きで、それに必死ではあった。 7月に書いたブログ：なぜノーコードツールは売れるのか？

8月:ぎっくり腰との戦い

8月15日にぎっくり腰を発症して、歩き方画像を複数投稿するという悲劇的な展開。基本的な歩き方からラクな歩き方発見まで、リアルタイムで報告してた様子が痛々しい。

8月に書いたブログ：「コンテキストをすくい上げて育てる」のが良い会話だとわかってきた

9月：組織の転機

案件数が多くとにかく忙しかった。 組織的にも方向性など転機があり、事業としても落ち着いてきたかなというタイミングだった。 この頃から、ビジネス職での役目を一旦置いておいて、エンジニアに戻るか？俺は何者なんだ？というようなところを考えるようになった。 その結果、社内異動など考え始めた。社外の人にキャリア相談をしたりもするようになった。 9月に書いたブログ： ・業務を兼任することになった時にやってたこと ・そうは言ってもHowは大事

10月：ぎっくり腰再び

月初にまたしてもぎっくり腰を発症。 「ワークライフバランスの鍵は腰を守ること」という投稿がLikes 9で月内トップになるほど共感された。コルセットのおすすめもしながら、体の大切さを痛感した月

「手戻りなんてないさ」というブログ（おばけなんてないさのオマージュ？）も投稿

Kotlin Festは無事開催されたみたいだけど、今年は何も運営協力できなかったので申し訳ない。

とにかく忙しかった。 10月に書いたブログ：手戻りなんてないさ

11月:Podcast再開とAI深掘り

ずっとサボってたPodcast配信の再開。Claude Code、Codex、MCP、デジタルタトゥーなど、複数回にわたって配信した。AIと新卒の仕事についてのブログも投稿して、「プログラミングの機会が奪われる？」という問いと向き合った

とにかく忙しかった。 11月に書いたブログ：新卒ソフトウェアエンジニアがAIに本当に奪われるのものは「プログラミング機会」

12月:新ブログ開始と年の瀬

実は社内異動の他のオプションとして、転職活動をしており、それが落ち着いたのが12月中頃だった。
仕事としても年内やることは落ち着いた。 自分の進路やキャリアを悩む時間が長かった。 ということで来年から別の会社で働く予定なのですが、また改めてその話はします。

年末の大きな動きは、12月30日のはてなブログ開始。「ヤンクの毛刈り∴yank shaving」というタイトルで。yak shaving縛りかも。 12月に書いたブログ：タネも仕掛けも見せないで 12月に始めた新ブログ「ヤンクの毛刈り yank shaving」：はてなブログ始めました

まとめ:変化と継続の一年

2025年は「ソフトウェアエンジニアやめました」で始まり、新ブログ開始で終わるという、変化に満ちた一年だった。キャリアの内省、生成AIとの本格的な格闘、2度のぎっくり腰、Podcast再開と、大小さまざまな出来事があった。それでも一貫してたのは、ダジャレと自虐ユーモア、コミュニティへの愛、そして技術と真摯に向き合う姿勢。AIにコードを書かせながらも人間の役割を考え続け、疲れながらも娘の成長に癒され、腰痛と戦いながらも前に進んだ

↑は、Claudeによる分析。結構あたってると思う。確かにこんな感じだったかな〜。

2025年の目標を振り返る

年の初めに立てた目標は3つあった。

• とにかく生きる！家族を大事にする。関わる人すべてを大事にする
• ブログを継続する。毎月ブログを書く
• 大きい何かインパクトを残したい。新しい挑戦をして結果を出したい

生きることと家族を大事にすることは達成できた。友達ともしっかりいろいろ話せたし、人並みに良いことも悲しいこともあった。

ブログも毎月書き続けることができた。

ただ、大きいインパクトは出せなかった。挑戦は色々したけど、自分へ期待してたような結果には届かなかった。自分を見つめ直して考えて。もがき続けたのが2025年だった

2026年の目標

来年の目標も4つ立てた。

• 健康で居続ける。2026年も生きる
• 着実に仕事で成果を出す
• 無駄なものを何か捨てる
• ブログを毎月書く

身体が資本。健康を維持しながら結果を出す。
選択と集中。無駄なものや執着がつよいものを手放す。ブログを習慣として続ける

こんな感じです！
来年も皆さんよろしくお願いします

タネも仕掛けも見せないで

答えに「価値」がない

最近は、ネット検索でも、GeminiでもChatGPTでも何でもいいんだけど、ちょっと調べればもう一瞬で答えが出るという時代になってきた。以前から、Google検索したら答えは出るっていう世界だったが、それに加え最近はAIにいろんなものを聞けばすぐに答えが出る。（とは言っても、AIは嘘をつきますが。それはさておき）

それらしい答えだったり、一般的な答えの価値ってのがどんどん下がってるっていうのは常々見聞きする。よく言われる言葉だと、コモディティ化。いろんなものがコモディティ化している。

AI・AIエージェント食傷

AIとかAIエージェントは、技術的なトレンド、新しいものとして出てきてる。しかし、AIを使うとかっていう面に関しては、もうそれもある種コモディティ化してる。

だって、チャットを使ってAI活用するみたいなことは、誰でもやるみたいなことになってきてるから。

もっと言うと「開発にAIエージェントを使う」ことや「企業が、AIエージェントを実サービスに入れていく」みたいな動きも、もうみんなやり始めてるという。それも一個の戦略手段として当たり前になってきてるっていう感じ。

もうええわい（AI）を超えられるか

それが実際の収益になったりとか、事業として成立したり組織の生産性をあげたり。そういう意味でまだまだ発展途上ってところはあると思うんだけど、これもコモディティ化の"兆し" が見えてきてる。

ここに関する見解は人それぞれになると思うんだけど、それを超えて、ゲームチェンジ的な大きな波を起こせるかどうかっていうのが大事になってくる。乗るしかないこのビッグウェーブに。

まだ、こけるかどうか。乗るかそるかみたいなのが各組織、各サービスわかんないところかなと思っていて。ちょうど今日、見聞きした言葉を借りれば、「インターネット的な普及をするのがAIなのかどうか」っていうことになってくる。

インターネット級の変化は来るのか

2025年の今ある常識を、5年後10年後覆して「もうAIやAIエージェントが生活の一部になる」みたいな、未来になるのかどうか。

AIエージェントとかAIを使ったプロダクトサービス群が、日常に必要不可欠な状況で価値を届けているのか。

そういう世界になるかっていうところ、そこをつくっていけるのか、みたいなところもある。
そこも、やりようとかやりがいはあるなと思いつつも、ある程度答えが見えてきてるなというか。

「見えない問いを探れば出せる答え」は山が低い

「見えない答えを探る」って行為があると思う。
いわゆる、仮説を立ててとか検証したりとか。戦略を作ったりとか。そのあと色々また分析したりだとか。

そのサイクルを回せばAIエージェントでうまくいくっていう未来もいろんな企業であるんじゃないかなって思う。ある程度のその未来が見えてきてるなと思ってて。それも未来が見えた瞬間に僕は予定調和だなって感じてしまう。

つまり、AIとかAIエージェントとかの、築ける山のてっぺんが見えてしまいそうな空気感を僕は感じてしまっている。

てっぺんの見えない山

てっぺんが見えるのって面白くないですよね。各社「見えない山」を築いて欲しい。

つまり「予定調和じゃないものをいかにつくれるか」ということ。

「これは予想の斜め上を行ったわ！」っていうのをでみんな驚かせて欲しいなという。誰が言うてるねんて話ですけど。

「SaaS×AIエージェント」のワンパターン化

SaaSももうオワコンだオワコンだとか最近は言われるけど、SaaSに関しても

• SaaSへAIエージェントを組み込む
• 独自データやカスタマイズで付加価値をつくる
• コンサルやBPaaSなどもやる
  みたいなのが、ある程度各社やりだしてワンパターン化してるんじゃないかなみたいな風にもみえる。多分そういう動きをしてる会社が十数社はある。

別にそれを非難したいわけじゃないし、それを真剣にやってるとか実行してることって素晴らしい。
でも「そのパターン見たわ！」と思えてしまうと若干興ざめしてしまうみたいなところがある。

種も仕掛けも見せない魔法をつくる

つまり、マジシャンとか手品で考えてみて欲しい。手品の種が見えちゃうと、やっぱ冷めちゃう。なんとなくその種とか仕掛けが透けて見えてきてるような気がして、「もうそれはいいかな」って食傷気味になってしまうっていう。

なので、僕は予定調和じゃない、種も仕掛けも分からないところに突っ込んでいければいいなっていう風には思う。

もっと大きな山を狙いませんか？

新卒ソフトウェアエンジニアがAIに本当に奪われるのものは「プログラミング機会」

はじめに

最近、ポッドキャストで「AIは新卒ソフトウェアエンジニアの仕事を奪うのか」というテーマについて話してみた。この問いに対する僕の答えとしては「細かな作業は実際奪われていくかもしれないが、レビューや意思決定といった部分は残るので、新卒ソフトウェアエンジニアであっても仕事は完全には奪われない」という結論になった。

しかし、それを話してみてからもう少し考えてみたくなった。

奪われるのは「仕事」ではなく「機会」

実は、「仕事」ではなくて「コーディングする機会そのもの」が減ってるんじゃないだろうか。それはつまり、学びの機会がAIに奪われているともいえる。

これは、昔あった「IDE使うな論争」に近いかもしれない。VS CodeやIntelliJ IDEA、Eclipse、Xcodeなど、いわゆる統合開発環境が登場した時、コード補完が出てきたり、右クリックでインターフェースの実装を自動生成してくれたりする機能を「使うな」という派閥がいたわけだ。

初めにコードを自分の手で書いてから、理解した上でIDEで楽をするという手順を取るのが大事だと言っていた人たちがいた。そして今、AI時代において同じような構造の問題が起きているのかもしれない。

AI エージェント時代の到来に感じる馬鹿らしさ

Claude Code、Codex CLIなどAIエージェントが出てきた時、ほとんど自分がコードを書かなくて済むし、イエス・ノーだけの世界になったり、レビューをするだけの世界になる。そうすると、実際にタイピングしたり、どういうところでコンパイルエラーが出たりとか、どういう補完をするといいとか、コーディングをする上での基礎体力というのは奪われてしまうかもしれない。

結局、どういうプロセスか（自分でコードを書くかAIが書くか）に関わらず、いい機能を作ったり、プロダクトを作ったり、ソフトウェアを作ったりというところでは変わりない。しかし、どうしても自分でプログラムをする機会が減るので、その基礎体力的なところは如実に減ってしまう。

仕事云々よりも、そのコードを書く機会が奪われるというのが一番困りそうな気がする。AIが楽に書いてくれるんなら自分で書くのは馬鹿らしい。過去もそうで、IDEが気を利かせてやってくれるのに、わざわざ全部手書きで書くのも馬鹿らしい。

新卒とベテランの違いは、この機会損失

だから、新卒にとって本当に奪われるとしたら、仕事が奪われるというより「プログラミングをする機会」。自分でコードを書くというチャンスが取られちゃっている可能性がある。

一方で、一通りコードを散々書いてきたシニアエンジニアやスタッフエンジニア、ベテランと言われるような人たちにとっては、「もう一通りコード書いたから、そこはAIにやってもらっても別に構わない」という人もいるかもしれない。

技術発展と「強制ギブス」の矛盾

AIが作れない部分。その残ったところでオリジナリティを出したり、判断をしたりということになると、より原始的なタイピングとか、コードを書くとか、いろんなメソッドを探索的に調べて、どのメソッドを使うこと（言語組み込みのビルトインのライブラリとか何を使うとか、外部のライブラリー何を使うとか）という細かいことからだんだん離れていくような気もする。

でも根本的には、やっぱりその発達した技術を使わないで、そこを使わない、禁止してやるっていうのはすごく時代に逆行している。IDE禁止だとか、ラムダ式禁止とか。新しいテクノロジーや技術が出るたびに禁止したり、逆に良くないみたいな言説や主張が生まれたりするわけだ。

ただ、IDEとかはアシストなのだが、AIエージェントとかってなってくると、アシストを超えてもう勝手に動いてくるわけなので、そういうコーディングの機会というのは如実に奪われていっているのかな、というところ。そこが、多分そのシニアエンジニアやスタッフエンジニア、ベテランに比べると、新卒のソフトウェアエンジニアの方がダメージがでかいんではないかと思う。

では、どうするか

1. プロダクト全体を見る力を磨く

一つは、思い切って一気通貫でアプリを作るとか、プロダクトを作るというディレクター的なところや、プロダクト自体を全部見るというところに振り切る。そのキャリアを早く進むことが、いろんな人ができるようになったかもしれない。

2. 仕事以外でコーディングの機会を作る

一方で、そのコーディングをする機会は奪われているので、仕事以外の機会で自分でコードを書いてみる。例えば、本や教材であるような「コードを自分で書いてみましょう」というエクササイズをAIなしでやってみるというのは部分的にはありかもしれない。

あとは競技プログラミングと言われるような、いわゆるコードを書くこと、自分だけで書くことも目的にした問題に取り組んでみる。

※競技プログラミング界隈もAIに対してどういうレギュレーションを作ってんだろうなとか、地味に気になるところではある。

3. 時々はAIに頼らずに書いてみる

仕事以外でそういった機会を作るか、時々はAIに頼らずに仕事でも書いてみるとかをしないと、仕事で磨かれていっていたはずの部分が、新卒のソフトウェアエンジニアだと磨かれていかないのかもな、というところはあるのかもしれない。

「プログラミング」の"価値"

AIというテクノロジー自体は全然いいのだが、一番それが新卒のソフトウェアエンジニアとかキャリアが浅い人にとってのダメージになるような気もする。それか、プログラミングを自分で書くこと自体の価値がどんどん下がっていくのか。そうすると、その価値というのは下がると判断して、そこはバッサリと諦めるとか割り切るというのも一つの手なのかもしれない。

低レイヤーと高レイヤーの往復

でも結局、根本的には原理原則とかコアな部分——例えばカーネルがあってOSがあってとか、CPUがあってとか、その上でアプリケーションが動いているとか、高級言語というものがあって、コンパイラがあってとか、インタープリターがあってとか、いろんな処理系があるとか——そういうところ、さらにコーディングは手で書いたりもできて、さらにそれを便利にするためにはIDEがあって、いろんな情報があって、それをAIがまとめている。それらをあたかも人間が書いたかのようなコーディングができるという風に、より低レイヤーから高レイヤーになってきている（AIは単純に上位レイヤーとは言えない別文脈のものだけれども）

結局、その何層にも重なっている深い構造が理解できないと、問題が解決できなかったり、分からなくなったりする瞬間も多くなってきそう。

なので、よりAIに踊らされやすいとか、その表層的な部分しか見れなくなってしまうというリスクがある。

常に手で書けとか、そういうところは考えなくていいと思うが、一度は自分でコーディングしてみるとか、OS作ってみるとか、パソコン組み立ててみるとか。

レイヤーを下げるとか、低レイヤーに潜り込んだり、元のレイヤーに戻るという往復をして、より具体的なところとか、コアな部分を見る。それを見た上で、より今やっていることが何なのかというのを改めて理解するというような行き来、往復みたいなのは大事なのかなという気もする。

おわりに

実際、新卒のソフトウェアエンジニアの世界でどういうことが起こっているのか分からない。

むしろAIが入ったことによって学習サイクルがめちゃくちゃ速くなって、新卒の1年目にして超ベテランだったりとかという人がいっぱい生まれてたりする可能性もあるし、学生時代、就職前からすごいプロダクト作ってる人もいっぱい増えているかもしれない。

そこが楽しみでもあり、どうなっているのか知りたいところでもある。

手戻りなんてないさ

手戻りといえば、一度転職してから元の会社に戻ること…いや、それは違う。これは「出戻り」だ。
よく手戻りと出戻りを混同している人がいるが、毎回気になるところではある。
まあそれは置いておいて。

手戻りというのは、いろんな工程を踏んでやったのに、またやり直しになることを指す。

手戻りとは、作業工程の途中で問題が発生し、
前の段階に戻ってやり直すことを指します。

https://aippearnet.com/column/glossary/temodori/

手戻りという捉え方の問題

しかし、これって結構難しい概念だと思う。
手戻りという言葉を使ってしまうと、全部却下されてやり直しになるような印象、プロセスの逆流のようなイメージを受ける。 でも、そうやって捉えてしまわない方がいい場面も結構あるんじゃないかと思う。

例えば

• ドラフトやアイデアを作る
• レビューする
• 実装する
• テストとかレビューとかする
• 「じゃあこれでやっていきましょう」とリリースする

その途中、リリースのプロセスだったり、実装し始めてからのプロセスで何かフィードバックをもらって、そのポイントの調整・やり直しが必要になる。これを「手戻り」として受け取ってしまうとする。

フィードバックサイクルとの区別

でも、よくよく考えると、実はこれってフィードバックサイクルの一環なんじゃないだろうか。

これを仮に手戻りと呼んでしまうのであれば、イテレーション開発とかアジャイルとかスクラムとか呼ばれるものは、全て「手戻り開発」であると言えてしまう。 実はこの手戻りをただ素早くやっているだけなのである（我々は、手戻り開発をやっていたのだ！）

だから、手戻りという言葉はあまり使わない方がいいんじゃないかと最近思う。

どうしてかそう思うかというと、そこまで重くないことのやり直しで手戻りと感じるというのは、多分、各プロセスを重く置きすぎだからなのかもしれない。それはウォーターフォールがやってきたことだ。

フィードバックサイクルと真の手戻り

僕は最近、本当に全く同じ作業をやり直すという、まさに「手戻り」というのを経験した。
おそらくこの、「問題が見つかって、本当に全く同じ作業をもう一回ゼロからやる」ということこそが手戻りなんだと思う。

だから、それと、フィードバックループやPDCAサイクルというのは混同しない方がいい、ごちゃ混ぜにしない方がいいと思う。

フィードバックを引き出すプロセスづくりが大事

いや、もちろん上長だったりリーダーだったり、ビジネスメンバーだったり申し訳なさみたいなのあると思う。

「こう出来ないですか？」と言うのはやり直しや調整のお願いではあるので。

でも、この「申し訳なさ」を感じさせてしまっていると、いいフィードバックなんかもらえないじゃないですか。言ってくれなくなるのでね

一度立ち止まって考えてみてもいいかもしれない

結局、手戻りというのは、起こったフィードバックだったり、この変化の適用というのをネガティブに捉えてしまう言葉かもしれない。それは勿体ない。

「手戻りなんてないさ」と言いつつ、本当の手戻りというのは真の意味で存在する。でも、ほとんどの場合は手戻りと捉えてしまっているだけで、本当はただのフィードバックサイクルなのかもしれない。
プロセスの逆流がなるべく発生しないようにするのは、進め方として気をつけたほうが良いですけどね。

まとめ

ということで簡単にまとめます。

• 手戻りというのは、行った作業を全く同じようにもう一回やり直すということ、その工程が繰り返されること
• 一方で、手戻りとして捉えてしまうけども、実はそれはフィードバックサイクルの一環と考えた方が良いものもあるかもしれない
• 手戻りという言葉をそろそろ再定義しても良いかもしれない
• そのフィードバックサイクルがうまく循環せずに、単なる工程の繰り返しになってしまっているということは、プロセスの進め方自体に問題があるのかもしれない
• 「手戻り」という風に受け取ってしまうと、純粋なフィードバックをビジネス側・顧客側から得ることができなくなるので、建設的ではなくなってしまうかもしれない
• フィードバックサイクルをうまく回す。そしてフィードバックをうまく受け取る。そして業務プロセスを繰り返さないように済むような形で、インクリメンタルに開発するとか取り組んでいくというのが一番いいんじゃないだろうか

変化を受け入れたいし、変化を受け入れやすいプロセスや協力関係を上手くつくりたいと常々思いますね（自戒）

業務を兼任することになった時にやってたこと

業務の兼任は大変だ。これは間違いない。

何が大変かというと、業務量が増えるのもそうだが、それ以上に「違う仕事をする時の脳みその切り替え」、つまりコンテキストスイッチがとにかく辛い。これは当時の上司にも釘を差されたことだった。

僕の場合、ソフトウェアエンジニアとマーケターの兼務を数年していた。この経験を踏まえて、コンテキストスイッチの大変さと兼務する上での心得について書いてみたい。 偉そうに言えたもんではないが、誰かの参考になればと。

兼務はパフォーマンスを下げる

トム・デマルコの『ピープルウェア』でもたしか触れられていた。「人は一つのことに専念する時が最もパフォーマンスを発揮できる。どんなに優秀な人でも、マネージャーとプレイヤーの両立や複数プロジェクトの掛け持ちをすればするほど、パフォーマンスは落ちていく。」

実際、僕も兼務していた時は常にそう感じていた。「開発にもっと集中できれば、絶対にいいアイデアや実装ができるのに」「マーケティング施策をもっと追いかけられれば、いい提案ができたり、細部にもこだわれるのに」という思いが常にあった。

しかも厄介なのは、綺麗に50%・50%に分かれることがないということ。イメージ的には45%・45%で、自分の体の中の10%ぐらいが欠損してしまう感じ。つまり、足し合わせても100%にならない状況になってしまう。

どちらも100%コミットできず、綺麗に等分にもできない。これが兼務の最も苦しいところだと思う。

対処法1：スケジュールを明確に分ける

コンテキストスイッチは避けられないが、頻繁に発生しないよう工夫はできる。

僕がやっていたのは、業務をやる日を明確に分けること。例えば：

• 週の前半は開発、週の後半はマーケティング活動
• この週は開発、次の週はマーケティング活動

もちろん、日常のやり取りやコミュニケーションは毎日入ってくるので、それには対応する必要がある。でも、メインのタスクについてはなるべく明確に分けることを心がけていた。このあたりはシングルタスクという本を読むとより詳しく書いてある。

対処法2：周囲への宣言と期待値調整

これがすごく大事だと思うのだが、関わるメンバーや周囲の人に「自分がここまでやります」「直近1〜2ヶ月でこういうことをやります」ということを先に宣言しておく。

僕の場合：

• 細かい実装タスクには入れないかもしれないが、設計方針を決めるミーティングには必ず出る
• いいアイデアが出たら積極的に伝える
• マーケティングのスケジュールに合わせて「この週はこちらに集中します」と事前に伝える

逆にマーケティングチーム側にも「開発がこういう事情なので、ここは開発に入ります」ということをなるべくは伝えるようにしていた（と思う）。

なぜ宣言が重要なのか

自分のスケジュールやタスク管理をするだけでなく、どういう成果を出そうとしているか、どういう進め方をしようとしているかを周囲に伝えることが案外重要だ。

というのも、兼務していると「あちらもこちらもやって、この人何をやってるのかわからない」という状況になりがちだからだ。でも事前に伝えておくことで：

• 相手が「このタイミングだったら来てくれる」「このことを期待して話せばいい」とわかる
• 「それじゃ足りない」「もっとやってほしい」「それをやらなくていい」といったフィードバックも事前にもらえる
• 期待のミスマッチがなくなり、お互いに心理的にも安心してやれる

まとめ

兼任・兼務の大変さは：

1. 業務量の増加
2. コンテキストスイッチの複雑さ
3. 自分の成果が足し合わせても100%にならない状況

基本的に兼務はパフォーマンスを下げる行為だということを大前提として理解しておくといいかも。

その中での対処法は：

1. スケジュールを固めて、なるべくコンテキストスイッチが発生しないようにする
2. 周りの人に自分のやり方・進め方・目標などを明確に伝えて協力を仰ぐ

兼任や兼務をやることになった人の参考になれば幸いだし、僕自身も兼務をやっている人からアドバイスをもらったり助けてもらったりしたので、そういう人たちにもマジ感謝、感激、スペシャルサンクス

他の人のやり方も知りたいとこでもある。割とプレイングマネージャーとかもなりがちかも？