こんにちは。ソフトウェアエンジニアとして、カケハシの新規プロダクトの開発をしている鳥海です。
カケハシでは、組織横断で特定のテーマについて知見を深め合う「研究会」という取り組みがあります。 今回は、その中の AI 活用研究会からの発信です。
今回のテーマは、未経験領域である Windows アプリ開発において、AI を活用しながら立ち上げの初速を出しつつ、Web フロントエンド開発との文化の違いを吸収し、経験者との共創を通じて価値を作っていく方法です。 実際に取り組んだ内容をもとに、うまく進んだことだけでなく、失敗しかけた場面やそのときに感じていたことも含めて、背景や課題感、どのように考えて進めたのかをまとめます。
いまどんな状況で向き合っているのか
私が現在関わっているのは、新規プロダクトにおける Windows アプリケーションの開発です。 もともと私は Web フロントエンドエンジニアとしての経験が中心で、Windows アプリの開発経験はありませんでしたが、この領域に一人目のエンジニアとしてアサインされる形で開発に向き合うことになりました。
未経験領域に一人目として入ることになったときは、正直かなり不安でした。Webでは、ブラウザが間に入ってくれることで、OSのことはあまり考えずに開発できます。また、配布の方法なども違ったりします。このようにWeb では当たり前にできていた判断が Windows アプリでもそのまま通用するのか確信が持てず、「動くものは作れても、それが自然な作りなのかは分からない」という感覚がずっとありました。
立ち上がりの時期は、技術選定や実装方針の検討、仕様理解のどれをとっても手探りな部分が多く、知識や経験が十分ではない中で意思決定していく難しさがありました。 最近は C# の経験があるメンバーもチームに加わり、徐々に相談しながら進められる体制になってきていますが、個人としてもチームとしても学習しながら価値を作っていく必要がある状況です。
一方で、実際に AI を使いながら手を動かしてみると、最初に思っていたよりも前には進める感覚もありました。「意外とやれるな」と思える瞬間が少しずつ増えていったことは、未経験領域で試行錯誤を続けるうえで大きな支えになりました。
なぜ未経験領域の新規事業開発をリードすることは難しいのか
未経験領域での新規事業開発が難しいのは、単に知らない技術を学べばよいわけではなく、何を作るべきかとどう作るべきかを同時に考える必要があるからだと感じています。
既存の事業や経験のある領域であれば、業務の前提や技術選定の勘所、過去の進め方がある程度見えていることも多いです。一方で新規事業では、どこに価値があるのか、どの機能を優先すべきか、今のフェーズに合った作り方は何かを探りながら進める必要があります。
その状態で未経験領域に入ると、仕様の妥当性、技術選定、実装方針のいずれにおいても判断の拠り所が少なくなりやすく、意思決定そのものの難易度が上がります。特に立ち上げ初期は相談できる相手や前例も少ないため、自分で解像度を上げながら進める必要があり、そこに難しさがあると感じています。
加えて、今回は Web フロントエンド開発と Windows アプリ開発で、設計判断の置きどころに違いを感じる場面も多くありました。
どちらの開発でも、まず動くものを素早く作ること自体は重要です。一方で Windows アプリ開発では、その後の保守性や責務分割をどう考えるかといった観点で、自分がこれまで慣れていた判断基準との差を感じることがありました。
そのため、単に AI でコードを出して前に進むだけではなく、どういう観点で設計や実装を判断するのかという考え方自体を吸収していくことが重要でした。
この状況下でどう進めるか
未経験の中、AIを使って早めに形を作る
未経験の状態で立ち止まりすぎないために、まずは AI を使って早めに形を作ることを意識しました。 コードのたたき台や画面・処理の骨格を早い段階で作ることで、PdM と「いま考えている要件はこの形で実現できそうか」を具体的に確認しやすくなります。 動くものがある状態にしておくことで、文章だけでは曖昧になりがちな認識合わせを、実物ベースの会話に変えられるのが大きかったです。
AI の出力をそのまま使わず、経験に変えていく
Anthropic の記事でも書かれている通り、AI の使い方次第で学習効率は大きく変わります。
PdM が整理した要求に対して、それがどういう概念なのか、実現には何が必要なのかを AI も使いながら掘り下げていきます。 ただ、AI の説明や実装案はもっともらしく見えるぶん、そのまま採用すると危ないこともありました。実際、Windows アプリでは一般的ではない実装パターンをそれらしく提案され、そのまま進めていたら後で直すことになりそうだった場面もあります。最初は速く進めたつもりでも、レビューやリファクタリングで結果的に工数が増えることがあり、AI に頼りすぎる難しさを感じました。 また、リファクタリングや日々のカイゼンを通じて、「なぜ今の実装がよくないのか」「どのような設計や実装が望ましいのか」を言語化することで、やってはいけない実装についての知見も吸収していきました。
このように、要求事項に対する概念理解を深めることと、日々の改善によるフィードバックループを回すことを通じて、未経験ながら少しずつ経験や知識を自分のものにしていきました。
自分と新規メンバーで体系化していく
AI を使うことで、現在の要件や既存コードから学べることは多くあります。一方で、運用や保守を見据えた判断、他のケースに広げたときの考慮、Windows アプリ開発ならではの設計観点については、経験者との対話が不可欠でした。
特に、namespace の切り方や責務分割、UI スレッドと async/await の扱いは、経験者との会話を通じてレビュー観点として明文化していったポイントの一つです。たとえば、Web の感覚で「まずは動くものを作って、あとから整理すればよい」と考えそうになったことがありましたが、Windows アプリでは初期の namespace の切り方や責務の置き方が、その後の保守性に強く影響することを学びました。UI スレッドを塞ぐ処理になっていないか、UI イベントハンドラ内の例外が適切に扱われているかに加えて、どこに何を置くべきかという構造の観点も丁寧に見る必要がありました。こうした点は、Web フロントエンド中心だった自分にとって新しく学ぶ部分でした。
最近は C# 経験のあるメンバーとも会話しながら、「どういう観点でレビューするのか」「何をルールとして持っておくべきか」を少しずつ明文化するようにしています。たとえば、明文化した内容を次のような形でルールに落とし込んでいます。
- レビューツールである CodeRabbit のレビュー観点に追加する
- Claude Code のルールや Agent Skills に追加する
このように経験者との共創で判断の質を上げ、その知見をチームで再利用できる形にしていくことで、日々起こるチームの体制変動があっても、適切に運用ができる開発体制を作っていくことができます。
進める中で見えてきた難しさと気をつけたこと
AI とともにコーディングを進めるうえで、特に難しいと感じているのは、運用や保守まで見据えた設計判断です。 目の前の要件を満たすコードを書くことはできても、それが長期的に扱いやすいか、将来の変更に耐えられるか、Windows アプリの文脈で自然な形かどうかは、経験の差が出やすい部分だと感じています。
また、AI が API やライブラリの使い方をもっともらしく補ってきて、こちらも「たぶんそうだろう」と受け取ってしまい、実際には成立しない前提で調べ直すこともありました。AI がハルシネーションしたというより、自分が十分に検証しないまま採用しかけた、というほうが正確かもしれません。
そのため、AI の出力を鵜呑みにせず、経験しているメンバーの観点を取り込みながら進めることを強く意識しています。未経験領域に飛び込むときほど、AI に任せる部分と、人に学ぶ部分の線引きを丁寧にすることが大切だと思いました。
まとめ
AI の力を借りることで、未経験領域でも立ち上げの初速を出し、手を動かしながら理解を深めていくことは十分可能だと感じています。 一方で、AI は「正解らしいもの」を素早く返してくれても、その領域で自然に保守していくための「作法」まで自動で身につくわけではありませんでした。 だからこそ、価値あるプロダクトを継続的に作っていくうえでは、AI だけで完結するのではなく、その領域を経験してきたメンバーと共創しながら判断の質を高めていくことが重要でした。
まだ道半ばではありますが、未経験領域に飛び込む際の一つの進め方として、参考になれば嬉しいです。 ここまで読んでいただき、ありがとうございます。カケハシでは、引き続き採用を進めていますので、ご興味が深まれば、幸いです。
