イベント

2013年7月17日、日立ソリューションズにて、弊社主催のAgile Conference Tokyo 2013が開催されました。

今年で、5回目を迎えたアジャイルカンファレンス東京ですが、満員札止めの状態でした。 盛りだくさんのセッションがあり、満足できる一日だったと思います。

最初に行われたのは、ThoughtWorks社のプリンシパルコンサルタントである Kraig T.Parkinson氏による基調講演です。「戦略としてのカンバン: ビジネスイノベーションのために」と題して、イノベーションを起こすために必要とされる考え方やフレームワークについて紹介されていました。

「戦略としてのカンバン」とは、種のようなアイデアでも表に出していき、可視化して、チーム全員が参加することでソリューションへと育てていく仕組みです。現在はテクノロジが可能とするユーザ体験をタイムリーに出していかないと生き残れない時代です。アイデアだけでは駄目でソリューションとして実行することが必要となります。そのためにカンバンを活用するという話です。
アジャイル開発において、カンバンはバックログを管理するために用いられることもありますが、それだけにとどまらずユーザストーリーの背後にあるビジネスオポチュニティを掴んでいくことにカンバンが使われています。
イノベーションはチームスポーツであり、さまざまな役割を持った人がチームの中に揃うことが必要です。まず、ビジネスに対して責任を持つ人が必要です。危機感のない代理人では駄目です。またできるできないを判断できる技術者が必要です。ユーザエクスペリエンスの専門家も必要です。こうなったらいいなという声を指摘するユーザや顧客も欠かせないでしょう。ビジネスイノベーションを実現するには、これらの人々を共同作業させるためのフレームワークに関しても、この基調講演で紹介されました。
チームだけでなく企業全体にアジャイルを適用するという昨今の風潮に沿った形で、今回の基調講演が行われたのだと思います。

基調講演に続いては、オージス総研の藤井様よりScaled Agile Framework (SAFe)の概要を紹介していただきました。

Scaled Agile Framework (SAFe)は、チームレベルで当たり前のように行われて成果も出しているアジャイル開発を企業全体に広げて、大規模システム開発にも対応できるようにするための仕組みです。スクラムの源流となった『知識創造企業』においては、経営陣からの戦略を実現するうえで中間管理職が大きな役割を果たしてきました。SAFeでは、かつて中間管理職が暗黙的に行っていたことを形式的に行うことを目指しています。

SAFeは、ポートフォリオレベル、プログラムレベル、チームレベルで構成されます。ポートフォリオレベルでは経営陣によって投資判断が行われ、投資対象となったものがアジャイルリリース列車として実装します。プログラムレベルではポートフォリオレベルで投資決定されたエピックからビジョンとフィーチャに展開されます。プロダクトマネージャがフィーチャの管理を行い、ユーザーストーリーに分割して、各チームに実装を行わせます。チームレベルではスクラムとXPを用いて、品質を高めます。
Scaled Agile Framework(SAFe)は、Dean Leffingwellが中心となって策定されています。Leffingwellの著書である『Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise』において、そのモデルが詳しく説明されています。Agile Software Requirementsの日本語版は現在翻訳中だそうです。

日本マイクロソフト提供セッションでは、三菱電機の細谷様より、スクラムと品質に関する講演を行っていただきました。

ソフトウェアの品質が悪いと、アップグレードすることができずに、ユーザから見た価値がどんどん落ちてしまいます。そのような事態は開発者も顧客も望んではいませんが、オーバーコミットと階層的な組織が組み合わさると、そのような事態を招いてしまうと細谷氏は説明します。そして、スクラムには「プロダクトバックログに対するチームの見積もりを尊重する」「Doneの定義を明確にする」など、品質の劣化を防ぐためのルールが用意されていると指摘します。

また、実際に使用するソフトウェアの開発を通じて新人の成長を促すプロジェクトの例を紹介していただきました。新人と経験者でチームを構成し、経験が必要とされる工程では、チーム全体で設計を行い、経験があまり必要とされない工程では新人同士のペアプログラミングで対処させるという話でした。
.Net系の開発では、ほとんどすべてのプロジェクトでマイクロソフトのTeam Foundation Serverを利用し、チャットやCI、テスト管理、レポート生成などに活用しているそうです。

特別講演では、豊田マネジメント研究所の高木様と戦略スタッフ・サービスの三井様より、TPS（Toyota Production System)/TMS（Total Management System)はマネージメントのためにあるという講演をしていただきました。

マネージメントとは、部下に成果を出させる能力のことです。部下は自律的に動くことを求められていますが、ルールや原理・原則がないと自律的には動けません。上司が変わると仕事のやり方が変わるというのではなく、共通の価値観のもとで確立したマネジメントのある文化や風土が求められます。

TPS/TMSにおいてカンバンは仕事をうまく回すためにあるのではありません。仕事の流れを整え、問題をあぶりだすためにあるのです。エンタープライズ規模でカンバンを運用する場合、暗黙的に行われている仕事の内容をカンバンとして表に出すことから開始されます。そこででてきた問題に対し、何とかしたいという思いがあるか、チームとしてどのようにあるべきか、チームに属している個人の意義は何かを考え、目標を明確にするのが第1ステップとなります。その後時間や品質で定量化するのが第2ステップとなります。
擬似的な環境での研修だけでは効果が上がらず、組織全体で実践することが重要だという話には納得させられました。

日本アイ・ビー・エムの上村様には、IBMのソフトウェアグループで大規模分散アジャイル開発を行う際に欠かせないツールとインフラについて紹介していただきました。
IBMのソフトウェア製品開発部門には全世界で80か所の開発拠点があり、3万人が携わっています。プロジェクト管理、要件定義、設計、テストなどを行う人々が世界中に散らばって協業を行っています。役割によって使用するツールは異なるので、異なるツール間の連携を行う必要があります。IBMではグローバル分散、コラボレーション、ツール統合、スケールに対応したプラットフォームを活用しています。
このプラットフォームは、OSLC (Open Services for Lifecycle Collaboration) に基づいています。OSLCはビルド、バグ、変更管理、テスト、要求定義などのデータをすべてリンクさせて、さまざまなツールを統合するための仕様です。
OSLCに基づいたIBMのツール統合プラットフォームがJAZZです。そしてJAZZプラットフォーム上で作られたさまざまなツールをそれぞれの役割にある人が使用しています。
https://jazz.net/にアクセスすると、IBMの開発者が実際に使用しているのと同じインフラを体験することができるそうです。

セールスフォースのPaaSを活用したアジャイル開発の実践例をシャノンの堀様に紹介していただきました。

シャノンでは2009年からアジャイルを導入し、開発部分に関しては、ある程度効果が出てきたので、企画→開発→運用というフロー全体にアジャイルを広げようとしています。新しいサービスを少人数・低予算で実現というミッションに対して、フルスタックエンジニアと呼ばれるような企画から運用まですべてに対応できる人がいればよいのでしょうが、現実的ではないので、テクノロジの理解と適切なツールの活用を通して、フィードバックループを早く回すことで対応しようとしています。
使用しているツールやサービスの具体例として、Pivotal Tracker、Git Hub、Jenkins、Herokuを挙げられました。シャノンでは企画を立てる単位、予算を立てる単位をエピックと呼んでいるのですが、そのエピックを実現するストーリーとの関連がPivotal Trackerではうまく管理できるそうです。Git Hubではコードレビューなどの開発者同士のコミュニケーションが便利であり、アクティビティが数値が残るのも役立ちます。Jenkinsはビルドだけでなくコードカバレッジやデプロイ、さまざまなテストに最大限活用しています。また、専任のインフラエンジニアを確保できない組織には、Herokuのサービスがとても役立つそうです。

日立ソリューションズの平岡様からは、アジャイルは手段であり、課題を分析して目的と優先度を明確にすべきであるという話をしていただきました。

目的がタイムリーな市場投入にあるのであれば、アジャイルが有効でしょうが、生産性向上にあるのであれば、アジャイルは不要でツールの活用で十分なことが多いでしょう。また開発前に全体規模を確定して予算取りを行わなければいけない状況であれば、途中まではウォータフォールのプロセスで進めるべきかもしれません。

日立ソリューションズの奈加様から失敗例と成功例を紹介していただきました。
ドキュメントを作成せずに、本に書いてある通りにやればうまくいくだろうと、開発者に任せてアジャイル開発を行った結果、結合テストでインターフェースが食い違って動かず、インターフェース定義書の作成からやり直さざるをなかったという失敗例です。成功例においては、目的から立ち戻り、プロセスを作り直したそうです。また、顧客を含むメンバーへの教育も行われました。そして進捗管理も厳しく行うようにしました。チケットは8時間以内とし、8時間を超えるチケットは工程別・機能別に分割したそうです。その結果進捗遅延は即座に分かるようになったそうです。ただし、方式検討のチケットが抜けていたため、イテレショーン１では休出と残業でリカバリーしたそうです。また、夜間にCIが行われ、朝会でその結果が発表されるため、慎重なコミットが行われ品質が向上したそうです。
プロジェクトごとに目的にあったプロセスが必要だという興味深い話でした。

今回も共同主催のThought Works社からコンサルタントに来日していただき、国際色豊かなカンファレンスとなりました。

ご来場いただいた皆様には、どのような印象のカンファレンスでしたでしょうか? 単独のプロジェクトやチームにアジャイルを適用するのは、もはや当たり前となり、企業全体に営業や間接部門など開発以外の方々にもアジャイルを広がっていく時代になりつつあることが伝わったと思います。許されるのであれば、是非来年もこのようなアジャイルを広げていく試みを継続できることを願っております。

多数のご来場ありがとうございました。

Agile Conference Tokyo 2013 公式サイト