無料ブログはココログ

« 2013年10月 | トップページ | 2013年12月 »

[#TiDD] リポジトリマイニング - お手軽にリアルタイムの生データ -

ソフトウェア開発のデータベースに相当するものを「リポジトリ」と呼びます。具体的には、バージョン管理ツールの履歴情報のデータベースや障害管理システムのデータベースなどがあります。

ソフトウェア工学では、古くからメトリクス(尺度)の研究が盛んでした。計測できればより制御が容易になる事から、コード行数や障害件数など様々なメトリクスの分析が行われてきました。

メトリクスの研究の課題は、どのようなメトリクスがソフトウェア開発に役立つのかということのほか、データ収集の負担、収集にかかる時間、人手が介在する事で不正確になる、といった事です。

そこでメトリクスのデータとしてソフトウェア開発のリポジトリを使えば、お手軽にリアルタイムの生データが得られるようになります。

このような考えで作られたのが、EPM(Empirical Project Monitor)です。

リポジトリマイニングに関する国際会議が開かれているほか、チケット駆動開発もその応用の一つと考えられると思います(EPMについては書籍「チケット駆動開発」でも触れています。また、EPMの後続システムでRedmineやtracに対応したEPM-Xについては神谷芳樹さんが「チケット&計測でITプロジェクト運営の体質改善 」で書かれています。電子版はオーム社のサイト、Google、Amazonで買えるようになるそうです)。

教育分野への応用としては、井垣宏先生がProject-based Learningを実践されています。11月30日の第9回RxTstudyで招待講演をお願いしていますので、ぜひご参加ください。

【告知】[#RxTstudy] チケット駆動開発と教育、Redmineの事例とプラグイン、そしてgit


電車でPDFが読める! iPad mini retinaモデル WiFi C?

色々と悩んだ末に iPad mini retinaモデルを買いました。これまで読めなかったPDFの書籍が読めるようになりました。

悩んだ理由

◎画面と大きさ
かつてEPUBのデバイスとしてkoboを買いましたが、解像度が低い事、スクロール時にチカチカするという理由で、PDFは読む気になりませんでした。

そこで、大きい画面が欲しかったのですが、10インチは重そうでしたし、Airにはかなり惹かれましたが、やっぱり重いと思いました。重さと解像度で考えるとKindle Fire HDX 8.9が魅力的でしたが、アプリの充実度からiPad mini Retinaモデルにしました。

◎容量
使わなかったKoboやAndroid系の端末ならSDスロット装備のものもありますが、iPadはスロットがないので悩みました。

使用中のiPhoneが64Gなので、同期をしようとするとかなりお高くなります。iCloudと音楽の購入分だけなら大したサイズではないですし、ネットワークさえ用意すれば色々なサービスも使用できるので、16Gモデルにしました。

◎通信方式
やっぱり、通信したい場面は多々あると思い、LTE対応モデルにするか悩みました。本体が1万円高くなるほか、(いまのところ)iPadはSIMフリーでないので通信費もかさみます。

ひとまず、iPhoneのテザリングではじめて、遅くて我慢できないならU-mobileを利用しようと考えました。フレッツユーザーなのでルーター込みで1000円ちょっとですが、充電対象をあまり増やさないようにしました。

使用感

◎持った感じ

20131124_144704_2

両手が好ましいですが、片手でもPDFが読めます。そのままではすべすべして落としそうなので、100円ショップのCanDoでiPad mini用のケースを買いました。長靴のような手触りですべりにくくなりました。マイク穴が一つ隠れたり、チープさからiPad mini Cと呼ばれたりしますが、気にしていません。

ガラス面が保護できないのでダイコクドラッグの100円コーナーでスポンジ入りのモバイルケースを買いました。仕様では幅が足りないのですが、マチ(厚み)に余裕があるので、ちょうど良い感じです。

両方をあわせて424グラムです。モバイルケースから出すと387グラムですので、両手なら立ったままでも余裕です。片手なら10分ぐらいで持ち替えたくなりますが、20-30分ぐらいは我慢できます。ちなみに、iPad Airは「片手は無理!」と知人から聞いています。

◎画面と操作性
PDFを見た感じは原寸大でも読めなくはないですが、字が小さいので横向きにして拡大しています。イメージとしてはA4の印刷物を2つ折りにして読んでいる感じです。画面端のタップかスワイプでページめくり、上部のダブルタップで拡大の2つの操作で良い感じで見れます。

20131124_93542_2

Nexus 7も一時期検討していたのですが、iPhone 5のように細長いとスライドや文書などを拡大すると狭くなるか大きくならないかなので、iPadの画面比率は魅力でした。実際に知人のiPad Airと見比べると、横方向で少し大きめの字になって、おじさんにはちょうど良い感じである事が確認できました。写真ブラウザで見てますが、Kindleアプリなどではメニューがないのでもっと広く使えます。

最近、色の再現性が話題になってますが、少しだけギラつく気がする意外は、あまり気になりません。写真がメインではない人なので、これだけきれいに見えれば十分ではないです。

◎容量

どちらかというと、電子書籍がメインなのでゆとりが欲しいところでした。そこで、KindleクラウドにPDFを送って見るようにしています。あまり見ないものは端末から削除しておいて、必要なものはサーバーからダウンロードします。Kindleクラウドは4GBまで使用できます。

◎通信方式
Bluetoothでテザリングしています。一度ペアリングすればiPhone側は触る必要がなく、iPadで設定->Bluetooth->接続だけで通信できます(切断は画面下からスワイプすればワンタッチです)。

通信速度は遅いですが、アプリやファイルのダウンロード以外はあまり気になりません。WiFiとちがって、通信時以外はあまり電池を消費しないようで、iPhoneで操作している時の電池の減りと大きくは変わらないように思います。

iPad自体はBluetoothやWiFiをオフにしていると、使用中以外はほとんど電池が減りません。PDFを見てる時間が長い事もあり、数日に1回ほど充電しています。

まとめ

買って良かった!

世界が広がります。いままでは、iPhoneが隙間時間の利用だけでなく「暇つぶし」として色々操作していました。しかし、iPadで本が読めるようになると、隙間時間が有効に使えるようになりました。

少し前は、Twitterで得られる情報が膨大であまり気にならなかったのですが、最近はfacebookのグループなど狭い範囲で情報発信される方が増え、有用な情報が減っているように思います。

本というのはそれなりに情報がまとまっています。読みたい本があるのなら、短い時間の利用方法としては良いと思います。

通信を頻繁に行う人ならキャリアのLTEか、いずれ出るかもしれないSIMフリーモデルに安いSIMも良いかもしれません。私は通勤経路では電波の弱いところもあって電池の消耗が予想されるので、WiFiモデルが正解だったと思います。

メモリーに関しては難しいところですが、 私の場合はサブですので、いまのところ問題ありません。 検討される場合はKindleクラウドで節約する方法や通信方法も含めて、事情にあわせて考えてみてください。

このエントリーをはてなブックマークに追加

アジャイル開発におけるプロジェクト成功の定義 - アート・オブ・アジャイル デベロップメント -

ようやく電車でPDFを読む環境ができたのでオライリーで購入した「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)」のPDFを読み初めました。

アジャイル開発では勝手なやり方をせずに数ヶ月は続けるように書かれているものの、どのようにプラクティスを選択追加したかが書かれているなど、現実的な内容が書かれています。

数年前の本ですが、アジャイル開発を考え直す良い機会になっています。まだ、読みだしたばかりですが、「成功の定義」がアジャイル開発と従来の開発の本質的な違いではないかと思っています。

この成功の定義を除くと、アジャイル開発は従来の開発と対局というよりも、その延長線上にあるのではないかとも思っています。

本の内容とは少しずれますが、私なりに考えた従来の開発法の仕組みをの延長線上にアジャイル開発のある事を説明して、成功の定義に触れたいと思います。

開発標準

義務的に捉えがちな開発標準ですが、本来は良いプロセスを示すことで、それを現場が身につけて、組織的に改善することを目的としています。

アジャイル開発では、これを繰り返しのリズムで実現しています。開発標準でもトレーニングや経験が必要なように、アジャイル開発では日々の繰り返しや開発の繰り返し(イテレーションまたはスプリント)のリズムによって、開発プロセスを身につけて経験を蓄積します。

メトリクスの収集

プロジェクトでメトリクス(定量的なデータ)を収集する目的は、状況を把握することです。開発規模やレビューの指摘件数、障害数などを収集する事で、予定通りプロジェクトが進んでいるか、特殊な状況が生じていないかを確認します。

アジャイル開発ではバーンダウンチャートのほか、タスクボードやカンバンバードなどによる見える化、繰り返しの中でのレビューによって状況を把握します。

テーラリングと計画の変更

テーラリングはプロジェクト固有の状況に合わせて、標準プロセスに定義されたやり方を変える事です。テーラリングはプロジェクトの最初にプロセスを変更して計画を立てますが、開発中に計画を変更する事もあります。障害が想定よりも多いなど、異常なメトリクス値が得られた場合は、テストやレビューの追加など、計画を変更します。

アジャイル開発では、繰り返しの中でふりかえりを行って改善策を検討します。次の繰り返し作業の最初に行われる計画ゲームの中で、改善策を組み込みます。

フロントローディング

フロントローディング とは、後の工程で発見された問題を、早期の発見や対策を可能にすることです。障害の原因を取り除けるようにチェック項目の追加、静的解析ツールや自動テストの導入、などがあります。もちろん、実装しなければ分からない、実現可能性や性能、ユーザビリティ、などはプロトタイプを作成して確認します。

アジャイル開発では繰り返しの単位で実装と動作確認をします。漸増的に実装することで確認を後回しにしません。こうして、確認された部分を増やしていきます。

いずれにしろ大切な事

このように考えると、従来の開発法とアジャイル開発は対立的というりも、発展的に見えてきます。仕組みを関連づけて考えれば、理解が深まって適用範囲が広がるのではないでしょうか?

ソフトウェア開発の問題に対する従来法の仕組みがアジャイル開発の仕組みに発展したと考えた場合ても、変わらないものもあります。ソフトウェア開発で大切なのは、技術力、モチベーション、コミュニケーション、など、チームの力を示すものです。チームで開発する場合には、考慮しないといけません。

技術力を除いたものはアジャイルマインドと呼ばれ、体系化されたものはプロジェクトファシリテーションと呼ばれます。仕組みだけでなく考え方も大切なものです。従来法でも大切にする人は大切にするし、アジャイル開発の仕組みだけを強制しても身に付かないものだと思います。

プロジェクトの成功

アート・オブ・アジャイル デベロップメントを読んでいると、従来の開発法との違いを明確に分けるものが載っていました。それはプロジェクトの成功の定義です。

従来、ソフトウェア開発の目標はQCD(品質、コスト、納期)とされてきました。品質は本来はライフサイクル全体で評価すべきですが、リリース時には基準を満たしている事の確認しかできません。そこで、基準を満たした後のリリース時に予算と納期を守る事がプロジェクトの(ひとまずの)成功とされてきました。

しかし、この本の6ページには

「アジャイル手法では、価値を提供することとコストを削減することを重視して成功を達成する」

とされています。従来の「品質」と「納期」が「価値の提供」に置き換わっています。

暗黙のWin-Winから「価値の提供」へ

「価値の提供」は、従来の開発でも意識されていました。しかし、それはWin-Winの関係と呼ばれているもので、開発側だけが利益を得るのでも、顧客だけが利益を得るのでもなく、顧客に利益のある形で開発というビジネスを行うものと考えられていました。

かつて高機能なソフトウェアを開発する場合、品質、特に信頼性の確保が困難でした。品質問題によって納期が守れなくなる事が多く、とにかくソフトウェアの信頼性を高める事が重要でした。信頼性の高いソフトウェアをリリースする事が、その後のクレームによる保守コストを低減し、Win-Winの関係を実現すると考えられていました。

時代は変わり、高機能なソフトウェアの開発が比較的容易になり、テストの自動化や実装優先と組み合わせる事で、早い時期から利用可能な動くソフトウェアを提供する事が容易になりました。

すると、動くソフトウェアが得られるだけではビジネスに勝てなくなり、顧客のビジネスにとってより価値のあるソフトウェアの実現が求められるようになりました。つまり、ソフトウェアの品質に求められるものが、「信頼性」からROIの「効果」に変わりました。

あたり前を実現するのはアジャイル開発だけではない

このように考えるとアジャイル開発は時代の変化にあわせて、暗黙的なゴールだった「あたり前のゴール」を明示したと言えるでしょう。変化するビジネスの中では、開発対象のスコープを変化できるアジャイル開発は、顧客の価値の創造に向いているでしょう。

しかし、本当にアジャイル開発でないと実現できないかと言うと、そうでもないと思います。

組み込みソフトウェアの世界では、ソフトウェアのダウンロードが可能なものが増えてきましたが、やはり一定期間のスコープ(仕様)の凍結が必要な場合も多いでしょう。

また、法律に関わるソフトウェアなど仕様が明確なものは、段階的な開発は可能ですが、スコープの変更はある程度計画できる範囲に限定されるでしょう。

そのような分野では、Win-Winの関係が成り立たないかというと、そうでもないでしょう。顧客の価値を無視して契約だけを守る最低限のソフトウェア開発や、仕様変更はいっさい受けない頑固なソフトウェア開発、では仕事がなくなるからです。

従来の開発方法をベースにした場合でも、チーム開発の大切なことを守り、顧客に価値を提供するために、現場では色々と工夫されているでしょう。

チケット駆動開発でも、「[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発」に書いたように、色々と工夫できると思います。

まとめ

アジャイル開発と呼んでも怒られないような開発もする事もありますが、アジャイル開発をしてるかと聞かれると「していない」と答えています。

アジャイル開発は目的でないし、プラクティスを厳密に守ろうとしていないからです。しかし、アジャイル開発が大切にしている価値観には共鳴できる事が多く、常に意識しています。この本にある成功の定義は、ソフトウェア開発とは一体何かを説明してくれています。

有名なアジャイル開発の方法は良くできたパッケージです。そのまま適用できるなら、それなりの効果が期待できます。しかし、適用が難しくカスタマイズして利用したい場合やプラクティスだけを利用したい場合もあるでしょう。その場合は、アジャイル開発の仕組みを、良く理解していないとうまくいきません。

この本は典型的なXPだけではなく、カスタマイズされた現実のアジャイル開発の方法が書かれています。注意深く読み進める事で、よりアジャイル開発の理解を深められると思います。


【告知】[#RxTstudy] チケット駆動開発と教育、Redmineの事例とプラグイン、そしてgit

11月30日(土)に

第9回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪)

を開催します。今回は、事例とツールの特集です。



招待講演は大阪大学の井垣宏先生にチケット駆動開発とスクラムを適用したProject-based Learningの事例をご紹介いただきます。

チケット駆動開発はチケットを中心にプロジェクトを運営する事で、コミュニケーションを改善すると共に、ツールによる自動化や、個人とプロジェクトのタスク管理を容易にします。

その基本原理は、チケットによるプロジェクトの可視化です。これはソフトウェア工学の世界ではリポジトリマイニングと呼ばれるもので、様々な応用が研究されています。

今回は教育分野への応用になりますので、若い人への指導の参考になるでしょう。自己管理の苦手な人への指導、状況の管理のほか、関連技術への興味をどのように引き出すかなど、個人的にも大いに期待しています。

そのほか事例セッションでは、赤羽根(@akahane92)さんより、ソフトウェアの開発・運用現場で各工 程が抱える困難に対して、課題管理シ ステムがいかに応え、現場を助け、品 質に資するのかをお話ししていただきます。阪井(@sakaba37)は3種類・4分類の事例を報告します。

ツールセッションでは、粕谷(@daiksy)さんより、チームでのgitの失敗談とそこからの改善などのお話をしていただきます。会場スポンサーのアジャイルウェアの川端(@agilekawabata)さんはUIをWISIWYG的に改善するRedmineのガントチャート強化プラグインのお話が予定されています。

みなさまお誘い合わせの上、ぜひ、ご参加ください。



*会場がいつもと異なりますので、ご注意ください。



アジャイル開発の理解に必要な3つの視点

先日公開された、JEITAの企業ITに関する日米調査の記事を見ていると、日本がITのマーケットを開発する意欲に欠けている事がよくわかります。これは、諸外国ではITでマーケットを開拓する方法としてアジャイル開発が常識であるのに対して、日本ではアジャイル開発に対する理解が不十分([#Agile] アジャイル開発の課題と対策 その1)なためにこのような状況になっているのだと思います。

アジャイル開発はすでにアーリーアダプタの技術ではなく、一般的な技術としてCMMIやPMBOKでもアジャイル開発について書かれています。このような普及の理由は、XPなどのプラクティスの技術的側面やアジャイル宣言に見られるマインドなどの単純な視点では説明できません。開発、プロセスのルーツ、ビジネスの3つの視点が必要です。


【開発の視点】

開発の視点でアジャイル開発をみると、オブジェクト指向の流れを汲む最新の考え方や技術が見えてきます。

マインド:顧客への価値の提供を目的とした自律的な組織サーバントリーダーシップ

プラクティス:責務を果たす信頼できるモジュールのチーム開発と組合せの保証

ツール:コミュニケーションの効率化とプラクティスの支援・自動化

ツールをプラクティスに含めて、これらをレフトウィングとライトウィングに分けて表現される事(An Agile Way)もあります(同様にチケット駆動開発も同様に分ける事もできます)。


【プロセスのルーツの視点】

アジャイル開発には複数のルーツがあり、それらは繋がっています。

繰り返し:不確実性や変化への対応からスパイラルモデルに始まり、RAD(Rapid Application Development)、そしてDECの成果がスクラムに生かされました。アジャイル開発では変化に対応できるように、スコープを変更しつつ開発します。

実践知:ホンダの流れを汲む実践知リーダーシップはオリジナルスクラム、SECIモデルをへてスクラム開発に活かされています。

ムダ取り:トヨタ生産方式(TPS)で始められたムダ取りの考え方で、リーンカンバンボード、のほかアジャイルではありませんがTOCのCCPMにも影響を与えました。


【ビジネスの視点】

ビジネスの視点で見ると、アジャイル開発は変化に対応でき、改善を繰り返しながらより良いものを開発できます。また、ムダの少ない投資で新しいマーケットを開拓できます。

変化への対応:業務、環境、実現方法の変化に繰り返しの際のスコープ見直しで対応します。

ものづくり:段階的に作り込み、成果物を確認し、継続的に改善します。

企画・マーケティングリーンスタートアップ要求開発DDDなどと組み合わせて、新しいマーケットを開拓します。

このように、アジャイル開発は技術だけでなく、プロセスやビジネスとも深く関わっています。日本の失われた20年の間、乾いた雑巾を絞りながら景気の上向くのを待ち望んでいました。その間に、米国ではアジャイル開発を中心に、IT技術を使って新しいマーケットを開拓していました。


【まとめ】

上記の様々な視点で分かるように、アジャイル開発には新しい技術や考え方が含まれていて、新しい産業の多くはアジャイル開発で行われています。アジャイル開発を学ぶ事で新しい技術を習得できますし、新しい仕事を求める場合には新しいビジネスと結びついたアジャイル開発は有望なマーケットでしょう。

SIerはオワコンとか、未だにウォーターフォール(WF)なんて、というつぶやきを見かけることがあります。それは、ここに挙げた内容が整理されずに語られていると思います。1次産業、2次産業、3次産業と社会は発展しながらも、必要な産業は残り、新しい産業で使われている技術を取り込みながら発展したように、SIerはまだまだ存続するでしょうし、WFが向いている開発もあります。

ブームというのは必ずさめてきます。ブームに乗って騒いだり、知名度を高めようと釣り針をたらしているだけでは限界がくるでしょう。いずれアジャイル開発もあたり前になって基本的な理解だけでは差別化できなくなり、本質的な理解が必要とされるようになるでしょう。その頃には従来の業務知識や大規模開発のノウハウが必要とされる場面も増えてくると思います。

技術者であるからには、常に自分の強みを意識すると共に、新しい技術を正しく理解する必要があります。そして、それぞれの立ち位置での問題に対してふさわしい形で適用し、継続的に改善する。それがアジャイル開発の目指すものを理解した技術者のあるべき姿だと思います。

一方、経営者は世の中の潮目を見極めて、必要な判断をする必要があります。古い雑巾を絞って景気が良くなるのを待つだけでは未開のマーケットを手に入れる事はできません。次の一歩を見定めて技術者を育てておき、時を見定めて果敢に攻める事も必要でしょう(そうしないと、経営者が最大の問題になり、技術者にピボットされてしまうかもしれません)。

このエントリーをはてなブックマークに追加


御利益宗教の危険性と標準化の落とし穴

ソフトウェア開発の特定技術への偏重について「宗教」に例えられる時があります。大抵は理論的裏付けがないとか、実証されていない、あるいは、別の技術との違いが明確でない、といった意味で使われるのだと思います。

御利益宗教の危険性

信仰なのですからそれぞれの自由でも良いかもしれません。しかし、宗教にも現世利益を求める宗教と人の成長に繋がる宗教があって、現世利益を求める宗教が国や組織の標準となると、宗教改革前のカトリックのような組織的な腐敗の危険性があります。

現世利益を求めるものはご利益宗教(ごりやくしゅうきょう)と呼ばれますが、政治的に利用されたり、 免償符 (俗にいう免罪符)やツボを売られるなど、利益に繋がる形骸化した行為のみが重視され、人間的な成長はありません。一方、倫理的な宗教は、極楽浄土や天国に行けるような心清らかな生き方をする様に促すもので、(その考え方が倫理的であれば)人を成長させます。

技術の導入はプロジェクトの成功という即物的な利益を求めるものですから、技術がきちんと実証・説明されないまま標準化されて、その行為のみ求められてしまうと御利益宗教になりがちです。

標準化の長所と短所

そもそも標準化による長所と短所を考えると

【長所】

  • 全体の技術的な底上げができる
  • 良いプロセスを知る事ができる
  • プロジェクトごとの差分を考えれば良いので効率化できる

【短所】

  • 標準の善し悪しを考えなくなってしまう(思考停止)
  • 標準がゴールになって形骸化しやすい
  • 標準以外のやり方に制約が付く

さらに思考停止によって以下のような問題が生じます

  • 作業が必要な理由を考えない
  • より良い方法を考えない
  • 標準の問題を見過ごして改善されない

つまり、技術者は習熟するものの成熟しません。成長せずに硬直化してしまいます。お百度参りは、それで願いが叶うからするのではなく、それだけお参りすればあきらめがつくからとも言われています。標準が宗教化すると理由を考えずに妄信して実施するので、ある程度の失敗であればあきらめが付くのかもしれません。

どうすべきか

そもそも技術なのですから、論理的に説明するとともに、結果を定量的に実証すべきです。しかし、ソフトウェア開発は全く同じプロジェクトで比較実証できません。そこで、ある程度の実績を蓄えて統計処理したいところですが、それには時間が必要です。

そこで必要なのは論理的な説明によって宗教化を防ぐとともに、技術の背景にある価値観を理解することだと思います。宗教化を恐れずに標準化するのなら、すくなくとも技術者としてのあり方を教えて、倫理的な宗教にすべきだと思います。

たとえば、「信頼性の向上」「顧客への価値の提供」「開発者の能力を最大限に発揮する」「ムダをなくす」などの重要な価値観の理解が大切です。それらを理解した上で、実践を通じて社会貢献できれば、技術者の良心や誇りなど、道をあやまらない心得を持てるでしょう。

価値観を理解できるようなトレーニングを

かつて「信頼性の向上が生産性の向上につながる」と言われていました。これは、信頼性の問題によって保守工数が増加するからで、その後、多くの実証が行われました。

近年、信頼性以外の品質特性も重要視されるようになり、

  • どのように顧客に価値を提供するか
  • 開発者の能力を最大限に発揮させより良い開発をする
  • 開発のムダをなくして効率化する

という事も重視されてきています。これらはビジネスの成功という形で、ある程度は証明されていますが、定量的にはなかなか実証の困難な事です(大切な事は理解していただけるでしょう)。

そのイメージは実践しないとわかりにくいものです。CMMブームの際も改善活動を組織で実践するには、理解を深めるワークショップが有効だと言われていました。価値観を身につけるには知識だけではなく、トレーニングや意見交換などの学びの場が必要でしょう。

ビジネスの失敗は組織を消滅させる危険もあり、時には組織的な強制も必要になるでしょう。しかし、それは短期的には効果があるものの、長期的には標準の形骸化をもたらし、使えない開発者を生み出します。長期的な組織の成長には、 技術者の成長が欠かせないと思います。

おわりに

人のする事には、永遠に成り立つ完全な正義というものは、まず存在しないでしょう。ソフトウェア開発の途中で暴れだす狼男に対する銀の弾丸が存在しても、フランケンシュタインやドラキュラに効くかどうかはわかりません。技術には適用範囲があり、正しく利用しないと失敗します。

しかし、現実には良さそうな技術が生まれた時は、適用範囲は明らかではありません。それぞれが工夫して利用するしかないのです。その際に重要なのは、なぜその技術が必要なのか「価値観」を理解する事です。

宗教化しやすいものは、エディターなどのアプリケーションやプロセスなどの実践的な技術です。これらは複合的な技術なので、定量的な実証がすぐには追いつきにくい分野です。技術として発展・普及させるには、開発現場の情報公開と開発者の交流がとても大切だと思います。

このエントリーをはてなブックマークに追加

SEA関西「ぐるぐるDDD/Scrum」 - モデルは実装のうずまきで洗練される -

第53回SEA関西のプロセス分科会では、原田騎郎さんをお迎えして「ぐるぐるDDD/Scrum – モデリングと実装のうずまきをまわそう」というワークショップをお願いしました。

概要

スライド前半の説明の後、50分間で2回繰り返して、駐車場のシステムをモデリングして開発しました。分析はホワイトボードで行い、開発は得意な人にしていただきました。隣のチームは模造紙とメモパッド(付箋)も使っていました。今回は スクラムらしい役割分担はしませんでした。

感想

早期に実装を始めるやり方は、「コタツモデルを実現したスクラム開発」に書いたように、実装を考慮しないことによるリスクを下げるものだと考えていました。しかし、このワークショップは、短期間の作業の繰り返しで、より小さく、よりコアな仕様をみつけるためのものでした。

仕様を決めようとすると、ついつい大きな仕様になりがちで、実現できなくなってしまいます。これは開発者が議論に入ることで、ある程度押さえる事ができます。しかし、開発者は開発者でモデリングをやり過ぎしたり、枝葉の詳細な仕様にこだわってしまいがちです。

そこで、一定期間ごとに「小規模ながらも価値を提供する実装おこなうこと」を制約と与える事で、よりコアな仕様を考ざるを得ないように関係者を追い込むという方法がとられたのだと思いました。

良くできたトレーニング

初めて参加した原田さんのワークショップは「スクラムを味方につけろ! - SEA関西プロセス分科会 -」の元になった時のもので、プランニングポーカーを使ったワークショップでした。

記事に書いた改善が実感できたほか、「なるほど、見積もるだけでなく情報共有にもなっているのか」という感覚が理解できました。得るものが実感としてどっしりときます。

これは、明確なゴールに向けてトレーニングが構成されているからだと思います。テーマや進め方がきちんと構成され、ワークショップの途中でも何度か言葉をかけられていました。

より良く進めるにはドメイン知識が重要

ワークショップ中の原田さんの指導を思い返すと、それはツボを押さえた言葉でした。指導された際の「このワークショップは何度もやってるから」との言葉は、ドメインがわかっているからできるということだと思いました。

つまり、開発者が言語を知っているだけではダメで、テストコードとセットで開発できないといけないように、仕様を決める人は幅広くドメインを理解していないといけません。どのようなバリエーションがあり、どのようなモデル化が良いか、どのような実装が可能か、仕様決定者、モデラー、実装者がともに知恵を出し合うことで、コンパクトでより価値のあるコアな部分を見つけ出す事ができると思います。

今回はプロダクトオーナーを決めませんでしたが、このように考えると(少なくともDDDをScrumで回す場合には)プロダクトオーナーがチームの上に立つものでないと思われます。ドメイン知識を提供し、開発者などのステークホルダーの協力を得て、仕様を分割して優先順位を決めていく役割だと思いました。

ワークショップでは議論が重要

人にモノを伝えることはとても難しいことです。複雑なものをそのまま伝えると理解してもらえないので、ある程度は単純化して構成する必要があります。

しかし、良くできた発表やセミナーであるほど単純化されていますので、実践するにはそれ以外の事を聞き出さないといけません。それは質問や議論によって可能になります。

質問時間のない講演もありますが、講演だけで得られるのは気付きや情熱です。使える技術を得ようとするなら、質問するとか、懇親会に出てお話するなど、より詳しく聞く必要があるでしょう。

まとめ

より良いモデルを作るには、よりシンプルな実装をしようとする事で、本質が見えてきます。DDDとスクラムを組み合わせるメリットは実現可能性もありますが、短期間という制約によるよりコアなドメインの実現が容易になる点だと思いました。

講師の原田さんは「できる人を観察して勝負する」に書いたような人だと勝手に思っています。わかり易く明確な意見を述べられますが、質問すると立場論ではなく率直な意見を答えてくださいます。

そのようなトレーニングは、「竜馬がゆく」での西郷隆盛を評してかかれた言葉「小さくたたけば小さく鳴り、大きくたたけば大きく鳴る」というイメージのものです。得るものは大きいと思いますので、ぜひ質問をされると良いと思います。

いつも色々面倒臭い質問をしてご迷惑をおかけしていますが、とても勉強になっています(「自己組織化あるいは自律的組織」にも書いたUAS3のアジャイル放談参照)。今回も色々勉強させていただきました。ありがとうございました。


[#agile] 「リーン開発の現場」を読んで その4 - 知識が繋がった -

本の感想には色々あると思いますが、「リーン開発の現場」は、これまでの知識が繋がったような感動を覚えました。

川口さんのAgile and Leanの資料にあるようにアジャイル開発の源流には2つあり、野中氏のオリジナルスクラムとトヨタ生産方式(TPS)です。それぞれソフトウェアの世界では、スクラムとリーンとして取り込まれました。

これらは共にアジャイル分類される事が多いのですが、かつてアジャイルはXPとほぼ同じ意味だった頃にリーンの本が出た時には、リーンがアジャイルと呼ばれる事に違和感を覚えていました(川口さんの図でも点線になっています)。

しかし、それがAgileを経てカンバンになると一つにまとまります。これはAgileの目指すものという意味では理解できるのですが、具体的な姿はイメージしにくいものです。

アマゾンのレビューにも書きましたが、 やってみないと理解が難しいのは人を重視するアジャイル共通の難しさです。たとえば「リズム」と言われてもなかなか理解できないもので、私はチケット駆動開発をやってみて、ようやく日々のリズムを感じる事ができました。その様子は書籍「チケット駆動開発」のプロローグをお読みください。)

スクラムとリーンからカンバンで一つになる。それもやってみないと難しいものなのかもしれません。しかし「リーン開発の現場」の具体的な事例を読む事で、それが感じられました。

これまでに取り上げたキーワードだけでも、事例を通して知識が共通化されます(これ以外にも色々あります)。

カンバンボード

情報共有してみんなで考え、現場で改善します。コミュニケーションは古くからソフトウェア開発の課題でした。XPもスクラムもカンバンも貼りものによる情報共有で、コミュニケーションを改善します(貼りものではありませんがチケット駆動開発でも同じですね)。

WIP制限

開発者の能力を最大限に発揮させます。プロジェクトファシリテーションやチームソフトウェアプロセスでも言われている事です。WIP制限では仕掛り数(同時作業数)を制限する事で実現します。

キュー

パイプラインのバッファを適切にとります。トヨタ生産方式の影響を受けたと言われるTOC/CCPMと方法は違いますが、同じようにバッファをコントロールすることで全体最適します。

優先度

適切な時期を考えます。より積極的なリスクベースの考え方をとっていますが、「リーン開発の現場」では主に作業がなくなるリスクを意識している様です。どちらも優先度といえるでしょう。

この本を通して具体像が見えてくると、アジャイル開発がオリジナルスクラムとTPSだけでなく、多くのソフトウェア開発の技術と繋がっている事がわかります。

これまで別々の知識として理解していたことが、この本の具体的な事例を通じて一つに繋がりました。知識がより深まってさらに一歩、実践できるレベルに近づいたように思います。


« 2013年10月 | トップページ | 2013年12月 »