プログラマの思索

第50回SEA関西プロセス分科会の放談会で話しながら、2012年末時点で、ITの地殻変動がどこに起こっているのか？を考えてみた。
＃ラフなメモ書き。

【1】日本のSIもアジャイル開発を最近は積極的に取り入れようとする流れがある。
2000年代前半、XPをコミュニティ中心で実践したものの、日本のIT業界のメインストリームにならなかった頃に比べると隔世の感がある。

ニュース - NTTデータと楽天が共同でアジャイル教育コース作成、両社で180人育成へ：ITpro

その理由は、欧米を中心にScrumを中心としたアジャイル開発が主流になったため、日本でも従来のウォーターフォール型開発にこだわらず、最新の開発プロセスを取り入れようとしたいからだろう。
だから、アジャイル開発が日本のソフトウェア開発の現場に合っているかどうかは、過去の経緯からして、まだ未知数の段階だろうと思う。
でも、リーマン・ショックや東日本大震災が突然降りかかり、ビジネス環境が激変する現代では、10年もの長期計画を綿密に立ててもあまり意味がなく、環境の変化に俊敏に合わせないといけないことは、経営者も痛感しているようだ。
管理職層よりも経営者にいる人たちの方から、アジャイルと言う言葉を最近はあちこちで聞かれるようになってきたからだ。

【2】そして、アジャイルという言葉がそれぞれの立場で意味が異なってきていると思う。
平鍋さんが、各人が発するアジャイルという言葉の違和感に対して、以下の記事でうまく表現されている。
僕としては、平鍋さんのように2つの意味で分ける意見はとてもしっくりする。

アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：ITmedia オルタナティブ・ブログ

アジャイルの右翼は開発重視。
TDD、CI、継続的デリバリ、分散バージョン管理など、技術的側面を重視ないし、ツールによる開発の効率化を重視する方向性を指す。
2000年頃、XPが提唱したTDDやCIなどの諸概念は、ソフトウェア自身でソフトウェア開発を効率化、透明化する流れへ発展した。
チケット駆動開発も本来はこちらの流れにいるだろう。

10年前はソフトウェア開発の環境自体が貧弱だったけれども、今となっては誰もが手軽にプログラミングできるようになっただけでなく、オブジェクト指向やXPのプラクティスのように優れたノウハウをすぐに吸収できるような環境がある。

逆にアジャイルの左翼は、マネジメント重視。
Scrum、PFなどが相当するだろう。
特にソフトウェア開発では、専門家集団によるチーム開発になりやすいため、チームで一体化して開発するのが難しいという特徴があると思う。
隣の人の仕事が大変で助けたいと思っても、技術や専門的知識がなければ、人を投入しても解決できないのだ。
それは人月の法則という経験則から既に言われていることだ。
だから、専門家集団がいかにチームで一体感をなしてチーム開発していくか、というマネジメントスキルが現代ではとても重要になってきている。

その流れにおいて、最近目立つ特徴は、Scrumにあると思う。
現代のアジャイル開発の隆盛を理解するには、Scrumが必須だと思う。
そして、Scrumは体系として確立されたフレームワークゆえに、WFだけでなく、XPやFDDなど他のアジャイル開発とは全く異なる開発スタイルと認識して勉強し直した方がいいと思っている。
そうでなければ、Scrumの理解を誤ってしまうから。

第三者からScrumを見ると、とても厳しいマネジメント手法の一つだと思う。
Scrumの価値は「コミットメント」「集中（専念）」「オープン（透明性）」「尊重」「勇気」の5つがあるが、それらをそのまま理解したとすれば、まるで軍隊の規律のように思える。
その5つの価値を促す行動を実践すると、アジャイルな特徴が出てくるのが面白い所だと思う。

【3】アジャイル・ルネサンスの中で違和感を持つのは、アーキテクチャなどの設計技法が軽視されていること。
技術革新が速すぎて、過去の経験が有効でない場面が多いのだ。
例えば、一昔前は、DB設計の非正規化によって性能要件を確保していたが、今となってはそのテクニックそのものが古い。
リソースが不足していたからそんなバッドノウハウが必要だっただけのことだ。
あるいは、業務システムでは、Cobolなどのバッチ設計がとても重要だが、Webシステム全盛の中でそのノウハウが忘れ去られている。
むしろ、RDBMSのスケールアップが現代の流れに遅れていて、NoSQLやMapReduceのような開発スタイルの方が注目されている。
確かに、Cobolという言語は個人的には消え去って欲しいけれども、バッチ設計というノウハウはJenkinsによるジョブ管理ツールでよみがえると思っているのに。

すると設計技法そのものが過去の経験知を活用しにくいため、プロセス管理で設計の未熟さを補おうとする傾向があると思う。
その傾向があるからこそ、アジャイル開発が注目されているのだと思う。
つまり、試行錯誤しながら小規模リリースすることによって、少しずつ設計したものを試しては安定できる基盤を求め、少しずつシステムを作っていくしかベストな方法がないのだ。

そんな考えは、以下の記事でも書かれている。

設計と実装の狭間で - 急がば回れ、選ぶなら近道

今はそういう時代なので、設計技法を確立するのはかなり難しい。
でも、個人的には、日本人技術者が過去の開発で蓄積してきた技術であるDOAや品質管理は、今のアジャイル開発にも適用できるし、設計技法の不足に対して何らかのサポートができるのではないか、と直感している。

忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索

忘れ去られた日本のIT技術～プロジェクト管理: プログラマの思索

この辺りで考えたことは又まとめていく。

【追記】
阪井さんとデブサミ2013に応募しましたので、応援してくださる方は、講演資料に「いいね」をお願いします。

Developers Summit 2013 Action!

デブサミ2013のプレサイトオープン～「公募コミュニティ」に加え、「公募セッション」「公募レポーター」を新設：CodeZine

(12) Developers Summit 2013 公募セッション応募ページ

あきぴーさんと二人でデブサミに応募させていただきます。
タイトル：「チケット駆動開発の本質」
応募者：阪井 誠 ＆ あきぴー
「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の著者らが語る実践を踏まえたチケット駆動開発の本質。著作に書ききれなかった思いを語らせていただきます。
まず、阪井がチケット駆動開発のバリエーションの一つである「挑戦の道具としてのチケット駆動開発」について語り、あきぴーが「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」と題して語り、チケット駆動開発の本質に迫ります。
デブサミでは、リンク先のスライドをベースにより洗練した発表を二人で行います。１コマにまとめるつもりですが、２コマに分けての講演も可能です(コメントをお願いします)。応援の「いいね！」をお願いします！

「挑戦の道具としてのチケット駆動開発」

「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ」

【追記2】
小林さんの資料もリンクしておく。
資料に掲載されている以下4つの論文は、いつか再読する。

・「ウォーターフォール」原論文再読 Windston Royce, “Managind the Development of Large Software Systems”
・プロダクト指向からプロセス指向へ Christiane Floyd, "Outline of Paradigm Change in Software Engineering"
・プロセス・プログラミング Leon J. Osterweil, “Software Processes are Software too”
・ソフトウェアの進化 M M Lehman and J F Ramil, “Software Evolution”

【追記】
感想を見つけたのでメモ。
共感してくれた人がいるのは嬉しいです。

Twitter / mnagaku: http://ow.ly/fL74z あきぴーさんの記事はイチイチ刺さるわー。「軍隊の規律」とか「リソースが不足していたからそんなバッドノウハウが必要だっただけ」とか。アジャイル界隈の言説で一番好きかも。自分が気になってて他人の意見を聞きたいとこを書いてくれる感じ。