はじめに とあるプロジェクトで手動運用業務をAIを活用して効率化したいという背景で参入、すでに複数の自動化ツールを作成しました その経緯で学んだことをまとめてみます。 本記事のテーマ AIを活用した業務効率化を担当することになり、本格的に生成AIを学び実践してきました。 その中で最も重要だと感じたのは、「AIが回答しやすい・考えやすい環境を作ること」 プロンプトの工夫ももちろん大切ですが、求めている回答を引き出すには、前提となる「潤沢な背景情報」が不可欠 もしAIに渡す情報が足りているか不安なときは、「今の指示で足りない情報はありますか？」とAI自身に聞いてみるのも1つの手だと思

はじめに こんにちは。medibaの山本です。 エンジニアとしてSES企業でさまざまな開発を渡り歩いた後にmedibaに入社し、受託開発案件のBE・インフラ領域でリーダー業務に携わってます。 普段の開発業務のなかで、「見積もり」に膨大な時間を取られて頭を悩ませることはありませんか？ 今回は、思い切って見積もり作業の一部をAIに委任してみた試行錯誤の記録と、そこから見えてきた課題・今後の方針について共有します。 AI見積もりの導入の背景と目的 開発組織において、見積もりは常に「重い課題」としてのしかかります。私たちのチームでも、以下のような課題を抱えていました。 調査コストが

medibaでCTOをしている下地(@primunu)です。 AI版の自分を実装してみたのでその経緯等をまとめてみました。 きっかけ：「自分らしいAI」を実装してみる 昨今、生成AIを活用して「自分の分身」を作る事例が注目されています。 そうした流れの中、私自身も思い立ちました。 「学習も兼ねて、自分の思考・価値観を反映したAIを実際に作ってみよう」 社内メンバーがGeminiを活用し「AI上司Gem」のプロンプトを公開していたので、それをベースに実装を開始しました。ツール自体はすぐに動作しましたが、「自分らしさ」の精度を高める調整に、結果として15時間以上を費やすことになりまし

先日、AWSの「AI-DLC（AI-Driven Development Lifecycle：AIネイティブなソフトウェア開発ライフサイクル）」ワークショップに参加してきました。 「AIを使って開発を効率化したいけれど、いまひとつブレイクスルーを感じない」という方に向けて、AI開発の最前線と、実際にワークショップでシステムを構築した体験談を簡単にまとめます！ 1. なぜ「AI-DLC」が必要なのか？ 現在主流となっているAI活用のアプローチには、実はそれぞれ限界があります。 AI-Managed（AIが全て自律実行）の限界: 人間の介入がないため、複雑なロジックで誤ったり、組織固

はじめに はじめまして。株式会社medibaで開発組織のマネージャーを担当している成田です。普段の業務領域では、主にテスト工程や品質管理（QA）にかかわる領域を担当しています。 昨今、AIによる開発支援は、すでに「便利な補助ツール」という段階を超えつつあります。 コードを書く、テストコードを修正する、エラーを調査する、設計案を出す、既存コードを読んで改善案を提案する。特にコーディング領域におけるAIの能力はすさまじく、人間の作業速度や探索範囲を大きく上回る場面が増えています。 一方で、「AIに任せればすべてうまくいく」という話でもありません。国内外のコミュニティでも議論され始めていま

はじめに こんにちは。medibaの原です。 mediba入社後、エンジニアを経て、現在はSysDir / TCL として、主にブリッジ体制でのベトナムの開発会社を利用したオフショア開発に携わっています。 エンジニアから現在の立場になり、いくつかのプロジェクトを俯瞰して見る中で、スムーズに進行するケースと、いわゆる「品質問題」に直面して現場が疲弊してしまうケース、その境界線がどこにあるのかを考える機会が増えました。 今回は、私が社内でのヒアリングや実務を通じて感じている「オフショア開発におけるインプットの重要性」について、等身大の視点でお話しできればと思います。 上手くいくプロ

はじめに こんにちは。株式会社medibaでバックエンドエンジニアをしております井上です。 日々のプロダクト開発において、新機能の追加やユーザーへの価値提供のスピードは非常に重要です。特に事業をグロースさせるフェーズでは、スピード優先で開発を推し進めるべき時期もありますよね。 決してそのスピードを落としたいわけではないのですが、走り続ける中でどうしても後回しになりがちな「既存コードの見直し（リファクタリング）」について、今回は少しだけお話しさせてください。 今回は、長く運用しているシステムで起こりがちな「あるある」なシチュエーションを例に挙げながら、**「時には少しだけ立ち止まって、

はじめに 「ガードレール」、最近インフラやセキュリティ系の話題でよく目にする単語です。 私も普段からAWSやGoogle Cloudを触っており、IAMの権限管理やネットワーク設定の基本は理解しているつもりでした。 しかし、社内クラウド環境への「ガードレール導入プロジェクト」を担当することになった時、最初に頭に浮かんだ率直な感想はこれでした。 「ガードレール？ 道路にあるアレですか？」 各クラウドサービスの機能は知っていても、組織規模での「ガードレール型の統制」という概念がどういうものなのか、すぐにはピンときませんでした。 そこで今回は、ガードレールという考え方の概念や従来のセキュリ

! あくまで本記事の内容は個人的な見解であり、会社を代表するものではありません。 はじめに 私の周りで最近よく耳にする「BTC人材（Business, Technology, Creativeを兼ね備えた人材）を目指そう」という言葉。これを聞いて、あなたはどう受け止めていますか？ 「また経営層が無理難題を言ってきた」「自分たちの領域が侵食される」と、どこか冷ややかな戸惑いを感じる人も多いのではないでしょうか。 しかし、私はPMとして数々のプロジェクトに関わる中で、ある事実に気づきました。 技術の正しさだけでは、私たちが心血を注いだコードを守り抜くことはできない。 どれだけ素晴ら

はじめに 株式会社medibaでエンジニア組織マネージャーと複数プロダクトの開発責任者を担当している船田です。 GitHub CopilotやClaudeといったAIツールの普及で、コーディングなどの実装工程は効率化されました。しかし、プロジェクト進行中の情報のやり取りにおいて、日々の現場でこんなコミュニケーションが発生していませんか？ 「あの機能の仕様ってどうなってましたっけ？」とエンジニアに質問が飛ぶ → エンジニアが開発の手を止め、過去の仕様書や要件定義書、あるいはソースコードを読み解いて「こうなってます」と回答 こうした確認に対して、エンジニアが過去の資料や複雑なソースコード

AIは「上流」で爆速、「下流」で失速する 開発速度ムラの話 AIコーディングツールを使い始めると、最初は「なんでも速くなった」と感じます。確かに速くなりました。 でも、どこが速くなったのかを正確に把握しておかないと、正しくAIを活用できたと言えないのではと考えています。 水道工に例えて AIが普及してから、「実装速度」という水圧は確実に上がりました。コードは以前より速く書けます。ドキュメントの草案も一瞬で出てきます。 蛇口の水圧が上がっても、「どの機能を作るべきか」「なぜこの設計を選ぶのか」という判断の仕組みは変わっていません。 水を流す勢いは増しましたが、水が正しく流れるため

はじめに バックエンドエンジニアとして業務をしているnipeです。 直近のプロジェクトではフロントエンド開発の比重が高く、 状況によってはフロントエンドのみを担当する機会もありました。 その中で、 Next.js Material UI (MUI) を用いた管理画面の実装を担当することになりました。 フロントエンド領域についてはこれまで触れてきたものの、 Next.js や Material UI を前提とした管理画面開発に関しては、未知な要素も多い状態でした。 そうした状況の中で、今回かなり積極的に活用したのが AI でした。 本記事では、 実装フェーズにおける AI 活用の

こんにちは。medibaテクノロジーセンターで主に業務改善を担当しているやまめです。 はじめに この記事は、medibaが実施した、AIによる知財チェックツールの開発、運用ルールの策定、全社員教育の3つのアプローチについて紹介しています。AI生成画像のリスク管理に悩んでいるDX担当や法務担当の方々の参考になれば幸いです。 AIの生成画像を活用したい 昨今、AI生成画像の進化は凄まじく、これを業務効率化やクリエイティブの質向上に活用したいと思うのは自然な流れでしょう。しかし、企業がこれを推進するにあたって、必ずぶつかるのが、「知的財産権侵害のリスク」の壁ではないでしょうか。 med

はじめに AIによるコード生成において、一つの巨大なプロンプトで全てを完遂させる手法（A群）と、設計・実装・テストといった「スキル」を使い分けながら自律的に試行錯誤するエージェント型（B群）のどちらが優れているかを検証しました。 仮説 A群: 単純なタスクであれば極めて高速だが、複雑な要件や環境特有 of バグに弱い。 B群: 初期コスト（トークン、時間）は高いが、テストを通じた自己修復能力により、最終的な信頼性が高い。 実験結果の比較 評価項目 A群 (Monolithic) B群 (Agentic) 備考 テスト成功率 100% (5/5) 100

はじめに はじめまして、バックエンドエンジニアを担当している小林です。 今回はPMを担当する機会があり、PMをやってみて自分なりに意識したことをまとめてみました。 現在のPM歴は約3ヶ月ほどです。 気をつけたこと メンバーへの反応を早くする 今回PMを担当し、最も気をつけたことはメンバーへの反応を早く行うことです。 反応を早くすることが重要だと考えた点は下記の理由となります。 チームの生産性向上 メンバーが「返事待ち」で手が止まる時間を最小化することで、チーム全体の生産性が向上すると考えました。 見ていることを伝える 反応がないと見てもらえているのかわからないので、質

はじめに エンジニア組織でグループリーダーをやっているチェです。 今回は、社内のモバイルアプリ開発チームで採用しているFlutterでの開発についてお話しします。 現在、モバイルアプリのメイン技術としてFlutterを選定し、開発を進めています。 Flutterという技術選定によって、どのような開発体験がもたらされたのか。 そして、その高い生産性を維持し続けるために、どのようなアーキテクチャとして採用しているのかについて共有したいと思います。 チーム内でのFlutterのアーキテクチャ https://docs.flutter.dev/app-architecture/guide

はじめに 株式会社medibaでバックエンドエンジニアをしているRetchです。 社内でのAI利用が当たり前になり、 開発や意思決定の中にAIが自然に組み込まれるようになってきました。 その過程で、AI活用に関する記事や議論に触れる機会も増え、 いくつか気になる点を感じるようになりました。 本記事では、そうした日々の体感をもとに、 AI時代にエンジニアとして意識しておきたい考え方を整理します。 1. 「AIがやったから」は責任を免除しない 最近、「とりあえずAIでやった」という言葉を耳にすることが増えています。 この表現自体が問題だとは思いません。 正しく使えば、AIは非常に強力

はじめに 初めまして、システムディレクターの浜崎です。 私は元々フロントエンジニアとして、開発現場でコードを書いていましたが、 今後のキャリアを見据えて、2年程前にシステムディレクターという役割に転身しました。 今回は弊社のシステムディレクターについてお話ししていきます。 弊社のシステムディレクターとは 役割を一言で言えば、ディレクター（企画者・顧客）が求める「ビジネス的な要望」と、開発者が求める「技術的な整合性」の間に入り、落とし所を見つける仕事です。 また、スケジュールの管理や先方とのやり取り、必要であればコードを書くなどなんでもします。 『縁の下の何でも屋』という言葉があれ

! この記事の対象読者 採用活動を「業務外の雑務」と感じてしまい、少し距離を置いているエンジニアの方 チームの採用がうまくいかず、リソース不足に悩むテックリードやマネージャーの方 自身のエンジニアとしての視野や可能性を広げたいと考えている方 はじめに 「採用は人事の仕事で、エンジニアはコードを書くことに集中すべき」 そんな風に、採用活動を少し遠いものに感じている方は多いかもしれません。 私はこれまで人事部で10年ほど採用に携わってきましたが、現在は開発現場におり、techと人事を繋ぐ立場として採用もお手伝いしています。 この「tech（現場）」と「人事」の両方の視点を行き来する

Introduction ! この記事は、 mediba アドベントカレンダー2025 の25日目最後の記事です。 25年度はアドベントカレンダーのスタートとエンドを任されました、medibaでCTO/VPoEを やっている下地です。 タイトルの通りですが、CTOに就任して10月で1年、執行役員CTOとなって8ヶ月が経ち、無事に“CTO2年生”になりました。そこで今回振り返りを兼ねて、この1年間でCTOとして実施してきたことを記述していきます。"medibaのCTOはこんなことをしているんだ"という理解を少しでも持っていただければ幸いです。 以前から実施している主な業務 VPo