マネジメントのスピードが開発のスピードに直結する
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。
【元ネタ】
アジャイル開発のボトルネック - Social Change!
(中略)
つまり、発注側のかけるコスト(工数)の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数(コスト)以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)
上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。
僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ!と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。
すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。
この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。
従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。
XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。
ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。
今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。
要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。
その作業をつなぐ部分にボトルネックがあるのかもしれない。
| 固定リンク
「モデリング」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- Go言語でできることは何なのか(2022.11.06)
- クラウド上の開発がJavaに与えた影響は何なのか(2022.10.16)
- 「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった(2022.09.18)
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「ビジネス・歴史・経営・法律」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- 農林水産業はITと相性がいい(2023.01.09)
- 過学習に陥った人間や社会の事例は何があるのか(2023.01.09)
- 経営戦略とIT戦略をつなぐ鍵は何なのか(2023.01.04)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「TestLink」カテゴリの記事
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- TestRailの感想(2021.06.23)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント
わかります。
レビューって日程調整・参加者の選定・レベルを考えた説明など考え出すと、準備でもかなり能力・時間を使ってしまいます。
その上、決定の遅延があった時には。。
本当どうしたらいいんでしょうね?
>要求を洗い出す作業と、要件を仕様化する作業は別の能力
私もそう思います。ざくっとしたプロセスとして、発散と収束のように感じます。渡辺幸三さんの本にヒントないだろうか。。
P.S.
現在、リニューアルシステムのUI設計しています。利用者との打ち合わせのしょっぱな「そもそも何するシステムですか?」orz
上流の担当者は何してたのだろうか。。。
投稿: YF | 2009/11/07 18:50
◆YFさん
そうなんですよ!
レビューのコストとそのメリットを天秤にかけると、意外と割が合わないのです。
要件定義もレビューも、もっとアジャイルにできないか、試行錯誤しています(^^;)
投稿: あきぴー | 2009/11/08 18:02