agilejp_2016_800px

こんにちは、PoohSunnyです。
5月31日に行われたアジャイル系のイベント・『Agile Japan 2016』nawoto(西村直人、以降nawoto)さんとふたりで登壇してきました。
僕たちは「事業会社でのアジャイル奮闘記 新世代と作るアジャイルな土壌作り」と題し、入社して約1年のnawotoさんと約7ヶ月の僕という、見た目とは裏腹な“社歴はフレッシュ”なコンビがどのようなことを考えて仕事をしてきたかを話してきました。

事業会社でのアジャイル奮闘記

なぜこのような話にしたか

まず、アジャイル開発の導入に取り組んでいる会社として考えると、弊社はまだ過渡期だと思います。よって、着飾った成功例というよりは、「どういう問題を抱えていて、どういう取り組みをしているのか」をありのままに語ったほうが聴衆に勇気を与えられるし、参考にもなると思い、なるべく実体験に即したものを話すことにしました。

ぼくらの目指した姿

まず、目指した姿として、「アジャイルな組織を作りたい!」「仮説と検証をスムーズに回せる仕組みを作りたい」「決めたらすぐやる」「高頻度でリリースをしたい」「リーンな組織を目指したい」・・・というものがありました。

僕がリクルートジョブズに転職して良かったと思うことは、僕はソフトベンダー出身で、過去の経験では「できることから施策を打つ」ことが多かったのに比べ、この会社ではまず『あるべき姿を先に考える』というところです。
また、『技術がツール(実現手段)である』ところも良いと思いました。ただ、ToBe志向で決断が早いのは長所なのですが、調整ごとや打ち合わせが多いという短所があるのも事実です。

では、実際に開発はどうかというと、「システムのレガシー化」「社内のナレッジ不足」という問題がありました。そのため、例えば機能追加/削除をしようとした時に正しいジャッジができなくなる、という状況が発生していました。
そのような問題を解決するために、開発サイドと物理的な場所も違うと、顔が見えない上にやりとりも煩雑になるので、まずは「同じ場所で開発しよう」ということでスペースを設けました。
そして、スクラムを導入し、いくつかのチームはスクラムでリリースの頻度を上げていました。ここまでが僕らの入社前の話です。

エンジニアの評価制度を作る

nawotoさんが入社して最初に着手したのは、エンジニアの評価制度を作ったことです。最初はチームの取り組みを支援することから始める会社が多いと思いますが、最初に仕組みを作ったというのは珍しいし、おもしろいですよね。それでできたのが、『アジャイルに特化したキャリアパス』です。特に、“スクラムマスター”というキャリアパスがあるのは日本ではかなり珍しいと思います。
そして、スクラムは認定資格がいくつかありますが、当時僕がいたチーム6人の取得実績では、Certified Scrum Master (CSM)を6人中4人、Certified Scrum Product Owner (CSPO)は6人全員取得など、会社で取得を推進していることもあって、資格取得者の割合が高くなっていきました。

実績から巨大なプロジェクトに

エンジニアの評価制度ができたら、次は実績を作らないといけません。ある仮説検証プロジェクトで、弊社では比較的短納期でリリースできて、当時のディレクターは社内表彰されるなど、実績ができてきました。
そして、次のプロジェクトはもう少しだけ難しいものにチャレンジできると良かったのですが、実績ができたがゆえ、「主要メディアの基盤移行」という相当難しいプロジェクトになってしまいました。
当初は小さいチームで進めていたのですが、どんどん雪だるま式に人数も増えていき…。最初は大丈夫だろうと高を括っていたものの、次第に「プロジェクトが基盤刷新」/「新技術」/「新メンバー」・・・とたくさんの「新」がある状況になっていき、僕たちは“ヤバイ兆候だ”と話すまでになってしまいました。

どうやったか

そのような状況の中でどのような方針で進めたかというと、まずは「自分たちで作ろう」ということ。それまでは外部ベンダーにお願いすることも多かったのですが、そうではなく自分たちでやろうと号令をかけ、社内のエンジニアに集まってもらってチームを作りました。
ただ、プログラム初心者も多く、彼らを短期間で育成しないといけなかったので、nawotoさんが若手のプログラマーに一対一で教えるという徒弟制度でのスキル習得を実践しました。このようにしてチームが結成されました。
そして、試行錯誤が多いプロジェクトはスクラムが向いているので、スクラムでやることにしました。
あとは、弊社はプロジェクトの兼務が多く、各人の全体のタスクが見えにくくなることも問題でした。そこで、「いくつ兼務していて、どのような仕事を抱えているのか」を共有するため、タスクボードを作って全部“見える化”することで、各メンバーがどれくらい稼働できるかをわかりやすくしました。

良かった点と悪かった点。そして結果は……

このような試みを実行して良かったのは、タスクを“見える化”したこと。そして、徒弟制度はとても評判がよかったです。
あとは、社内にもこうした開発の前例がなかったので、自分たちで考えるいい機会にもなりました。ディレクターがエンジニアリングすることでいろいろな気付きもあっただろうし、ディレクションをやっていたからこそ、エンジニアリングする時にいろいろな気付きもあったと思います。

悪かったところは、まずはタスク溢れ。若手の人にはキャッチアップに集中してほしかったので、プロジェクト管理系のタスクは全部僕が引き取りました。しかし、いかんせん自分たちも新人で会社の作法もわかっていなかったので、必要なタスクが溢れてしまい、最終的にチームに迷惑をかけることになってしまいました。
そして、教育・育成の計画の難しさ。教えたからすぐできるようにはならない訳です。個人の特性もありますし、僕たちの教え方が悪かったところもあると思うのですが、なかなか思うようには進みませんでした。
あとは、教育の成果を本人と上層部へどう伝えていくか。たとえ、「成長している」ときちんと伝えたとしても、「自分が進んでいる」という実感を得られなければ、なかなか納得はしないと思うので、そこは悩みました。
そして、我々はプロジェクト全体で6ユニットくらいある中の1ユニットだったのですが、全体ではウォーターフォール型で進めていたのに、我々のチームだけがスクラムで進めようとしていたので、全体の整合性のとり方が大変でした。

結果、どうなったかというと、実は全体的な方針変更があり、僕たちはチームから離脱することになりました。

考察

小さなチャンスを成功させると、いきなり巨大なチャンスになるというのは新鮮な経験でしたが、正直なところ、「もう少しステップバイステップでやりたい」とも思いました。nawotoさんが話していたことで印象的だったのは、「自分たちがちゃんと変化を受け入れようとしていなかった」ということです。
つまり、知識・経験があるとは言っても、自分たちは会社内ではまだ新人なので、いろいろと会社の習得すべきことがあり、その上で改善するべきだったのですが、自分たちの得意なスクラムというフィールドに強引に寄せようとしてしまったところがありました。アジャイルには「Embrace Change(変化を抱擁せよ)」というキャッチコピーがついていますが、気づくとそれをあまり実行していなかったのです。僕たちも新人だということもあって余裕がなかったし、追い込まれていたのだと思います。

最後に

今回の登壇では、もともとこのようなある種の失敗談にしようとは思っていませんでした。Agile Japanへの登壇が決まったのがかなり前で、このプロジェクトが華々しく進んでいるという話をしようと思っていたのです。
ただ、方針変更があったので、気を取り直して、「どうせだったら失敗談でもいいから経験談を話そう」と思いました。
結果としては大好評でしたし、成功例を話すことが多いイベント登壇の中で、実際に使える経験をシェアできたのではないかな、と思います。
そして、「失敗談は共感を生む」ということを講演してみて実感しました。今回の経験は、「エンジニアチームから組織へ」「エンジニア教育の検討」など新たな課題も生みましたが、この経験を踏まえて次に続けていくというのが僕らのやり方なので、そういう意味も込めて最後のスライドは『To Be Continued』としました。
いい体制もでき始めているので、これからもがんばります!