Ultimate Agile Stories Iteration 2 - 次の10年に向けた開発環境との向き合い方

2,043 views

Published on

Ultimate Agile Stories Iteration 2 に寄稿した記事です。

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,043
On SlideShare
0
From Embeds
0
Number of Embeds
868
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Ultimate Agile Stories Iteration 2 - 次の10年に向けた開発環境との向き合い方

  1. 1. 1次の 10 年に向けた開発環境との向き合い方 長沢智治 (@tomohn) / マイクロソフト エバンジェリストはじめに マイクロソフトのエバンジェリストが、「開発環境の話を書く」となると、開発ツールの話だと思われることでしょう。今回はそんな期待を裏切るつもりです。この 10年でソフトウェア開発を取り巻く環境は大きく変化してきました。それは急激な変化の積み重ねでもあります。特にこの変化には日本だけを見てしまうと気づかないこともあります。私は幸いにも、10 年以上外資系のソフトウェア開発の最先端の会社に所属し、しかも数社を転々としながらこの変化にさらされてきました。 今回筆を執ったのは、「文脈」と「環境」というキーワードで、みなさんの開発現場を見つめ直すひとつのきっかけにできたらと思ったからです。もちろん、アジャイルについても触れていきます。THE DECADE この 10 年間でビジネスとIT の関係は大きく変化してきました。Iteration 1 でも触れましたが、 は、 IT ビジネスにとってただ便利なものから、 不可欠なものにまで進化を遂げています (図1)。IT がコストセンターから戦略に進化したと言われています。 図1 ビジネスとIT の関係略図 さて、その反面みなさんの現場やお客様はこの流れを敏感に感じ取っているでしょうか?多くの開発現場が今まで培ったやり方で、ソフトウェアを作っているのではないでしょうか?たとえば、ビジネスのアジリティに対応し続けなければならないソフトウェアの開発を行っているのに、あらかじめ計画したとおりに開発を行い、変化をうまく受け入れることができていないということはないでしょうか。 1
  2. 2. 2 文脈の見つめ直し なぜこのように実情に合わないやり方に固執するかのような状況が起こるのでしょ うか?それには、意思疎通のプロセスが関連していると考えてみると見えてくるもの があります。 実は、文脈 (Context) が、一致している前提で、議論されることがよくあります。 先の例では、定義されたプロセスに従い、時間と人員を割り当て (人月)、全体計画通 りに進行することでビジネス価値を提供できるソフトウェアは開発できるという文脈 が前提となります。文脈が固定された中で見出された開発のやり方で、ビジネスアジ リティに対応することを強いるのです。すでに文脈が変わってきていることは議論に 入らないことが多いというわけです。 これは日本の文化に由来する部分も多いと思われます。同じ時間を同じ価値観で共 有し、 同じ評価を受けるという文化です。 ここでは文脈は固定化されがちなため、 「文 脈を合わせる」という概念が省略されます。 IT においても、実はビジネスニーズもソフトウェアも多様化し、文脈が固定化され なくなってきているという実情があります。それに対して、「文脈が一致している」 前提で進行しようとするため、本質がぶれてくるのではないでしょうか。これは非常 に大きな問題につながります。従来の文脈で、「IT とビジネスは密には同期しておら ず、要求は予め定義でき、人員と時間を決めればよいソフトウェアが提供できる」と いう文脈で固定されているとするとビジネスニーズに合ったソフトウェアが提供する ことがより困難な状況となりえます (図2)。 図2. IT の常識の変化 その点では、欧米諸国は、元々多様化した文化が前提なため、ソフトウェア開発に おいても、まず文脈を一致させ (一致しているか確認し)、何を作るのかに取り組む姿 勢ができているのではないでしょうか。したがって、ビジネスニーズとソフトウェア の多様化にもいち早く気づき、文脈が固定化されていな現実と向き合い、文脈を一致 させ取り組むやり方を模索できたと考えています。その一つとして代表的なものが、 アジャイルではないでしょうか。 アジャイルでは、定義されたプロセス (Defined Process) では対応しきれないビジネ スニーズとソフトウェアに対応するため、実測駆動なプロセス (Empirical Process) で 挑みます。常に文脈を確認し、揃えながら取り組んでいくということになります。2
  3. 3. 3 重要なのは、文脈は常に合致しているわけではないという姿勢で臨むことです。これは、みなさんの現場でアジャイルを推進したいときにも役に立つ姿勢だと考えています。「アジャイルでやるべき!」という熱い想いを一旦押さえて、みなさんの現場の周囲を見てみてください。そこにはみなさんの熱い想いと明らかに異なる文脈 (考え方や経験) を持った人がいるはずです。人は文脈を伴わない想いや事柄は理解することができません。今まで事柄や想いで理解できていたのは先述したように日本の文化では文脈が固定されがちであったためです。昨今の多様化した文化の中ではまず文脈を揃えることからはじめないといけません。みなさんの熱い想い、経験を現場で活かすためにもぜひ文脈に着目し、見つめ直してみてはいかがでしょうか。継続的な行動とそのための環境が人と現場を変える 次に重要なのは、「人の気持ちは何人たりとも変えることができない」という事実と向き合うことです。私は長年プロセス改善のコンサルタントをしてきましたが、 「あなたが変わってください」といって変わったためしはありません。人の心に他人が土足で足を踏み入れることは決してできません。したがって「アジャイルでやるべきだよ!」といくら正攻法で面と向かって直接言っても、異なる考え方を持つ人は決してうなずいてくれません。 「人を変えること」はできませんが、「人に変わってもらうこと」はできます。それは、環境が変わることで現実のものとなります。環境を変えるには、行動を変えることが重要です。行動を変え、それを継続しうることができれば、人の心に変化をもたらすことができます (図3)。 図3. 人と現場を変える原動力は環境と行動の継続性 たとえば、テスト駆動開発がよい例です。Red-Green-Refactor のリズムで小さな成功体験をし続けることで開発者の気持ちもソフトウェアも変わってきます。継続可能なリズムという点では、スクラムのケイデンス (リリース、スプリント、デイリーのリズム) も同様です。アジャイルなプラクティスの多くは、この継続的な行動を起こしやすく、 良い環境を作りやすくする作用があると考えます。 したがって、 結果的には、 3
  4. 4. 4 このリズムに乗れれば、「人に変わってもらうこと」が可能になるのではないかと期 待しています。これはまさにスクラムでいうところの自己組織化 (Self-Organization) に つながります。 アジャイルブッフェ ワークショップのススメ アジャイルブッフェ (Agile Buffet) とは、 私が TechEd North America のセッションで 見た考え方です。 元々の発想は、 Patton 氏のCommon Agile Practice takes the best from Jeff the buffet にあります。また、実践されているアジャイルの現場の多くが純粋に XP や スクラムを実践しているというより現場に応じたアジャイルなプラクティスを取捨選 択している Mixed Agile であることもこのアジャイルブッフェに至る重要な要素でも あります。それを XP 祭り 2011 で吉羽 (@ryuzee) さん、海江田 (@Qooh0) さんとワ ークショップとして実施してみました。仮想の開発現場を想定し、その文脈を共有し たうえで、アジャイルプラクティスのどれをどのタイミングで適用したら開発の現場 の課題を克服できるのかを話し合うというのが基本スタイルです (図4)。 図4. アジャイルブッフェ ワークショップの基本スタイル これは、先述の文脈を一致させる効果と、継続的に実施可能な行動であるアジャイ ルプラクティスを見つめ直す効果があると考えています。元々このワークショップを 行ったのは、現場の文脈でやれることは何かを模索するきっかけづくりとスクラムや XP などの理念を再認識するきっかけと考えていました。 しかし先述の考え方と見事に 一致していたとこの原稿の執筆中に気づき、 追記をしているところです(笑) 私は、 。 アジャイルブッフェは、「守破離」でいうどのフェーズであっても有効な手段である と思っています。いきなり「守」をスキップしてよいということではなく、本来の目 的と現場の文脈の一致に役に立つと考えています。 ここではアジャイルブッフェをおすすめしましたが、このスタイルがよいというこ とではなく、文脈を見つめ直し、本質にアプローチすることができるきっかけが大切 であると理解ください。 THE NEXT DECADE 文脈の見つめ直しについて触れ、現場を変えるためには行動を変えること、それを 継続し続けることが重要ではないかと書かせていただきました。それこそがまさに 「開 発環境」と言えるのではないでしょうか。少なくとも開発環境でこれらは無視できな いくらい重要になっていると感じています。4
  5. 5. 5 もちろん、ソフトウェアエンジニアリングとしての「開発環境」も無視してよいも のではありません。継続し、その状況を透明化し、無駄を減らし、技術的負債のリス クを軽減し、価値の流れを創出するエンジニアリングにするためには、人とプロセス だけではなく、開発ツールも不可欠です。ビジネスのスピードに対応する価値あるソ フトウェアを提供し続ける (Continuous Delivery) のための開発ツール環境も重要であ ることは念頭に置いておくべきです。 冒頭で述べたビジネスとIT が融合した世界においては、Cycle Time と MTTR をい かに短縮し、あらゆるフィードバックを継続的に収集、応対することが求められます (Continuous Feedback)。ソフトウェアエンジニアリング環境は、すでにこのレベルにま で達しています。これらも含め、今そしてこれからのソフトウェア開発の準備はすで にスタートしています。 大事なことはすべて書きました。 さぁ、次の 10 年の準備を進 めようではないですか! 私は、エバンジェリストという仕事柄、ここに記載したようなお話しを各種のイベ ントやコミュニティ、企業のエグゼクティブや現場向けによく行っています。こうい う話に関心がある、現場の文脈を一致させるためのきっかけとして話に来てほしいな どお役にたてることがありましたら、まずはお気軽にご連絡ください。 tomohn@microsoft.com (@tomohn) http://SoftwareEngineeringPlatform.com参考文献『アジャイルソフトウェアエンジニアリング - 基本概念から継続的フィードバックまで』 (Sam Guckenheimer, Neno Loje 著, 日本マイクロソフト, TFSUG 監訳, 日経BP)『臨床家族心理学 - 現代社会とコミュニケーション』 (秋山邦久 著, 福村出版) AgileProductDesign.com,,Kanban Development Oversimplified (Jeff Patton) http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html IT とビジネスの可能性, Agile Buffet やってみた【XP 祭り2011】(Tomoharu Nagasawa) http://blogs.itmedia.co.jp/nagap/2011/09/agile-buffet-xp-37ea.html 5

×