【公開】XP祭り関西2011講演資料「Agile開発のスケールアップ~Agile2.0を支えるチケット駆動開発」 #xpjugkansai
XP祭り関西2011で講演した資料をCC Attributionライセンスで公開します。
最近考えたこともメモ。
【1】先日、著者の長谷川さんと橘高さんから「アーキテクチャ中心設計手法」を献本して頂いた。
ありがとうございます。
本の内容は、アーキテクチャ中心設計手法(ACDM)に関する解説で、本邦初とのこと。
似たような本として「実践ソフトウェアアーキテクチャ」もある。
今回の発表では、自分が大規模プロジェクトの一つのチームリーダーとして、プロジェクト全体の中でどのように動いたら良かったのか、そして、プロジェクト全体をどのように率いればよいのか、を色々考えてみたことを入れている。
今後は、アジャイル開発をブラッシュアップする技術として、チケット駆動開発がもたらしたワークフロー・トレーサビリティ・自動集計のような機能だけでなく、アーキテクチャ設計やテスト管理の観点も入れることを考えている。
【2】懇親会や2次会で話していて思ったことがある。
一つは、ソフトウェア開発の技術革新が過去の技術ノウハウや成功体験を陳腐化させていること。
メインフレーム+Cobolや昔の組込みシステムの開発で経験した技術ノウハウは、現代ではむしろ邪魔する時がある。
バッチ処理は昔は1日1回回すだけでも大変だったから、あれこれ工夫していたけれども、今は1日にリアルタイムのように何度もバッチ処理を走らせるのも普通。
バッチ処理もCobolよりもDBMSのストアドの方がメンテナンスも楽ではないかと思ったりする。
又、DBの性能が出ないためにテーブルの非正規化などのノウハウがあるけれど、今はDBMSも性能が良くなり、しかもサーバーそのものの性能もかなりいいので、むしろDBの非正規化によって、プログラムの保守の方が大変な時がある。
サーバーもHDDやメモリが1年おきに性能が拡張されて、値段も安くなるだけでなく、SSDのようにメモリをHDD代わりに使うことによって、I/Oの性能改善だけでなく、信頼性の向上という利点もある。
サーバー構築の手法も5年前に比べると、かなり変わってきている。
組込みプログラムも、昔は少ないメモリ上でいかにプログラムを書くかというノウハウがあったけれども、Androidプログラミングのように、今は大量のメモリがある前提で作った方が綺麗なプログラムが書ける。
そして、技術ノウハウもネット上に溢れているために、会社が技術の標準化を頑張ったとしても、その内容はネット上で探せるレベルならば価値がないし、技術革新の速度に追いつかなくて陳腐化しやすい。
つまり、10年以上前の技術の成功体験は実はあまり役立っていないどころか、綺麗なプログラムを書く邪魔をしている時すらある。
むしろ、経験者がアドバイスできるのは、プロジェクトマネジメントの経験ぐらいであり、組織運営やプロジェクト管理の方面だけに限られている。
そして、従来のプロジェクト管理の技法も、Agile開発やチケット駆動開発などで、プロジェクト管理の経験がない人達が模擬体験できる時代になりつつある。
すると、ソフトウェア業界で過去に成功した人達の存在意義があまり役立っていないような気がしている。
技術革新が過去の成功体験の価値を下げている面がある。
【3】もう一つは、日本人技術者は今までソフトウェア開発の技術に関してかなり経験を持っているのに、理論化出来ていない事。
その問題意識については下記に書いた。
忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索
忘れ去られた日本のIT技術~プロジェクト管理: プログラマの思索
日本人技術者は過去数十年のシステム開発で、品質管理・DOA・プロジェクト管理についてかなりのノウハウを持っている。
しかし、そのノウハウを体系化して、一つの理論として、書籍として公開してくれていないように思う。
だから、今の技術者は過去の人達のノウハウを流用できてない。
品質管理における信頼度成長曲線などのメトリクスに関する研究は、製造業の手法を参考にして、日本のメーカー系SIが独自に生み出してきた。
しかし、奈良さんの「ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点」ぐらいしか日本人の著作がない。
金融系などの業務システム開発の経験を踏まえて、1970年頃の早い段階でTHモデルやT字形ERなどのDOAが生み出されてきた。
しかし、今の日本の業務システム開発において、参考にされてはいるが、殆ど使われていない。
むしろ、Railsが出てきて、DOAの重要性が逆に注目されているというのに。
そして、大規模プロジェクトの経験から、プロジェクト管理のノウハウもいくつかの書籍として散らばった形としてまとめられている。
しかし、CMMIもPMBOKも過去のそれら知識を集大成して整理したたものに過ぎないのに、そちらの方がはるかに普及している。
せめて日本人技術者のプロジェクト管理のノウハウを、デザインパターンのようにプラクティス集にまとめてくれるだけでもいいのに。
但し、組み込み系プログラムの保守開発の経験から、清水吉男さんが提唱するXDDPという派生開発は独自発展している。
XDDPと言う派生開発: プログラマの思索
派生開発プロセスXDDPの講演メモ: プログラマの思索
アジャイル開発もスクラムもリーンソフトウェア開発も、本来は日本の野中先生の論文やトヨタ式生産手法がアイデアの発端にある。
アジャイル開発を日本流にアレンジしたアイデアとして、平鍋さんが提唱したプロジェクトファシリテーションというプラクティス集もある。
しかし、プロジェクトファシリテーションはこれだけ価値があると知られていて普及しているのに、代表的な著作がないのがとても残念。
平鍋さんはプロジェクトファシリテーションを書籍として出版しないのかな?
自分としては、過去の日本人が既に経験している優れたノウハウを集めて、一つの体系にして、公開できるものにできたらいいな、と思っている。
| 固定リンク
「モデリング」カテゴリの記事
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
- 諸問題を組織論に持っていくのは目的を手段化していないか(2022.02.02)
「プロジェクトマネジメント」カテゴリの記事
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想(2022.02.18)
「コミュニティ」カテゴリの記事
- 『ものづくりの数学』の感想 #もの数(2022.04.10)
- RedmineJapan vol.2が開催されました #RedmineJapan(2022.02.25)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
- なぜソフトウエア後進国の日本でRubyは成功したのか?~ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある(2021.11.09)
- redmine.tokyo10周年を祝う会でふりかえりしました #redmineT(2021.08.08)
「Redmine」カテゴリの記事
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- RedmineのWikiタグでタスクリストを書けるようになった(2022.03.21)
- RedmineJapanで参考になった講演資料を読み直す(2022.03.06)
「ソフトウェア工学」カテゴリの記事
- ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ(2022.05.14)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
「プロジェクトファシリテーション」カテゴリの記事
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 信頼と心理的安全性は概念が違う(2021.11.23)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
コメント