/home/by-natures/dev*

ソフトウェア開発者として働く人の技術的なメモ

Agile Conference Tokyo 2013 に参加しました

agileconferencetokyo2013_logo

ThoughtWorks Inc.と株式会社テクノロジックアートの共催で行われた、Agile Conference Tokyo 2013 に参加しました。

アジャイル開発も近年では、導入を始める大手企業も増え、 更なる広がりを見せると同時に、最新のアジャイル開発プロセスにも注目が集まっています。 そこで今年は「ソフトウェア開発からビジネスのトータルマネジメントへ ~TMSとKANBANによる~」をテーマとし、最新のアジャイル開発についてのコンテンツをご提供致します。

…ということで、開発プロセスとしてのアジャイルではなく、ビジネス全体をアジャイルとして捉えなおすセッションが多かったのが特徴でした。私の会社ではちょうど部署再編や組織変更が行われている最中で、どのような組織がよいのか考える良い機会となりました。例えば事例紹介で、部署を超えて「カンバン」で各自の進捗を「見える化」して共有し合うことで、全社で一丸となって業務改善に取り組んでいる企業がありました。営業部まで巻き込んで業務を「見える化」しようという活動は素晴らしい取り組みだと感じ、胸が熱くなりました。

最初に感想を、そして数々のセッションのうち、いくつかをご紹介します。

感想

アジャイルに詳しくないので勉強がてら…と思って参加したカンファレンスでしたが、良い意味で予想を裏切る内容でした。

アジャイル」と聞くと開発寄りの話なのかと思いますが、このカンファレンスでは、アジャイルの考え方をどうビジネスに取り入れていくかという、会社やビジネス・組織に関する話題が中心でした。アジャイルでおなじみの XP, スクラム, TDD, バックログetc... は用語が出てくるだけです。アジャイルを導入する目的を考え、アジャイルを導入し、その結果を検証するという PDCA サイクルや、アジャイルの考えをビジネスにまで拡大し、全社でカンバンを運用する事例の紹介など、方法論にとどまらないセッションが多かったです。

開発手法の一種としか思っていなかった僕にとってこのカンファレンスは本当に驚きでした。カンバンの考え方がアジャイルと繋がること、どちらも結局は方法論であり、目的が何より大切であること、会社ごとに、部署ごとに、チームごとに、案件ごとにベストな運用方法は異なるため、それぞれでどうアジャイルを適用するかを「考える」プロセスが重要なのだと知りました。

とある目的で、現在「アメーバ経営」について学んでいるのですが、これも書中に「アメーバ経営は手段である」という注意書きが散見されます。アジャイルもカンバンもアメーバ経営も方法論であり、何かに準ずれば成功するとか、方法論に即していないから上手くいかないとかではなくて、状況に応じてどう運用するかを考えることが大切なんですね。

逆に言えば、アジャイルやカンバン、アメーバ経営を導入したての頃は、十中八九上手くいかないとも考えられます。苦しみながらも、どう業務改善をしていき、目的を果たすか…。ツールを入れて解決するならツールにすがりたい気さえしてしまいますね(^_^; 最初は上手くいかないかもしれないけれど、「みんなで共通の目的に向かおう」という強い意思が必要だと感じました。

(株)豊田マネージメント研究所の高木さん曰く、「社風の土壌醸成には2年かかる」とのことでした。特に施策開始時には、方法論云々以前に、やり抜く意思を継続させることが一番大切なのかもしれません。

[toc]

セッション内容

agileconf2013 003

アジャイルな企業のTo Beモデルを提示するScaled Agile Framework (SAFe)のご紹介 by (株)オージス総研 藤井 拓氏

オージス総研の藤井さんは、Scaled Agile Framework(SAFe)の紹介をしました。

アジャイルは一般的に、小規模開発にしか向かないというイメージがあります。しかしアジャイル宣言から10年経った今、欧米ではチームレベルのアジャイルは当たり前となり、さらに大規模開発へ拡張するためのノウハウが蓄積されてきています。

そのフレームワークの一つとして、Scaled Agile Framework(公式ページ) があります。

知識創造企業はスクラムの原型ですが、かなり限定された形で取り入れられているとのこと。これを、"アジャイル企業" のあるべき姿(To Be モデル)として捉えなおしたものが、Scaled Agile Framework です。

以下は SAFe の概要図です。かなり複雑ですが、小さいチームに分かれて、それぞれの作業連携はスタック(バックログ)を通じて行う、というもの。クライアントはポートフォリオのレイヤーで絡んできて、具体的な要件がバックログで落ちてきます。

SAFe

スクラムと品質 by 三菱電機(株) 細谷 泰夫氏

スクラムだけやっていても、上手くいかない」と語る、三菱電機の細谷さん。スクラムを実践する上で何が大切なのかを語りました。

品質について

アジャイルでは一般的に品質が下がると考えられていますので、品質について考えることは重要です。「品質」について考えると、製造業だと、お客さんにリリースしたタイミングが最高品質(Point of sales)ですが、サービス業だと、常に利用中が最高品質(Point of use)となります。

[caption id="attachment_3283" align="aligncenter" width="640"]aaaa Point of sales, Point of use の概念図(SocialChange! 様から引用させていただきました)[/caption]

品質の狩野モデル、というものがありますが、これは物理的充足と顧客満足の2軸に対し、魅力的品質(無くても気にならないけど、あれば満足)・一元的品質(あればあるだけ満足)・当たり前品質の3つに分けられます。Point of sales だと、時間が経つにつれて陳腐化し、充足状態から不足状態になります。

Point of use だと、変化に応じて常に価値を提供し続ける必要があるのですが、品質が悪いと、変化する度に動作が不安定になり、変化に追随できなかったり、コストがものすごくかかってしまいます。ひとたび品質が悪くなってしまうと、良くするのは難しいです。これは変化へのプレッシャーが大きいのと、根本的に作り直すような障壁があるためだと語ります。

[caption id="attachment_3284" align="aligncenter" width="505"]あああ 狩野モデルの概念図(SQiP 様から引用させていただきました)[/caption]

もちろん、エンジニアは別に悪いものを作ろうとしているわけではありません。しかし結果的に品質が落ちる理由として、「オーバーコミットメント」と「階層的な組織構造」が品質の悪化を助長してしまうとのこと。

これを防ぐためには、スクラムのルールを徹底的に守る必要があります:

  • プロダクトオーナーは、プロダクトバックログの優先順位を付けることができる
  • チームのみがプロダクトバックログの項目を見積もることができる
  • スクラムマスタは、スクラムのルールを壊す存在を排除する

次のようなルール違反を犯してはいけません:

  • POや組織がチームの見積もりを否定(「そんなのちょちょっとやったらいいじゃん!」等)
  • スプリントの期間を延長
  • チームが情報を隠す

ルール違反の代償としては、得られた価値に釣り合わない価格、費やした労力に釣り合わない価格になり、クライアントとの信頼関係が損なわれてしまうことが挙げられます。2つ目に、トップからの矛盾が次第におりてきて、テストをしないなどでプロダクト側で吸収してしまうため、成果物の品質が落ちることが挙げられます。品質を守るためには、バックログの完了の定義にテスト実施を含めるなど、定義をしっかりと定めることが重要です。

フレームワークについて

細谷さんはアジャイル開発をスポーツに例えました。

フレームワークはスポーツに例えるとルールにあたります。例えばスクラムフレームワークです。

プロセスは2人以上の人が連携して何かをすること or 一人の人が複数の手順で何かをすることです。サッカーに例えると、ワン・ツー、セットプレー、フォーメーションにあたります。

型とは武道の型のようなもので、サッカーだと、トラップができるか、などがあたります。

スポーツの例えで言えば、「ルールを守るだけでは面白いゲームはできない!」というのが、冒頭で述べた「スクラムだけやっていても、上手くいかない」理由になります。どのようなフレームワーク、プロセス、型を使うかを、様々な状況に合わせて自分たちで考えることが必要です。

細谷さんの実体験では、1~2年目の新人にソフトウェアの製品開発を経験させるという目的をもち、ベテラン社員と一緒に開発をさせました。課題は「経験の浅いメンバーをどのように促していくか」と「製品の品質をどのように確保するか」です。この課題をアプローチ、実践方法に落としました。例えば、経験の浅いメンバーの促しは、ベテラン・新人社員でのペアプロを実施しました。

他にも TDD を利用する場面もありましたが、TDD は習得期間が必要なため、頭ではなく体になじませる、いわば基本動作の練習が必要とのことでした。

エンタープライズ規模におけるカンバンの運用 by (株)豊田マネージメント研究所 高木 徹 氏, (株)戦略スタッフ・サービス 三井 伸行氏

「カンバン」というとトヨタの生産システムで有名なため、製造業に限った話かと思われますが、実はホワイトカラーの現場でも「カンバン」を利用することができる、と三井さんは語りました。

株式会社豊田マネージメント研究所は、TOYOTA Wayの思想・考え方を基に、企業の人材教育や職場改善を行っている企業です。

IT業界において、人材はマネジメント能力(改善能力)が不足しているといいます。従来はカリスマ性のある経営者が引っ張っていくことが多かったのが、最近ではそうではなくなり、マネジメントが放免されているとのこと。ここでいうマネジメントとは、管理・監視・指示・強制ではなく、より一般的に「部下に成果をださせる能力」を指します。

同社では TMS(Total Management System) という教育コンセプトをもっています。これはカンバンの考え方を、会社として共通の価値観(言語)にまで拡張したコンセプトです。TMS にはアジャイルの考え方も取り入れられていますし、アジャイルにも「アジャイルかんばん」として、カンバンの考え方が取り入れられています。出所は違えど、目指すところは一緒、といったところでしょうか。

[caption id="attachment_3271" align="aligncenter" width="640"]アジャイルかんばんの様子 アジャイルかんばんの様子(ThoughtWorks Inc. から引用)[/caption]

しかし TMS にしろアジャイルにしろ、これらはツールであり、導入すれば効果が出るものではありません。ソフトウェアやツールを導入すると、一見成果が出たように感じますが、土壌が育っていないとすぐに陳腐化してしまうため、土壌醸成が大切です。

事例紹介として、A社(仮)を取り上げました。A社では2011年から開発チームが自主的にアジャイル開発を開始しました。続いて2012年、事業部全体のプロジェクトにカンバンの考え方を取り入れて「見える化」を実施。2013年から、全社での TMS 導入へチャレンジしています。このように年月を掛けて、アジャイルやTMSの考え方が会社に染みついていきます。

全社での TMS ということで、開発部門だけでなく、営業部、導入支援、ヘルプデスクまでもがカンバンを作り、各部の状況が「カンバン」を通じて一目で分かるようになっています。カンバンのフォーマットやチケット細分化・結合は日々行われており、業務改善の早さが伺えます。

Q&A

同セッションはもっとも Q&A が多く、TMS(カンバン)への関心の高さが伺えました。

私も会社全体を挙げて TMS に取り組み、業務を改善していこうという事例に胸が熱くなってしまい、どうしたらこれが実現出来るか、質問させていただきました。私の質問も含め、ご紹介します。

事業部をまたいだカンバンの運用はどのように始めたら良いか

A:まずはトップから話を通すのが早い。パイロットフィッシュ的に、局所的に始めさせられることも多いが、支援者がいないので結局長続きしない。少しずつ広げるにしても、上からの支援が必要。

アジャイルとカンバンの関係が知りたい

A:どちらも突きつめればツールである。細かいことは気にせず、ホワイトカラーは原理に帰って、暗黙知をどうやって形式化していけばよいかを考えるべきだろう。

単に導入するだけで回るとは思えない。例えば、スクラムとして Problem/Try/Keep を出していく際に、不満が言いづらい雰囲気などが挙げられるだろう。これはどう改善すべきか

A:不満点が出しづらいというチームの問題があぶり出されただけでも良い。チームに能力がないと分かった時点で、「変えたい」という思いがあれば、アジャイルでもカンバンでもTMSでも、問題を解決するための議論が始まるだろう。実はTMSはこのような基本的なことから始めるので、土壌が育つのに数年かかる。最初は面倒でも、のちのち楽になる、と理解してもらえば上手くいく。

事例から見るアジャイルの失敗と成功(二度とアジャイルはやりたくなかった人が語るアジャイルの成功ポイント) by (株) 日立ソリューションズ 平岡 嗣晃氏, 奈加 健次氏

日立ソリューションズではアジャイル開発の考え方が取り入れられており、成功した/失敗したプロジェクトと、その具体例を紹介しました。

同社では2010年からアジャイル開発を始めしました。アジャイル開発の考え方を取り入れることを「アジャイル適用」と呼んでいます。これは「アジャイルプロセスの適用が目的ではなく、手段であること」と「状況に応じてプロセスの良いところを取り入れる」ことを指します。このポイントとして、以下の4つを上げました:

  1. アジャイル導入の目的を明確にする
  2. 適用するプロセスは目的や状況に応じて使い分ける
  3. 成功も失敗も管理次第。進捗・コスト・品質・変更の4つを管理することが重要
  4. アジャイルプラクティスはノウハウの塊
(1) アジャイル導入の目的を明確にする

アジャイル導入にあたり、現状分析をして課題を見つけ、目指すべき姿(to be)を描きます。そこからどういうプロセスで管理するかや、効果を予測し、実施結果を評価するというPDCAサイクルを回します。

目的の例としては、「タイムリーな市場投入がしたい」(一番多い)、「仕様認識齟齬による手戻り低減をしたい」、「ユーザーエクスペリエンス(UX)の向上がしたい」などがあります。

(2) 適用するプロセスは目的や状況に応じて使い分ける

目的を明確にした後は、どのプロセスを適用するか検討します。同社では純粋なアジャイルの他、以下のような使い分けをしています。

ハイブリッドアジャイル
要件定義、基本設計まではウォーターフォールで行い、コーディングのフェーズをアジャイルで行い、最後にテストを行います。反復のタイミングでユーザに見せ、フィードバックが得られるので認識齟齬が減ります。SIer 的な都合だと、多くのクライアントが予算取りが必要になるため、全体のシステム規模を最初に見る必要があるので、このようなスタイルを取っているようです。
プロトタイプ検証タイプ
ユーザーの要件が分かっていない場合に、プロトタイプを作ってしまう方法です。
上記の組み合わせ
フロント(WEB)とバックエンドで分かれている場合、フロント側はプロトタイプで、後ろはウォーターフォールで開発を行い、最後に連動テストをします。
(3) 成功も失敗も管理次第。進捗・コスト・品質・変更の4つを管理することが重要
進捗管理のポイント

チケット管理は懸案を管理するだけではなく、チームの開発スピードを管理するものなので、必ず8時間以内のチケットにします。これは朝会で毎日進捗管理します。

また、変更を受け入れるための進捗に「ゆとり」を持たせるのですが、エンタープライズ系だと、納期が大切なため、スプリントを増やすことができません。そのため、作業遅れは休出も含めて、可能な限りイテレーション内で吸収し、それでもあぶれたものは次のスプリントへ回します。

コスト管理のポイント

アジャイルは管理が減るわけではなく、追加される作業もあるので忘れてはいけません。例えばペアプログラミングでの生産効率の低下は、2人に対して1.6人日程度となるそうですが、開始当初は予想以下になることが多いそうです。変更を受け入れるための「ゆとり」は、事前に発注側と開発側で合意しておき、上限を設けることも必要です。

品質管理のポイント

一般的にアジャイルだと品質が落ちるという誤解があるため、ウォーターフォールに劣らぬよう、テストもしっかり行います。

アジャイルでテストというと TDD が思い浮かびますが、TDD は習得期間が必要なため、いきなりは難しいそうです。TDD を始める場合は、最初のスプリントで習得期間も見積もっておきます。

変更管理のポイント

仕様の確認方法と、受け入れ方法を確定しておきます。変更についてはスピードが肝心で、ユーザとの打ち合わせ中に受けたちょっとした変更であれば、その場で直してしまうぐらいのつもりで臨みます。

受け入れる変更量は、進捗とコストの「ゆとり」の範囲内で行います。初期開発に対して20%ぐらいを当初から見積もっておき、これを超えないようクライアントとも合意を取ります。仕様確認は全員の合意をとり、手戻りを避けることも大切です。

(4) アジャイルプラクティスはノウハウの塊

以上、アジャイル開発を実践するうえでのハウツーを記載しましたが、目的に応じてプロセスを変える必要があるため、「この場合にはこのプロセス…」といったノウハウが重要になってきます。同社のノウハウとして、成功事例と失敗事例をそれぞれ紹介していただきました。

成功事例

同社のアジャイル適用が成功したのは、以下のような場合でした:

プロダクトや社内システム開発
アジャイル(特にXP, スクラム)は小規模に向くと言われますが、仕様がチーム内で決定できるものであれば仕様変更に対する作業がスムーズなので、XP, Scrum は向いています。
ユーザーと仕様を固めながら行う場合はスクラムがよい
ユーザーのITに対する知識が低く、要件定義書では要件を決められない場合は、画面を見せながら要件を詰めていくと効率よく開発ができました。
アプリ開発はハイブリッドアジャイルで行うと上手くいく
ユーザへもアジャイルの知識を学んでもらい、イテレーションごとにユーザに確認してもらいました。
失敗事例

同社のアジャイル適用が失敗したのは、以下のような場合でした:

アジャイル人材の不足
スクラムマスタが前のプロジェクトに引き抜かれ、プロジェクトをコントロールできる人がおらず、破綻してしまった
無謀な見積もり
アジャイルでやりたいというクライアント要望だったが、アジャイル=工数が減るということで、メモベースで安易な見積もりをした結果、工数がふくれあがった
品質劣化
詳細設計を省略したため、プログラマ任せなコーディングにより、単体テストや品質基準が保てなかった。
変更対応のためのゆとりのない計画
変更を受け入れるための工数が必要なのに、これを見積っていなかった。受け入れるのであれば受け入れる上限と、ゆとりが必要。
アジャイルの効果がでてない(よくあるそうです)
ウォーターフォールを単にアジャイルに変えただけで、目的もないし試作も打っていない。単にアジャイルを適用しただけでは何にも変わらない。
保守の考慮をしていなかった
次の期に改修するために外部発注したが、仕様書がないため、設計書を再作成するために。。(昔はよくあったそうです) 

これだけ成功と失敗のノウハウを貯められるのは SIer ならではですね…。開発会社にいては貯められない、貴重なノウハウだと思います。

失敗したプロジェクトの反省会では「なぜウォーターフォールでやらなかったのか」と現場から怒号が飛び交うなど散々たる状況だったようです。それでもトップのアジャイル開発を行うという意思は固く、上手くいかなかった理由を考え、アジャイル開発導入によるメリットを訴え、現在に至るそうです。