エイジィのアジャイル開発への取り組み

これはエイジィアドベントカレンダーの2日目です。
1日目は、くぼっちさんによる「Raspberry Piによる社内サーバの構築」です。

自己紹介

@sawai_hiroakiです。
・創業から4ヶ月のxxx株式会社(エイジィと読みます)で制作チームのマネジメント業務と開発業務に従事しています。
エイジィでは、ポムと呼ばれていますが、由来は不明です。※PM(プロジェクトマネージャ)をもじったという説や、「Peace of Mind(心の安らぎ)」の略などの説があるらしいです。
・ネット系のエンジニアになったのは、学生時代から主にC/C++でプログラミングを学び、就職活動をしている際に、ネットビジネスの将来性に惚れ込んだのがきっかけです。
・Javaのサーバサイドエンジニアから始まり、最近はネイティブサイドの開発も担当しています。
・1年に及ぶ典型的なウォーターフォール型開発で痛い目に遭ったことや、半年間を超えるような比較的規模の大きいスクラムによるアジャイル型開発の経験があります。
・直近の2年間は、スマホゲーム会社でプログラムを組まないマネージャー(開発部門長とプロジェクトマネージャを兼務)業をしていました。

本稿で書くこと

タイトルの通り、エイジィのアジャイル開発に関する2015年末時点での取り組みを書きます。逆に、本稿でアジャイル開発やスクラムの基礎的な説明は行いません。既に多くのサイトで説明されているためです。以下のサイトや書籍が詳しいので、興味のあるかたはこちらをご参照ください。
https://ja.wikipedia.org/wiki/%E3%82%A2%
https://ja.wikipedia.org/wiki/%E3%82%B9…

http://www.amazon.co.jp/dp/4274068560/
http://www.amazon.co.jp/dp/4152095423/
http://www.amazon.co.jp/dp/B00DIM66P0/

また、本稿に記載する内容は、執筆者個人の考えであるため、誤ったものも含まれると思います。そういった場合は、そっと指摘をいただけたらありがたいです。

アジャイル開発宣言

我々の会社で取り組んでいるアジャイル開発に触れるまえに、アジャイル開発とは何かについて触れたいと思います。(これはアジャイル開発の本質をまとめた文章で、特定の開発方法論を指したものではありません。)
・プロセスやツールよりも個人と対話
・包括的なドキュメントよりも動くソフトウェア
・契約交渉よりも顧客との協調
・計画に従うことよりも変化への対応

アジャイル開発手法の多くには、イテレーション型の開発を取り入れることでリスクを最小化しようとする共通点があります。
アジャイル開発では、各イテレーションが終了するごとに、ソフトウェアのリリースを行い、プロジェクトの優先順位の評価をし直します。こうすることでプロジェクトが明後日の方向に打ち上げられることを防いでいます。

アジャイル開発手法が生まれる以前にあったウォーターフォール型開発と比較する場合、「適応重視」なのか「計画重視」の軸によって比較するとわかりやすい。つまり、「適応重視」がアジャイルで、「計画重視」がウォーターフォールとなります。どちらの手法でも、日常のワーキングスタイルに、「計画」と「統制」が存在します。
稀に、「放任型」か「統制型」かの軸で、アジャイル開発とウォーターフォールの比較をする場合がありますが、アジャイルでもウォーターフォールでも、制作の対象物やチームもしくは構成メンバーのスキルや経験値によって流動的に変動させる要素であるため、この軸で説明するのは難しいだろうと考えています。

スクラム

最近、ネット業界で広まっているアジャイル開発手法にスクラムがあります。
スクラムは、「プロダクトバックログ」というステークホルダ全員が参照可能なリストによって優先順位付けし、スプリントと呼ばれる期間の終了ごとにリリースとスプリントレビューと呼ばれる製品レビューを重ねることでイテレーション型開発を実現しています。
また、スクラムは上記のイテレーション型のみでなく、クロスファンクショナルなチームで開発に関する意思決定を開発チームに移譲し、リーダーにサーヴァント型のマネジメントを実行させ、開発チームに自己組織化を促すことで、主体性の強いラーニング・オーガニゼーションを構築することができると言われています。
スクラムの導入と言うと前者のイテレーション型開発のみでも効果を発揮しますが、後者のマネジメントを行っていきたいと考えています。
この辺りのことは、「最強組織の法則―新時代のチームワークとは何か」でも詳しいので気になる方にはご一読をおすすめします。
http://www.amazon.co.jp/dp/419860309X/

100020DSC05823-a9bc2

エイジィで取り組んでいるアジャイル開発

続いて、2015年12月時点で、取り組んでいる開発手法について触れます。
前述のスクラムをベースに、前者については全面的に導入し、後者については開発の意思決定を現場に委ねてしまえるほどの開発基盤ができていないこともあり、マクロな意思決定についてはマネジメント側で行うような進め方をしています。
開発メンバーの主体性については、プロダクトのビジョン理解の促進(インセプションデッキを作成)やミクロな意思決定の移譲、キャリアパスの尊重によってフォローするようにしています。(そもそも創業期なので、そこまで気にしなくても大丈夫!)

■具体的な実現イメージは下記の通り。
・プロダクトバックログによる優先順位付け  ○
・スプリントの導入  ○(1週間で区切る)
・スプリント計画の実施  ○(毎週月曜に1時間ほどで実施)
・チームによるスプリントバックログの決定  △(マネジメント側からの指定が強い。)
・デイリースクラム ○
・タスクかんばん ○(trelloというツールを使用)
・継続的インテグレーション ○
・スプリントレビューの実施 ○
・インセプションデッキ ○
・ユーザストーリーの実現手段  △(設計や実装方針についてマネジメント側からの指示あり)
・ワーキングスタイル(各メンバーがスケジュールやタスク管理を行う)
・クロスファンクショナルなチーム
・少人数チーム(1チーム9人未満)

ダウンロード

ウォーターフォール型開発をけなすひと

少し脱線し、ウォーターフォール型開発をけなす人というものに触れておきたいと思います。
統制度合いの強い反復型開発に対して「ウォーターフォール的でダメだ」という批判を何度か目にしました。統制型=ウォーターフォールだと思い込んでいるのでしょうが、冒頭で触れた通り、アジャイル型開発とウォーターフォール型開発の違いは、「放任-統制」軸ではなく「適応-計画」軸で見るべきです。こういった諍いで職場の雰囲気が悪化する場面を見たことがあるので止めるべきかと思っています。
概ねこういった諍いをしているひとは、ウォーターフォール型開発の経験がなく、アジャイル開発以外は全てウォーターフォール型開発と思っているフシがあります。個人的にウォーターフォール型開発も経験した人間としては、もう少しウォーターフォール型開発の特長を知ったうえで批判して欲しいと思います。ウォーターフォール型開発の出身者で現在スクラム信者という立場のひととは建設的に話せる場合が多く、そうしたなかで少しでも開発の在り方を発展させていきたいものです。

スクラムの背景にある考え方

スクラムのベースとなった「新たな新製品開発競争」という論文をご存知でしょうか。
1986年の「ハーバード・ビジネス・レビュー」に掲載された、野中郁次郎氏と竹内弘高氏がまとめたものです。そこで、生産性の高い革新的な世界企業の強みを次のようにまとめています。
①開発プロセスが段階ごとに分断せず重なりあっていて、スピードも柔軟性も優れている。
②機能横断的なチームで主体性がある。
③境界を超えた大きな目標がある。
④自分たちの枠を超えた大きなものを目指している。
⑤チームが自ら決定する力がある。
⑥マネジメント部門は製品開発の中身や進め方を細かく指図しなかった。
⑦管理職はサーヴァント側リーダーで、チームが仕事を進める障害を取り除くことに徹している。

スクラムを考案したJeff Sutherland氏は、こうしたアプローチをソフトウェア開発に取り入れたと言われています。

200px-Jeff_Sutherland honda 3m

以前、あるアジャイルチームのリーダーから、「うちのチームは、上が指示をしなくても自発的に作業するので暇なんです」と自慢気に言われたことがあります。悪意はないと思いますが、そもそもそのような志で①~⑦を満たすようなチームを作れるものでしょうか。
スクラムを取り入れたもののチームの熱意が失われたと聞くことがあります。その原因が「会社のマネジメントスタンス」にあるのか「リーダーシップスタイル」にあるのか「スクラム」自体に弊害があるのかを分析することは、最近の興味深いライフワークとなっています。

最後に

現在エイジィでは、上述したようなアジャイル手法を取り入れ、「爆速開発」と銘打ち、普通に開発した場合の1/2程度の期間で開発を終えられないかを工夫するようにしています。創業期という段階を踏まえるとこんなものかとは思うのですが、単に「スピード早いです」とか、「アジャイルやってます」とか、「みんな笑顔です」とか、そういうことでなく。大きな目標を掲げ、全力で取り組みつつ仲間のために奉仕し、そうしたなかでのチームの前進を喜びと感じられるようなチームの構築を目指しアジャイル開発に取り組んでいきたいと考えています。

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です