プロジェクトの掛け持ち禁止！ 『OHAKO』流のスクラム実践法とは？

---

［記事ハイライト］
・「マルチタスクは悪である」
・全てはユーザーファーストのために
・「スプリント」を1週間に設定。プロジェクト全体をスクラムに
・活用ツールは？... craft、GitHub、Backlog、Sketch
・「無駄な経営リソースをさかない」というマインドの醸成
・スクラムを導入することで得られたメリットとは？

「マルチタスクは悪である」

UI・UXデザインカンパニーである『OHAKO（オハコ）』。彼らがユニークなのは、すべてのプロジェクトを「スクラム」でプロジェクトを進める点だ。

「スクラム」はソフトウェア開発で知られているプロジェクトマネジメントの手法。日本においてもさまざまなWebサービス・ソフトウェアの開発現場で導入されてきた。

その起源はアジャイル開発にあり、概念の根幹は下記の部分。

今回取材したUI/UXデザインカンパニー『OHAKO』は、この「スクラム」をあらゆるプロジェクトに展開。デザイナー（11名）、エンジニア（7名）、PM（5名）はもちろん、バックオフィスメンバーも概念・進め方を理解し、取り入れているという（一部事務職を除く）。

スクラムには「マルチタスクを推奨しない」という考え方がある。ここに則り、デザイナー・エンジニアにおける「プロジェクトの掛け持ち」を基本的には禁止としている。

『OHAKO』CEO菊地涼太さん（23）は、その理由をこう語ってくれた。

「クライアントに対し、最大限の事業貢献をしていく。そのための方法がスクラムであり、プロジェクトの掛け持ちをしないという方針でした。1つずつのプロジェクトにメンバーがフルコミットするため、正直、目先の利益はあまり上がりません。ただ、中長期的に見ると、後々の大きな仕事につながっています」

一体なぜ彼らはこういったやり方に行き着いたのか？
実際にどのようなツールを用いて、なにを実践しているのか？
導入したことで得られたメリットとは？

彼らのスクラム実践例から見えてきたのは、チームワークで成果を出す（プロジェクトを成功へと導く）ヒントだった。

---

＜プロフィール＞
菊地涼太 Ryota Kikuchi　／　デザイナー・認定スクラムプロダクトオーナー
1993年生まれ。高校時代よりWebデザインに触れ、事業会社でのWebデザインを経験。2012年に慶應義塾大学総合政策学部（SFC）入学後、同年12月に株式会社オハコ設立。サービスのUXデザインからUIデザインを軸に事業会社のサービススタートアップをサポート。2015年にはデザイン人財を増やすことを決め、直近2年で4名から25名を超える規模へと拡大中。

全てはユーザーファーストのために。

まず気になったのが、『OHAKO』がUI・UXデザインを強みとする会社でありながら、スクラムを取り入れているということ。菊地さんは、その理由をこう語る。

現在は「デザイン」に対する価値が高まっている時期だと捉えています。しかし、2、3年後も同じように、現在のデザイン単価が維持されているか、わからないですよね。「デザイン」のみが重視されるのではなく、再現性のあるユーザーファーストなプロダクト開発、そのプロセスにこそ価値があると考えています。デザイナーとエンジニア、PMが一体となり、柔軟に、プロジェクトを進め、成功の確度をあげていく。こういった観点から、スクラムが適していると思っています。

たとえば、急激なデザイントレンドや市場の変化をキャッチアップし、対応できるのが「スクラム」だという。プロダクト開発のスピードが加速している時代、たとえば、ウォーターフォール型では大幅な手戻りの発生リスクがある。具体的なストーリーでいえばこうだ。

デザイナーが多く時間を費やし、考えた複数のデザイン案。それをエンジニアにパス。いくつかの案を検討し、実装していく。その間に他社が同じようなプロダクトを先にリリース（デザイントレンドや市場環境も変化）。途中まで実装していたが、勝ち目がないと判断され、プロジェクトは仕切り直しに。デザイナーがせっかく作ったデザインもイチからやりなおし。その間にもさらに他社から別プロダクトが・・・。

一方、スクラムだと「エンジニアとデザイナーの橋渡し」という概念がなく、手戻りが発生することもほぼない。密なコミュニケーションがそれを補完する。

デザイナーとエンジニアは並行して、同じ「ユーザーストーリー」に着手。ただし、そのストーリーはクライアントの要望を満たすミニマルなものとする。少ない工数でつくり、クライアントに確認。世の中にローンチし、ユーザーからフィードバックを早く受けとる。さらに次のスプリントのプランニングしていく。

「スプリント」を1週間に設定。プロジェクト全体をスクラムに

スクラムにおける全体的な概要説明については、提唱者であるジェフ・サザーランド著『スクラム 仕事が4倍速くなる”世界標準”のチーム戦術』に譲るとして、ここでは『OHAKO』が実践していることを見ていこう。

まず、彼らはスクラムを組むチームを3～5名とする。そして「1週間」を「1」とする単位のスプリントで区切り、繰り返す。（事業推進関係のプロジェクトでは２週間でまわしている）

そこからは一般的なスクラムと同様に、スプリントを始める前には必ず「ユーザーストーリー」を立てる。開発するプロダクトを使用するユーザーは、どうアクションし、何を達成していくか可視化する。

注意点として、ユーザーストーリーは経験豊富なメンバーが書くということ。予想外にタスクが膨らまないように、実践・繰り返しから「ユーザーストーリー」の適切な粒度が見定められるメンバーが担当しているそうだ。

見せていただいた、ユーザーストーリーの１つ。
簡潔に内容が書かれている。

全ての「ユーザーストーリー」を洗い出したら、1回のスプリントでどのくらいプロジェクトを進められるか、どれくらい時間がかかるか。「ストーリーポイント」で見積もりを決めていく。

用いるのは「プランニングポーカー」というカード。全メンバーでポイントの書かれたカードを出し合い、「なぜ、そのポイントか」を口頭で補足。相対的にタスク規模を見積もっていく。

プランニングポーカーの実物。数値は、0~89のフィボナッチ数。
メンバー全員でこのポーカーを出し見積もりを出す。

スプリント内で行っていく「ユーザーストーリー」の優先度も、プランニングポーカーを使用する。最近だと専用のアプリがあり、それを使って行うこともあるそうだ。

このようにして決めた「ユーザーストーリー」の中から、

・ユーザーにとって価値が高く、コストが低いもの
・ユーザーにとって価値が高く、コストが高いもの

といった順番で、実際の作業へと移っていく。

その他、スプリント中は、毎日決まった時間に15分間で「デイリースタンドアップミーティング」を実施。話す内容は『スクラム 仕事が4倍速くなる”世界標準”のチーム戦術』に忠実だという。

活用ツールは？…craft、GitHub、Backlog、Sketch

次に、実際にどのようなツールを用いて『OHAKO』スクラムを実行しているのか、紹介していこう。

craft（ https://www.craft.io/ ）

craftは、海外で生まれたプロジェクトマネジメントツール。作ろうとしているサービスの概要、ユーザーストーリー、ロードマップを管理。「ストーリーポイント」「ユーザーに対する価値」の数値を入力し、活用している。

GitHub／zenhub

GitHubは開発のスプリントにて用いていく。メンバーはデザイナー、エンジニア、プロジェクトマネージャー。特にGitHubのエクステンション「zenhub」を活用し、開発のためのタスクをチームのメンバーと共有しながら、確認していく。

Backlog

事業企画・組織開発・ブランディング、各部門責任者メンバーとはBacklogを活用する。

Sketch

デザインツール。プロジェクトのファイルサイズがPhotoshopに比べて小さく使いやすいこともあり、『OHAKO』ではファイルをgitで管理する。

「無駄な経営リソースをさかない」というマインドの醸成

ここまで実践とツールを見てきたが、もちろんはじめから導入がうまくいったわけでなかったそうだ。デザイナーやエンジニア、プロジェクトマネージャー全員にスクラムの概念と手法を理解してもらう。その上で苦労した点について、菊地さんはこう語る。

１、２、３とスプリントの回数を重ね…つまり１ヶ月くらい経つまではカオスでしたね。やめたほうがいいじゃないかっていうくらい最初はうまくいきませんでした。こういうもんだから…とメンバーに説明し、本で勉強してもらって。ただ、振り返りを通し、プロセスを改善し、地道に辛抱強くつづけることで、ようやく形になっていったという感じです。

そもそもは組織全体で「どのプロジェクトで何が起こっているかメンバーと共有できていない」という課題があったという。そこで、「スクラムオブスクラム（スクラムを組んだチームのオーナーが集まり、さらにスクラムをする）」という概念を思い出し、まずは社長直下のチームから導入を進めたそうだ。

それは、採用や広報など、経営におけるプジェクトに関しても、本当に価値があるのか、どのようなインパクトをもたらすのか、プロダクト開発と同じようにスクラムによって「優先度」と「見積もり」を決めて進めるため。そうすることによって「無駄な経営リソースをさかない」というマインドも生まれていったという。

スクラムを導入することで得られたメリットとは？

取材の最後に伺えたのは、スクラムを導入して得られたメリットについて。

その１つに「共通認識」があげられる。プロジェクトの目標はもちろん、各ユーザーストーリーに対する見積もり、作業完了の定義について認識の齟齬が埋まる。そうすることで無駄がミーティングなどもなくなったという。

プロジェクトを進めていくにあたり、見積もりやタスクボリュームは無意識に大きくなりがち。「将来的に必要になりそうだから今やっておこう」というマインドは、誰しもが持ってしまうもの。なかには「いまは考慮しなくて良い」というタスクもある。こういった前提が職種をまたいだ時にも共有される。スクラムのプランニングは職種を横断し、コミュニケーションを取る機会を提供してくれるといえるだろう。

ただ、同時にすべての組織にスクラムがフィットするわけでもない。一体どういった組織に向いているのか。最後に、導入時に気をつけたいポイントと併せて伺うことができた。

これから組織をつくっていったり、新しいプロジェクトを立ち上げるということであれば、とても有効だと思います。初めはうまくいかないかもしれませんが、とにかく原則に従うことが大事。スクラムは「守破離」を大事にしていくもの。しっかりとロードマップを立てる、タスクを洗い出し、スプリントをプランニングする、デイリーミーティングで状況を把握する。これを1ヶ月続けてみると、変化が見られると思います。

文 ＝ まっさん