本記事は READYFOR 株式会社の READYFOR Advent Calendar 2023 の [15日目] です。 ※ 本記事の内容は所属会社の公式発表・見解を示すものではありません。 ■ 「言葉集め会」とは？ 弊社 READYFOR では2年ほど前より DDD に関する取り組みを行っています。 「言葉集め会」とは、そんな弊社にて実施した コンテキストマップの作成や精度向上 を主目的とした 『ドメインエキスパートの皆さんを招待し、仕事で使う「言葉」とその関係性を改めて見出してみる』イベント です。 同僚の方が前職の体験を元に考案したもので、準備を除き全体でおよそ4時間という少し長丁場のプラクティスとなります。 その経験について本日はお話をさせて頂きます。 ■「言葉集め会」で期待できること 「言葉集め会」を実施することで、以下の効果を期待することができます。 エンジニア目線 自社の
Tabnine | Plans & Pricing
Features include Code completions powered by best-in-class AI models AI chat agents in the IDE to generate code, test, docs, and more AI agents personalized to your code in the IDE Code recommendations exclusively drawn from permissively licensed codebase Switchable models for AI chat agents, including models from Tabnine and third-party providers Security vulnerability filtering in generated code
GPTsをMVPに使うアジャイルな社内LLMツール開発 / Agile in-house LLM tool development using GPTs as MVPs
生成AI新年会2024 LT資料 https://algomatic.connpass.com/event/306870/
プロジェクトマネジメントにおいて、工数管理は非常に重要な要素の1つです。一方で、工数という言葉はビジネスシーンで日常的に使われていることから、なぜ重要なのかをあらためて問われると答えるのは難しいと感じるのではないでしょうか。 今回は、工数の定義や工数管理を行うメリット、効果的な工数管理のポイントについて解説します。工数管理に役立つツールや業種別の注意点もあわせて紹介しますので、ぜひ参考にしてください。 工数管理が適切に行われれば「プロジェクト期間・費用について精度の高い見積もり」「正確な進捗管理」ができるようになります。この機会に工数の基礎をマスターしましょう。 そもそも「工数」とは何を意味しているのでしょうか。工数の定義や必要性、計算方法について基本的な知識を整理しましょう。 工数の定義 工数は、ある作業が完了するまでに必要な人数・時間を表す指標です。作業完了までに要する人員や時間が多い
こんなシステム開発はもうイヤだ！ありがち失敗事例10連発 ~ あるいはユーザーが本当にホントーに欲しかったものは何か - Qiita
「予定通り完了」＋「ある程度予定通り完了」、「満足」＋「ある程度は満足」の割合 は、いずれも開発規模が大きくなるほど小さくなっていますが決して悪くないレベルだと感じるのは筆者だけでしょうか。特に品質については、500人月以上の開発プロジェクトでも74.4%と多くのプロジェクトで満足しています。 でも、品質・コスト・納期を満たせるだけでシステム開発は成功と言えません。品質は悪くないけれど、業務に合致しないシステムや誰も使わないシステムは役に立ちません。せっかくコストと人手をかけてシステム開発をおこなっても、これでは成功と言えないでしょう。 では、どうしてシステム開発において、品質・コスト・納期を満たせなかったり、役に立たないシステムができてしまうのでしょうか。 そこで、どこかで聞いたような情景をまとめてみました。もちろん、すべての失敗プロジェクトがこんな具合という訳ではありませんが、どこか腑
エンジニアの富岡です。2ヶ月ほど前まで、Wantedly 利用企業向けのプラン契約や料金請求周りのシステムの改修と機能追加を行うプロジェクトをやっていました。1年半ほどの長期プロジェクト、かつステークホルダーの多いプロジェクトだったので、プロジェクトマネジメントの観点でも書くべき話題はあるのですが、今回はより技術的な部分に焦点を当てて、プロジェクト開始時点でレガシー化していたシステムの状態を改善するために行った取り組みを紹介したいと思います。 背景Wantedly は SaaS 型のビジネスを提供しており、利用企業の契約プランに従って毎月の料金の請求を行ったり、契約の自動更新を行ったりといった処理が発生します。こうした処理を行うシステムは、今から8年ほど前までにそのベースとなるものが作られました。それ以降は消費税率の変更や、新しい支払い方法の対応など、必要に応じて散発的に変更は行われていま
厳しい国際間競争にさらされている航空業界。国内2大エアラインの一翼を担うANA（全日本空輸）も今、生き残りを賭けた大規模な改革を進めている。その改革をけん引しているのが、ANAでイノベーション推進部の部長とデジタルデザインラボのエバンジェリストを兼任する野村泰一氏だ。 一度はANAを辞め、国内初のLCC（Low Cost Carrier）、Peach Aviationの立ち上げに参画したこともある野村氏は、一貫して“本質的な改革”に取り組んできたことで知られており、Peach Aviationではコストと効率を考えて開発した段ボール製の手作りチェックイン機の開発で世間をあっと驚かせた。 ANAに戻ってからも、利用者の予約からチェックイン、搭乗までの情報をデータベース化することによる、“顧客情報基盤の構築”や、ビーコンによるベビーカーと車椅子の管理、「ヒアラブル端末（イヤフォン型のウェアラブ
RDRA学習ロードマップ
RDRAが広まってきているので情報源を充実させたい リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。 RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。 要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。 RDRAで可視化されたビジネスルール（バリエーション・条件・状態モデル）をビジネスロジックとして実装しています。 ドメイン駆動設計の実装例としても参考にしてください。 https://t.co/UyFscwKMPi#CCSR手法 — 増田 亨． (@masuda220) May 26, 2020
要件定義で得た学び・気づき
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
早稲田大学 早水桃子研究室 on Twitter: "プレゼンの予定がある全ての大学生に役立つ素晴らしい無料のPDFテキスト📙私の研究室の学生にも熟読を勧めました✨／大学生のためのプレゼンテーション基礎 千葉大学大学院 人文社会科学研究科 教育・学修支援研究会 千葉大学 人文社会科学… https://t.co/41xE0plA5s"
プレゼンの予定がある全ての大学生に役立つ素晴らしい無料のPDFテキスト📙私の研究室の学生にも熟読を勧めました✨／大学生のためのプレゼンテーション基礎 千葉大学大学院 人文社会科学研究科 教育・学修支援研究会 千葉大学 人文社会科学… https://t.co/41xE0plA5s
「Google Things to do」連携リリース - アソビューでの機能開発の流れ - asoview! Tech Blog
こんにちは! アソビューでバックエンド アプリケーションエンジニアをしている山野です。 アソビューは7月にGoogleとの連携機能「Google Things to do」のリリースをしました。 今回はこの機能開発について紹介したいと思います。 Google Things to doとは Googleがアクティビティやアトラクション分野で導入した予約検索表示機能です。 これにより世界中のゲストが世界中のアクティビティやアトラクションを見つけ、 Google上で価格を比較することができます。 またゲストは体験したいアクティビティ・プランを見つけた場合は、 Google上からサービス事業者のWEBサイトへのダイレクトにアクセスでき、予約に進むことが出来ます。 google things to do 開発体制 プロダクトオーナー・プロダクトマネージャーとエンジニア(私)の３人体制で開発を行いまし
「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、west-cです。 業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。 【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？ 作者:清水 吉男技術評論社Amazon ◆ 関連ブログ 仕様書 とは 【まとめ】 おすすめの読者層 要求仕様書の目的・ゴールが曖昧な方 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方 依頼者から要求を引き出す方法の糸口を掴みたい方 要求仕様書とは 書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。 要求（今回の機能で実現したいこと）は曖昧なものを含
「マンモスプロジェクト」を提供するパラダイスウェア株式会社のYouTubeチャンネル「プロマネ道場ラジオ」。新規事業やプロジェクトについてのあるあるや、明日から使えるノウハウについて語ります。今回のテーマは「要件定義のコツ」。要件定義のあるあるや、うまくいくコツについて話しました。 要件定義でぶつかるジレンマ、トリレンマ 橋本将功氏（以下、橋本）：みなさんこんにちは、パラダイスウェアの橋本です。 中島大輔氏（以下、中島）：中島です。 古長谷莉花氏（以下、古長谷）：古長谷です。 橋本：「だれプロラジオ（「誰も教えてくれないプロマネのコツラジオ」）」第33回は……。 古長谷：「こうすればうまくいく！要件定義のコツ」です。 橋本：要件定義はみんな悩んでるポイントかなと思いますが、要件定義のコツって何ですか？ 古長谷さん。 古長谷：今、本当に困っている。 橋本：リアルタイムに（笑）。 古長谷：うわ
【要件定義】いきなり内容説明しない！業務フローを説明するまでの「長い道のり」をまとめました。 - Qiita
要件定義をしているときに、お客さんに資料を説明することがあります。ITを専門にしていないお客さんにどのように説明するのがよいのでしょうか。まずは、資料の中身を説明する前に、前提を話す必要があります。資料の作り方は書籍やネットの記事でよく目にしますが、資料説明の仕方はあまりないようにみえます。ので、資料を丁寧に説明する流れを検討し、自分なりの言葉でまとめました。 本記事では、 ①紙媒体で行っていた業務をシステム化するプロジェクト ②「要件定義フェーズ」 ③「業務フロー」を「お客さん（ITを専門にしない方）」に説明する と仮定して、セリフと解説を記載してきます。 説明の流れ 1.ウォーターフォールモデルにおける要件定義の解説 2.使用する資料の概要説明 3.近々のスケジュールの確認 4.資料の見方と説明の流れの提示 5.資料の説明開始！
この連載では、開発現場で実践できるカイゼンのやり方と考え方について、お伝えしていきます。下敷きになっているのは、「カイゼン・ジャーニー」という書籍です。「カイゼン・ジャーニー」も、現場のカイゼンがテーマになっています。この新たに始める連載は、内容としては書籍を補完するもので、チームが現場でこのWebページを開きながら、実際にふりかえりをしたり、カンバン作りをしたりできるように作っています。本を開きながらより、Webページをモニタに映す方が、ワークショップもやりやすいですよね :) また、読者の皆さんが実際の状況を重ね合わせられるよう最初にストーリーがあり、その後解説が続く、といった構成にしています。ストーリーでは、カイゼンを実施するにあたってどんな背景や課題を想定しているかを描いています。よく知らない手法については、ストーリーに目を通すようにしてください。
不確実性に立ち向かう各社のアジャイル開発のリアルについて話す「『不確実性』にどう立ち向かう？アジャイル開発現場のリアル【BASE・DMM】」。ここでBASE株式会社の炭田氏、植田氏、櫛引氏が登壇。まずは、不確実性に振り回される5つのパターンと、その対策法を紹介します。 炭田氏の自己紹介と本日のアジェンダ 炭田高輝氏（以下、炭田）：それでは、「アジャイルで不確実性に向き合うための開発タスクの切り方」の発表をします。よろしくお願いします。 はじめに自己紹介をさせてください。BASE株式会社でネットショップ作成サービス「BASE」のエンジニアリングマネージャーをしている炭田高輝といいます。BASEには2020年に入社して、エンジニアリングマネージャーはかれこれ1年くらいやっています。 （スライドを示して）本日のアジェンダはこちらです。最初に「不確実性とは何か」について説明して、次に「受け渡し型開
開発における認知負荷を低減するためにオープンワークで実践していること7選 - OpenWork Tech Blog
Webアプリチームの西川です。面談でよく話題に挙がることをうまくまとめたいと思っていたところ、「認知負荷」というキーワードである程度まとめられそうだったのでまとめてみました。 認知負荷とは 「ワーキングメモリで利用される心理的労力の総量」として提唱されたものであり「課題内在性負荷」、「課題外在性負荷」、「学習関連負荷」に分類されます。 課題内在性負荷：課題を解決するにあたり必要となる基礎的な知識（例：プログラミング言語、フレームワークなど） 課題外在性負荷：タスクが実施される環境の知識（例：デプロイ、リリース手順など） 学習関連負荷：特別な注意が必要な知識（例：SEO、業務知識など） （参考：チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計） 認知負荷を低減するために実践していること 1. ペアプログラミング 低減する負荷：課題内在性負荷 当社ではリモートワークが主体の
技術選定、してますか？ こんにちは！エンジニアリングマネージャーの佐藤（@unsoluble_sugar）です！ 今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。 エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc... 挙げだすとキリがないですよね。 個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。
ひと昔前のシステム開発では「どのように開発を行うか（How）」に重点を置き進められていましたが、その進め方では不備や失敗が多く、ひととおり経験したのちに、現代のシステム開発の関心事は「どんなシステムが必要か（What）」に変わりました。 このように、よいシステムを開発するには、考え方や進め方、成果物の書き方に至るまで、目的や環境に合わせて常に変化していく必要があります。しかし、ただ一つ変わらないことがあります。品質は顧客が決めるということ、つまり「品質＝顧客満足度」という図式です。 今回は、システム開発の超上流工程の要求定義と品質をテーマに、要求定義の進め方や書き方、要件定義書やRFPとの違いに至るまで網羅的に解説していきます。どうぞ最後までお付き合いください。
「心理的安全性を高めたい」という企業からの依頼 安斎勇樹氏（以下、安斎）：ここまでお互いの書籍の概要をお話ししてきました。ここからは少し石井さんとディスカッションをしながらやっていければなと思っています。 石井遼介氏（以下、石井）：安斎さんのおっしゃっていた、「なるほど、わかった。うちがだめなのは心理的安全性がないからだ！ すっきり」というのは、本当にあるんですよね。 安斎：今日はこれを掘り下げましょうよ。僕、困っているんですよ。 （一同笑） 安斎：先に困っていることを言っていいですか。 石井：もちろんです。 安斎：僕、『問いかけの作法』で講演の機会をたくさんいただけて、ありがたいなと思っていて。呼んでいただいたところに「過去にどんな方が登壇されたんですか」と聞くと、だいたい石井さんが登壇しているんです（笑）。石井さんが登壇した会社の社内セミナーに、僕が数ヶ月後に行くパターンが多くて。 『
アルプの開発チームがどのように開発手法を試行錯誤しているかを残しておく。振り返ることでこれまでどのようなことを、どのようなチームで、どのようなアイデアで解決してきた*1のかを整理できる。 改めて振り返ってみると「開発手法に銀の弾丸などない」という一言に尽きるくらい、変化が激しい。それでもやってこれたのは、より良い開発にこだわり続ける情熱を持ちつつ、変化に寛容なチームだからだろう。 なお、これは古いドキュメントを辿った断片的な情報の集約であり正確ではないため、チームからのレビューなどでアップデートされる可能性が高い。 「誰かのために〜」とは考えていないが、あえて言うならば、これから入る未来の仲間へ向けていると言えるかもしれない。歴史は文化として残るか、文章になる。文化は僕らが行動で示していくが、理由を知りたい人もいると思う。そんな人はこのブログを読むのをお勧めする。 これを読まなくても困らな
コーディングファクトリー部の松原です。 昨年まで、コーディングファクトリー（以下CF）で、ディレクター兼コーダーとして働いていましたが、今年からは「案件・技術相談窓口」として、お客様からご相談いただいた案件の見積やスケジューリングをする上で必要な作業工数の算出をメインで担当しています。 工数出しは、コーダー時代も業務の一環として行っていましたが、メインの仕事として行うようになってからは、どうすればもっと効率よく、精度が高い工数が出せるのか、これまで以上に意識するようになりました。 そんな中、アジャイル開発の現場では「プランニングポーカー」という工数の見積もり方法があると知り、とても興味が湧きました。単純に「ポーカー」という名前から、トランプゲームみたいで面白いのだろうと想像したのです。 調べてすぐにわかったのは、残念ながら私が思っていたほどゲーム性はなく、年末に家族で楽しめるようなカードゲ
要求定義とは？要件定義との違い、進め方のポイント
要求定義はシステム開発の用語で登場しますが、要件定義と混同したり、中身を決めるときの方法や内容が違ったりして、さまざまな失敗やトラブルを引き起こします。 システム開発をベンダーに依頼する場合には、システム開発を依頼する担当者も要求定義や要件定義の違いを理解した上で、要求定義や要件定義を進めていく必要があります。 本記事では、要求定義と要件定義の違いをわかりやすく解説した上で、要求定義の重要性や陥りやすい失敗事例、進め方のポイントについて解説していきます。 要求定義・要件定義の違いは？ システム開発会社ごとやシステム開発に関わる企業担当者によって「要求定義」と「要件定義」の言葉の指す範囲や意味が異なる場合があります。しかし、両者の定義を不明瞭に開発を進めることは、後述するようにさまざまな問題を引き起こします。本章では、要求定義と要件定義の違いについて、わかりやすく解説していきます。 要求定義
はじめに 私は普段、受託開発を多く行っております。 ヒアリング・設計から行う開発が基本になりますが、中には**「サーバ保守のみを行って欲しい」**という依頼も少なくありません。 「保守のみの依頼」というのは下記のような内容が含まれております。 トラブル・障害の対応 軽微なシステム修正 サーバの死活監視・リソース監視 SSL証明書の更新 ドメインの更新 発注者からの問い合わせ対応 またこういった依頼が来る際、発注者側では以下のどれかに該当するパターンが多いです。 エンジニアが急に辞めてしまった 保守をお願いしていたエンジニアと揉めた（もう連絡を取りたくない） サービスを納品されたが保守をする人間が必要になった サービスを納品されたが複雑すぎて保守できない サービスをもうすぐリリースするのだが保守担当がいない サービスのランニングコストが高すぎてすぐにでもコスト削減したい サービスの売上がなく
アジャイルテスティング問答 - 千里霧中
先日、「人類よ！これがアジャイルテスティングだ！QAテックリードが語るアジャイルQAの実践とは何か？ - connpass」というイベントに登壇させていただきました。 インタビュー形式だったので講演資料などは特に残ってないのですが、内容の記録のため公開に差し障りのない問答についてまとめたいと思います。念の為、一般的な定義というより、あくまで自分なりの考えになります。 Q. アジャイル開発におけるQAエンジニアの役割と責任は? QAエンジニアの定義に幅があるので難しい問いですが、今回はプロダクトの品質を保証する役割の人を、QAエンジニアという前提で話します。 まずアジャイル・ウォーターフォールなどプロセスを問わない役割として、QAエンジニアは、様々な品質を保証する手段を直接担当したり、支援したりして、総体として品質を保証する仕組みを構築する役割だと考えています。 直接担当の役割としてはQAテ
こんにちは。Leaner Technologiesの小久保(twitter:@yusuke_kokubo)です。 これはなに Leanerでは「Leaner見積」と「Leaner購買」という二つのプロダクトを開発提供しています。 ここでは「Leaner見積」の開発プロセスをざっくり説明します。 開発プロセスはプロダクトや事業、組織のフェーズによって日進月歩で変わっていきますので、あくまで執筆時点のスナップショットとしてご覧ください。 この開発プロセスの狙い 顧客フロントに立っているセールスや、カスタマーサクセスのメンバーと共同でプロダクト開発をするにあたり、以下の課題を設定して考えました。 （ビジネス側とDev側で）開発粒度の認識をいい感じに合わせたい （ビジネス側とDev側で）開発するうえでの難しさの認識をいい感じに合わせたい 今の開発プロセスになる前は、ここの認識が上手く合っていなかっ
変化の速い現代において、臨機応変に対応しやすい開発手法として「アジャイル開発」があります。この記事では、アジャイル開発について詳しく解説します。 あらゆる業界で変化のスピードが速まり複雑化している現代においては、将来を正しく予想し、それに基づき計画を立ててプロダクトを開発していくことが難しくなってきています。場合によっては計画段階で見込んでいた条件や状況が、実行段階には変化していることもありえます。そういったケースにも臨機応変に対応しやすいのが「アジャイル開発」です。この記事では、アジャイル開発について詳しく解説します。 agile（アジャイル）には、「機敏な」「素早い」「迅速な」などの意味があります。アジャイル開発は、その名の通り、ソフトウェアの開発をスピーディーに、そして柔軟に行うことができる手法のひとつ。要求や要件定義、計画、設計、開発、テストといった一連の開発工程を短期間で反復的に
Webサイトのデザインや設計を行うとき、昔は工程によっていろんなツールを使い分けていました。今はそれを（私の愛してやまない）Figma一つでブラウザ上だけで完結できます！ 【目次】 私の愛してやまないFigma Webサイトの制作フロー ヒアリング（オリエン） 要件定義 サイトマップ ワイヤーフレーム デザインラフ デザインカンプ プロトタイプ フローチャート 実装段階もシームレスに 最後に 私の愛してやまないFigma 私の愛してやまないデザインツールFigma、ブラウザ完結のツールです。このブログ上の図もほとんどFigmaで作っています！ ※参考：Figma: the collaborative interface design tool. 操作感はAdobe XDなんかと似た感じです。イラレのようにベクターデータのパスを描ける！ ※参考：4-5. ペンツールと鉛筆ツールの使い方 |
なまぬるいおにぎり🍙 @onigiritan ユーモアとものづくりが好きなおにぎり🍙 IT系の笑いを時々届ける、スタートアップのUIデザイナー（女性です）｜変な制作物はモーメントに👇最近作ったサービスは👉 #ITおみくじ （現在停止中🙏）有益ツイートしたい人生だった（皆無） amazon.jp/hz/wishlist/ls…
新人Webディレクター必見！要件定義とは
更新日: 2017年3月21日公開日: 2016年10月27日新人Webディレクター必見！要件定義とは Web ディレクターにとって必須工程となる要件定義。 なんだか面倒くさそう、難しそう、と思って後回しにされていませんか？ 自己防衛の意味でも 要件定義 は重要なファクターとなりますので、頑張って基礎知識だけでも習得しておきましょう！ 新人Webディレクター必見！要件定義とは要件定義とは img:IPA 要件定義とは、Web サイトやアプリケーションなどの開発初期段階において、発注者と受注者の情報共有のために、実装すべき機能や満たずべき性能を第３者でも分かるように明確化しておく作業のことです。 要件定義は、Web サイトやアプリ開発において非常に重要な役割を担っていて、要件定義のでき次第で開発の成功が左右されるとも言われています。 一般的に要件定義の主導権は受注側（開発側）のディレクターが
「トヨタ流 勝ち残る設計」
連載趣旨 トヨタ自動車はなぜ強いのか。その理由は「トヨタ生産方式（TPS）」にあると、これまで頻繁に語られてきました。生産現場のムダ・ムラ・ムリを徹底的に追及して改善するゲンバの方法は製造業の模範となり、競合他社のみならず、他の業界までが導入する取り組みとなっています。 しかし、TPSに勝るとも劣らない、いや、それ以上に高い競争力を磨いたものがあります。それが、設計です。設計力が伴っていなければ、いくら生産現場でムダを削っても、優れた製品を形にすることはできません。 では、トヨタの設計は何が違うのでしょうか。まず、トヨタは「トヨタ車を選ぶお客様は安全と安心を購入する」と考えています。そのため、安全と安心を最優先した上で、品質と性能の目標を立てていきます。前段がなく、いきなり品質と性能の目標を立てる多くの企業とは一線を画す考えを持っていると言えるでしょう。これは、「トヨタらしさ」とは何かと、
『継続的デリバリーのソフトウェア工学』は、『継続的デリバリー』の共著者として著名なDavid Farley（デイビッド・ファーリー、ファーレイと表記する場合もある）による「もっと早く、もっと良いソフトウェアを作るための」書籍です。 本書が力を入れて説明しているのは特定の手法ではなく、高品質なソフトウェアを迅速に開発する際に役立つ10個のスキルとその関係です。 本書で説明されるテスト可能性、デプロイ可能性、スピード、変数の管理、そして、継続的デリバリー（Continuous Delivery）といった最終的な目標を目指せば、開発プロセスが逆算されて結果的に高品質なソフトウェアを迅速に開発しやすくなるでしょう。本書ではこの目標に到達するために、「学びのエキスパート」であることと「複雑さ管理のエキスパート」であることが求められるとし、それぞれに必要な5個ずつ合計10個の重要なスキルが具体的、かつ
「上司・部下のぎすぎす」を一発解決したすごい一言
テキサス大学オースティン校を卒業後、Thinkwell社を共同創設、ハーバード・ビジネス・スクールでMBAを取得。現在はデューク大学ビジネススクール社会起業アドバンスメントセンター（CASE）でシニアフェローを務めている。兄チップとの共著に『アイデアのちから』（日経BP）、『スイッチ！』『決定力！』（ともに早川書房）、『瞬間のちから』（ダイレクト出版）がある。著書は世界300万部以上を売り上げ、33言語に翻訳されている。米国ノースカロライナ州ダーラム在住。 上流思考 私たちは「ちょっと変えればいいだけ」のことをしていないために、毎日、膨大な「ムダな作業」をくりかえしている。全米最注目著者ダン・ヒースが、何百もの膨大な取材から生み出した話題作『上流思考』から、一部を特別掲載します。 バックナンバー一覧 『上流思考──「問題が起こる前」に解決する新しい問題解決の思考法』が刊行された。世界150
見積もりじゃなくてプロダクトを見ながら開発 #RSGT2024 - Mitsuyuki.Shiiba
Regional Scrum Gathering Tokyo 2024 (RSGT2024) で、ゆのんさんと一緒に登壇してきました。 資料 https://speakerdeck.com/kakehashi/develop-a-new-product-with-bad-practices 話したこと ゆのんさんがエンジニアリングマネージャ兼スクラムマスター、僕がフルスタックエンジニアとして4人のチームを作って、新規プロダクトの立ち上げにスクラムで取り組んだ。 その中で、Badプラクティスと呼ばれる「あまりやらないほうがいいと言われていること」も選んで開発に取り組んだのだけど、どうしてそんなことをしたのかってお話。 新規開発と見積もり 今回はReadyになるのを待たずに、見積もりをせずに開発に取り組んだ。 新規開発って、分かっていないことがたくさんあるし、開発を進める中でも新しい情報がどん
要件定義書テンプレート｜システム開発を成功に導く進め方
要件定義書テンプレート(サンプル付) 要件定義書のサンプルテンプレートを紹介します。要件定義書は進めるプロジェクトによって実際に記載する項目はことなるので、フォーマットのサンプルとして必要部分を参考にしてください。 エクセル版 エクセル版の要件定義書のサンプルテンプレートです。表紙と目次、各項目のフレームだけが使用できます。エクセルの場合、図や表を作成するのは容易ですが、目次を作成するのが大変なのでワードと併用するといいでしょう。
GitHub における PR レビュープロセス - conversation の活用 | 豆蔵デベロッパーサイト
GitHub の PR(Pull Request) レビューのプロセスは、開発チームによってバリエーションはあると思いますが、おおよそ次のようになると思います。 flowchart TB subgraph レビューイ ブランチ作成-->コード修正-->PR作成-->レビュアーアサイン subgraph レビュー対応 コメント箇所修正-->rep[conversation リプライ] end レビュー対応-->再レビューリクエスト end subgraph レビュアー レビュー-->CH{Conversation<br>がない or<br>全て resolved}-->|yes|approve-->マージ CH-->|no|RC[Request changes] subgraph レビュー cv[インラインコメント<br>conversation 開始] end subgraph 再レビュー
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDD を成功させるためにドメインエキスパートと「言葉集め会」で「生の言葉」を聞いてみよう - Qiita
工数とは？基本的な人日・人月の意味から見積もりの計算方法まで解説 | Backlogブログ
WBSの作り方と注意点〜現役PMが説明「Excelテンプレート付き」 | 若手エンジニアの羅針盤
レガシー化していた課金周りのシステムを改善するためにやったこと | Wantedly Engineer Blog
ANAを変えた、見えない課題を発掘する「魔法のワークショップ」とは
こうすればうまくいく“要件定義のコツ” プロジェクトの牽引役・PMにとって大事なスタンスと心構え
「1on1」はただの面談ではない～メンバーが気づきを得るためのカイゼンの場を作ろう
サービス開発における5つの“不確実性”パターン 曖昧さをコントロールするために、ユーザーストーリーを活用する
エンジニアリングマネージャー目線で見るライブラリ技術選定の勘所 - Activ8 Tech Blog
要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説
「心理的安全性が低くて心理的安全性が上げられない」？ できない理由を探し続ける「ラベル貼り」問題の打開策
Alp開発日誌 Day10 「開発手法史2020」 - 道産子エンジニア
ゲーム感覚で工数見積もり！プランニングポーカーを使ってみました
「Webシステムの保守業務のみ」を請け負う（お見積もり用の質問集も公開） - Qiita
〜2023年11月版〜 Leaner見積の開発プロセス
アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
Figmaで完結する！Webサイト設計の流れ - クモのようにコツコツと
要件定義「ここは俺に任せてお前たちは先に実装しに行け！俺も後で追いつく！」→「あかん」「別人になってるやつ」
https://twitter.com/tweeting_drtaka/status/1461994920575651849
酒匂寛が推す「より速く、より高品質なソフトを作るための良書」
https://www.agilejapan.org/2018/session/d2_APPRESSO.pdf
/blog/2020/05/solving-uninitialized-stack-memory-on-windows/
