アルバイトとして入社して7年目、新規事業に携わることになった三浦 慶太郎。しかしメンバーのアンテナの高さが裏目に出て、プロジェクトは暗礁に乗り上げた。そんな窮地の突破口になったのは、三浦が出会った「スクラム」という開発手法。今回は彼が、「スクラム」を根づかせた経緯とスクラムマスターとしての想いを語ります。

アルバイトから8年。「スクラム」との出会いが窮地の突破口に

僕がアルバイトとしてリザーブリンク（以下、RL）に入社したのは、2011年の2月のことです。当時はまだ大学院生で、専攻していた情報系の仕事を浜松で探していたところ、情報系に強いという印象があったRLに飛び込みました。そして、その2カ月後に正社員として採用してもらえるという話になり、正式に入社。

最初はプログラマーとして働き始め、いくつか受託案件の仕事をしていました。その後、徐々にプログラマーからSE、プロジェクトマネージャーとして役割が変わってきて。2015年からはメイン事業であるChoiceRESERVEの開発リーダーとなり、2年ほどどっぷりと開発に関わることに。

そして2017年ごろ、そろそろ新規事業に取り組まなければという話が持ち上がりました。RLは基本的にボトムアップで事が進む社風なので、そういった議論をしていた社内メンバーがそのまま新規事業に関わることになり、わたしもその一員になります。

しかし、新しいサービスを生み出すというのは、そう簡単じゃありません。新規事業開発にあたり、1年間ほどはなかなかうまくいかず、頓挫した企画もたくさんありました。

そして行き詰まってしまったときに考え始めたのが、「新しい手法を入れてもいいのでは？」ということ。そんなときにスクラムという開発手法に出会いました。「新しい手法を取り入れてもその型に完全にハマる必要があるわけでもない。もし合わなければ止めよう」という半信半疑な気持ちで取り入れたのですが、これがRLに大ハマりで。

それから試行錯誤を繰り返した末に、2018年、今のCOTOLというサービスの開発に着手して、やっとリリースまでこぎつけることができました。まさに日の目を見るという気分でしたね。

スクラムとは、アジャイルの考え方に沿ったフレームワークです。アジャイル思考には「計画的な進行よりも変化への対応を」「顧客の要求よりも対話を」といった決まりがあります。つまりは、プロジェクトを小さく回して変化に強い開発を行うという発想です。そんなスクラムの基本原則は、「透明性」「適応」「検証」。この3つを見える化して、小さな小さな試行錯誤を繰り返して、次の開発につなげてどんどんリリースしていくという手法です。

たとえばクライアントから「自動車が欲しい」という要求があったとします。でも、本当は自動車で移動することが目的ではなく、「目的地に行くことが目的」であるわけです。

ではまず「自転車をつくりませんか」と提案して、自転車をつくってみます。あるいは「いい靴を履きましょう」というような、もっと小さなことでもいいでしょう。

その後検証をすると、「自転車だと脚が疲れるから次はモーターをつけてバイクにしましょう」「バイクだと雨に濡れるから屋根をつけて車にしましょう」といった風にして変化していきます。

これに対して従来の “ウォーターフォール”という開発手法は、計画通り・手順通り進めることを重視します。3カ月で要件を決めて、2カ月で開発して、1カ月でテストとなると6カ月かかるわけです。

しかし、3〜4カ月先のことというのは見通しがつかないものです。クライアントからの要望はたいてい1～2カ月先に実現してほしいことだったりするので、タイムラインが合いませんよね。車ができ上がるまでに目的地が変わってしまっているかもしれない。

そもそもうちの会社の開発は、典型的なやり方ではありませんでした。ウォーターフォールっぽいけどウォーターフォールでもない。アジャイルっぽいけどアジャイルでもない。そのオリジナルのやり方を、先輩に教えてもらったりして継承していました。

しかし2016～2017年の新規事業に取り組み始めたときに問題が起きました。やりたいことはたくさんある。でもイチから開発するとなるとリリースできるものは限られている。でも、それなら今一番に何をすべきなのか──こうなると、誰も決められませんでした。そして「それならば欲しいものからつくっていこう！」ということになりました。しかし次の障壁は、6カ月もかけて新しいものをつくっても、そのときにはそれはもうすでに“アツくない“こと。

一体どうすればいいのか？ 何か変化に強いいい開発手法はないか。そんなことを考えていたとき知ったのがスクラムでした。小さく回して、次々に開発してはリリースしていく。これは、と思いました。もしうまくいかなければほかの手法を探していたと思いますが、結果的にはとてもRLに合っていて。そして2019年の今は、「スクラムマスター」という役割についています。さらにスクラムマスターとしての仕事だけでなく、受託案件のSEやChoiceRESERVEの開発の一部や、エンジニアの採用も行っています。何足ものわらじです。

「積極的な利他主義であれ」チャレンジャーの背中を押す社風が力に

しかしもちろん、新しい手法の導入がすべて順調に進んだわけではありませんでした。今までやってきたやり方を変えるというのはとても難しいことです。みんな耳はきちんと傾けてくれますが、疑問を持つのは当然ですよね。

私はまず専門書を読んで、その受け売りで説明してみましたが、まあ説得力がなく響かないわけです。

「これはどうにもならない」と思って次に資格を取得することにしました。スクラムマスターの資格（認定試験）です。 費用に関してはありがたいことに会社が支援してくれました。

うちの会社はやりたいことに対して前向きで、決して否定はしません。もちろん「なぜ」それが必要なのかという説明は必要ですが、その明確な目的と理由をしっかり持ってさえいれば、受け入れてくれる体制はあります。

そんな風に私がなんとかスクラムを取り入れようと奮闘しているとき、ちょうどCOTOLやマーケティングに関わる井出というメンバーに「なんだかスクラムっていうのが良さそうなんだけど三浦さんどう思う？」と声をかけられました！想いをともにする者が増えて、それも後押しになりました。

すぐさま「じゃあ一緒にやりましょう！」とタッグを組み、互いに仕事のかたわらで勉強に励んで、わたしはスクラムマスター、井出はプロダクトオーナーの資格を取得しました。資格を取得したことで、私にちゃんと知識があるという前提ができたわけです。

しかしそれでもまだほかのメンバーからは抵抗がありました。それでも「まぁまぁそこはいったんやってみましょうよ」と呼びかけました。スクラムは1週間で1サイクルが終わります。それをとりあえず2～3週間回せば、悪いところもいいところも見えてくるはず。

とりあえず1週間、とりあえず2週間、とりあえず3週間。「とりあえず、とりあえず」と説得して、それを1年近く継続して今に至ります。

まずは、COTOLチームでスクラムを回していいところが見えてくると、COTOLメンバーが「スクラムっていうのが良かったよ」と社内に広めてくれるようになりました。そうするとほかのチームも興味を持ち始め、形勢逆転です。あれほど最初の導入に苦戦したことがまるで夢だったかのように、ほかのチームのスクラム導入まで支援するようになりました。

その良い流れを断たないように、スクラムとは何かということを記事にして社内に流したり、スクラムを取り入れているチームがうまく進められているか声をかけて回って確認したりして、少しずつ社内の認知を確立してきました。

私がここまで熱意を持って取り組めた背景には、ひとつの好きな言葉があります。それは、リザーブリンクのバリュー “リザーブリンクマンシップ” として掲げられている、「積極的な利他主義であれ」という言葉です。

ほかの人に対して、働く環境や心持ちがより良くなってほしい。不幸せになってほしくない。そして支えていきたいと思います。愛社精神というとなんだか仰々しいけれど（笑）、そうすることが好きなので。

これまでの開発手法の中では、さまざまな立場のメンバーがうまくいかずモヤモヤしている部分がありました。会社のメンバーは、みんなアンテナが高い。顧客との対話での気づきも、市場からの得た情報も、とにかくたくさんあって、結局開発ができないという悪循環でした。やりたいことはいっぱいある。そしてやりたいことはどんどん変化していく。

でもそのやりたいこと、つまり「要求」をプロジェクトに落とし込むには1カ月ほどかかってしまいます。1カ月かけているうちに新しい要求が出てきたり、今までの要求が変化してしまったりします。そうなると、度々開発の手を止めて、また要求をプロジェクトに落とし込む作業をすることになります。

そしてまた新しい要求がやってくる。そんな調子ではみんなが幸せになれると思えませんでした。 「もしかしたらスクラムがこの状況を打破してくれるかもしれない」「みんなが幸せになってほしい」──そんな想いが私を推し進めてくれました。

気をつけたのは、強引に実行するのではなく、「こちらの方がいい」と主張するときに「なぜその方がいいのか」をしっかり言語化すること。そしてみんなにゆっくり浸透させて、徐々に盛り上げていき、形にしていくことです。

社内制度や方針をトップダウンで大きく変えようとするパターンも耳にしますが、RLのメンバーはみんなそれぞれがほかの誰にもない能力や役割を持つ個性的な集団です。

その「個」は強みだから「個」を大切にしようという社風なので、トップダウンで変化させようとするのではなく、ある意味“根回し“のコミュニケーションが必要です。それは、それぞれのメンバーの想いや個性を尊重しながらチームワークを高めるために大切なことだと思っています。そうやってコミュニケーションすることでみんな、快く耳を貸してくれたり、改善の提案をしてくれたりしますね。 とにかく、やろうと決めた本人にはブレずに突き通す力が必要です。

「中空の点を取れ」スクラムマスターはナナメ上を目指して空気を読む

スクラムを取り入れてからも困難はありました。最初はみんな慣れなくて、1週目は文句もありました。スクラムでは打ち合わせが多いため、「そんなに打ち合わせが必要なのか」という疑問も出ました。でも、決まった時間に打合せしているとほかの時間の開発に集中できるようになります。3週もすれば習慣化します。

次に、「打ち合せで言おうと思ったことを打ち合せで言わないでください」と呼びかけました。打ち合わせまで温めておくのではなく、思いついたそのときにチャットで投げるようにする。困っている人をあぶり出すために、とにかくコミュニケーションを取るようにすることが私たちには必要でした。

問題点になっていないところから新しい問題を見つけ出して、すぐさま解決する。それを繰り返していくうちにみんなのアンテナは磨かれていって、みんなが小さな問題点に気づくようになり、チームが自立するようになります。

このようなスクラム手法によるメリットで、社内コミュニケーションはずいぶん増えました。“言うほどでもないか“と思って心に留めてしまっていたちょっとしたことも声に出せるようになりました。小さなことの積み重ねが大きな変化につながるはずです。

「みんなの前で問題点を挙げるのは、不満を言っているようだったり、自分は仕事ができないと示しているような気持ちになったりして難しい」というのは、どんな仕事でもよく耳にすることです。でもスクラムの手法を取ることで、みんなが小さなことでも問題点を挙げる雰囲気になるため、何でも言っていい雰囲気になります。

これは開発手法というツールとしてのみならず、極端に言うと「仕事が楽しくなる」というように、働く環境にも意義のあることだと思っています。もちろんまだモヤモヤのすべてがなくなったわけではないと思います。でも以前よりもずっと発言しやすくなり、少しずつスッキリしてきたんじゃないかと。

もちろん見えてきた課題もあります。やることが明確であればいいのですが、不確実性が高い課題の場合、チームがどのようにして対応していくかが難しい。見積もることのできない課題、外的要因が大きい課題は、袋小路に迷い込んだように右往左往してしまいチームの士気が下がることがあります。そのときにいかにして解決し、サポートしていくかが重要になると思っています。

またコミュニケーションの面でも、もっと上を目指せると考えます。2019年現在、東京、静岡、外部委託としての北海道の3拠点で業務が回っています。

基本的に拠点間のコミュニケーションは問題がないのですが、オフラインのコミュニケーションに勝るものはありません。これをどのようにして補っていくのか。スクラムマスターとして、「見えないところで何をやっているか」をどう見える化するか考えあぐねています。

将来的には拠点ごとにスクラムをつくることができればいいなと思い、自分自身も組織づくりに積極的に参加しています。

スクラムマスターになってから、開発者としても意識に変化がありました。今までは「個」で働いていたのですが、スクラムマスターになってから「チーム」を意識するようになったことです。スクラムマスターとして、チームが良くなる方向に動く必要がある。だからこそ、周りに対して積極的になりました。

小さなチームだけでなく、会社との関わりも密になりました。技術部として、会社として、そういった大きな規模の「チーム」がより良くなるにはどうすればいいのかという視点を持つようになりましたね。

役割が変わり手法が変わり、環境の変化は大きいですが、楽しさの量は変わりません。楽しさの質は変わりましたが、エンジニア時代も今も、アグレッシブなことをする楽しさは同じです。スクラムマスターとなったことで外的要因が増えて、うまくいかないことは増えましたが、それもまた楽しいです。

スクラムマスターのとくにおもしろいところは、空気を「読む」ことです。私はよく弁が立つと言われていて、とにかくしゃべりだけでなんとかしようとしてしまうけれど、それじゃいけません。スクラムマスターが自分の空気に持っていくのは良くないと思います。そうではなくて、空気を読みながら、自分の空気も含むみんなの空気を中和させていくのが理想です。

私はよく「“中空の点“を取りましょう」と伝えています。単純に中間点ではなく少し上を目指そうと考えています。そうやってみんなの空気を読んで中和させていくことはとてもおもしろいです。

「スクラムにこだわる必要はない」チームに大切なのは引き出しを増やすこと

今後は、スクラムはフレームワークとしてすばらしいものだと思っているので、社内にもっと取り入れられるようにサポートしていきたいと思っています。

それから、スクラムポリスとしての役割も重要です。中途半端なやり方でスクラムをやろうとして失敗してスクラムの評価が下がるのは本末転倒です。「スクラムの敵は悪いスクラム」です。だからこそ、正しいやり方で、より効果的にスクラムを浸透させていきたいと思っています。

ただ、スクラムはあくまでもひとつのツールです。それを磨き続けることだけを目指しているわけではありません。今は順調ですが、もし今後スクラムがうまくいかない、合わないという状況になったときのために、新しい開発手法を今から見つけ出しておく必要があると思っています。

次の手段があれば、引き出しが増えて、会社としてより幅広い能力と知識を備えることができると思うのです 。

スクラムを始める前、新規事業がうまくいかなかった時期にスクラムに出会い、そこから導入までずいぶんと時差がありました。勉強して、資格を取って、社内に浸透させて。

もしまた同じことが起きるならば、次は時間差なくスムーズに変化することが理想です。うまくいっているときこそ次の半歩先を行くというのは、エンジニア時代からの私のモットーですね。

そして、ほかのメンバーとともに個人のアンテナをできるだけ張っていきたいと考えています。小さな会社なので、自分が何をしたいのか、という意識が大切だと思っています。“個”が主体となっているフラットな社風だからこそ、市場にも社内のメンバーにも視野を広げてしっかりアンテナを張る。そして、メンバーさまざまな意見や新しい提案に対して関心を持つことで、RLというチームはより強固になっていくと思います。