大手食品メーカー石井食品(株)他、経験豊富なフリーランスエンジニア兼スクラムマスター。「楽しく作る」を極めたい。旅をこよなく愛し、エンジニアの世界とビジネスの世界(非ITの世界)を幸せにつなげていくことをテーマに活動をしている。言ってしまうと、まず“アジャイル開発”という開発手法があって、そこで使うフレームワークの一つが“スクラム”です。“アジャイル開発”とよく対比されるのは、“ウォーターフォール型の開発”ですが、日本ではこの“ウォーターフォール”型の開発がまだまだ多くて、でもこのやり方でうまくいかなくって、“アジャイル開発”にする、という流れが来ています。うまくいかない、とは。“ウォーターフォール”型の開発って、長期間のプロジェクトで工程が上から下に流れるので、一旦走り出すと戻れないんですね。実装となるんですけど、でっかいシステムを作るためにこのでっかい規模での計画を長期間で立てて。一度スタートしたら、途中での気づきがあっても戻れない。使ってみたら使いづらい、とか、使ってみたけど当初の課題解決ツールになってない、とかよくあるんです。当初に立ち戻ることができないままプロジェクトが進んで、最終的に「誰のせいだ!」みたいになる。そんな結果は発注側も望まないだろうし、つくっているエンジニアにとっても、とてもストレスだし、出来上がったものが役に立たないのは悲しいことなんですよね。大きな予算をかけて、残念なものができるのは・・・確かに良いものづくりには繋がらないかもしれないですね。そこで“アジャイル開発”が登場したんです。小さな期間で繰り返します。だいたい2週間の単位が多いですね。これはスクラムでも提唱されています。その方法だと、やるべきことや向かうゴールが明確になって、振り返ることでミスや気づきを次のサイクルに活かしたり軌道修正したりできるので、良い結果を生みやすいんです。日本ではまだまだ“ウォーターフォール”型が多い、とおっしゃいましたよね。日本ではまだまだ“ウォーターフォール”ばかり。海外では、どんどん“アジャイル”型が増えていて、アメリカ西海岸ではかなりスタンダードになっていますよ。“アジャイル型”、スクラムは時代のスピード感にあっているということなんでしょうか。うーん、僕から見ると、「逆に事業計画が大丈夫なんですか?」という。今の時代、1年の間に内部外部の環境はどんどん変わるし、競合が出てきたとか想定できないことが出てきたときに立ち戻れないと、差別化した製品は作れないんじゃないかなと思ってます。そんな、企業の思惑と現場のギャップが出て来ていて、今進化の途中って感じだと思います。“アジャイル開発”がメジャーなアメリカ西海岸では、アジャイルコーチっていう人たちがいて、彼らは経営管理についても踏み込んでいるように思います。経営者に、予算計画や経営計画も提案するんですよ。確かに“ウォーターフォール型”に比べて忙しいかもしれないですが、それよりもエンジニアにとって、「役に立ちたいところに役に立っている!」実感が得られること、スクラムのメリットって、これがすごく大きいんじゃないかと思いますね。“ウォーターフォール型”は、プロジェクトの途中、何のために作っているのかが、わからなくなって来る時があるんですね。この開発、絶対違うだろ、絶対こっちの方が将来的にニーズがあるのに。エンジニアは、とにかくいいもの作って、ユーザーに「使ってよかった!」と思ってもらいたいからね。確かにスクラムでは、究極マネージャーは不要で。過渡期は大変ですが、チームで目標立てたり達成していけば大丈夫なんです。受け身なエンジニアが多いと、マネージャー不在の不安が出て来ることもありますけど。実質的にプロジェクトがスクラムで回ってくると、チームが自分たちで判断してどんどん進むので、マネージャーの役割がなくなって来るんですね。“アジャイル開発”は、チームを育成しながら進めるので、メンバーは変わらず行くのが理想ですね。スクラムって、プロジェクトマネジメントというよりは、チームマネジメントなんです。“ウォーターフォール型”だと、ビジネスオーナーも受注側も、プロジェクトさえ進めば良いとか期日どおりの納品があれば良い、みたいな感じがあるんですけど、アジャイルは違う。小さな単位でみんながコミットするというか。コミュニケーション、ゴールの共有、信頼関係などがとっても重要になってきます。その点、mofmofはすごくうまくやっていますよね。今mofmofで一緒に働いてるエンジニアは、みんなそうやって短いサイクルでコミュニケーションをとりながら、効率的にプロジェクトを進めて成果を出してます。僕がエンジニアで彼らの気持ちがよくわかるというのもあるし、採用と社風がうまくマッチしていると、プロジェクト進行もうまくいくんじゃないかと思ったりもします。アジャイル、スクラム、っていう新しい開発の進め方は、エンジニアによって向き不向きがあるかもしれないけど、要は慣れなんじゃないかなと思います。「楽しく」「いいものを作れる」方がいいですよね。スクラムを導入すると、最初は全然喋らなかった人も、少し喋った意見がプロジェクトに取り入れられたりすると、そのあとどんどんジョインするようになって来るんです。スクラムでは、気づきを付箋に書いて意見交換、みたいなワークショップを行うんですが、2週間に一度、繰り返して行くことでこういったことにも慣れてコミュニケーション方法も上手くなっていくと思います。お二人がスクラムに出会ったきっかけを教えてください。僕がスクラムに出会ったのは、まさにこちらの“スクラムおじさん”石井さんに出会ってから。フリーランスの時、古い開発手法で、受注して作った結果「喜んでもらえない」壁に悩んでいたんですが、そこで「アジャイルソフトウェア開発宣言」に出会いました。その内容に“おお!”と。アジャイルでの開発を実現したくてしっかり学び始めて、試行錯誤をしながら会得してきました。アジャイルって、テクニックだけでやろうとすると失敗するんです。短期間でただ開発作業を回せばいいってわけじゃないんですね。チームで達成すべき目標は何か?を常に考えないといけない。本質を考えず、テクニックと作業だけ繰り返しても、失敗するんです。アジャイルを実践してそんな失敗をしながら頑張っていると、何個か成功することも出て来たり。こんな試行錯誤をしている人たち、きっといるだろうと思ってアジャイル初心者を集めて情報交換をしようと「アジャイルひよこクラブ」というコミュニティを立ち上げました。2回目くらいから石井さんが参加して、スクラムの考え方が入ってきたんだよね。僕は、以前はコンサル会社でエンジニアをやっていました。ここではもちろん“ウォーターフォール”で、疑問をずっと感じてたんですね。アジャイルというキーワードを知って、これはやってみたい!と思ってました。この会社で新規サービスを開発するときに、アジャイルをチャレンジしたことがあるんだけど、お客さんが求める見積もり・発注サイクル(お客さん的には数ヶ月以上がやりやすい)が合わず、断念。アジャイルがやりたくて、新規事業がメインのベンチャーに転職。ここでもチャレンジとともに失敗がありまして。原因として、1つ目はこちらの経験不足がありました。情報を学びながら見よう見まねでやると失敗しちゃうんですね。2つ目は、今まで隠されていた課題がアジャイル開発のスタイルだと、出て来るんです。チームや個人の生産性、やるべき課題、目標の間違いなどが全部見える化されてしまうと、色々都合の悪いことも出て来る。本当はいいことなんですけどね。「アジャイルサムライ」「スクラムブートキャンプ」という本を書いた西村直人さんに出会います。スクラムマスターっていう資格があることも教えていただき、自腹で参加しました。その研修で出会った、スクラムを作った一人、ジム・コプリエンというデンマーク人の講演は熱量がすごかった!「この中にPMはいるのか、お前は一体なにをマネジメントしていると思っているのか?」と。それまで抱いていたマネジメントの考え方、チームに対しての見方がぶっ壊されました。そんな、フリーランス活動をしている中で、「アジャイルひよこクラブ」原田さんに出会いました。スクラムでは、3つの役割があります。3、スクラムマスター。スクラムマスターは、1と2の調停者、サポート、同じ方向を向かせて、みんなが働きやすくして行く役割を担います。スクラムマスターが使うツールはいくつかあって、「スクラムガイド」がわかりやすいです。手法は、バックログというやりたいことリストを作成、やりたい順に優先順位をつけ、見積もりをする。次の2週間でできることを目印つける。ポイントになるのは、前もってプロダクトのバックログが整理されていれば、そのあとの流れがスムーズになりますね。重要なのが、チームメンバーの意識合わせ。デイリースクラムっていう、朝15分くらいのミーティングは効果的です。今日のやること、昨日のこと、今困っていることなどを共有します。2週間開発したあとの振り返りも重要。振り返り&お披露目会、が主流になって来ていますね。体系化して経営を巻き込めればいいなと思っています。今、組織の運営や新製品のマーケティングを行うチームにいますが、そこではバックログをやり始めました。開発だけではなくて、リアルのマーケティング、このイベントに出展する、とかそういったプロジェクトに対してもスクラム的な要素が役に立っているんですね。最初はでてこないんだけど、スクラムマスターとしては、それを出せるようにするっていうコミュニケーション力が求められるよね。言いづらいことを言ったときに、気まずい雰囲気にしない、とかね。わかっていることもあえて質問する、っていうのも意外と大事だったり。エンジニアはこだわりのある人が多かったりするから、メンバーによっては軌道に乗せるのは大変かもしれない。うちはそんな場面はあんまりないけど。お客さんとか他の部署も一緒にチームだから、いきなり“スクラム”とか“アジャイル”とか言わないようにしてる。エンジニア用語でしょ、と他人事になってしまうと、進まないので彼らにも馴染みのある「PDCAを回す手法」「改善する手法」って言ってるかな。確かに、相手が押し付けられてる感じがしちゃうとだめだよね。そのあたりの言葉を使うと、まさか「PDCAしたくない」なんていうわけないし、受け入れられるかも。国内の異業種だけではなくて、オランダの学校では、スクラムを教育に取り入れている事例もありますよ。理科の実験のクラスか何かだったと思うんですが、先生がゴールだけ与えて、タスクやスケジュール、そのためのチームビルディングを生徒が考えて実行する。大学の授業でも、スクラムを取り入れるとコミュニケーションがきちんと取れているチームは成績がいいらしいです。楽しくコミュニケーションをとりながら進めて、チームワークが良くなることで結果が出せるんですね。スクラムの話をしていて思い出しましたが、「パターン」っていうものもあるんです。いろんな製品、業界における開発で起こった事例をパターンとしてまとめている人たちがいて。いろんなところでうまく言っていること、トラブルなどをまとめていて、これもすごく面白いんです。来年この勉強会も立ち上げたいと思ってます。募集要項Wantedlyコラムお問い合わせmofmofブログ。