そういえば、ふと思ったんですがエンジニアの方って毎日四六時中コードと向き合っていて、頭がオカしくなったりしないんですか？
頭がオカしくなる、ですか？（笑）
はい。もう毎日誰とも話さずただ黙々とコードと向き合い続け、さながら指だけが動くアンドロイドのごとく無機質な文字列を生み出す日々の末に目の前のコードは徐々にゲシュタルト崩壊を起こしていき、今自分が一体何を書いているのか、何をつくっているのか、ここは一体どこなのか、この宇宙の原理とは、生きている意味とは、と自問が止まらなくなり、突如として奇声を発して泣き始める…みたいなこと。あまりないんですか？
ものすごいイメージですね（笑）怖すぎませんか？ そういう人は見たことがないですが、確かに、自分がつくろうとしているプロジェクトに何一つとして自分の意見の反映される余地がなく、100%プランナーの言いなりでプロダクト自体に思い入れもなければ、そして人間関係も悪い上に働きづめとなれば、職場は苦しいものになるでしょうね。
ただ、実際のエンジニアの働き方は、イメージとだいぶ違うと思います（笑）
そうですか。エンジニアの方がどのくらいプロダクトの企画に関与しているのか、ひいては、日々どんな風に何を考えて仕事しているのかというのは、すごく気になります。
エンジニアがどれだけ主体的にプロダクトに関われるかというのは、実際にやりがいの面以外でもすごく重要なポイントです。ちょっと、最近あった非常に重要なプロジェクトの例で、そこに関連するような話があったので紹介できればと思います。
開発手法の話
最近、レアジョブの基盤となるシステムを刷新するという全社的にも非常に重要なプロジェクトがあり、そこで「スクラム開発」というものを取り入れました。
スクラムカイハツ？円陣でも組んでみんなで声を上げながら開発するんですか？
全然違う！と言いたいところですが、結構近いです（笑）
技術的知識のあまりない方にとって、開発の工程というとざっくりどのようなイメージがありますか？
うーん、まず必要になる機能をすべて明確にして、それぞれどのようにつくるか決めて、そこからプログラマーが一気にコードを書いていって、最後にテストして、完成…という感じですかね。
そうですね、それは、一般的に「ウォーターフォール型」と呼ばれている開発手法です。プロジェクト全体を各工程にわけて、一つひとつ確実に進めていく方法で、古くから一般的に採用されてきました。
ウォーターフォール型開発は、しっかり計画を立てるのでスケジュールが立てやすい、予算を組みやすいといったメリットがあるのですが、一方で、最初から「これをこうつくる」ということを細かく決めないといけないという弱みも存在します。つまり、抽象的なお題に答えることには向いていません。
確かに、つくりながら考える…という風にはしづらそうですね。
そこで採用されるのが、アジャイルと呼ばれる開発手法です。これは、短い期間でテストを繰り返しながらスピーディに開発していく手法です。
ウォーターフォールと違い、開発を小さな単位にわけて、それぞれの機能ごとに「計画」「設計」「実装」「テスト」「リリース」という流れを何度も繰り返す方法です。一度決めた計画を絶対のものとせず、柔軟に開発を進めていきます。
なるほど。開発中に機能を追加したりしやすそうですね。
その通りです。そして、このアジャイル開発の手法の一つとして、「スクラム開発」というものがあります。スクラムという言葉のイメージ通り、チームワークやコミュニケーションを重視している開発手法です
スクラム開発の特徴は、たとえば「2週間」といった固定の短期間（スプリント）で開発を区切り、そのなかで計画を立てることです。そして、プロジェクトの状況や進め方に問題がないか、メンバー同士で、毎日確認し合います。
毎日？毎日の朝礼みたいなものですか？？ 逆に開発の最先端の現場で、古き良き日本企業みたいな方法が取られてるんですね。
そうですね（笑）デイリースクラムと呼ぶんですが、いわゆる「朝会」に近いですね。毎朝、15分程度で、自分の周りの状況を共有し合います。
スプリントのゴール達成のために前回のデイリースクラムから自分が何をやったのか、今日は何をするのかを話し合うんです。「朝会」は一般的に業務報告のような一方通行のイメージが多いですが、デイリースクラムではチームとしてどうゴールを達成するかの計画の場なので、コミュニケーションをとる機会が非常に多いんです
ただ、目的に向けた話し合いだけでなく、雑談だったり、直接的には関係ないけれど気になっていることだったりをそれぞれが語る場はたくさんあるので、ただひたすらコードに向き合って黙々と作業する…というエンジニアのイメージとは大分違うと思います。
また、スプリントレビューという成果物に対してレビューする場があるのですが、その時に成果物に関して主体的に考えを持ちやすいというのもあるかな、と。
スクラム開発の難しさ
なんか、聞いてるとアジャイル開発ひいてはスクラム開発の方が、ウォーターフォール開発よりも随分と楽しそうですね。どうしてこれをさっさと導入しなかったんですか？
楽しいというか、これは目的によって適切な手法があるということですね（笑） ウォーターフォールの方が良い案件もあります。ただ、なかなかスクラム開発が採用されて来なかった背景には、単純に導入の難しさがあったというのもあると思います。
スクラム開発の導入が、難しいんですか？
ものすごく難しいです。というか、正確に言うと、形式的に導入することは簡単なんですが、それを「意味のあるものとして活用する」ことが難しいんです。
やり方はわかるけど使いこなせない、という感じですか？
その通りです。やり方に関しては、教科書があるんです。「スクラムガイド」という公式のガイドがあって、そこにスクラム開発の目的だったり、定義、用途、それぞれの進め方が細かく書いてあります。
あ、そうなんですね。
ただし、教科書通りに形式的なことをやってもスクラム開発は成り立ちません。それは、スクラム開発がすべてのチームメンバーの能動的な関与を必要としているからです。
たとえばメンバーの何人かが「スクラム開発をやらされている」という状態になると、スクラム開発は機能しません。
チーム全員がスクラム開発を採用する意味を知っていないといけないし、それがどういうものなのか腑に落ちていないといけません。
なるほど。確かに“スクラム”って、無理やり組ませるものじゃないですもんね。
さらに、スクラム開発の教科書はあるものの、これはそのまま使えるものでもないんですね。それぞれの会社に当てはめて、スクラム開発というベースの考え方を自社用にチューニングしないといけません。書いてることはわかるが実際に上手く使えるかどうかは別問題ということです。
言うは易く行うは難し。ですね。
そういうわけで、僕も前職で何度かトライしたことがありますが、なかなか上手くいかなかったという経験があります。
レアジョブでも、かつてスクラム開発に挑戦し、半年くらい形式的にスプリントを回した結果「いやもうウォーターフォールでよくね？」となり、空中分解した歴史があったみたいです。
なんと…。というかこのスクラム開発というのは、誰が指揮をとって進めていくものなんですか？
スクラムマスターという、すべての関係者の「調整役」ポジションの人がいるんです。プロジェクトを円滑に進めるために、スクラムのルールや進め方を各ポジションの人に伝えていく役割の人ですね。
すごい名前ですね、スクラムマスター。めちゃくちゃかっこいいじゃないですか。名刺に書きたいです「スクラムマスター」って。
ところで、そのレアジョブのスクラム開発のスクラムマスターは、誰なんですか？
あ、僕です…。
スクラムマスターああああ！！！！！！！！！
レアジョブのスクラム開発
レアジョブの基盤となるシステムを刷新という直近の重要プロジェクトで、スクラム開発が成功したのはどういう要因だったんですか？
結局、メンバーが良かったんだと思います。レアジョブって、真面目で根が良い人が揃っている印象があるんですよね。
「我が我が」となってしまう自分本位な人が多いと、やはりスクラム開発は成り立たないんです。周りをすごくよく見て動いてくれるけど、実はポテンシャルも相当ある…みたいな人材が多いですね。
だから、僕が最初にスクラムの基本的な考え方や、何を目指してどのように進めていこうと考えているかを共有した時から、ものすごく進めやすかった記憶があります。僕がやっていたのは、ごく基本的なことでしたが。
今回のプロジェクトは、わりと大胆にデザインもフルリニューアルして、既存のものをぶっ壊して新しいものを作って良いというものだったんです。自由度が高くて面白い分、与えられた命題が抽象的なので、落とし所を見つけていくのは簡単ではありませんでした。
そんななかで、いろんなことを考えてみよう！と盛り上がりつつ、多くの時間が掛からず効率的に仕様が決まっていきました。議論の進み方はよかったですね。
そういう意味では、何かこの要因があったから良かったというより、メンバー全員の能力やマインドセットが良かったんだと思います。ものすごい漠然とした言い方になってしまいますが（笑）
なるほどですね。
エンジニアがどんな感じで働いているか、何を考えているか、少しイメージしてもらえましたかね？
後日、スクラム開発成功の秘訣について開発チームに聞いてみると、「三上さんの働きによるところが大きい」という意見が殺到しました。
インタビューでは自らの功績を全く語ることのない、恐るべきスクラムマスター…
