チケット駆動開発の適用範囲

日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。
以下ラフなメモ書き。

【元ネタ】
「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索

[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば

ユーザの力を利用するアジャイル開発: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。
でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。

チケット駆動開発をWF型開発に適用する場合、「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事にもあるように、方法は二つあると思う。
一つは、WF型開発の一部の工程にチケット駆動開発を導入すること。
もう一つは、チケット駆動開発の特徴の一つである「チケットと構成管理情報の連携」機能やワークフロー管理機能を使って、変更管理を強化すること。

前者は、テスト工程の障害管理や設計工程や開発工程のレビュー管理に使う時が多い。
例えば、RxtStudy第1回勉強会で@ahyari氏が講演されたように、レビュー工程でRedmineを使って作業をスムーズに行えたという事例もある。
@sakaba37さんが提唱された補完チケット方式のチケット駆動開発は、WF型開発で予期していなかった作業の管理に適用するものだが、普通はテスト工程のタスク管理が当てはまりやすい。何故なら、テストしてどれだけバグが出るのか、というのは実際にテストしなければ分からないからだ。
つまり、テスト工程やレビュー工程では作業内容を計画的に予見することができないという特徴がチケット駆動開発と相性がいい。
チケット駆動開発はタスクの変更に強い、という特徴を生かすやり方だ。

後者は、障害管理におけるソース修正など成果物の変更を厳格に管理する時や、バグ検証やリリース作業、レビューのように複数人が連携する作業の管理で使う時が多い。
チケット駆動開発の醍醐味の一つは、バージョン管理のリポジトリにある全ての成果物の変更がチケットに記録されることによって、何故そのような変更がなされたのか、を後から追跡出来る点にある。
また、チケットのトラッカーをSW開発のワークフローと対応付けておけば、チケットの起票から終了まで、担当者がワークフローを意識しなくてもバックグラウンドでツールがワークフローを監視してくれる仕組みがある。
これらの特徴をSW開発の変更管理に適用することで、担当者が意識しなくても変更作業を透過的にモニタリングする仕組みが整う。
更に、HudsonやJenkinsのようなビルド管理ツールも連携すれば、ソース修正からビルド、リリースに到るまでの作業を全てツール上でコントロールできるようになる。

この変更管理の強化は、WF型開発だけでなくAgile開発にも適用でき、その恩恵を受けることによって、頻繁なソース修正があっても、常時リリース可能なコードラインを保持できるようになる。
この意味はとても大きい。

上記のように従来のWF型開発にチケット駆動開発を適用したいという要望はかなり多いように思う。
上記の記事によれば、日本のシステム開発モデルのうち「ウォーターフォール開発が全体の9割強をしめ、反復型開発およびその他の開発モデルは全体の3.9％程度にとどまっている」らしいからだ。
だから、昨今の高機能化したツールを上手く生かすことで開発プロセスを強化したいという動機につながっているのだろう。

僕は更に他の考えも持っている。
一つは、製品の開発者と製品を使うユーザの関係をサポートすることで、製品開発にユーザの力を利用できるようにすること。
ユーザの力を利用するアジャイル開発: プログラマの思索にも書いたけれども、現代ではソフトウェアだけでなく家電製品でも、そこそこの品質を確保できればいち早くリリースしてユーザに使ってもらい、ユーザのフィードバックを受けながら製品を小刻みにバージョンアップしていくビジネスモデルへ変化している。
これはまさにアジャイル開発における小規模リリースの発想と同じ。
その時に、製品開発のタスク管理だけでなく、製品を使うユーザが議論できるフォーラムや、ユーザからの障害報告や改善要望をチケットへ起票してもらう運用などがあれば、製品開発へダイレクトに生かすことが出来るだろう。
RedmineやTracを開発者とユーザがコミュニケーションできるポータルな場として提供し、チケット駆動開発の特徴を組み合わせて、ユーザの力を開発に利用できるようにしたいのだ。

もう一つは、チケット駆動開発の適用範囲について、ソフトウェア開発だけではなく、他業界の作業の管理や課題管理にも使えるのか、にも興味がある。
下記の記事にも書いたけれど、営業マンのタスク管理や情報システム部門・サーバー運用保守の課題管理、製造業や製薬業の作業の管理に使っている人達もいる。

RedmineのTime Trackerプラグイン運用の注意点: プログラマの思索

その場合の使い方が、SW開発におけるアジャイル開発のプロジェクト管理とどのように違うのか、という点を聞いてみたい。
僕の勝手な推測では、逆にチケット駆動開発のアジリティの特徴が出ていて、むしろアジャイルな作業管理になっているのではないかと思っている。
その人達はアジャイルという言葉を知らなくても、実際にアジャイルを実践しているのではないか、と期待しているのだ。

チケット駆動開発の適用範囲については、コミュニティで今後議論されると面白いだろうなあと思っている。

WF型開発におけるプロマネのテクニック

WF型開発におけるプロマネのテクニックを見ると、アジャイル開発に似ている部分もあれば、異なる部分もある気がした。
考えたことをラフなメモ書き。

【1】段階リリース、一定期間の仕様凍結、部分稼働
Twitter / @akipii: WF型開発における段階リリース、一定期間の仕様凍結、部分稼働、低リスクの都度対応はプロマネが良く取る手段だが、それはアジャイル開発につながるのか？多分アジャイル開発とは本質的に異なると直感している。

Twitter / @MyTH774: @akipii リスク受容が事前に行われるか事後あるいは暗黙に行われるかの違いかと。後者の方が発注側の開発結果から直接利益を受けない担当者からは予算ありきで主導権を握ることができるので好まれますね。

Twitter / @MyTH774: @akipii 社内システム開発を想定しています。そこで担当者は工期と予算の変更について必ず説明責任を負うが効果については融通が利くことがあります。WF型でリリースできたことにし立ち入った問題解析と責任を回避しつつ恩を着せるというあまり気持ちのよくないでもままある構図かと思います

WF型開発でもアジャイル開発のように、システム対象をフェーズ化して分割してりりーする「段階リリース」という手法が存在する。
段階リリースでは、1～3ヶ月単位でサブシステム単位にミニWF型開発を行う手法。
段階リリースは、プロジェクトマネジメントの経験が豊富なプロマネがよく取るテクニックの一つ。
1年以上かけてシステムを工程単位に開発していくのはやはりリスクが大きいからだ。

だが、段階リリースのテクニックはアジャイル開発とは本質的に異なると思う。
何故なら、アジャイル開発では、イテレーションと言う1ヶ月のタイムボックス内では、工程単位の開発スタイルではなく、設計も開発もテストも同時並行で作業しているから。
段階リリースのタイムボックスを3ヶ月、2ヶ月、1ヶ月、3週間とどんどん短くしていけば、ミニWF型開発を実施できる限界が来て、そこで破綻するか、アジャイル開発のように全ての作業を同時並行で作業するように変わるしか無いだろう。

また、段階リリースの場合、最後の工程である総合テストやシステムテスト、受入テストで、仕様凍結の期間が設けられる。
最後のテスト工程で、仕様変更が起きると手戻り作業が発生して納期が遅れる可能性もあるし、せっかくテストで仕上げた品質に修正したソースのバグが紛れ込んで品質が劣化する可能性もあるからだ。
つまり、仕様凍結の期間は、顧客のバックログが貯まるだけで消化されない期間になる。
この点はアジャイル開発とは根本的に違う。

そして、WF型開発では、バグ退治に一括修正する期間を設けるパターンが多い。
バグの都度対応ではコストがかかるだけで完全根治が難しいから、全てのバグを確定した後に要員を一気に投入して解決する手法をよく取る。
アジャイル開発は継続的に機能改善やバグ修正を行っていくから、都度対応を実施している事と同じゆえに、全く異なる。

また、納期遵守が厳しく、どうしても全ての仕様を実現できない場合、システムの部分稼働という手段もよく取られる。
つまり、顧客の業務に必要最低限の機能は本番稼動させるが、低頻度の性能要件や重要度の低い機能は2次開発で対応する手法だ。
例えば、トランザクション量が増えると機能要件すら満たさなくなる場合は非常に危険だが、そのリスクが1年後に発生すると分かるならば、今すぐに対応する必要はない。
@MyTH774さんが言うように、まずはシステムが部分稼働であれ本番稼動したことを顧客に恩に着せて、その後、性能要件や未実装の機能要件を実現していく構図はとても多い。

【2】プロジェクトオーナーやプロダクトオーナーの権威を利用する
Twitter / @akipii: プロマネの手法として、事態打開のためにプロジェクトオーナー(SI側の決裁権限を持つ上司。多分部長クラス)やプロダクトオーナー(顧客側の決裁権限を持つ上司)へ直訴する回答が多い。Agile開発であれWF型開発であれこの手法がいつも有効なのか、疑問に思う。

例えば、現場リーダーがプロジェクトを運営していてどうしても人が足りないケースや予算が足りないケースでは、自分よりも格上の上司(プロジェクトオーナー)に人員投入や予算増額を決裁してもらわないといけない。
あるいは、顧客サイドから膨大な要件があり、予算や納期の都合上全てを実現できない場合、顧客サイドの責任者(プロダクトオーナー)と調整しなければならない。
あるいは、顧客企業の窓口が一本化されておらず、あちこちの部署から要望が開発側へ来る場合、変更管理の手順を守ってもらうように顧客側の責任者(プロダクトオーナー)へ要請しなければならない。

この内容については、プログラマにコミュニケーションが足りないと言われる時: プログラマの思索で書いた。
WF型開発では、顧客側も開発側も体制が複雑な階層構造になっているため、この種の調整が非常に難しい。
だがとても重要な作業なので、放置されるとプロジェクト破綻のリスクが高まる。
Agile開発では、顧客側はプロダクトオーナー又はオンサイト顧客という役割で窓口が開発側に近く、舵取りはWF型開発よりも楽な構造になっている。

【3】稼動実績のあるシステムを流用
Twitter / @akipii: プロマネの手法として、運用実績のあるシステムやモジュールを流用してプログラムをコピー＋新規で作り、カスタマイズする手法が良く取られる。確かに当初リリース時の品質はいいだろうが、似たようなPGMが増えて保守性が悪くなるし最新の技術を取り入れにくい。そんな手法を取ってよいのか？

WF型開発では、既存の業務システムのプログラムを流用して、コピー＋新規でプログラムを作る手法をよく取る。
何故なら、既に本番運用されているプログラムはバグが少なく、品質が安定していると思われるからだ。
この種の品質を運用品質と呼び、テスト工程を通過した品質はテスト品質と呼んで区別している。

だがこの手法は、クローンプログラムを増殖させて、リファクタリングしにくくなる危険性があると思う。
また、最新のフレームワークや技術を反映しづらくさせる弱点があると思う。

【4】システムのフィージビリティスタディー(実現可能性検討)
Twitter / @akipii: 提案や要件定義でアーキテクトやSEは、システムのフィージビリティスタディー(実現可能性検討)の説明責任を顧客に対して負う。プログラマはシステムの完成責任を顧客に対して負う。アジャイル開発ではフィージビリティスタディーはどのように解決されるのか？

システム提案時に顧客に大きな夢を語り、要件定義でシステムの概要を煮詰めて、外部設計でシステム対象を確定させる。
その時、システムをどんな方式で実現するのか、というフィージビリティスタディー(実現可能性検討)をアーキテクトが中心になって外部設計で固める。
その外部設計終了時に再見積を実施して、開発金額や納期を確定させて、開発の請負契約を締結させる流れがWF型開発では一般的。

アジャイル開発では、システムのフィージビリティスタディー(実現可能性検討)をどのフェーズで実現するのか、あるいは誰が責任を持っているのか、という話はあまり議論されていないように思う。
基本は開発チームがイテレーション単位に開発していくから、開発チームがシステムのフィージビリティスタディーもシステムの開発も責任を持つ。
その意味では、開発チームの責任はとても重い。
既にフレームワークなどの方式要件が決まっていれば、アジャイル開発はとてもスムーズに行くが、それすらも曖昧な場合、作っては壊して検証していく開発スタイルになる。
その開発スタイルがどこまで通用するのか、はやってみないと分からない。

四半期と言うタイムボックスは長すぎる

@kuranukiさんのつぶやきを見て、なるほどと思ったのでメモ。

【元ネタ】
Twitter / @kuranuki: 定例会議のよくないところは、そのタイミングまで話すべきことを貯めておいたり、その会議までにやりさえすれば良いと締切駆動になってしまうところ。物事がその定例の間にしか進まないとしたら、週イチでやる組織ならその程度しかスピードが出ないとしたら遅いはずた。

Twitter / @kuranuki: タイムボックスは〆切駆動が出来て、ズルズルと続けるよりは全然良いのだけど、デメリットはそのタイムボックス中は見直しをしなくても良いと思ってしまいがちなこと。短いタイムボックスならまだましだが、半期や四半期というのは長過ぎて変化出来なくなる。一般的な企業はそんな感じだが。

Twitter / @kuranuki: みんなわかってるはずでイテレーションはそうするのに、事業計画だけは短くても四半期単位で見直そうとしてる。それは長い。 RT @haradakiro: @kuranuki タイムボックスの終わりが肌感覚でわからない長さのタイムボックスは有害というか、そもそもタイムボックスじゃない。

普通の定例会議では、進捗や課題について報告を受けたり、方針を決定したりする。
そのサイクルが週1回ならば、1週間経たないと問題解決できないから、その間プロジェクトの進捗が滞る。

普通の会社は四半期ごとに決算して、損益計算書や貸借対照表を作って公開する。
つまり、会社は4ヶ月というイテレーションないしタイムボックスで活動しているのと同じ。
普通のAgile開発の感覚では、4ヶ月と言うサイクルは長すぎる。

四半期というサイクルでしか会社の財務内容を精査できないのは、今までは手作業で決算整理していたため、それぐらいの時間がかかる理由があったのだろう。
だが、今はIT化によってもっと早く作業できるようになったはずだし、現代のように市場の変化がとても早い場合はビジネスが付いていけないだろう。
急ブレーキ、急発進できる意思決定の仕組みが必要とされているのだろうと思う。

ユーザの力を利用するアジャイル開発

「グーグルで必要なことはみんなソニーが教えてくれた」を読んで思ったことをメモ。

「グーグルで必要なことはみんなソニーが教えてくれた」の著者は、元ソニーのエンジニアの方がソニーで四苦八苦したプロジェクト内容とグーグルへ転職した時の雰囲気について書いていた。

気になった文章は、「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」の二つ。

前者は、製品をすぐに作ってはユーザへフィードバックして評価してもらい、その結果を製品に取り込んで機能改善していくこと。
後者は、すぐに作った製品の完成度があまり良くなくても、ほどほどの品質で早めにリリースして、ユーザにバグ報告とバグ検証をしてもらうような仕組みを作ること。

いずれの文章もAgile開発の発想にとても良く似ている。
ポイントは、「ユーザの力を利用して継続的に製品の完成度を上げる」「ユーザの力を利用して問題発見と問題修復を継続的にやっていく」ということ。
つまり、単なる継続的改善だけでなく、ユーザのフィードバックを吸い上げてその内容を製品へ反映していく仕組みも必要なことを示唆している。

Agile開発の発想がソフトウェア業界だけでなく、ソニーのような家電製品などの業界でも必要とされている。
その事実に正直驚いた。
しかし本を読む限り、その発想を著者が在籍していた時代のソニーは理解できていなかったらしい。
著者は「日本人の完璧主義が足を引っ張っている」と言っている。

アジャイル開発の発想をITエンジニア以外に他業界の技術者が理解して実践していく環境は、現在も揃っていないのではないかと思ったりする。

その中でも、「ユーザの力を利用する」仕組みがとても難しいのだろうと思う。
製品の購入ユーザには熱心な人も入れば、アンチなユーザもいる。
彼らの声を全て正しいと仮定して製品に全て取り込むには現実的に難しい。
また、彼らの声がたくさんあるほど、重要なメッセージを見落としやすい。
そして、ユーザの声を反映した製品を更にユーザに使ってもらえるように、届ける仕組みも大事。

最近流行しているFacebookやTwitterは、そういうユーザの声をリアルタイムに集めやすい。
だからFacebookファンページでユーザの声を収集してはユーザへフィードバックしていく手法で、マーケティングをやっている会社も多いのだろう。

チケット駆動開発でよく使われるRedmineやTracも、高機能化したBTSやITSを単なるバグや課題を収集するシステムではなく、一つのポータルなシステムへ拡張していると思う。
例えば、収集したデータを各種の観点でレポートしたり、問題修復した製品をアナウンスしたり、ユーザと議論するフォーラムがあったり、製品のTipsを公開するWikiがあったりする。
それらの機能があるおかげで、ユーザと製品の開発者がリアルタイムに議論して、より良い製品へ改善していく仕組みが整うはず。

アジャイルという発想は僕はとても自然だと思う。
でも、実際の組織に当てはめて運営していくには、まだまだ何かが足りない。

【告知】SEA関西ではOOA、関西IT勉強宴会はDOAの勉強会あります

SEA関西ではOOAのお話を児玉公信さんが講演されます。
関西IT勉強宴会では、ＲＤＢ理論を打ち立てたコッド博士の原論文を読んで議論するDOAの勉強会があります。
モデリングに興味のある方は、是非参加してみると良いでしょう。
以下、OOAとDOAに関してラフなメモ書き。

【元ネタ】
1月14日 第46回 SEA関西プロセス分科会(大阪府)

第13回関西IT勉強宴会 : ATND

【1】僕は、OOAからモデリングに入りました。
最初にきちんと理解して読めた本が児玉公信さんの本「UMLモデリングの本質」です。
そこから、OOAやDOA、ビジネスモデリングの本を片っ端から読んできました。

僕の中では、OOAは児玉公信さんの本、DOAは渡辺幸三さんの本がBestです。
お二方とも内容は抽象的ではなく、とても実践的です。
業務ロジックや業務が抱える問題をどのようにモデルに表現して、モデルからその本質を取り出すのか、とても詳しく書かれているので、とても役立ったからです。
そのモデリング方法を、児玉さんは「モデルの揺さぶり」と呼んでいたのが印象的。

【2】児玉公信さんの本は一通り読んだ。
「UMLモデリングの本質」で教わった点は二つある。

一つは、クラス図は抽象的な図なので、オブジェクト図やシーケンス図で具体的にイメージしながら整合性を取って書くべき、という点。
クラス図における継承関係は、オブジェクト図に書くと一つのインスタンスに過ぎない。
つまり、継承関係は具体例を抽象化した図なので、常に具体例を意識して書かないと、単なるお絵描きに過ぎない。
だから、インスタンスでクラスの関連を書くようにすれば、クラス図の品質は上がるだろうと思う。

もう一つは、アナリシスパターンの実例が具体的に書かれていてとても分かりやすかったこと。
例えば、知識・操作レベルの話は、クラスの集合とクラスの関係で表現できる。
「エリック・エヴァンスのドメイン駆動設計」では、知識モデルとはリフレクションをドメイン層に適用したものに過ぎない、という優れた指摘がある。

あるいは、勘定パターンは会計モデルだけでなく在庫モデルにも出てくる。
面白かった点は、航空機チケットの予約システムをモデル化すると、実は小売業や製造業の倉庫の在庫管理システムと似ている点。
航空機チケットもJRチケットもホテルの部屋も四季劇場のチケットも、そのチケットや部屋というのは論理的な在庫であり、常に予約されなければ売上につながらない。
すなわち、小売業の商品や製造業の製品は倉庫に長期間保持せずできるだけ早く販売するように、在庫回転率を上げるような経営戦略を取る必要があるという法則がモデルから導き出される点が面白かった。
ここから、ソフトウェア開発のモデリングがビジネスモデリングにつながるわけだ。

児玉公信さんの本としては他に「システム開発の見積りのための実践ファンクションポイント法」も良かった。
内容は、ER図とDFDからモデルの開発規模を見積り、そこから工数や納期へ変換する手法を解説している。
児玉公信さんはファンクションポイント関係の学会にも所属しておられるので、とても内容は深い。

モデルが見積りと関係する理由は、システム提案や要件定義のような上流工程でモデルを作れば、システムの開発規模が大体分かり、そこから本来の工数や価格を提示することが出来るからだ。
そして、ゆくゆくはファンクションポイントをシステムの開発規模を表す単位として貨幣のように流通できれば、システム開発を投げ売りにしたり、高価格で売ることなく、本来のあるべき価格で開発できるはず、という主張が面白かった。
つまり、モデルの利用目的としては、ビジネスの戦略のサポートだけでなく、規模見積りも行いたいという暗黙的な存在理由もある。

【3】渡辺幸三さんの本も一通り読んだ。
「業務別データベース設計のためのデータモデリング入門 」「生産管理・原価管理システムのためのデータモデリング 」の本がとても良い。

渡辺幸三さんの本から学んだ点は二つある。
一つは、DOAの方がOOAよりもはるかに制約が強いために、ビジネスルールを明確に反映しやすいこと。
下記の記事にも書いたけれど、2次識別子や暗黙的なリレーションシップ(継承属性とも呼ぶ)の使い方の解説は秀逸だと思う。

(3-1)ボイスコッド正規化は2次識別子の制約を課す
(3-2)継承属性を明示することで暗黙的なリレーションシップを見出す

DOAとOOAの違い: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

日本のソフトウェア設計では、OOAよりもデータモデリング中心。
でも、DOAをより深くまで知り尽くして設計しているとは到底言えないと思う。

ER図を見れば、設計者がどのように業務をモデル化したのか、分かる。
テーブルの構造や関連に業務ルールを入れ込んで制約を表現することで、業務データの一貫性や整合性を保持しやすくなる。
「ERPの本質は統合DBの構築にある」と主張する「楽々ERDレッスン」の羽生さんが言う通り、業務データの設計はまさに業務システムの設計に直結する。

もう一つは、業務システムのDB設計の背後には簿記の知識が絡んでいること。
「販売管理システムで学ぶモデリング講座」では、販売管理システムを対象にそのDB設計を詳しく説明している。
だが単に業務ルールをER図へ埋め込むだけでなく、会計の観点ではどのような意味を示しているのか、も詳しく書かれている点が秀逸。

特に倉庫への材料や製品の入出庫に関する受払業務は、簿記2級の工業簿記の知識がなければ、本当に理解できたことにならないと思う。
例えば、材料が倉庫へ入庫して買掛金が発生した場合、材料が倉庫から出庫して工場へ仕掛品ないし製造間接費として消費された場合、製品が完成して倉庫へ入庫して販売を待つ場合、製品が倉庫から出庫して販売されて売上が発生した場合では、それぞれのケースで会計の仕訳が発生する。
つまり、倉庫の入出庫のタイミングで、費用や資産、売上が計上されて、モノの流れとお金の流れが連携してデータが変わっていく。

「エリック・エヴァンスのドメイン駆動設計」でも、そのモデルの背後には会計知識が絡んでいる。
下記にも書いたけれど、「船荷証券」「発生主義会計(つまり、未払費用・受取収益のような経過勘定科目)」という概念がOOAでも本質的に出てくるのだ。

Agile開発に足りないもの～モデリング技術: プログラマの思索

だが、仕入や売上の割引や返品のように、業務にもシステムと同じように例外処理があり、それも考慮しなければ良いモデルとは言えない。
当然その業務にも仕訳があり、モノの流れと同じようにお金の流れもモデルに組み込む必要がある。

ERPの落とし穴part2～業務の裏には会計あり: プログラマの思索

OOAでもDOAでも、ソフトウェアの対象となるビジネスや業務をモデル化する技術を提供してくれる。
個人的には、モデル化に必要な技法(OOA・DOA)とモデルの背後にある本質的な概念(例：簿記)を区別してまとめたいなと思う。

PostgreSQLの再帰SQL

PostgreSQLでも再帰SQLが使えると聞いたのでメモ。

【元ネタ】
住友電気工業株式会社におけるオープンソースソフトウェアの積極的な導入 ? Let's Postgres

再帰SQL ? Let's Postgres

新しい業界標準「SQL99」詳細解説

再帰SQL | 最近、開発に縁が無くなってきた技術者のきねづか

再帰SQL: プログラマの思索

再帰SQL part2: プログラマの思索

OracleのPIVOT句: プログラマの思索

再帰SQLの使い道は、階層構造を持つテーブルやデータの検索。
よくある例は、ツリー構造にカテゴライズされた商品の検索や、製造業の生産管理システムで部品や品目を検索する時だろう。

この業務ロジックをアプリケーションで書くのは結構苦労する。
ストアドやSQLで複雑な業務ロジックを隠蔽化できるならば、アプリ側はストアドをコールするだけでいい。
そして、DBサーバー側でストアドを実行するので、業務処理の高速化も期待できる。

また、DBUnitを使えばストアドの単体テストにも使えるので、品質向上も見込める。
つまり、テストに必要なテストデータを準備すれば、DBUnitでストアドのテストを自動化することも可能だ。

SQLは色んな書き方があるので、知っておくと便利。
だが、最近のWebアプリ開発では、DBサーバーがボトルネックになる時が多く、DBサーバーのスケールアップに難があるため、アプリケーションサーバーのスケールアップを利用して、DBを単なるデータの格納庫で設計するやり方も見かけるようになった。

KVSのような脱RDB、Hadoopなどの新技術と今後のDOAの進化については、アーキテクチャ設計も絡めてもう一度考え直してみる。

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり～クラウド時代の非同期処理: プログラマの思索

ALMはSW開発のERPと同義

最近、アプリケーション・ライフサイクル・マネジメント(ALM)という言葉を聞くようになった。
僕の理解では、ALMはSW開発のERPと同義だ。
考えたことをメモ。

【元ネタ】
アプリケーション・ライフサイクル・マネジメント - Wikipedia

IT Pro のための ALM 入門 | Tech Fielders コラム

IBMが推進する“分散型開発でのALMソリューション” － TechTargetジャパン プロジェクト管理

MSのTestManagerはTestLinkと全く同じ！: プログラマの思索

アジャイル開発はツールに依存している～SW構成管理を再考しよう: プログラマの思索

Kent Beck VSTSのホワイトペーパーの日本語訳

【1】アプリケーション・ライフサイクル・マネジメント - Wikipediaによれば、ALMとは、システムをツールでで継続保守するための全体的な管理を指す。
そもそもソフトウェアには納品という概念はない。
何故なら、納品後はシステムは稼働中となり、ユーザが日々運用していく。
つまり、システム開発には、運用中か開発中、未着手という三つのステータスしか無い。

その話を考えると、@kuranukiさんが言われている「Point of Sales」から「Point of Use」へ」の話を連想させる。
ソフトウェアは製造業と違い、納品したら常時稼働し始めて、運用保守しながらバックエンドでは次の新機能開発に従事する並行開発が普通なのだ。
だから、製造業よりもはるかに難しい場面が多いのだろう。

ALMはそのような状況を背景として、ソフトウェアを継続的に開発していくための開発インフラを提供する。
IBMのRational製品、MSのTFSが具体的に実現された製品群になるだろうと思う。

【2】しかし、ALMの弱点はアプリケーション・ライフサイクル・マネジメント - Wikipediaに書かれている通り、製品を提供するベンダーにロックインされてしまうこと、ソフトウェアの保守コストが大きくなることがあるだろう。

多分、普通はバージョン管理を入れて、障害管理にBTSを導入して少しずつ開発インフラを整えていく。
だが、スケジュール管理やコスト管理、テスト管理などソフトウェア開発全般をツールでカバーしようとすると、MSやIBMのような製品を使わざるを得なくなる。
すると、開発ツールがベンダーにロックインされてしまい、その後の開発や運用保守にも影響を受ける。
ベンダー製品が技術進化に遅れる危険もあるし、製品のライセンス費用もバカにならない。

【3】そんなことを考えると、ALMという概念とセットに売り出された製品はソフトウェア開発のERPと同じように思える。
ソフトウェア開発に必要な開発インフラを提供するだけでなく、コスト管理や内部統制などの機能まで付けている。
盛りだくさんの機能があるほど、管理者も開発者もどこまで使いこなせばいいのか分からない。

開発ツールを導入すると、副作用がある。
丁度、顧客がERPパッケージを導入すると従来の業務フローが変わるだけでなく、組織体制も変わってしまうのに似ている。
それについては以前下記で書いた。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ALMを提唱する製品を開発チームが使う場合、まずFG分析で、自分たちのチームにどこまで製品(ツール)の機能を新しく取り入れて、従来の運用は崩さないようにするか、見極める必要があるだろう。
そうしなければ、ツールを使いこなすだけで精一杯で、肝心の開発に役立たない。
そして、実際にツールを使いこなしていきながら、測定して評価する改善プロセスを実施する必要がある。
そうしなければ、高いライセンス費用を払ってでもツールを買って使いこなせているか、評価できないからだ。

つまり、ALMを提唱する製品はプロセスを含んでいて、それは従来の開発スタイルを大きく変える副作用がある。
事前調査してから使いこなさなければ、本来の威力を発揮できない可能性の方が高い。

ERPの導入事例は90年代から歴史があり、成功事例よりも失敗事例の方がはるかに多いように思う。
だから、ソフトウェア開発にERPのような大げさなものを導入して、逆に生産性を落とす危険性があると考えている人は多いだろうと思う。

【4】チケット駆動開発は本来Tracのチケット管理をSW開発のタスク管理に適用する発想から生まれた。
開発現場で試行錯誤しながら生まれた開発スタイルであり、ALMのような高尚な概念までたどり着いていない。

しかし、チケット駆動開発を実現するRedmineやTrac、GitやMercurial、HudsonやJenkinsと言ったツールを組合せると、最終的にはソフトウェア開発のERPのような仕組みに似てくる。
ツールによって、作業を見える化するだけでなく、コミュニケーションを活発化させて、開発チームの透明性を上げていく方向へ進化している。
ケント・ベックは「Kent Beck VSTSのホワイトペーパーの日本語訳」において、アジャイル開発にはそのようなツールが必要と述べている。

だが、その危険性についてもたくさんの人が感じ始めている。
@yusuke_kokuboさんや@daipresentsさんの主張を読むと、一度ツールにのめり込んだ後、ツールから離れた開発スタイルを追いかけているように見える。

Twitter / @yusuke_kokubo: @yusukey 一応補足しておきますけど、Redmineを独自カスタマイズしてるのは業務にあわせてゴリゴリしてるだけで、決して使うこと自体を目的にしてるわけではないですよ。 最近ではRedmineをどれだけ使わないで開発を進められるかが個人的なテーマです。

Redmineが1000人のエンジニアに使われるまでのこと | 世界

ツールに依存しすぎて重たすぎるERPになってしまうと、本来のアジャイル開発とはかけ離れてしまう危険があるからだろう。
今後は、その危険を避けながら、チケット駆動開発がどこまで進化できるのか、という問題が大切になってくるだろう。

【5】これほどERPの失敗事例がありながらも、ERPを導入して成功した事例もある。
羽生さんの本「楽々ERDレッスン 」では、ERPはBPR実現のドライバとして有効であり、 BPRでは統合DBが重要と認識した企業がビジネスプロセスの再編に成功している、と書かれている。
つまり、ERPで成功するには、統合DBという考え方を具現化することでBPRが促進されることを理解するのが重要ということ。

これは、統合DBで情報が一元化されることによって、その情報を複数のビューで見たり、多種多様なレポートをいくらでも出力できるようになる恩恵があることを指していると思う。
統合DBという資産を作り、その資産からどのように価値を生み出すのか、という視点が必要なことを示唆しているのだ。

この考え方をALMやチケット駆動開発に当てはめてみると、ERPの統合DBに相当するものは何なのか？
それは、バージョン管理の配下にあるソースや設計書、ビルドスクリプト、DDLなどだ。
更に、ITSチケットやWikiなどの情報も含まれる。
つまり、SCMリポジトリやITSのDBが統合DBに相当するものになる。

チケット駆動開発の発端となった運用ルール「No Ticket, No Commit」はソースの修正理由を必ずチケットの履歴に残す。
成果物の変更履歴をITSチケットに必ず残すという運用のおかげで、変更管理の情報がITSへ集約される。

そして、チケットを作業指示書と見なして、プロジェクト内部の全ての作業履歴をチケットへ集約する。
すなわち、チケット駆動開発における統合DBはSCMリポジトリやITSのチケット・Wikiなどの蓄積された作業履歴や共有情報になる。

チケット駆動開発では、全ての情報がITSを通じて表示できる仕掛けがあるので、ITSのレポート機能を中心にもっと強化すればいろんな価値を生み出すことができる可能性を秘めている。
チケットの粒度と進捗ビューの関係: プログラマの思索にも書いたけれど、Redmineのレポート機能は正直貧弱であり、まだまだ改善できる余地がある。

Redmineに蓄積された情報をどのように保守しながら、価値ある情報を見せていくべきか、という観点でプラグイン開発していけば、もっと進化できる可能性はある。
色々考えてみる。

Redmine Advent Calendar jp 2011とRedmine1.3に向けての感想

Redmine Advent Calendar jp 2011という催しが開催されていたのでメモ。

【元ネタ】
Redmine Advent Calendar jp 2011 : ATND

plugin 作る時にはこの設定 - Change The World

Haru's blog: Redmine 1.3.0の個人的な注目機能

インフォメーション：本日12月1日より，プログラマ有志による2011年の技術系Advent Calendarが各所ではじまる｜gihyo.jp … 技術評論社

クリスマスまで1日1つの記事をBlogやSNSへ公開していくリレーらしい。
@changeworldさん、@haru_iidaさんの記事が公開されているので読める。
技術系Advent CalendarはRedmine以外にもたくさんあるみたいなので、追いかけると楽しいかもしれない。

最近のRedmineの動向としては、次のメジャーバージョン1.3.0がいつリリースされるのか、という点だろう。
1.3.0のチケットは全て完了していて、リポジトリにも1.3.0-stableのブランチが作られているから、即リリースしてもおかしくはない。

1.3.0 - Redmine

@haru_iidaさんの記事によれば、1.3.0では、PDF出力やREST APIの強化、Wikiやリポジトリブラウザの改善などが含まれているらしい。

@naitohさんの力作であるPDF出力は、マネージャ向けにアピールできるウリになるから重要な改善だと思う。
マネージャも顧客と同じく、帳票という紙にとてもこだわる人種だから。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

また、REST APIが使い物になるならば、スマートフォンや携帯など各種デバイスからRedmineへアクセスして情報を取得するのが容易になる利点がある。
つまり、REST APIの機能強化によって、他サブシステムや多種多様なクライアントとの連携がやりやすくなるので、例えばiPhoneやAndroidアプリの開発も促進されるだろうし、それによってRedmineの使い勝手も上がるだろう。

Redmineプラグインあれこれメモ: プログラマの思索

SOAPからRESTへ: プログラマの思索

RedmineのRESTful APIを使う: プログラマの思索

一番興味を惹いたのは、リポジトリブラウザのリビジョングラフ表示機能だ。
この機能はGitやMercurialで、コードラインの変遷を1本の線として表示する機能。
TortoiseHgでは既に実装済みの機能であり、複数の開発者のパッチがいつtrunkへマージされていったのか、がとても分かりやすくなる。

git-flow による構成管理とRedmineの関係: プログラマの思索でも書いたが、最近は分散バージョン管理ツールを駆使すれば、並行開発がとてもやりやすくなってきた事情がある。
例えば、複数の案件が同時並行で開発されていて、それらの新機能がmasterへ随時反映されていく並行開発の場合、リビジョングラフ表示があれば、生物の系統図のようにシステムがどのように進化していっているのか、がよく分かる。

Redmineがコミュニティをバックグラウンドとして、どんどん機能改善していくのはとても頼もしいと思う。