「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を０から自力で作ろうと思うと４０時間はかかるが、chatgptを使う事によって４時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全
どうも、外資系うさぎのちょこさんです。 気がつけばもう2023年が始まってしまってますね。 一年の計は元旦にあり、ということで正月早々とても有益なnoteを書いて徳を積むところから今年をスタートすることにしましょう。 年末年始に限らず、それなりにまとまった時間を使えるタイミングってインプットにもアウトプットにもとても良いですからね。 せっかくなのでﾌｫﾛﾜｯｻﾝ各位も何かアウトプットしてみるとよいんじゃないでしょうか。 というわけで、新年早々のアウトプットにおすすめな、土地勘の無い業界/テーマのプロジェクトにアサインされた場合の最低限の情報収集を手早くこなすにはどうするのがよいかってnoteをお届けします。 これは再現性のあるやり方なので、このnoteを見ながら同じような流れで情報収集して自分なりの見解なんかをまとめてみたりすると良いセルフトレーニングになるはずです。 これは有益な情報なの
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
これまで何人も強いエンジニアと出会って、 「なんで自分はあの人と比べて何もできないんだ・・・。」と何度落ち込んだことか。 ただ、最近強いエンジニアの仕組みを理解してから落ち込むことは無くなった。 それについて書いていく。 （強いエンジニア達本人に聞いたわけではなく、観察してえられた個人の見解です） 気づき：強いエンジニアを見て落ち込む要因は2つありそう 1つは今の知識や技術力の差。 書くコードの違いだったり、成果物ができるまでの時間に差がありすぎたり、PRレビューで自分が思いもしなかったウルトラ解決策を何度も提示されて、自分の実力の無さを感じて落ち込む。 もう1つは新しいことを学ぶときの時間の差。 お互い知らない技術だったはずが、いつの間にか強いエンジニアはその技術に習熟(しているように見える)して、自分は理解不足で取り残されているという状況が発生しがち。 この時、自分には才能がないのかと
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
要件定義とはそもそも何か
BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登壇資料です。 2023年4月28日(金)に開催。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AI搭載エディタCursorを色々と試しているのですが、これが非常に興味深いです。 普段の開発業務はもちろん、少し工夫することで、要件定義のような上流工程も大幅に効率化できるのではないか？という気づきがありました。 本日はその試みについて、私が行った具体的なプロセスと合わせて共有できればと思います。 概要 不動産テック業界に限らず、SaaS開発などに携わっていると、日々さまざまな要望が寄せられますよね。 「ここにこんな機能を追加したい」「あの画面のここをこう変更してほしい」といった具合です。 そして、それらを適切に実現するためには、まず
2023年度リクルート エンジニアコース新人研修の講義資料です
ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントや本があるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基本的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基本的にそのためにやることは3つしかないと
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ
あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 生成AIに「要件定義プロンプト」を作らせてみたら、未来が見えた話 要件定義って何から書けばいいの？ 😕 いつも同じような項目で悩んで時間がかかる… ⏳ もっと効率よく、質の高い要件定義書を作りたい！ 😫 そんな悩みは 生成AIに「要件定義プロンプト」を作ってもらう で解決できるかもしれません。 1️⃣ なぜ生成AIにプロンプトを作らせようと思ったか？ 「要件定義」はプロジェクトの成功を左右する重要な工程ですが、品質が担当者によってバラついたり、何を書くべきか迷うことも多いですよね。 そこで、「デキる人が書いた質の高い要件定義書」を学
こんにちは、リファクタリングが大好きなミノ駆動です。 これは、私が執筆した『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』について紹介する記事です。 2022年4月30日発売です（ほぼ同日に電子書籍版も出ます）。 AmazonなどECサイトで、すでに多くの予約が入っており、ヨドバシ.comでは一時期予約終了になったほどです。おかげさまで初版部数が2倍になりました。 ■どんな本？皆さんはプログラミングでバグを埋め込みたいですか？ロジック修正が上手くいかず、ヒィヒィ言いながら長時間残業したいですか？イヤに決まってますよね。ところが現実には、 何度もバグを埋め込んでしまう ロジックを読み解くのに時間がかかる やっとロジック修正しても、全然違う箇所がバグ化してしまう ……ほとんど誰もが体験しているのではないでしょうか。 でも、こうした状況をなんとかしたいと思って
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
著者のChris I.氏は、カナダ・トロントでデータサイエンティストとして活躍しています。同氏がMediumに投稿した記事『機械学習エンジニアが職を失いつつある。しかし、とにかく機械学習を学ぼう』では、北米のAI業界に関する雑感とAI業界で働き続けるための心得が書かれています。 Chris I.氏が北米のAI市場を見る限りでは、「第三次AIブーム」の熱は冷め、AI技術の研究職に関する求人は減り、AI技術者の供給が需要を上回る景気後退局面に入りました。しかし、こうした見方はAI業界の一側面を見ているに過ぎません。AI研究に対する熱は冷めたかも知れませんが、既存のAI技術を活用して解決すべき問題は、まだ無数にあるのです。このように現状を見たうえで、今後もAI業界で働くにあたっての心得を同氏は以下のように書き記しています。 問題を解決するのに、最先端のAI技術は必要ない。むしろ、既存のAI技術を
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
【入門】事例で学ぶ要件定義 - Qiita
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 本記事について Findy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した内容を元に作成しています。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像
「要件定義のスキルを上げたいけどどうしたら良いかわからない」 こんなふうに悩んだことはないだろうか。 要件定義ではかなり幅広いスキルが求められる。さらに要件定義の対象は毎回異なるため、具体的なレベルでスキルを言語化するのがかなり難しく、どうしてもスキル定義が「コミュニケーションスキル」や「ビジネス理解スキル」といった抽象的な言葉になりがちだ。 そこでこの記事では、要件定義を第一線で実行してきた私が、要件定義を構成するスキルを以下の５つに分解し、それぞれの向上のための方策も可能な限り具体化した。 ・論理的に物事を整理するスキル ・ビジネスの数字を理解するスキル ・業務のフローを理解するスキル ・要求を具現化するスキル ・要求を達成するために必要な機能を洗い出すスキル それでは一つずつ見ていこう。 １ 要件定義をするために必要な5つのスキル この章では、要件定義に必須なスキルとそれがなぜ必要な
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
「Product Roadmaps Relaunched」（オライリー未邦訳）がプロダクトマネージャーにとって非常に良書 - SaaSベンチャーで働く社員のブログ
プロダクトロードマップに関する書籍を探していたら、「Product Roadmaps Relaunched」に辿り着きました。未邦訳なので英語で読んでいったのですが、非常に良い本です。 Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty (English Edition) 作者:Lombardo, C. Todd,McCarthy, Bruce,Ryan, Evan,Connors, MichaelO'Reilly MediaAmazon アウトカムベースのロードマップ(Outcome Based Roadmap) プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカ
www.oreilly.co.jp 目次はこちら 第1部 主題 1章 ソフトウェアエンジニアリングとは何か 第2部 文化 2章 チームでうまく仕事をするには 3章 知識共有 4章 公正のためのエンジニアリング 5章 チームリーダー入門 6章 スケールするリーダー 7章 エンジニアリング生産性の計測 第3部 プロセス 8章 スタイルガイドとルール 9章 コードレビュー 10章 ドキュメンテーション 11章 テスト概観 12章 ユニットテスト 13章 テストダブル 14章 大規模テスト 15章 廃止 第4部 ツール 16章 バージョンコントロールとブランチ管理 17章 Code Search 18章 ビルドシステムとビルド哲学 19章 GoogleのコードレビューツールCritique 20章 静的解析 21章 依存関係管理 22章 大規模変更 23章 継続的インテグレーション 24章 継続的
こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 本記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン（業務活動）にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ
「オープンセミナー岡山2022」のイベント登壇で用いた資料です。 https://okayama.open-seminar.org/
リファクタリング自爆奥義集 - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに？ コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
シリーズ: 要件定義とはそもそも何か 要件定義の目的とゴールとは（本記事） 要件定義の重要ポイント〜要望・要求・要件を見極める 事業・業務・システムの3階層で要件を捉える 業務フロー図で見える化する業務プロセスからシステム要件への道筋 ユースケースとロバストネス図によるシステム要件定義 システム要件定義の成果物〜設計へのインプットを作成する TRACERYプロダクトマネージャーのharuです。 「要件定義とは何を目的としたプロセスなのか？なにが出来たら完了なのか？」 はじめて要件定義する人は、ここで詰まってしまうことが多いようです。 要件定義は、設計や実装に比べて、具体的な作業がイメージしにくいプロセスです。 そのような背景もあってか、2023年4月のBPStudy#188〜要件定義を学ぼう。ChatGPTを添えてに私が登壇した時の以下のスライドには、945個のはてなブックマークをいただき
ソフトウェア品質特性、意識してますか？AIの真の力を引き出す活用事例 / ai-and-software-quality
こちらのイベントの登壇資料です。 AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 https://pages.awscloud.com/eib-aiml-250522-reg.html 負債分析プロンプト「バグサーチャー」の元…
コンポーネント設計って何だろう | ドクセル
マーチン・ファウラー モジュールとは、明確に定義された一部のサブセットを 理解するだけでシステムを変更できるようにソフトウェ アシステムを分割したものと定義します。 コンポーネントはモジュールの一形態であり、独立して 置換できるという追加の特性を備えています。 出典 martinFowler.com “Software Component” より筆者抄訳 https://www.martinfowler.com/bliki/SoftwareComponent.html https://www.martinfowler.com/bliki/SoftwareComponent.html
メガベンチャーがデジタルがちょっと得意な中堅企業になる理由～とあるメガベンチャー社員との対話から考える「スタートアップ・ピーターパン現象」～
中野 仁 (AnityA) @Jin_AnityA 長いので少しまとめると... ・ベンチャーは上場前後から人材と文化の変質が起きる ・中間層が厚くなり、そこにいい感じに情報の非対称性を取るのに長けた人材(Taker)が増え始める ・足らない部分の仕組みを人手で回していた有能な善人(Giver)たちが逃げ始める 2022-06-25 19:14:10 中野 仁 (AnityA) @Jin_AnityA ・経営が全体を把握する為に必要な仕組み(ルール・システム)も未成熟な状態から、混乱と停滞が発生しやすい ・結果、仕組み化を備えたエンプラにもならず、ベンチャー的な雰囲気とデジタルが得意な中堅企業として固定化する 2022-06-25 19:15:56 中野 仁 (AnityA) @Jin_AnityA とあるメガベンチャーの文化と人材の会話メモ： ・「成功したら自分の手柄。失敗したら他人のせ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
【雑感】絶対覚えて！案件アサイン前情報収集の鉄板のやり方！｜外資系うさぎのちょこさん
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
実践要件定義入門以前 - 勘と経験と読経
AWS システム構築 非機能要件ヒアリングシートを公開してみた | DevelopersIO
「強いエンジニアは結局休日に勉強してるじゃん」って思うけど - spice picks
Cursorで要件定義がエラいスムーズになった話 - Qiita
現代的システム開発概論
生成AIに「要件定義プロンプト」を作らせてみたら、未来が見えた話 - Qiita
『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動
Webサイト制作の要件定義書の確認項目｜重松佑 / Shhh inc.
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
モダンなソフトウェア設計の書籍 - kawasima
実践要件定義入門 - 勘と経験と読経
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
機械学習エンジニアが職を失いつつある。しかし、とにかく機械学習を学ぼう | AI専門ニュースメディア AINOW
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
５年やって分かった要件定義に必須な５つのスキルとその上達方法 - みんなのシステム企画
Agile and Requirement : アジャイルな要件定義について考える
「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
「Googleのソフトウェアエンジニアリング」を読んだ - wyukawa's diary
DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog
不幸を再生産しないための設計に対する向き合い方
スタメンの技術的負債解消戦略 - stmn tech blog
要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）
knock3.hamnaly.com
response.jp
www.moomoo.com
www.google.com
kurarin2000.blogspot.jp
share.google