わざわざ自分がアウトプットしなくても、AIに聞けば解決してくれるという時代において、どんなアウトプットが必要になるでしょうか。
AIができないこと、その一つが経験です。フィジカルでも、オンラインであっても、AIは経験を積み重ねることができません。コンテキストがリセットされれば、それまでにやりとりした履歴は忘れ去り、まったくのゼロベースで会話が始まります。
技術記事などを書く際に、「困り事→解決」だけを見れば、無数のコンテンツがすでに存在しますし、AIが最も得意とするところでしょう。しかし、あなたの体験は真似ることができません。なぜその課題が生じたのか、なぜその解決策を選択したのか、実施にあたって生じた問題はどうだったのかなど、解決に至るまでの経験はあなただけのユニークなコンテンツになります。
AIが書いている文章に抜けているのが、感情です。AIに小説を書かせれば、それっぽい感情を含んだ内容を書くことはできるでしょう。しかし、大抵の場合薄っぺらく、どことなくAIが書いたんだろうと匂わせる文章になっているはずです。
技術的な記事においても、感情は十分に入り込む余地があります。うまくいった時の嬉しさ、最初のトラブルで感じた焦り、周囲からの感謝の言葉で得られた感情など、心の琴線に触れる機会が多数あるはずです。そうした心情の変化はAIでは決して再現できない、あなただけの唯一無二のコンテンツになります。
こうした人間しか書けないコンテンツを作る際に肝になるのが、言語化です。今（または数日前）自分が感じている感情や経験を、言語化しないとアウトプットはできません。嬉しかった、だけではあまりにも情報量が少なく、AIでも十分に出力できる内容です。より深く、自分の状況を言語化できないといけません。
言語化は仕事の上でも役立つはずです。AIへのコンテキストを与える際には、人間相手であれば当たり前だからと無視されている内容を盛り込まないといけません。言葉一つ取っても、その定義や期待値を明確にしないと間違って認識されてしまうでしょう。これは人相手でも同じですが。あれやこれ、いい感じにやっておいてといった適当な指示でうまくいっていた時代は終わり、より言語化能力の高さが（エンジニアであっても）求められるようになっています。
そしてもう一つ大事なのが記録です。記憶はあっという間に薄れてしまいます。今感じた感情を、今すぐメモしておきましょう。今苦しいと思った感情も、明日になれば霧散してしまいます。いわゆる喉元過ぎればという状態です。こうなると、自分の経験を正しくアウトプットできなくなります。
そこで、記憶がフレッシュな内に、メモしておくのが大事です。脳に入れておくだけではあっという間も薄れてしまいますが、どこかに小さくメモしておけば、後になって見返した際に記憶が再現されるでしょう。全てを記して置く必要はありません、記憶を呼び覚ますきっかけになる一言さえ残しておけば問題ありません。
昔、PMを始めた頃には、「厳密なドキュメントさえ書けば、システムは正しく実装される」と思っていました。しかし、実際に出来上がるのはとても読みづらい、堅苦しい文章です。そんな文章は誰も読みたがらないでしょうし、目が滑ってしまいます。その結果、要件もれが発生します。ドキュメントにある、と突っ込んだところで意味がありません。読まれない文章には価値はないのです。
プレゼンテーションなども同じです。いくら良いことが書いてあっても、伝え方が悪ければなんの意味もありません。逆に、どれだけ拙いスライドであっても、相手に伝わっているならまったく問題ありません。
つまり問題は伝え方なのです。コミュニケーション文脈で言えば、ストーリーテリングと言えるかもしれません。事実を淡々と伝えるのでは、人の心は動きません。感情を共有し、あなたの経験から語ることで、相手に響く文章になり得るのです。
今後、AIを使った開発がますます増えていくでしょう。そうなった時に、個人のキャリアはどうなっていくでしょうか。大規模なシステム開発に従事したとしても、やっていたことがAI任せだとすれば、あなた自身の価値はどこにあるのでしょうか。
キャリアとしての地固めをする上でも、アウトプットは役立つはずです。そして、そこで大事なのは自分が何を考え、何に苦労し、どうやって克服したかという経験なのです。その経験をアウトプットするのは、他の人との差別化につながるでしょう。
個人的にはブログの文章を書く際に、GitHub Copilotのような優秀なAIサジェストは使わないようにしています。自分が書こうと思ったことを先出しされ、承認しているうちに徐々に思考誘導されている感じがするからです。
自分の内にあるアウトプットしたい内容は、自分だけのものです。AIが介在し、彼ら（？）の望む何かに変えられてしまうと、自分が本来言いたかったことではなくなってしまう可能性があります。何より、自分なら絶対に使わないであろう文章の書き方（太字、横棒、文末が：で終わるなど）があると、それはもはや自分の文章ではなくなってしまうのです。
AIに頼らない文章は、読みづらい部分があったり、誤字や脱字があるかもしれません。それはそれ、人間ならではの味というものじゃないかなと割り切っています。
AI時代になって、むしろアウトプットの重要性は高まっているように感じます。それはアウトプットしている人と、していない人の差が広がっているという意味です。AIでなんとでもなる時代にあるからこそ、アウトプットしている人の価値が出てくるのではないでしょうか。
ただし、劣化版AIみたいなアウトプットは意味がありません。人間だからこそできる、経験と感情を含んだアウトプットこそ、価値になるでしょう。
]]>In an era where asking AI can solve problems without you having to create output yourself, what kind of output becomes necessary?
One thing AI cannot do is accumulate experience. Whether physical or online, AI cannot build up experiences. When context is reset, all previous conversation history is forgotten, and conversations start from complete zero.
When writing technical articles, if we only look at “problem → solution,” countless pieces of content already exist, and this is what AI excels at most. However, your experience cannot be replicated. Why did that problem arise, why did you choose that solution, what issues occurred during implementation—the experience leading to the solution becomes unique content that only you can provide.
What’s missing from text written by AI is emotion. If you have AI write a novel, it can produce content that includes something resembling emotions. However, in most cases, it will be superficial and somehow give off the scent of being AI-generated.
Even in technical articles, there’s plenty of room for emotion. The joy of success, the panic felt during the first trouble, the emotions gained from words of appreciation from others—there should be numerous opportunities that touch the heartstrings. Such changes in sentiment can never be reproduced by AI and become one-of-a-kind content that only you can create.
When creating content that only humans can write, the key is verbalization. You cannot produce output without verbalizing the emotions and experiences you’re feeling now (or felt a few days ago). “I was happy” alone contains too little information and is content that even AI can output sufficiently. You need to be able to verbalize your situation more deeply.
Verbalization should also be useful in work. When providing context to AI, you must include content that would be ignored as obvious when dealing with humans. Even taking a single word, if you don’t clarify its definition and expected value, it will be misunderstood. This is the same when dealing with humans too. The era of getting by with vague instructions like “do this and that nicely” is over, and higher verbalization ability is now required (even for engineers).
Another important thing is recording. Memories fade in an instant. Take notes immediately of the emotions you feel right now. The painful emotions you feel today will dissipate by tomorrow. It’s the so-called “out of sight, out of mind” state. When this happens, you won’t be able to correctly output your experiences.
Therefore, it’s important to take notes while the memory is fresh. If you just keep it in your brain, it will fade in an instant, but if you jot down a small note somewhere, when you look back later, the memory will be reproduced. You don’t need to record everything—there’s no problem as long as you leave just one phrase that can trigger the memory.
Long ago, when I started as a PM, I thought “if I just write rigorous documentation, the system will be implemented correctly.” However, what actually gets produced is very hard-to-read, stiff text. No one wants to read such text, and eyes will glaze over it. As a result, requirements get missed. There’s no point in insisting “it’s in the documentation.” Unread text has no value.
The same goes for presentations and such. No matter how good the content is, if the delivery is poor, it’s meaningless. Conversely, no matter how clumsy the slides are, if they’re getting through to the audience, there’s no problem at all.
In other words, the issue is delivery. In the context of communication, it might be called storytelling. Simply conveying facts in a monotone won’t move people’s hearts. By sharing emotions and speaking from your experience, it can become text that resonates with others.
Going forward, development using AI will increasingly grow. When that happens, what will become of individual careers? Even if you work on large-scale system development, if what you were doing was left to AI, where is your own value?
Output should be useful for solidifying your career as well. And what’s important there is the experience of what you thought, what you struggled with, and how you overcame it. Outputting that experience will lead to differentiation from others.
Personally, when writing blog posts, I try not to use excellent AI suggestions like GitHub Copilot. It’s because I feel like my thoughts are being gradually guided when suggestions pre-empt what I was going to write and I keep approving them.
The content I want to output from within myself belongs to me alone. If AI intervenes and changes it to something they(?) want, it might no longer be what I originally wanted to say. Above all, if there are ways of writing that I would absolutely never use (bold text, horizontal lines, sentences ending with colons, etc.), it’s no longer my own writing.
Text that doesn’t rely on AI may have hard-to-read parts or typos and misspellings. I’ve accepted that as it is—it’s what you might call a uniquely human flavor.
With the AI era upon us, I feel the importance of output is actually increasing. This means the gap between those who output and those who don’t is widening. Precisely because we’re in an era where AI can handle anything, doesn’t the value of those who produce output emerge?
However, output that’s like an inferior version of AI is meaningless. Only output that includes experience and emotion, which only humans can create, will have value.
]]>もちろん、当時と今では状況が違いますし、たまたまうまくいっただけの可能性もあります。ただ、今年再度会社員に戻るわけですが、副業としてフリーランス（個人事業主）に戻っていますし、万一会社員としてダメだったとしても、それほど気にしない理由もここにあります。
他の誰とも違う、自分なりの強みを持つのが一番大事です。○○と言えばあなた、というブランディングがとても重要です。むしろ、それがなかったら独立しないほうが良いと思います。
この強みというのは非常に難しくて、間違った方向に行くと誰にも何にも響かないものになります。ただ、一朝一夕で身につくものでもないので、少なくとも3〜5年はその道を突き進む必要があります。その間、その技術が廃れなければあなたの価値ですし、その技術界隈自体なくなってしまうと、しんどいものがあります。
そのため、自分が探求する技術については慎重な見極めと、諦めない根性が必要です。新しい技術が出るとついぶれてしまいがちですが、それをグッと堪えて突き進まなければなりません。
個人的には2000年からのオープンソース、2010年からのプロジェクト管理、2014年からのDevRelというチョイスが良かったと思っています。こういったキーワードを見つけられるかどうかがフリーランスにとって大事になります。なお、AIなど競争が激しすぎる、日夜変化するもので頑張るのは疲弊するのでお勧めしません。
先ほどの強みについて言えば、それは外部から見て評価されているものじゃないといけません。社内で評価されているから独立するというのはNGです。多くの場合において、社内と社外の評価はまったく違います。会社を辞めたらまったく相手にされなくなった、なんて話はとてもよく聞かれます。
外部評価されていると、バイネームで仕事を得やすくなります。そのためには外部での登壇を積極的に行ったり、執筆したり、普段から発信活動を行ったりする必要があります。
外部評価については、Googleで自分の名前を検索してみればわかるでしょう。そこにポジティブな評価がたくさん出ているようにしましょう。少なくとも私が仕事を依頼する際には、その人の名前や屋号で調べると思います。そこにネガティブな情報が出てくるようであれば、避けたくなるものでしょう。
技術力があれば、仕事は向こうからやってくるというのは幻想です。誰だって、見ず知らずの誰かに依頼するよりも、人となりを知っている人に依頼したいと思うものです。飛び抜けた強みがある人であればまだしも、そうじゃない場合は仕事を依頼してくれるツテが多いに越したことはありません。
そういった意味でも、会社員として働いている時からコミュニティに参加したり、人との積極的な関わりが欠かせません。特にエンジニア職は社内に閉じこもりがちで、外部との接触の多くない職業です。それだけに積極的に外に出るようにしたり、コミュニケーションするように心がけないといけません。
ただ、同じ開発者同士の知り合いができても、仕事には結びつかないケースもあるので注意が必要です。同年代では決裁権、決定権がないことも多いです。知り合ったエンジニアが出世や転職してCTOになっていたりすると良いですが、あまり他人に期待を寄せすぎるのも問題です。
外部評価とも似ていますが、人間関係はよくあり続けましょう。どこで人が見ているかわかりません。人間関係での悪い評価は、仕事を得る上でもネガティブです。共通の知り合いがFacebookやLinkedInにいれば、発注前に評価を聞きたくなることでしょう。そこでネガティブな評価をされれば、失注してしまうことにつながりかねません。
20代のフリーランスと、40代のフリーランスに依頼する内容は異なるのが当たり前です。もし発注側の担当者が30代の場合、どちらの方が自分の下で働いて欲しいと思うでしょうか。同一労働・同一賃金とは言いますが、発注側としては割と年齢は関係するものです。
社員雇用の場合ですら、年齢は関係します。フリーランスへの仕事依頼の場合は、さらに顕著です。年齢に合わせて、自分の仕事スタイルや求められるであろう内容もアップデートしなければなりません。例えば40歳であれば、マネジメントに関わるものであったり、コンサルティングなどになるでしょう。そうなると、それに見合った実績がなければ、仕事が得づらくなります。
フリーランスや起業していると、必ず悪い状況になることでしょう。そうした時に、周囲に当たっても何も好転しません。むしろ、そうした不安定さやどん底を笑い飛ばしたり、楽しめるような精神力が必要です。
晴耕雨読と言いますが、よくない状況（雨天）の時には自己研鑽に力を入れたり、新しい学習に取り組む時期だと割り切りましょう。また、よくない状況になってから動き出しても遅いので、良い状況の時ほど積極的に動くようにし、悪い状況にならないよう常に動き続けるのが大事です。
個人的にそういった感情になるのは、収入がダウンした時です。そうした時に備えて、通常時から余剰金が出るように心がけましょう。会社員と違って収入が不安定な分、調子がいい時に貯まるようにしておくと、ダメな時にも気落ちせずに済みます。
クライアントとの契約で、週○時間働いて欲しいと言われることがあります。個人的にはこういった仕事は断るようにしていました。1日8時間、週40時間しかない中で、週何時間かの拘束が発生するのは問題です。時間での拘束をよしとするならば、会社員でいいのではないでしょうか。
月にブログ10記事や、インタビュー記事1本などの仕事であれば喜んで請けています。それは、自分のやり方によって時間を短くでき、単位時間あたりの収入を上げられるからです。時間にコミットする仕事は、キビキビやってもダラダラやっても変わらず、こちらの生産性を下げる結果になります。
せっかくフリーランスになったのだから、束縛のない仕事を選ぶようにしましょう。
基本的に、客先常駐型の仕事は請けないよう心がけています。フリーランスの8年間でやったのは2回のみ、累計で1年くらいだと思います。
最初はフリーランスになりたての頃で、それまで勤めていた広告代理店で、自分がやっていた仕事を引き継ぐために出社していました。もう一つはプロジェクトマネージャーの仕事で、週2回オフィスに訪問するといった枠組みでやっていました。いずれにしても週5日、8時間といった制約は収入面や、契約が切れた後の案件探しという意味でも良くないと思います。
フリーランスになりたての頃に、システム開発の手伝いを2回ほど行ったことがあります。しかし、自分の単価と作業量を考えると、自分とクライアント双方にとって割りに合わないと感じました。おそらく、自分一人に開発をさせるなら、若手を3人雇った方が安いし速いのではないかと思っていました。
歳を取れば取るほど、開発効率は上がっていたとしても、実際の生産性は若手が束になったのに比べれば劣るでしょう。さらに昨今のAIコーディングがあれば、若手も生産「量」は劣らなくなります。自分自身、プログラミングの天才ではないので、そこで勝負しない方がいいと、さっさと土俵は降りてしまいました。
だからこそ、別な領域（他の人がいない領域）で勝負して生き残れたのだと思っています。
クライアントからお金をもらって仕事をする上で、どうお金が出てくるのかを知るのは大事なことです。会社には予算があり、決裁権を持った人たちから稟議・承認を得ないといけません。その人たちが会社にとってメリットがあると感じてくれないと、お金は一銭も出てこないのです。
お金が一番出やすいのは、クライアントが儲かるものです。さらに、それが手数料型・成果報酬型であれば稟議が通りやすいでしょう。開発チームに直接販売するものは、お金が出づらい傾向があります。なぜなら、開発チーム自体にはそれほど多くの予算が割り当てられておらず、開発チームが売上増に直結しているケースは少ないからです。
昨今のAIブームでいえば、開発生産性に関わるAIツールであれば予算が通りやすい傾向はあります。しかし、チーム全体で予算が決まっているケースが多く、他のツールをやめてまで採用してくれるかは不透明です。
大抵の企業は営業系と技術系（製造系）に分けて考えられます。それは社長がどちらの畑出身かによって分かれます。それによって予算をどう配分しているか、どういったツールであれば受け入れやすいかが決まってきます。こうしたお金の流れを把握せずに営業しても、うまくいかないことが多いでしょう。フリーランスでサービスを作ってもなかなかうまくいかないのは、こういったビジネス面の知見が少ないからだと思います。
そして何よりも大事なのは、安易に相談事に乗ったり、了承しないことです。詐欺師は優しい顔をして近寄ってきます。技術しか知らず、自分の価値を知らない人に対して、甘い言葉で擦り寄ってくる人たちは何かを奪おうとします。最悪なのは、その人たちは自分たちが悪い人だとまったく考えていないことです。
安い仕事を依頼する人は、次も安い仕事を持ってきます。知り合いからの紹介だからといって、いい人とは限りません。無理難題を一度聞くと、相手は敷居をそのラインに持ってきます。断固として断れというわけではありませんが、自分の価値を正しく見定めて取り組むのがお勧めです。
仕事を断るというのは、割と精神的に辛い場合が多いです。次はないかもしれない、やっておけば来月は楽になったかと…と心がぐらつくはずです。しかし、そこはグッと堪えて自分価値観と照らし合わせて、勇気を持ってお断りしましょう。
会社員、フリーランス、一人法人とやってきて、ベストな働き方はフリーランスだったと思っています。自己責任ながら好きな形で働き、自分の価値を最大限アピールできる働き方だからです。
もしこれからフリーランスになりたいと思っている方がいたら、その一助になれば幸いです。
]]>今回は会社員に戻るということで、あまりそういった機会は多くないので、ここにこれまでの略歴をまとめてみたいと思います。
最初はケーブル会社へ、品質管理のエンジニアとして就職しました。当時はインターネットケーブルを世界中に張り巡らせるプロジェクトが進行しており、光ファイバーケーブルの販売が伸びていた時期でした。
そんな折、たまたま英語が話せたので、営業部長と一緒に海外へ、営業のお手伝いに行く機会がありました。99年の12月、雪が降る中ニューヨーク（といってもイサカという超田舎）へ行って、子会社のECサイトを手伝うことになりました。ケーブルの出荷を手伝うような作業だったのですが、当時はAmazon.comがはじまったくらいの頃で、仕組みとしてはかなり先進的だった覚えがあります。また、Eコマースという仕組みに感動し、これから世界が変わるのを実感した瞬間でもありました。
そのあと、イギリスにいってMPEG4の前進になる技術を見たり（あの時、投資していたらこのケーブル会社はすごかっただろうに…）、オランダでマリファナ中毒者に声をかけられたり（今もオランダは合法ですね）、オランダからドイツに帰れとホテルを追い出された挙句、電車に乗れずに行き詰まったり（当時のオランダは英語話者が少なく、Googleマップもない時代）と色々面白い体験をしました。
日本に帰国後、USJにケーブルを卸した後で転職活動をはじめました。
2000年は日本でもインターネットブームが来ていました。ちょうど、3月にサイバーエージェントが上場し、熱量が高まっていたのを覚えています。いくつかの企業で面接をして、B2BのEコマースサービスを提供する企業に就職したのが2000年5月だったと記憶しています。
当時の渋谷はビットバレーと呼ばれるテック企業が集まっていた時で、その会社も1社に入っていました。DeNAの前身であるビッダーズや、Yahoo! Japan、Find! Jobのイー・マーキュリーなど色々な会社の人たちと徹夜上等で仕事をしていた時代です。近くのビルにネイバーというオンラインゲームの企業が入り、あっという間に大きくなって恵比寿に引っ越していきました。彼らはその後、合併してLINEになっています。
ビッダーズもオークションサービスの頃はヤフオクに押されて苦戦していましたが、モバゲーをはじめた途端に急成長して遥か遠い世界の人たちになってしまいました。私のいた会社はなかなか鳴かず飛ばず、かといって全くダメでもないといった低空飛行の状態でした。2、3回目の出資の関係でiPAQというPDAを手にしたのを覚えています。Windows Mobileで、通信カードも入れられて良い端末でしたが、コンパック自体があっという間に廃れてしまったのが残念です。
当時は働き方ががむしゃらで、生産性という意味では下の下みたいな感じでした。ほぼ自宅に帰らず働き続け、無茶なスケジュールに応え続ける状態でした。プロジェクトが佳境になるたびに徹夜が続き、ギリギリの状態でリリースするといったことが繰り返されました。スタートアップならではかも知れませんが、もっと効率的な方法は多数あっただろうと今ならわかります。
その頃、その会社のCTOが技術者交流会というのをはじめました。今の勉強会のはしりみたいなものかも知れませんが、特にセッションなどなく、集まって酒を飲みつつ会話するだけのものです。その会が縁で、connpassを提供するビープラウドの佐藤社長と知り合いました（その交流会の派生版だったと思います）。
結局、その会社では最初がMS Access + VBA、次がVB6、そのあとがPHP3でのシステム開発を経験することになります。PHP3のシステム（Eコマース側）は、Javaに刷新しましたが、私自身はPMとして指示するのみだったような記憶が。サーバーはTurbo Linuxを使っていましたが、日本語表示が変でOracle 8iのインストールに苦戦した思い出があります。
プライベートでは2002年に結婚して、2003年に子供が産まれています。ライフステージが変化しても働き方に大きな変化がなく、いつも終電で帰っているような状況でした。通常、スタートアップでは3年でIPOできないなら芽がないと言われます。3年目になり、離陸する雰囲気がなかなか感じられなかったこともあって、ワークライフバランスを刷新する意味でも転職を決意しました。
なお、この会社はその数年後に上場しています。ストックオプションはそれなりにあったと思いますが、とても耐えられなかったですね。
Eコマースの会社では割と高く評価されており、年齢の割に高い給与をもらっていました。そのため、いざ転職しようと思った時に、なかなか条件を維持するのが難しかったです。そうした中で2社ほどオファーをもらい、インターネット広告代理店に決めました。もう一つの会社は旅行代理店系だったのですが、社長がガンガン働くタイプで、こちらにもそれを期待していました。それではEコマース会社での働き方と変わらないと感じて、お断りすることとしました。
インターネット広告代理店での面接では、その辺りの要望を聞いてもらえたこと、裁量権の大きさが決め手になったと記憶しています。その頃から割と独立したいという気持ちが高まっており、3年で辞めると思いますとも伝えていました。結局、3年1ヶ月で辞めているので、予定通りだったと言えます。
インターネット広告代理店では、ITシステムの管理全般を担っていました。いわゆる情シス的な立場ですが、内部のシステム開発も行っていました。社内LANの整備から、複合機の契約、サーバーの購入とセットアップ、キッティング、個人情報保護法の教育などなど様々な仕事に関わっていました。代理店なので営業系の会社で、営業の人たちは夜遅くまで残業して仕事をしていました。そんな中、私は社内システムさえ適切に運用できていれば、定時で帰っても問題ない状態だったのでよかったです。
この頃から、徐々に独立を視野に活動を開始していました。Eコマース会社時代から片手間でやっていた、MOONGIFTというサイト（一時はOpen Alexandriaという名前）の更新を日々行い、徐々に知名度が上がっていきました。MOONGIFTの更新は朝5時起きで行っており、それが終わったら8時には出社して、他の人たちが出社する10時までにあらかたのタスクを完了させておくといった働き方になっていました。
これが2年以上続いて、徐々にMOONGIFTを通して仕事が得られるようになってきました。主にWebサービスのコンサルだったり、記事執筆の仕事などです。そうした中で、概ね目処が立ってきた頃、退職を願い出ました。なお、最初は引き継ぐ相手がおらず、外部企業に依頼する形になりました。その会社への引き継ぎで約半年ほど、MOONGIFTの席（物理）を置かせてもらいつつ、外部委託として運用を任せてもらっていました。
2006年の春頃には引き継ぎも完了し、広告代理店を離れることとなりました。
フリーランスになった初期の頃は、Webのコンサルティングであったり、ベクター社と一緒にMASHUPEDIAというサイトを運用したりしていました。一時期、システム開発のお手伝いなどもしていましたが、開発請負はほとんどやっていません。
2008年4月にBPStudy #8で登壇しています。connpassがはじまったのは、BPStudy #33から（それまではatnd）ですが、自社勉強会を管理するためにはじまったconnpassが、今も続いて巨大なコミュニティ管理サイトになっているのはすごいですね。
MOONGIFTはその頃も更新を続けており、2009年にフリー 〈無料〉からお金を生みだす新戦略という書籍が発売してフリーミアムという言葉が流行り始めのに合わせて、MOONGIFTプレミアムというサービスを提供し始めました。これはまったく鳴かず飛ばずでしたが、コンサルティングを行う上での大事な実験にはなりました。
2010年ごろからはプロマネのアウトソースを行っていました。週1〜2とかでクライアントのところに行って、進捗管理やタスク整理、ドキュメント整備などを行っていました。2010年ごろはiPhone 4が発売し、モバイルアプリ開発が盛んだった時期です。多くのVCがモバイルアプリ企業に対して投資し、開発スピードが求められていた時期でした。
そうして、2013年ごろに株式会社MOONGIFTを作り、法人化しています。理由としては、当時Mobile Touchというモバイルに関するメディアを立ち上げようとしたのに起因しています。メディアを立ち上げる上で、寄稿者や広告主に対して安心してもらうために法人化しました。結局、メディアとしては1年程度でクローズしているので全くダメだったのですが。
そうした中で、メディア以外の軸になる事業を考えていた時に出会ったのがDevRelというキーワードです。元々の発端としては、2014年2月ごろにEvernoteのマーケティングが日本と海外で全く異なるのを知ったことでした。海外（アメリカ）ではハッカソンの協賛したり、ミートアップ開催を通じてAPIを開発者に対して発信していました。それに対して、日本ではドコモ社との提携を通じて、カバンや文房具の販売など、一般ユーザー層に対してアプローチする方式をとっていました。この違いを調べていく中で出会ったのがDevRelです。
また、チャット友達のmasuidrive（増井雄一郎）さんがAppcelerator, Inc.にてエバンジェリストを行っていたことも大きかったです。上記の件を聞いた時に、そういった活動はグローバルではあるという話でした。また、すでにAWSではそういった活動が活発に行われていました。
海外では行われているのに、なぜ日本ではできないのかを考えた結論としては、エバンジェリストの給与水準が高いことが考えられました。例えば当時堀内さんがAWSのエバンジェリストをされていました。堀内さんといえばgumi CTOでもあった人で、そうした人を雇用するとなれば、それなりの給与が必要です。おそらく日本の給与レンジには合わないのではないでしょうか。
エバンジェリストは技術的レベルが高く、ブログなどのライティングスキル、登壇スキル、コミュニケーションスキルなどマルチに持ち合わせていることが求められます。こうした人は市場にも多くなく、その結果として給与が高くなります。そのため、日本企業では雇用しづらいと考えましたし、今でもそれは変わっていないように思います。
そこで、事業としてDevRelをアウトソースで請けるのを思いつきました。コンサルティングをやっていた際に感じたのですが、コンサルティングで必死に調査してレポートを書いても、それを実行するリソースがなければ絵に描いた餅です。コンサルティング側では実行責任を負わないので、金銭的には問題ありません。しかし、この実行に至らないレポートは本当に意味がないものに感じられていました。
アウトソースであれば、クライアントにリソースがなくとも問題ありません。こちらでできることを提案し、了承が得られれば実行するのみです。このやり方で2014年3月に2社ほど提案し、最初の2ヶ月は無料という形でスタートしました。結果として、この2社とも有償契約に結びついています。
DevRelを事業化する上で苦労したのが「DevRelが何かを説明するのに時間がかかる」ということです。説明した上で納得してくれる方は多かったですが、最初の認知のハードルが高過ぎました。約1年ほど一人で続けていても、ごくごく僅かにしか伝わりません。広がりに限界を感じる中で、考えたのがコミュニティの立ち上げです。
DevRel/Tokyoの前進であるDevRel Meetup in Tokyoを立ち上げたのが2015年9月です。ちょうど同じ年の2015年9月30日にDevRelCon London 2015が開催されることもあり、徐々に機運が高まっている時期でした。コミュニティの中で、開発者向けのマーケティングを行なっている人たちが、自分たちの活動がDevRelであると認知すること、どういった活動がDevRelであるかを広めていくことができました。
DevRelConについては、日本ではDevRelCon Tokyoとしてフランチャイズし、2018年から開催しています。また、DevRel/Japan CONFERENCEとして、日本語でのカンファレンスも実施しています。こうしたコミュニティイベントと、カンファレンスを通じて徐々にDevRelの認知度が高めていきました。
同時に行っていたのがインドでのDevRelコミュニティ立ち上げです。2017年8月に最初のイベントを行いましたが、この時は4人の参加者でした。そのあと、コロナ禍もあってしばらく間が開いてしまうのですが、2回目以降は150人〜200人くらいの参加者が集まるようになっています。
「なんでインド？」とよく聞かれるのですが、これは種まきです。インドは人口ボーナスがあり、ITも盛んです。世界のテック企業のCEO、その多くがインド人になるほど優秀な人たちが多いです。そうしたインドの優秀な人たちがサービス開発を行い、世界展開する上で日本市場に目を向けた時に私を思い出してもらうのが狙いでした。
最近行けてないのですが、また行きたいなーと思っています。
コロナ禍の混乱もありましたが、事業としては割と好調でした。オンラインのイベントであったり、オンラインコミュニティの育成に関わることも増えていましたし、ブログなどのコンテンツマーケティングは根強い人気がありました。出張は減りましたが、並行して進められることが増えたり、移動時間がなくなったことで作業時間が増えたのはむしろよかったです。
そうした中で劇的な変化が起きたのはAI（LLM）でした。2025年は猫も杓子もAIばかりでした。AI機能などまるで搭載していないサービスですら、AIと絡めたイベントを行いたい、ブログ記事を書いてほしいという始末でした。また、提供サービスがAIの煽りを受けて、売り上げが下がってしまい、マーケティング予算を削られるケースも多くありました。グローバルでは2023〜24年くらいにコロナ禍にレイオフの嵐が起きましたが、それの日本版が数年遅れてきたという感があります。
そうした中で、AI系については好調でした。特にCodeRabbitはシリーズAで1,600万ドル、シリーズBで6,000万ドルと高い評価を受けています。そして、日本では多くのユーザーがついていたこともあり、MOONGIFTにDevRel支援の依頼が来ました。
2025年について言えば、CodeRabbitともう1社、あとはブログ系で複数のクライアントで回っていたような状況です。
2022年くらいから感じるようになったのは、国内の開発者向けサービスの低迷です。実際には、もっと前からあったのかもしれません。
スマホが出てきた当初、アプリ開発をサポートする開発者向けサービスが多数出てきました。例えばアプリ開発プラットフォームのMonacaや、バックエンド機能を提供するニフクラ mobile backend、実機テストをクラウドで提供するRemote TestKitなどです。
また、IoTに注目が集まるようになった時にもいくつかのサービスが出てきました。最も有名なものとしてはSORACOMがあります。また、MOONGIFTでもサポートしていたIsaaxというサービスもありました。他にもobnizやeneblarなど様々なサービスが生み出されてました。
Web3（ブロックチェーン）に注目が集まると、Orbのようなサービスも出ました。その後、AI（LLMではない）の時代に入ると、FRONT-END.AIのようなサービスも出てきましたが、LLM登場以降は日本から開発者向けサービスがとんと出てこなくなった気がします。あっても、海外のオープンモデルなAI（Stable DiffusionやDeelSeekなど）をラップして提供するものくらいだったのではないでしょうか（そんな中、グローバルに対してサービスを打ち出しているROUTE06のGiselleやLiam ERDには期待したいですね）。
こうした背景があって、DevRel事業の軸足を外資系企業向けに変更したのが2025年後半くらいでした。つまり、外資系企業で日本市場に興味があるところが、開発者マーケティング委託先としてMOONGIFTを選んでもらう形です。スペクト株式会社さんとかが似た形かも知れません。
実際、いくつか問い合わせもあって話を進めていたのですが、ほぼAI系サービスでした。
そうした中で、2025年に始めたCodeRabbitへのフルコミットを決めました。元々、コミットする時間を増やせるかという相談はあったので、中途半端に増やすくらいならフルコミットした方がいいと判断しました。これは、いくつかの要因がありました。
AIは最後の発明と言われるほど、多くの可能性と今後の危うさを秘めた状態です。業界全体が大きく変わる可能性がありますし、すでに多くの面で影響が出ています。過去におけるドットコムバブル、スマホ、IoTにつぐ波になっています。まさにビッグウェーブ状態で、半端に関わるなら一気に飛び込んでしまうのも面白いと思った次第です。
元々CodeRabbitには2025年2月くらいから関わり始めていたので、大きな可能性を感じていました。しかし、類似サービスも続々と登場する中で「もしかするといきなり買収されてクローズするんじゃないか」という思いがあったのも確かです。アメリカのスタートアップではM&Aでサービス終了することも多々あるので、そういった可能性は外せませんでした。
しかし、2025年9月にシリーズBにて6,000万ドルの資金調達し、これはもっとぐんと伸びると確信しました。そこで、フルコミットする話を先に進めて、なんだかんだあって2026年2月から社員となることとなりました。3ヶ月くらいかかったのは、私自身が焦っているわけではなかったので、放置気味だったことも要因です。
フルコミットを決めた理由として、CodeRabbitでは日本人初の社員で、日本にいるのも自分一人ということが挙げられます。デベロッパーアドボケイトとして、あらゆるフェーズに関われますし、企画と立案そして実行まですべてをやらないといけません。ブース対応や登壇、ソーシャルメディアの運用といったわかりやすいものもあれば、広告出稿の契約や素材の用意、Tシャツのデザインと注文、事例インタビューの実施と記事執筆なども行なっています。この辺りは、一人法人でやってきた期間が長い分、自分で決めて自分で動くのが好きというところでもあります。
今回、個人的な使命として「日本市場の価値証明」があると感じています。日本市場は人口源、言語の壁というマイナス面が大きい中にあって、現時点では経済規模がそれなりにある状態です。投資対効果をはっきりと示せれば、人員追加や支社設立なども考えられるようになるでしょう。その先兵として、必要なことはなんでもします。その意味ではDevRel（開発者）だけでなく、エンプラ系企業の対応や、パートナー周り、カスタマーサクセスとの連携なども必要です。このAI界隈は動きがとても激しく、日々新しい状況が生み出されています。新規参入者もいれば、ビッグプレイヤーの参入もあります。
そういった変化の激しい状況の中で働くのは、2000年くらいのスタートアップ以来かもしれません。ただし、あの頃は開発だけしていれば良かったのですが、今回は他のこともやらないといけないのが大きな違いです。日本の情報の多くは日本語で発信されているので、海外にはほぼ届きません。そのため、コンテンツを翻訳・要約して伝えたり、イベント情報をまとめたりと、情報共有も欠かさず行わないと、日本のプレゼンスが示せない状態です。
そういった意味でも、割とこれまでに自分で培ってきた全ての知識やテクニックを総動員する必要があるなと感じています。開発者としての経験、コンサルティング、経営者（といっても12年間、ほぼ一人でしたが）としての経験をフルに活かして攻める必要があるでしょう。特にAI周りは今年、2026年が最重要な年になると感じています。
日本支社がない場合、日本の法令に則った雇用が難しくなります。そのため、本当に小さなところでは委託契約みたいな形になることもあるようです。CodeRabbitの場合、元々リモートで働くメンバーが世界中にいるので、RipplingというサービスのEOR（Employer of Record）を利用しています。これは、企業（CodeRabbit）に代わって、海外の従業員（私など）を雇用し、雇用契約や給与支払い、社会保険の加入などを代行する法人やサービスになります。つまり、厳密に言えば私はRipplingと雇用契約を結びつつ、CodeRabbitと報酬などについて契約する形になります。日本語では雇用主代行と呼ばれるそうです。
CodeRabbitに入社するにあたって、株式会社MOONGIFTはどうしようかと迷っていました。CodeRabbitの日本法人がないため、契約系で若干の面倒さがあります。そのため、外部委託として関わっていた頃は、株式会社MOONGIFTが代理店として契約する形をとっていました。この方がスムーズなのですが、そのためだけに法人を維持するのは意外とお金がかかります。各種クラウドサービスや会計事務所の契約、バーチャル住所などで年間50万円くらいでしょうか。その上、消費税の支払いなどもあり、とても面倒です。
そこで、会社自体解散する運びとしました。そして、またフリーランスとして屋号MOONGIFTを届け出済みです。いくつかの事業や経費はフリーランス側に引き継ぐ形になります。また法人が必要になるかはわかりませんが、必要になったら再度設立すればいいでしょう。freeeなどは会社設立ウィザードがあるので、以前と違ってとても簡単に申請できます。
正社員、フリーランス、法人といくつかの働き方を経験してきましたが、結果的にどの働き方がよかったのでしょうか。これは完全に個人的な意見ですが、フリーランスが良いのかなと思っています。
法人になるメリットは信用でしょうか。おそらく一人法人なら、それ以外のメリットは大してない気がします。よく法人税と個人の所得税の関係で、法人になった方が節税になると言われていますが、そんなことありません。そもそも「個人のお金」と「法人のお金」は別物なので、法人の方に残っているお金を個人の裁量で使ったら、それは横領です。個人で好きに使いたいなら、役員報酬を増やさざるを得ず、そうすると法人税を取られた上で、社会保険料も上がってダブルパンチです。
日本の企業と契約する上で、法人化していると話がスムーズというケースは多いかと思います。大企業であったり、上場していたりすると、フリーランスとの契約で手間取ったり、代理店が入ったりします。これが面倒というケースはあるかも知れませんが、請求書の出し先が変わるだけなので、慣れてしまえば大した手間ではないかも知れませんね。あと、外資系企業では問題視されないケースもあるので、日本企業（特に非IT企業）との契約が多いかどうかによっても違いそうです。
逆にデメリットとしては、費用が増える気がします。会計事務所との契約もそうですし、バーチャルオフィスの契約もあります。個人だったら不要と割り切れるクラウドサービスもあります。最初の定款を作成したり、法人印の作成などもあります。
フリーランスのメリットは、働き方の裁量が大きいことでしょう。逆にいえば自己責任ということですが、自分が納得できるなら自分の好きなように働き、仕事を選択できます。個人的には常駐型の仕事はできず、訪問したとしても週1〜2回といった程度にしていました。常駐型の仕事は時間型サービスであり、束縛が発生します。成果型の仕事にすれば、並列して実行でき、成果さえ上げられれば相手の満足度は変わりません。
フリーランスのデメリットは不安定さでしょうか。これは法人も変わりませんが、自分の強みであるスキルのトレンドが変化すると、あっという間に需要がなくなる可能性があります。その不安定さを楽しみに、自己研鑽して新しいスキルを手に入れ続けたり、他者とのコミュニケーションを欠かさないようにしないといけません。
では会社員が安定しているのか、と言われるとどうなのでしょう。確かに日本の雇用契約では、そう簡単に首にはできません。しかし、大企業では再就職支援や早期退職制度などを通じてリストラを行なっています。会社から言われたことだけをやってきて、社内でしか通用しないスキルを持った人が突然放り出されて、何ができるでしょうか。50代を過ぎて会社にへばりつくか、さっさと見切りをつけて次に向けて動き出すか、どちらかになるでしょう。
個人的には、自分の経歴を見る限り会社員には向いていないように思います。3年続かないのだから飽き性で、辛抱強くないのです。そのため、私自身は会社員のメリットというのがよくわかっていないのだろうと思います。CodeRabbitについては、会社員になるというよりもフルコミットして、CodeRabbitの成長をブーストさせたいという考えの方が強いです。ブーストさせるためには、もっと社内のリソースを知り、活用する必要があり、そのために社員になったという感じです。
99年卒ということもあって、私の世代はいわゆる就職氷河期世代です。たまたま私は高専に入り、就職には困らない状態ではありました（その中から選んでいないので意味なかったのですが）。そのせいもあってか「会社は自分を助けてくれない」という思いは常々あります。会社には私のリソース（時間、働きなど）を提供し、会社からはその報酬をもらうという関係でしかありません。もし私が大怪我、大病を患ったとしても、会社が生涯面倒を見てくれるわけではありません。特にIT業界では心を病んでしまう方も多く、個人的にもそうした人と何人か会ったことがあります。会社での働き方（働かせ方）に問題があったとしても、1年程度の休暇を与えて、その結果無理なら依願退職になります。それで終わりです。
そのため、お互いにメリットがある状態を維持するのが大事なので、メリットが感じられなくなった時点で退職してしまうのです。「早く行きたいなら一人で行け、遠くへ行きたいならみんなで行け」と言いますが、強力にブーストさせるなら多人数が集まった方がいいでしょう。つまり、個人的な成し遂げたい思いがあり、それが実現できる場ならば企業に属するのはいいと思います。
この記事を書いている時点では、まだ正式にCodeRabbitの社員にはなっていません（2026年2月から）。1月はこれまでの仕事の整理などに費やしていました。2月からアクセルを踏めるよう、しっかりと準備をしていきます。
ジョブチェンジも6回目、新しい挑戦のはじまりです。変化の激しいAIの波の中で、必死にもがいてみたいと思います！
]]>そんなTodoistでは、旧ビジネスプランのもっとも安価なものを使い続けており、年額3,500円でした。振り返ってみれば、すごく安いなと思うのですが、そんなTodoistではこのプランがなくなり、新しいビジネスプランが年額11,520円になります。個人用にはプロプランというのもあるのですが、こちらは月額672円（年額8,064円）になります。どちらを選ぼうが、2〜4倍近いコストアップになります。
物価高になってきて、その中での値上げはやむを得ない場合もあるでしょう。しかし、この手のSaaSの値上げって、明らかにユーザーが期待していない機能追加に伴うものな気がしています。つまり、AIです。Todoistでも Todoist Assist なるAIアシスタントが出ているようです。はっきりいって、不要です。この結果として値上げになったとしたら、非常に残念なことです。
よく知られているところではAdobeもそうです。Adobeのサブスクリプションは年々高額になっていますが、あれもAI機能の開発負担によるものが大きいように感じます。ユーザーの8割は、2割の機能も使わないと言いますが、PhotoshopとかIllustratorはまさにそうなんじゃないかと思ってしまいます。大半のユーザーにとって不要な機能が搭載され、その開発費用を支払うのはしんどいものがあります。
カレンダー自体はGoogleカレンダーに寄せている（Todoistでも連携機能を使っている）ので、これを機にタスク管理をGoogleカレンダーとGoogle Tasksに寄せることにしました。
しかし、一点問題があります。それは、Todoistの超絶便利な機能である「自然言語によるタスク追加」が必要ということです。例えば「再来週月曜日 ミーティング #プロジェクトA [3時間]」みたいな自然言語に合わせたタスクの入力ができるのが便利なのです。似たような機能はmacOSのカレンダーのクイックイベントがあります。しかし、同じ機能はiOSにはありません。
同じ機能がないと、タスクの入力やカレンダーへの予定登録が面倒になり、長続きしないことは明らかです。TodoistのOSS代替みたいのも探しましたが、やはり同様の機能を提供するものはありませんでした。
そこで、自作することにしました。
goofmint/Text2Cal: Add schedule to your Google Calendar from natural language.
Text2Calは、ごく小さなツールです。GoogleスプレッドシートのGoogle Apps Scriptで実行します。受け取ったテキストをChatGPTに投げて、予定入力用のJSONに変換します。
21日18:00 CodeRabbit User Group Tokyo #0
みたいな文字列を投げると、以下のようなJSONに展開します。
{
"title": "CodeRabbit User Group Tokyo",
"start": "2026-01-21T18:00:00+09:00",
"end": "2026-01-21T19:00:00+09:00",
"location": null,
"label": "0",
"timezone": "Asia/Tokyo",
"recurrence": null
}
これをGoogleカレンダーに登録する仕組みです。結果として、以下のようなJSONがGoogleカレンダーから返ってきます。
{
"id": "l0g...udo",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=bDB...",
"colorId": "8"
}
入力テキストの頭に ! を入れると、Google Tasksにデータを登録します。 !今日 請求書 みたいなテキストを入力する形です。
あとは、macOS/iOSのショートカットを作って、入力文字列をText2CalのWebアプリケーションに送信するだけです。Googleスプレッドシートを使っているのは、入力した内容や結果をログとして残せること、GoogleカレンダーやGoogle Tasks APIを簡単に使えるためです。
たったこれだけで、個人的に本質的に必要だった機能ができてしまい、Todoistから移行する準備が整ってしまいました。なお、一点課題があるのはGoogle Tasks APIは繰り返し予定の作成に対応していないので、 !毎年12月24日 クリスマスイブ みたいに入れても繰り返し予定にならないことです。
数年前にSaaS is Deadという言葉が流行りましたが、AI（LLM）によって現実味が増しています。ちょっとしたものであれば、自作してしまう方が安価で、速く、自分の要件にフィットするものが作れるようになっています。
この時、最も厳しいのが独自のデータベースがないものです。予定調整サービスがその最たるものです。データはGoogleカレンダーなどのカレンダーサービスに飛んでしまい、独自のデータがないのは致命的です。カスタマイズで様々な業務要件に対応したとしても、一人の顧客が使いたい要件は1つ、ないし2つしかなく、他の要件については過剰開発になってしまいます。
独自のデータベースがある場合、それをベンダーロックインとして囲い込む戦略が取れます。ユーザーとしては喜ばしくないのですが、ベンダーロックインによって、使い続けてもらうことは可能でしょう。しかし、ユーザーからのオープンデータに関する要望があって、エクスポート機能をつけると、オープンソースの代替サービスにインポートされる可能性があります。Todoistの場合、タスクは終了させていくのが基本なので、1年前のデータにそれほどの価値がないのが辛いところです。
オープンなプロトコル・基盤を代替するものは、スイッチングコストが低いのが利点でもあり、欠点でもあります。例えばパブリッククラウドのインスタンスであり、メール配信サービスなどです。SMTPでメール送信しているならば、その接続先を変更するだけで乗り換えができてしまいます。AWSで単にEC2インスタンスを立てているだけであれば、他のパブリッククラウドへも容易に乗り換えられるでしょう。
オープンソースの代替サービスが続々登場するのも課題です。OpenAlternativeでは、さまざまなサービスのOSS代替を調べられます。もちろん、全機能が揃っていない場合が多いのですが、8割の要望が満たせるなら十分というケースは多いのではないでしょうか。
では、生き残るSaaSは何があるでしょうか。一つは技術的複雑性を解決してくれるものです。代表的なものとしては、TwilioやStripeがあります。決済周りの仕組みは複雑で面倒なものですが、それをシンプルにしてくれます。もちろん、代替サービスはありますが、決済やSMS送信を行うSaaS市場はなくならないでしょう。
次に法的な課題を解決してくれるものです。たとえばfreeeやSmartHRです。決算書を作成したり、請求書や見積書などを作成するというビジネス上必要なフローを代替してくれます。会計ソフトや労務ソフトは年々制度が変わるのに合わせてアップデートが必要です。ローカルソフトウェアにしたところでバージョンアップ費用は必要ですし、macOSなど複数のプラットフォーム対応を考えると、こうした市場はなくらないと想定されます。
3つ目に、AI（LLM）に選ばれるSaaSです。最たるものとしてはSupabaseが挙げられます。何かデータベースが必要なWebアプリやスマートフォンアプリを開発する際に、Claude Codeなどを使うとSupabaseを要件に組み込んでくることが多いと感じられます。もちろん要件に合わない場合は外せば良いのですが、デフォルトで入ってくるとそのまま受け入れるケースも多いのではないでしょうか。LLMに聞いた時に、候補に上がってこないサービスは衰退していくと予想されます。
4つ目は、継続性によって価値が生まれるものです。単純にデータを蓄積すれば良いというわけではなく、データのベンダーロックインでもありません。データが蓄積することで、新しいビジネス価値を提示できるものは、使い続ける価値があります。SalesforceやDatadogはその系統のサービスだと思っています。Datadogを入れて即価値を見出すのは難しいですが、データが蓄積されていくことで可視化される領域が広がっていき、サービス価値が感じられるのではないでしょうか。Salesforceも今現在の対応状況だけでなく、過去の履歴やクライアントの状況がグローバルに共有されるからこそ、価値があるでしょう。
5つ目は、圧倒的な安価です。他社では真似できないレベルの安価であれば、選ばれる可能性があります。その最たる例がオープンソースです。オープンソース = 無料という認識はよくないですが、少なくともオープンソース・ソフトウェアであれば自社の責任において無償で利用できます。また、Cloudflareのように多くのサービスを無料で使えてしまうのも、他社との差別化になるでしょう。ただし、無料からの有料化は別な茨の道とも言えるので注意が必要です。
最後はデファクトスタンダードです。最たるものがMicrosoft OfficeやAdobe、Autodeskです。デザイナーの中でのスタンダード、CADの世界でスタンダードになることで、どれだけ価格が上がっても使い続けざるをえない状態になっています。Affinityが無償化を実施しましたが、あれで環境を移せるのは個人ユーザーくらいでしょう。ビジネスで使っている場合、スイッチできない状態になっているのではないでしょうか。
もし自社サービスがSaaSの場合、この辺りの生き残り戦略を見極めておかないと、あっという間に乗り換えられてしまう可能性があります。スイッチ先はライバルの場合もあれば、オープンソースや自社開発の可能性もあります。
AI、というよりLLMがSaaSの世界を一変しようとしています。2026年もまた、荒れそうで楽しみ（？）です。
]]>With Todoist, I’ve been using the cheapest legacy business plan at 3,500 yen per year. Looking back, it was incredibly affordable, but this plan is being discontinued. The new business plan will cost 11,520 yen per year. There’s also a Pro plan for personal use at 672 yen per month (8,064 yen annually). Whichever I choose, it’s a 2-4x cost increase.
With rising prices, price increases may be unavoidable in some cases. However, I feel that these kinds of SaaS price hikes are clearly driven by feature additions that users don’t expect. Namely, AI. Todoist has also introduced an AI assistant called Todoist Assist. Frankly, it’s unnecessary. If this price increase is a result of that, it’s extremely disappointing.
Adobe is another well-known example. Adobe’s subscription has become more expensive year after year, and I feel this is largely due to the development burden of AI features. They say 80% of users don’t use even 20% of features, and I think Photoshop and Illustrator are exactly like that. It’s tough to pay for development costs of features unnecessary for most users.
Since I’m already using Google Calendar (with Todoist integration), I decided to switch my task management to Google Calendar and Google Tasks.
However, there’s one problem. I need Todoist’s incredibly convenient feature of “adding tasks via natural language.” For example, being able to input tasks like “next Monday meeting #ProjectA [3 hours]” using natural language. macOS Calendar has a similar feature called Quick Event. However, iOS doesn’t have the same functionality.
Without this feature, entering tasks and scheduling calendar events becomes tedious, and it’s clear it won’t last long. I looked for OSS alternatives to Todoist, but none offered similar functionality.
So I decided to build it myself.
goofmint/Text2Cal: Add schedule to your Google Calendar from natural language.
Text2Cal is a very small tool. It runs on Google Apps Script in Google Sheets. It takes received text, sends it to ChatGPT, and converts it to JSON for schedule input.
When you send a string like:
21th 18:00 Meetup event
It expands to JSON like this:
{
"title": "Meetup event",
"start": "2026-01-21T18:00:00+09:00",
"end": "2026-01-21T19:00:00+09:00",
"location": null,
"label": "0",
"timezone": "Asia/Tokyo",
"recurrence": null
}
This gets registered in Google Calendar. As a result, you get JSON back from Google Calendar like:
{
"id": "l0g...udo",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=bDB...",
"colorId": "8"
}
If you put ! at the beginning of the input text, data is registered in Google Tasks. You input text like !Today Issue Invoice.
Then you just create macOS/iOS shortcuts to send the input string to the Text2Cal web application. I use Google Sheets because it keeps logs of inputs and results, and makes it easy to use Google Calendar and Google Tasks APIs.
With just this, I’ve created the functionality I personally need, and I’m ready to migrate from Todoist. One issue is that the Google Tasks API doesn’t support creating recurring tasks, so even if you enter !Christmas Eve every year, it won’t become a recurring task.
The phrase “SaaS is Dead” became popular a few years ago, but AI (LLMs) has made it more realistic. For small things, building it yourself is cheaper, faster, and fits your requirements better.
What’s most challenging here are services without proprietary databases. Scheduling services are the prime example. Data goes to calendar services like Google Calendar, and not having proprietary data is fatal. Even if you customize for various business requirements, each customer only wants one or two requirements, making other requirements over-development.
If you have a proprietary database, you can take a vendor lock-in strategy to retain users. While users aren’t happy about it, vendor lock-in can keep them using the service. However, if there are user demands for open data and you add export functionality, it might be imported into open-source alternatives. With Todoist, since tasks are meant to be completed, year-old data doesn’t have much value, which is painful.
Services that replace open protocols and platforms have low switching costs, which is both an advantage and a disadvantage. Examples include public cloud instances and email delivery services. If you’re sending email via SMTP, you can switch just by changing the connection destination. If you’re just running EC2 instances on AWS, you can easily switch to other public clouds.
The continuous emergence of open-source alternatives is also a challenge. OpenAlternative lets you find OSS alternatives to various services. Of course, they often don’t have all features, but if they can meet 80% of needs, that’s often sufficient.
So what SaaS will survive? One is those that solve technical complexity. Representative examples are Twilio and Stripe. Payment systems are complex and tedious, but they simplify them. Of course, there are alternatives, but the SaaS market for payments and SMS sending won’t disappear.
Next are those that solve legal issues. For example, freee and SmartHR. They replace necessary business flows like creating financial statements, invoices, and estimates. Accounting and HR software need updates as regulations change yearly. Even with local software, upgrade costs are necessary, and considering multi-platform support like macOS, this market shouldn’t disappear.
Third are SaaS chosen by AI (LLMs). The prime example is Supabase. When developing web apps or smartphone apps that need databases using Claude Code, I often find it incorporates Supabase into requirements. Of course, you can remove it if it doesn’t fit, but when it’s included by default, many cases probably accept it as is. Services that don’t come up as candidates when asking LLMs will likely decline.
Fourth are those where value emerges from continuity. This doesn’t just mean accumulating data or vendor lock-in. Those that can present new business value as data accumulates are worth continuing to use. I think Salesforce and Datadog are this type of service. It’s hard to see immediate value with Datadog, but as data accumulates, the visualization area expands and service value becomes apparent. Salesforce also has value not just for current response status, but because past history and client situations are globally shared.
Fifth is overwhelming affordability. If it’s so cheap that other companies can’t imitate, it may be chosen. The prime example is open source. While “open source = free” is a misconception, at least open-source software can be used free of charge at your own responsibility. Also, Cloudflare offering many services for free differentiates it from others. However, note that monetizing from free is a thorny path.
Finally, there’s de facto standard. Prime examples are Microsoft Office, Adobe, and Autodesk. By becoming the standard among designers or in the CAD world, they create a situation where people must keep using them no matter how much prices rise. Affinity implemented free pricing, but probably only individual users can migrate. For business use, they’re likely in a state where they can’t switch.
If your own service is SaaS, you need to identify these survival strategies, or you might be switched away quickly. The switch destination might be a rival, open source, or in-house development.
AI, or rather LLMs, are about to transform the SaaS world. 2026 will likely be turbulent and exciting too.
]]>2018年くらい（？）にEmacsからVS Codeに乗り換えて、ブログなどのライティングもVS Code上で行うようになっています。そして、2023年頃に現れたのがGitHub Copilotです。エンターキーを押すと、それっぽいコードをインテリジェンスに出してくれます。変数名の補完も、関数名も自在に保管してくれ、革命的に便利な機能でした。
たぶん最初の頃はプログラミング言語に対してだけ有効だったはずなのですが、すぐにドキュメントにも補完が行われるようになりました。ちゃんと日本語で、こちらの気持ちを察して生成してくれる。素晴らしい！
でも、それも先日まで。残念だけれど、Markdownに対してはGitHub Copilotは無効にしました。
その要因は、生成AIによって自分の思考回路が引っ張られる感覚が強くなったからです。文章の書き方は人によって違うと思いますが、私の場合は割と雰囲気で書いているところが大きいです。徐々に書いていく中で言語化・解像度が上がって結論につながっていくイメージです。
そうした書き方だと、長文の補完が出てきてそれを採用すると、自分の思考までぐっとそっち側に引きずられてしまいます。サジェストを数回採用すると、そもそも自分が書きたかった内容ではない「何か」になってしまっています。
その感覚を覚えてから、GitHub Copilotに書かせるのはダメだと気づきました。ゼロから一を作る部分は自分で進めなければ、何の面白みもない空気みたいな文章が生まれてしまう気がします。
もちろん、手作業で書くと時間がかかるし、支離滅裂な部分があったり、誤字もあるかもしれません。そうした時に最低限の編集をAIに任せるのは良いかもしれません。
AIで作るドキュメントとして向いているものがあるとすれば、ある程度作成したソフトウェアのREADMEや、ドキュメントはいいと思います。ベースになるソフトウェアのコードはあるので、それを網羅的に調べてドキュメントを作ってくれるのはAI向きではないでしょうか。
ブログはそうじゃなく、私の中にコンセプトがあって、それを吐き出す場です。そこにAIが絡むと若干の気持ち悪さがあるなぁと。
先日、zenn.devでブログ記事の自動英訳機能が炎上していました。
記事の英語版生成の実験的な提供を開始します（Beta） | What’s New in Zenn
デフォルト有効というのはよくなかったかも知れませんが、自動英訳自体はいいと思います。日本語の記事でとてもいい内容なのに、日本語であるためにグローバルに届いていないものがたくさんあるからです。
たとえばCodeRabbitに関する日本語の記事を紹介したいと思った時に、それを英訳してからSlackで共有するのは面倒なんですよね。日本にいいエンジニアがいることをアピールしたいのに、日本語という言語が壁になってしまうのは非常に勿体無いと感じています。
もちろん、誤訳があったり、どこからかいきなりツッコミが来るかも知れませんが、それも含めてコミュニケーションなんじゃないでしょうか。誤訳があっても自分が悪いわけではなく、zenn.dev側の問題ですし、0.001%の誤訳を恐れてグローバル発信を嫌がるのは勿体無いです。
ということで、この文章もAI味ゼロ%でお届けしました。
]]>Around 2018 (?), I switched from Emacs to VS Code, and I started writing blog posts and other content in VS Code as well. Then, around 2023, GitHub Copilot appeared. Press Enter, and it intelligently suggests code that looks just right. It autocompletes variable names and function names with ease—it was a revolutionary convenience.
I think it was initially only effective for programming languages, but soon it started autocompleting documentation as well. It would generate suggestions in proper Japanese, seemingly understanding my intent. Wonderful!
But that lasted only until recently. Regrettably, I’ve disabled GitHub Copilot for Markdown files.
The reason is that I’ve increasingly felt that generative AI was pulling my thought process in its direction. I think everyone has their own way of writing, but in my case, I write more intuitively. As I gradually write, my thoughts become clearer and more articulate, eventually leading to a conclusion.
With this style of writing, when a long suggestion appears and I accept it, my own thinking gets dragged in that direction. After accepting suggestions a few times, what I end up with is “something” completely different from what I originally wanted to write.
Once I realized this, I understood that letting GitHub Copilot write for me wasn’t working. If I don’t create that initial spark myself, the result feels like a bland, lifeless piece of text.
Of course, writing manually takes time, and there might be incoherent parts or typos. In such cases, it might be fine to let AI handle minimal editing.
If there are documents that are suitable for AI creation, I think READMEs and documentation for software that’s already been developed to some extent are good candidates. Since the underlying software code exists, having AI comprehensively examine it and create documentation seems like a good fit.
Blogs, on the other hand, are different—they’re a place for me to express concepts that exist within me. Having AI involved in that feels somewhat unsettling.
Recently, there was a controversy on zenn.dev about an automatic English translation feature for blog posts.
Having it enabled by default might not have been the best choice, but I think automatic translation itself is fine. There are many articles in Japanese with excellent content that don’t reach a global audience simply because they’re in Japanese.
For example, when I want to share a Japanese article about CodeRabbit, it’s a hassle to translate it into English before sharing it on Slack. I want to showcase the great engineers in Japan, but it’s a real shame that the Japanese language becomes a barrier.
Of course, there might be mistranslations, and someone might suddenly point them out, but isn’t that all part of communication? If there are mistranslations, it’s not my fault—it’s an issue on zenn.dev’s side. It’s a waste to avoid global outreach because of fear of 0.001% mistranslations.
So, this text was delivered with 0% AI flavor (only translation by Claude Code :-)).
]]>DASAによると、DevAIOpsには5つの原則があるとしています。
2025年はAIコーディングが流行り、エンジニア界隈は大きく揺れ動きがありました。AIコーディングエージェントは、それなりに良いコードを（最初は）書くのですが、突然崩壊したり、これまでのルールを逸脱するようなコーディングによって、私たちを悩ましていたと思います。個人的にはSpecKitを使ったり、コーディングガイドライン、小さなPRなどによって制御しようとしていますが、それでも時折悩まされることもまだあります。
とはいえ、AIコーディングエージェントがなかった時代に戻ることはもはや難しいでしょう。もし企業において、全面的に禁止したとしても、個人のスマホからAIを使うようなシャドーAIが蔓延る世界にしかならない気がします。
そうした潮流は、2026年において、さらに別な領域に広がっていくと予想されます。
こういった技術に対して、さらにAIによる自動化が進んでいくものと思われます。
この辺りまでは自動でできそうな気がします。
DevOpsは、開発と運用を以下の8領域に分割します。そして、各領域におけるAI/LLMの取り組みについてもまとめてみます（過不足あります）。
| 領域 | AI |
|---|---|
| PLAN / 計画 | 要件の壁打ち、レビュー |
| CODE / コード | SDD、AIコーディングエージェント、AIコードレビュー |
| BUILD / ビルド | |
| TEST / テスト | テストコード生成、柔軟なテスト実行、エラー時の原因究明 |
| RELEASE / リリース | リリースノート生成、ドキュメント反映 |
| DEPLOY / デプロイ | |
| OPERATE / 運用 | 異常検知 |
| MONITOR / 監視 | アラートノイズ軽減 |
現状では、領域ごとにグラデーションがありそうです。2026年では、不足している領域に対して、強力なサービスやソフトウェアが登場してくるのではないかと思います。
AIがDevOpsに入り込んでくるのは、もはや止められないでしょう。それを押し留めようとするのは、2000年前半のクラウドへの対抗だったり、2010年代のスマホ・タブレットへの抵抗に似たものかもしれません。時代の流れが変わってしまっているので、抗う意味がありません。
となると、1個人としては「乗るしかない、このビッグウェーブに」となる他ありません。コーディング領域は2025年、すでにAIによって破壊的変更が行われてしまっているので、他の領域についても積極的に取り組んでいくのみです。
そして、そうやってAIを積極的に取り入れた結果、人は何を行えば良いのでしょうか。人ができるのは「コミュニケーション」と「責任」です。
AIはベストプラクティス（っぽい）ものを出してくれますが、それっぽいだけです。過去の膨大なコンテンツに基づいた、それっぽいものを出しているだけに過ぎません。いわば、車輪の再発明の壮大なバージョンです。
逆に、これまでにない何かを作る際には、多くの失敗が伴うでしょう。また、多くのLLMでは、人が良いと判断する方向に出力を行うので、間違った意見でも肯定的になりがちです。これはビジネス的、個人的に大きなミスにつながる可能性があります。そのため、AIをコンサル代わりにすると、基本的はレポーティングはよくとも、その後のビジネス価値などではミスリーディングする可能性があるので注意が必要です。
そうした意味で、人に求められているのは人と人のコミュニケーションを通じて、課題や解決策を見出す能力です。私たちはAIに対してサービス開発する訳ではないので（たぶん）、人や企業が良いと思ってもらう必要があります。そうした部分は割とエモーショナルな部分が関わるので、機械的に「良いはず！」とゴリ押ししても通じない部分があるでしょう。
AIに責任は取れません。ChatGPTなど、LLMのサービスでは常に「回答は必ずしも正しいとは限りません」と書かれていますし、これは変わらないでしょう。つまり、AIが出力した何かに対しては、人が常に責任を持たなければならないということです。エンジニアが「AIが出力したので」と回答することはあってはならないのです。
ただし、AIの出力に対して人が見やすく、確認しやすくすることはできます。私が関わっているCodeRabbitはコードレビューに対して、サマリーやシーケンス図、変更ポイントをまとめて「人がレビューする際の認知負荷」を下げることができます。こうした人のための舗装作業をAIに行ってもらうことはできるでしょう。エラーが起きた際に、その要点をまとめたり、解決策を提案してくれるのも一つです。
人は責任を取りますが、責任を取りやすい形にするのもAIの役割になっていくと推測されます。
個人的に2026年はDevAIOpsのトレンドが来ると考えています。2025年はコーディング領域がメインでしたが、他の領域においてもさらにAIが活用されていくと思われます。特にテスト・CI・運用・監視の領域はもっとプレイヤーが増えるのではないでしょうか。場合によっては、既存プレイヤーが一気に壊滅される未来があるかもしれません。
個人のエンジニアとしては、戦々恐々とする部分もあれば、逆にチャンスもあると思います。新しいツールを作って世界的に広めるチャンスにもつながるでしょう。翻訳なんぞAIでも十分ですし、OSS + SaaSのビジネスモデルは嫌というほどあります。2026年もビッグウェーブがまだまだ起きるのではないでしょうか。
]]>According to DASA, DevAIOps has five principles:
In 2025, AI coding became popular and caused significant disruption in the engineering community. AI coding agents wrote reasonably good code (at first), but they frustrated us with sudden breakdowns and coding that deviated from established rules. Personally, I’ve tried to control them using SpecKit, coding guidelines, and small PRs, but I’m still occasionally troubled by them.
That said, it’s difficult to go back to an era without AI coding agents. Even if companies ban them completely, I feel like we’ll only end up in a world where shadow AI proliferates, with individuals using AI from their personal smartphones.
This trend is expected to expand into other areas in 2026:
These technologies are likely to see further automation through AI.
It seems like automation up to this point is achievable.
DevOps divides development and operations into the following eight areas. Let me also summarize AI/LLM initiatives in each area (there may be gaps):
| Area | AI |
|---|---|
| PLAN | Requirements brainstorming, review |
| CODE | SDD, AI coding agents, AI code review |
| BUILD | |
| TEST | Test code generation, flexible test execution, root cause analysis for errors |
| RELEASE | Release note generation, documentation updates |
| DEPLOY | |
| OPERATE | Anomaly detection |
| MONITOR | Alert noise reduction |
Currently, there seems to be a gradation across areas. In 2026, I think powerful services and software will emerge for areas that are currently lacking.
The integration of AI into DevOps cannot be stopped. Trying to hold it back may be similar to resistance against cloud in the early 2000s or resistance to smartphones and tablets in the 2010s. The times have changed, so there’s no point in resisting.
For individuals, there’s no choice but to “ride this big wave.” The coding area has already undergone disruptive changes by AI in 2025, so we just need to actively tackle other areas as well.
So, after actively incorporating AI in this way, what should humans do? What humans can do is “communication” and “responsibility.”
AI produces what seems like best practices, but it’s only seemingly so. It’s just producing seemingly good things based on vast amounts of past content. In other words, it’s a grand version of reinventing the wheel.
Conversely, when creating something unprecedented, many failures will accompany it. Also, since many LLMs output in a direction that humans judge to be good, they tend to be affirmative even with incorrect opinions. This can lead to major mistakes in business or personal matters. Therefore, if you use AI as a consultant substitute, while the reporting may be good, you need to be careful as it may mislead in terms of business value afterward.
In this sense, what is required of humans is the ability to find issues and solutions through human-to-human communication. We are not developing services for AI (probably), so we need people and companies to think well of us. Such aspects involve fairly emotional elements, so mechanically pushing “It should be good!” won’t get through.
AI cannot take responsibility. LLM services like ChatGPT always state “answers are not necessarily correct,” and this won’t change. In other words, humans must always take responsibility for what AI outputs. Engineers should never respond with “because AI outputted it.”
However, we can make AI output easier for humans to see and verify. CodeRabbit, which I’m involved with, summarizes summaries, sequence diagrams, and change points for code reviews to “reduce the cognitive load when humans review.” Such paving work for humans can be done by AI. One example is summarizing key points when errors occur or suggesting solutions.
Humans take responsibility, but making it easier to take responsibility is also expected to become AI’s role.
Personally, I believe the DevAIOps trend will come in 2026. While 2025 was mainly about the coding area, AI will be further utilized in other areas as well. In particular, I think there will be more players in the testing, CI, operations, and monitoring areas. In some cases, there may be a future where existing players are completely destroyed.
For individual engineers, while there are parts to be anxious about, there are also opportunities. It could lead to opportunities to create new tools and spread them globally. Translation is sufficient with AI, and there are plenty of OSS + SaaS business models. I think big waves will continue to occur in 2026.
]]>