生成AIの進化により、アプリケーション開発の在り方が大きく変わり始めています。 AIがコードを書くという世界も、もはや遠い未来の話ではなくなってきました。 本記事では、Codexを活用し、Javaアプリケーション開発をAIがどこまで実践できるのかを検証していきます。 想定読者 AIでアプリケーション開発をしたい人 Codexの基本を理解している人 JavaでのWebアプリ開発の経験がある人 Tomcat,PostgreSQLの基本知識がある人 環境構築編 全体構成 全体構成は以下になります。 Codexは現状Linux環境のほうが動作が安定するため、Windows環境上に

はじめまして、プロダクト推進本部カイポケ開発部でエンジニアをしている木野と申します。 2025年1月に入社し、あっという間に1年が過ぎました。 入社して感じたこと、育児をしながら働いてみてどうだったかを中心に振り返っていこうと思います。 現在エス・エム・エスに興味をお持ちの方の参考になれば嬉しいです！ ドメイン知識の習得と現場を知る大切さ 複雑な制度をシステムに落とし込む 私は介護事業者向け経営支援プラットフォーム「カイポケ」の障害福祉分野の開発に携わっています。 介護や障害福祉の事業所は、国が定めた制度に則って運営されています。 そのため私たちが開発する際も「行政から出される資料を読み解き、正しくシステムに反映すること」が何より重要になります。 制度、特に報酬算定（お金の計算）のルールは非常に複雑で、考慮すべきパターンや例外処理の難易度がとても高いです。 私は以前歯科向けの電子カルテ開発をしていた経験があり、厚生労働省の資料を読むことには多少慣れていました。ですが実際に障害福祉の分野に入ってみると、歯科とは考え方が異なる部分も多く、1年経った今も日々試行錯誤しています。 例えば歯科は「何をやったか（診療単位）」が基本ですが、介護や福祉は「誰が、どんなことを、何時間提供したか」といった要素の組み合わせで計算が変わります。 この「算定パターン」をどうシステムに落とし込むかを考えるのは、悩む場面が多いです。 ただこの難しさは同時に面白い部分でもあります。 制度の変更は現場のニーズや社会情勢が反映されたものです。資料を読み込み、落とし込んでいく作業を通じて、社会課題に向き合い、取り組んでいる実感が持てるのはこのドメインならではのやりがいだと感じています。 現場を知る 入社して早い段階で、実際の放課後等デイサービス事業所を訪問する機会をいただきました。 現場のスタッフの方々からお話を伺い、実際の忙しさや、業務上まだまだアナログが多い現状を直接目にすることができました。 本来の業務である「利用者への支援」に集中するため、事務作業を効率化する必要がある。 それを肌で感じたことで、自分が作っているシステムが解決すべき課題が明確になり、開発に向き合うモチベーションが高まりました。 実際の現場を見た後は、画面の入力方法を検討する際も「現場の入力負荷が増えないか？」「実際の業務フローとして不自然ではないか？」と、 解像度を上げて考えられるようになりました。 現場を知ることは、業務の解像度を高めるだけではなく、エンジニアとしての視点を広げるためにとても大切だと実感しています。 こうした事業所見学や体験を通じて現場を知る機会は社内に定期的にあり、 現場の「肌感覚」を大切にできる環境は非常にありがたいなと思っています。 「なぜやるのか」という文化 入社して一番驚いたのは皆さんのスキルの高さ、開発部全体に根付いている「なぜこれをやるのか」を考える意識の高さでした。 単に「どう実装するか」という技術的な話だけでなく、「なぜこれをやるのか」「なぜこの修正が必要なのか」「それによって誰がどう幸せになるのか」という問いかけをとても大切にしています。 もし自分の考えがぼんやりしていれば、納得いくまで前提から丁寧にすり合わせをしてくれます。 このおかげで、ブレることなく進められた場面が多くありました。 最初はレビューで「なぜこの実装にしたのか？」と問われても、言語化できずに固まってしまうこともありました。 チームのメンバーは、単に正しい書き方を教えるのではなく、「どういう理由でこの形にしたのか」という意図を根気強く引き出そうとしてくれました。 そのおかげで目先のコードの書き方だけではない、開発の根底にある「考え方」の大切さに気づくことができました。 この文化はコードレビューや設計の場だけでなく、チームの運営や方針を決める際にも徹底されていると感じます。 納得できないことがあればオープンに質問でき、それに対して「なぜこれを行うのか」を納得いくまで議論しています。 「なぜやるのか」を全員が徹底していることで、「誰のどんな助けになるのか」が明確になり、より誠実にプロダクトに向き合えているのだと感じています。 日々どうすればもっと良くなるかを考え抜いている皆さんをみて、1年経った今、私も自然と「なぜやるのか」を自問自答できるようになってきたと感じます。 今後は私もそんな風に、誰かの視界をクリアにできる存在を目指していきたいです。 モダンなツールとチームの支え 実際の開発業務では、本格的なJavaの開発は初めてで戸惑いもありました。 それでも、AIツールの活用やチームメンバーによる丁寧なレビューに助けられ、無事にいくつかの案件をリリースできています。 最近は、AIを日々の実務にうまく取り入れる流れが活発です。 個人としては、テストコードの作成やセルフレビュー、ドキュメント作成など日常的な作業の各所で活用しています。 チームとしても共通で使える各種設定を作成したりと、効率化がどんどん進んでいます。 先日もチーム間でAI活用の情報交換会が行われました。 「具体的なプロンプトをどう工夫しているか」といった現場ならではの共有が多く、非常に参考になりました。最新情報の共有もSlackなどで日常的に行われており、ツールを使いこなしながら、より本質的な設計や議論に時間を割こうとする自然な雰囲気があると感じています。　　 子育てとフルリモートワーク 「家族優先」が当たり前の空気感 私は現在、未就学児2人の育児中です。 入社直後は「急な欠勤や早退で迷惑をかけるのではないか」と心理的なハードルを高く感じていました。 その不安をオファー面談でお伝えしたところ、入社前に子育て中のエンジニアの方々とお話しする「座談会」を設けていただけました。 育児している時間が減るが、技術的なキャッチアップはどうしているか 急な休みはどう調整しているのか お迎えで1度抜けたり柔軟な勤務は可能か といったリアルな話をフランクな雰囲気で聞けたことが、入社を決める大きな安心材料になりました。 実際に働いてみると、開発部全体に「家族や自分の体調を最優先にする」空気が文化として根付いているのを実感します。 例えば、子供が急に発熱して中抜けや欠勤が必要になった際も、チームの皆さんが「お大事に！」「家族優先」と、当たり前のようにフォローし合える環境があります。 入社直後、メンバー数名体調不良で不在だった時期がありました。 その際も「お互い様だから無理せず休もう」という空気感が徹底されており、新入社員としての心理的なハードルがすっと下がったのを覚えています。 フルリモートで働くこと フルリモートと聞くと、コミュニケーションや情報のキャッチアップに不安を感じる方も多いかもしれません。 実際、社内には膨大なドキュメントやアウトプットがあるため、最初は情報の多さに圧倒されることもありました。 ただ、次第にすべてを完璧に追うのはやめて、esaの検索を工夫したりAIツールで要約したりと、自分なりのハンドリング術を模索するようになっています。 この情報の取捨選択スキルは、この1年で得た意外な収穫のひとつです。 Slackでのコミュニケーションも驚くほど活発です。 子育て中のメンバーが集まるチャンネルや趣味のチャンネルなど、業務外のつながりも多いため、リモート特有の孤独感を感じることはほとんどありません。 加えて、日々の業務における連携のオープンさも、大きな安心感につながっています。 例えば、メンションをつけていない独り言のような投稿に対しても、誰かがさっと解決策を提示してくれたり、類似案件を教えてくれたりすることがあります。 困ったときはすぐに「ハドル（音声通話）しようか」と声がかかるので、自宅で一人悩んで孤立することもありません。 程よい距離感の交流会もあり、オンライン越しでもチームのつながりをしっかりと感じられています。 終わりに 1年を振り返ってみました。 改めてエス・エム・エスに入社して良かったと感じています。 業務解像度が上がってきた今、新しいことにチャレンジをしながらさらに頑張っていきたいと思います。

こんにちは、kosuiこと岩佐幸翠 (@kosui_me) です。カケハシで認証権限基盤チームのテックリードを務めています。 私たちのチームでは、認証基盤・ID基盤・端末基盤・ライセンス基盤など、様々なプラットフォームシステムをTypeScriptで構築しています。 サーバサイドTypeScriptをビジネスとして実践する場合、動的型付けのPythonやPerl、クラスベースの名目的型付けのJavaやC#、パターンマッチ中心のElixirなど、型に対するアプローチが異なる言語の経験者が、様々なバックグラウンドを持ったチームメンバーとして開発・運用することとなります。しかし、それぞれのバックグラ…