Movatterモバイル変換


[0]ホーム

URL:


Hatena Blog Tags
はてなブログ トップ
開発プロセス
このタグでブログを書く
言葉の解説
ネットで話題
関連ブログ

開発プロセス

(コンピュータ)
【かいはつぷろせす】

ソフトウェア開発における開発プロセスは,ソフトウェアをどのように作り上げるかについて,手順や工程,要員,成果物,進め方に関する基本的な考え方を定義したもの.

ウォーターフォール型開発プロセスや反復型開発プロセス等がある.

このタグの解説についてこの解説文は、すでに終了したサービス「はてなキーワード」内で有志のユーザーが作成・編集した内容に基づいています。その正確性や網羅性をはてなが保証するものではありません。問題のある記述を発見した場合には、お問い合わせフォームよりご連絡ください。

関連ブログ

【組織進化編】AI×仕組みで「不確実性」をコントロールするプロダクト開発組織

こんにちは。アクセルラボのナカジマです。 以前の記事(前編・後編)では、4つの専門部門と横断型プロダクトチームが連携する、アクセルラボの開発体制の全体像についてご紹介しました。 この体制が定着し、各チームが自律的に動けるようになってきた一方で、プロダクトの規模拡大に伴い、私たちは新たな壁に直面しました。それは、「開発の上流における不確実性のコントロール」です。 今回は、その壁を乗り越えるために私たちが着手した、「テックリード(TL)の役割再定義」と、「AIを組織に組み込んだ新しい開発プロセス」への挑戦についてお話しします。 1. 「作る人」から、実行の「ゲートキーパー」へ これまでの体制では、…

ネットで話題

もっと見る

関連ブログ

Vibe Codingと品質の両立:AIに「変更容易性」を担保させる設計基盤の実践

はじめに こんにちは。プロダクト開発部 テックリードの夕暮おこはです。 現在、私たちのチームでは生成AIを開発プロセスに本格的に統合し、AIエージェントに実装の大部分を任せる、いわゆる「Vibe Coding」に近い開発スタイルを取り入れています。 AIにコードを書かせることで、確かに開発速度は向上します。しかし、その代償としてシステムの「変更容易性」が失われるリスクがあります。 AI任せの開発には、常に3つのリスクがあります。 ブラックボックス化: 背景や意図を知らないAIが書いたコードは、人間にとって解読不能なものになる可能性がある。 ビジネス(現実)からの乖離: ドメイン知識を持たないA…

Agentic DevOpsについて調べてSpec-Driven開発にチャレンジしてみた話。

こんにちは、CCCMKホールディングスAIエンジニアの三浦です。 クリスマスが過ぎて、いよいよ2025年も終わりだな、という気持ちになってきました。今年は"AI Agent"がとてもメジャーになり、DifyのようなAI Agentを誰もが構築できる仕組みも浸透してきました。「AI Agentの開発」はエンジニアの専門領域ではなくなってきているように感じます。 そんな中、2026年にエンジニアとしてチャレンジしたいと考えているのが"Agentic DevOps"です。Agentic DevOpsについてはMicrosoftのブログでも述べられていますが、ソフトウェア開発から運用に至るライフサイク…

計測から始める品質とスピードの両立 - TVerの開発組織改革2年間の記録

この記事は Tverアドベントカレンダー2025 25日目の記事です。24日目の記事は @tomat_oooさんのTVerでテレビの体験をつくる!5つの壁とUIデザインの工夫でした。 サービスプロダクト本部 本部長の脇阪(@tohaechan)です。 techblog.tver.co.jp 1年前に上記のような記事を書きました。 当時は技術統括(TVerサービス開発部門内のVPoEみたいなポジション)として、主に技術戦略や組織マネジメントに責任を持っていました。 そこからPdMやデザイナーも含めた開発組織の本部長となったこともあり、これまでの仕事に加えてプロダクト成長にもより強くコミットするこ…

新卒2年目エンジニアの私が、チームをリードするために「こだわっている」こと

※この記事は、2025 Speee Advent Calendar24日目の記事です。昨日の記事はこちら こんにちは。SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの山本です。 現在Housiiは2つのチームに分かれて開発を進めており、私は片方のチームの開発に取り組みながら、もう片方のチームをリードしています。 この記事では、そんな私がチームをリードするためにこだわっていることを紹介します。 この記事を通して、Speeeには新卒2年目でもこのような内容にチャレンジできる環境があることや、Speeeのエンジニアがプロダクトを作っていく中でどのようなことを考えているのか…

「できる領域」のやり方を、「できない領域」に転用する——そのために必要だったのは、暗黙知を「構造化」することだった

※この記事は、2025 Speee Advent Calendar 22日目の記事です。昨日の記事はこちら はじめに こんにちは、SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの北田です。 この1年で、事業として実現したいことの難易度が大きく上がりました。それに伴い、設計・調査の難易度も上がっています。結果として、私は「実装はできるのに、設計・調査になると見積もりが大きくズレる。対策を立てても改善しない」という壁にぶつかりました。 この記事では、そこから私がどうやってその壁を突破したのかをお伝えします。結論を先に言うと、「できる領域」で無意識にやっていることを構造化…

事業を動かすエンジニアの判断軸——達成プランを軸に判断する

※この記事は、2025 Speee Advent Calendar 21日目の記事です。昨日の記事はこちら はじめに こんにちは、DX 事業本部でエンジニアをしている大金です。 エンジニアとして4年目になり、純粋な技術的意思決定の枠を超えた判断を求められる場面が増えてきました。 技術的負債の解消にどのくらい開発リソースを割くのが正解なのか? どんな人を採用するべきか?採用要件は? 自分を含めてメンバーのアサインをどうするべきか? 「やった方がいいこと」は無限にある。しかし、リソースと時間は有限です。 この記事では、試行錯誤を経て馴染んできた「達成プランを軸に判断する」という考え方について書きま…

技術組織が事業フェーズの変化に合わせて変化してきた2年間の話

※この記事は 2025 Speee Advent Calendar 20日目の記事です。昨日の記事はこちら はじめまして。Speee リフォームDX事業部で開発責任者をしている佐藤です。 私がこの事業部にエンジニアとしてジョインしてから、約2年が経ちました。 現在は一定規模の開発組織となり、Budii というリフォーム会社向け営業支援SaaSをはじめ、複数のサービスを牽引できる状態になっています。AI で営業データの構造化を完全自動化するするといった面白い取り組みも徐々に増えてきました。 約2年前の参画当初は、プロダクトも組織も事業フェーズが切り替わる過渡期にあり、正直なところ明確な方向性が見…

AI エージェント開発で半年間成果が出なかった私が、前に進めるようになるまで

※この記事は、2025 Speee Advent Calendar 18 日目の記事です。昨日の記事はこちら はじめに こんにちは、DX 事業本部でエンジニアをしている 22 新卒の高島です。社内ではたかてぃーと呼ばれています。 大学院では機械学習の研究をしていましたが、入社後は既存プロダクトの保守運用や新規事業のアプリケーション開発を経験しました。2024 年 11 月からは、不動産領域で AI/LLM を活用した R&D プロジェクトをリードしています。 この 1 年間、AI エージェントに関する研究開発に取り組んできましたが、決して順調ではありませんでした。特に最初の半年間は、成果が見え…

「要件通り=正解ではない」新卒エンジニアが学んだ、"解くべき問い"のスコープ定義

※この記事は、2025 Speee Advent Calendar17日目の記事です。 昨日の記事はこちら こんにちは、SpeeeリフォームDX事業部に2025年新卒で入社したエンジニアの小町です。 普段はリフォームの会社探しサイト「ヌリカエ」などを運営する同事業部にて、ビジネスオペレーションを技術で改善する「BizOps開発」チームに所属しています。 今回は、私がBizOps開発でやらかしてしまった「言われた通りに作ったのに、現場では全く使えない仕様だった失敗談」と、そこから得られた学びをお話しします。 「要件通り完璧に実装したのに、解くべき課題のスコープを見誤ったために、全く使えないものを…


[8]ページ先頭

©2009-2026 Movatter.jp