開発見積りをテーマにしたパネルディスカッションの内容をまとめた記事です。過去の経験を見積りに活かす方法について議論しています。 見積もり結果や実績データの蓄積・活用方法、プロジェクト終了後の振り返りの重要性などが話題にあがっています。
開発見積もりにおけるトレードオフの考え方について議論しています。特に、予算感の早期共有、要件のツリー構造化による優先順位の明確化、品質の重要性について掘り下げています。パネリストたちの議論を通じて、見積もりプロセスにおけるコミュニケーショ…
ソフトウェア開発の見積もりをテーマにしたパネルディスカッションの内容を紹介する記事です。この記事では特に、「高すぎる」と言わせない見積りの技術について議論されています。見積もりの根拠を明確にすること、早い段階で見積もりを提示すること、スコ…
BPStudy#210で行われたパネルディスカッション「開発見積りの重要論点」の内容を詳細レポート。第1回は「内製開発と外部委託における見積りの相違点」に焦点を当て、注意点や落とし穴を話しあいました。
システム開発におけるデータベース設計の重要性と、要件定義の成果物をどのように設計に反映するかを解説します。クラス設計とデータベース設計の違い、データ品質の観点、具体的な設計手法について詳しく説明しています。
ビジネス+ITに掲載されたアジャイル開発に関するインタビュー記事を紹介。アジャイル開発でよくある失敗や誤解、成功のポイント、体制づくりについて、前編・中編・後編に分けて解説します。アジャイル開発を学び始めた方や、現場での活用に疑問を持つ方への…
ソフトウェア開発における「関心の分離」と「高凝集」という重要な設計原則について、これらの概念がなぜ重要なのかを説明し、具体的な設計手法として「オブジェクト指向設計」を取り上げ、特にその中核となる「クラス設計」の考え方を紹介しています。 クラ…
本記事では、システム開発における要件定義とソフトウェアアーキテクチャ設計の重要性について解説します。要件定義で作成された成果物をどのように設計に活用するか、また設計プロセスの流れや観点を理解することで、要件定義の成果物の実用性や完成度を大…
ROUTE06社に、要件定義の重要性と実践のポイントをテーマにインタビューしていただいた記事の紹介です。 特に要件定義の初期段階や、それ以前の企画・要求分析段階における考え方について掘り下げています。
要件定義のゴールは、設計の精度を高めるためのインプットとなる成果物を作成することです。そのためのシステム要件定義の成果物は、(1)ユースケース、(2)ロバストネス図、(3)開発品目の一覧、機能要件、非機能要件、(4)システム構成図、(5)概念モデルです。…
本記事では、システム要件定義において ユースケースとロバストネス図を活用してシステムの要素を抽出する方法 を説明します。前回の記事では 業務フロー図を用いてユースケースを導出 しましたが、本記事ではそのユースケースを詳細化し、ロバストネス図を…
「意」と「情」は互いを高め合う相乗効果が働きます。企画を進める際は、自分たちの「意」を「情」を通じて検証することが重要です。明確な「意」によって「情」に方向性を与えることでき、「情」によって「意」の視野を拡げることができます。
U理論でいうところの「self」と「Self」という概念や、匠Methodの要求分析ツリーにおける「業務要求」と「戦略要求」という概念を紹介しました。そして、これらの概念に共通する、次元を変えることによって問題解決につながります。論理思考で導いた結論を感…
U理論の「観察する」は、判断を「保留」して、立ち止まってフラットな目で見るという意味。現状を分析しすぎると、現状に囚われすぎてしまいます。問題解決のアプローチにすぐに行くと、本質的な解決に至らないことが多いです。匠Methodを用いて価値を見える…
匠Methodの進め方には、価値デザインモデルから始める方法と価値分析モデルから始める方法の2つがあります。経営者や事業レベルの人であっても、従来の成功パターンにとらわれ、新しいビジョンを見出せないことがあります。これは**U理論でいう「ダウンロー…
匠Methodでは「現意識」と「新意識」による未来価値を定義し、特に新意識は社会をより良くしようとする意志に基づく価値創出を意味します。自己中心的な視点から抜け出し、広い視野でビジョンを描くことが重要です。意志（意）を育むことが、より良い未来価…
匠MethodとU理論とのマッピング、およびU理論におけるプレゼンシングからビジョンを見出すプロセスについて解説しています。U理論の考え方を匠Methodのモデリングに取り入れる方法として、「自分たちは何者なのか」という問いを設定し、存在意義を深く考える…
システム開発では、ビジネス側と開発側が協調し、ビジネス価値の創出に向けて動くことが求められます。『超上流から攻めるIT化の原理原則17ヶ条』の第1条『ユーザとベンダの想いは相反する』の原則は、システム開発において、ビジネス側と開発側が持つ責任の…
要件定義を効果的に行うには、ビジネス側と開発側が協力し、互いの視点や目的を共有することが不可欠です。ビジネス側と開発側は具体的にどのように協力すればよいか、指針として参考になるのが、『*超上流から攻めるIT化の原理原則17ヶ条*』です。『超上流…
業務プロセスを構想し、整理する手段として、業務フロー図の作成が有効です。業務フロー図を作成する効果として、5W2Hの視点で業務の必要事項を漏れなく詳細化できること、業務の課題点発見とステークホルダー間の共通理解が促進されること、テスト設計や運…
ゴール記述モデルは、自分たちが果たすべき役割や責任を明確にし、覚悟を促すためのモデルです。このモデルを用いて計画の期間や担当者を決めることで、チームメンバーは現実的に自分ごととして捉えるようになります。また、ゴール記述モデルは、価値が適切…
匠Methodのモデリングにおいて、論理思考の落とし穴に陥らないためには、匠Method Value Metricsを活用して価値概念を記述し、価値を評価することが効果的です。価値概念を明確にすることで、認識の精度をより高めることができます。要求分析ツリーにおいて…
匠Method Value Metricsを活用することで、価値の「見える化」が実現し、視野が広がるだけでなく、価値が膨らむ、早い段階でモデルの品質が安定するといった効果が得られます。また、価値の評価と活動の評価を比較することで、その活動が真に価値を生むもの…
事業要件、業務要件、システム要件の3層に要件を階層化することは、事業戦略から業務運営、システム構築に至るまでの整合性を保つために不可欠です。各層がどのように連携して全体目標と一致しているかが明確になり、組織全体としての方向性が統一されます。…
ビジネス+IT様にシステム開発の要件定義に関するインタビューを受け、その内容が前編・後編の2部構成で記事として公開されました。要件定義の重要性やうまくいかない原因、アジャイル開発の誤解について前後編でじっくり解説しています。
『Learning Domain-Driven Design』(邦訳ドメイン駆動設計をはじめよう)の翻訳者とレビュアーによるパネルディスカッションの様子です。ドメイン駆動設計の重要概念である「区切られた文脈」の設計方法について説明しています。
『Learning Domain-Driven Design』(邦訳ドメイン駆動設計をはじめよう)の翻訳者とレビュアーによるパネルディスカッションの様子です。ドメイン駆動設計の重要概念である「同じ言葉」を日本で運用するノウハウ、特にソースコードでどのように扱うか、という…
『Learning Domain-Driven Design』(邦訳ドメイン駆動設計をはじめよう)の翻訳者とレビュアーによるパネルディスカッションの様子です。ドメイン駆動設計の原典とも言える通称エヴァンス本とLDDDの内容の違いについて、説明しています。
『Learning Domain-Driven Design』(邦訳ドメイン駆動設計をはじめよう)の翻訳者とレビュアーによるパネルディスカッションの様子です。翻訳者とレビュアーからみた書籍の魅力や特徴、書籍翻訳時のエピソードを紹介しています。
書籍「ドメイン駆動設計をはじめよう」の内容と書籍の特徴をお伝えします。 設計にこだわり、事業に貢献しようとする開発者にぜひ読んでほしい一冊です。
