1
/
5
This page is intended for users in Hong Kong(Chinese (Traditional)). Go to the page for users in United States.

エンジニアリングプロセスとデザインプロセスを相互にリンクさせたOKANのスクラム開発

こんにちは。OKAN CTOの川口です。

OKANではスクラム開発を取り入れて開発を行っています。よくあるなんちゃってスクラムではなく、結構真面目に取り組んでおりまして、日々進化しながら進んでいます。
そんなOKANの開発チームの様子、主にチーム内での役割りについて紹介したいと思います。

スクラム開発を取り入れている目的としては、生産性を向上させるというビジネス的な側面もありますが、チームと個人の視点から見た場合、仕事に対する満足度や幸福度を上げることによって成果を最大化していくこと。
そして、エンジニアのみんながフロー状態 (ゾーンに入っているとか表現されますが、仕事にのめり込んで集中できる状態) で働けるような環境ができるといいな、と思っています。

開発チームの役割り

開発チームでは、エンジニアチーム・デザインチーム・スクラムマスター・プロダクトオーナーの四つの役割にわけて開発をしています。


チームで課題に立ち向かうエンジニアチーム

エンジニアの責任範囲は、プロダクトをリリースすること、そしてリリースしたプロダクトが正常に稼働してユーザーに価値提供が行われることを保証していくことです。具体的な活動としては、技術仕様の策定、コーディングやデバック、テストを行って品質を保証すること、インフラの設計や構築、監視・運用などが含まれます。

これらの役割りを効果的に実行していくためにスクラム開発を取り入れています。スクラムでは固定の期間を設定して、それをスプリントと言うのですが、そのスプリントを繰り返して開発をしていくルールになっています。OKANではスプリントを2週間ごとに繰り返すことにしています。

スプリントの最初は、プランニングから。
プロダクトオーナーが作成したプロダクトバックログを元にエンジニアチームでスプリントの計画を自分達で立てていきます。管理者的な役割り、いわゆるリーダーのようなポジションは敢えて置いていません。指示待ちになるのではなく、メンバーひとりひとりがリーダーシップを持って計画を進めていきます。

何回かスプリントを実施して経験を積んだチームは、「計画をきちんと立てること」の重要性を知っています。何度も失敗した結果なんですけどね。
計画がどのくらいきちんと立てられるかで、スプリントの成否が決まってくると言っても過言ではありません。実際は計画を立てるのはすごく大変で、苦労しながらやっているのだけれど、やったらやっただけスプリントの成功確率が上がることがわかっているので、みんな真剣にやってます。
最近はスプリントバックログの分割の仕方や、見積もりの精度が上がってきて、プランニングのレベルが上がってきた。その結果、スプリントを成功することが多くなってきました。

タスクの分担をする時には、得意なところ、できるところばかりやるのではありません。苦手なところ、今後伸ばしたい未経験技術なども適度に織り交ぜながらチャレンジしていって、個人としてもチームとしても力がつけられるようになっていきます。先日、Rubyをメインにしていたエンジニアに、マイクロサービス化とNodeの話をして、この部分を切り出していきたいという話をしたら、とってもやりたそうな顔をしていたので、ぜひチャレンジしてほしいなと思っています。

開発のフェーズに入ると、日々デイリーミーティングで状況確認。問題点があった場合はチーム一丸となって解決していきます。
チームのメンバーには、自分のタスクという概念はありません。他の人が処理しているタスクでも問題があれば、チームとして解決していきます。自分のタスクが終わったら仕事は終わりという意識ではなく、チームの目標を達成して初めてスプリントのタスクが終わるといった気持ちで取り組みます。

スプリントの最後にはレトロスペクティブというふりかえりミーティングを行います。
ふりかえりとしてよく出てくるのが、「仕様が曖昧だった」「調査が不十分だった」「想定外のことが発生した」あたりでしょうか。ここで発見された課題については、なぜそれが発生したのかということをとことん本質的な原因まで落とし込みます。
そして、次からは気をつけましょうという精神論では終わらせない。かならず実行できるレベルの具体的なアクションまで考えて、次回以降のスプリントで実践していくということをしています。

前述した3つのふりかえりの例ですが、いずれもスプリント開始前あるいはプランニング時点での準備がしっかりとできていないことに起因するものです。最近、「想定外のことが発生しました」という発言をあまり聞かなくなってきたような気がします。気のせいでしょうか、、、チームが成長しているものと思いたいですが。。。

今の所まだ僕の出番(後述のスクラムマスター)がありますが、いずれ自分たちで全て進められるようになったら、僕の出番が無くなる日がくることでしょう。

プロダクト全体をデザインするデザインチーム

OKANのデザインチームのデザイナーは、単なるデザイナーではありません。グラフィックデザインやUXデザインだけではなく、プロダクト全体を考えてデザインを作っていきます。プロダクトデザイナーと呼んだ方が正しいかな。チームとしても実質的には仕様開発チームといった方が実態と一致しているかもしれません。

役割としては、エンジニアチームがスプリントを開始するために必要なものを一通りそろえることです。エンジニアチームと同じように、デザインチームでも2週間の単位でスプリント実施しています。

エンジニアチームのスプリントが開始できるようにするために必要なものとしては、仕様書が作成されていること。仕様書を作成するための前段の作業として、ユーザー調査、統計情報の作成と分析、類似のシステムの調査、ワイヤフレームの作成、ビジュアルデザインの作成などを行います。加えて、画像やアイコンなどのデザインパーツとHTML/CSSなどを作成してエンジニアチームに渡して行きます。

デザインチームと言いましたが、現在のOKANでは、開発チームごとに1名のUX/UIデザイナーがいるだけなのでチームとは言い難いところ。前述した作業を実質一人でこなしていくというマルチスキルが必要になっています。プロダクトの規模が大きくなれば、複数のUX/UIデザイナに参加してもらって、チーム体制をとり、役割をもっと細分化していくこともあるかと思うますが、今のところそこまで大きいわけではないので、プロダクトオーナーと一緒に仕様作成の仕事をやっています。

見守るスクラムマスター

スクラムマスターはCTO川口が自らやっております。本当は専任のスクラムマスターにお願いしたいのですが、いかんせんOKANの開発チームは発展途上、急成長中ではありますが人材が不足しております。どなたか、ぜひ我こそはという方、、、がいると助かります(心の声)。

スクラムマスターの役割りというと、「世界最高のチームを作る」といったことがよく言われます。
もちろんそれはそれで目指していきますが、当面の目標はスクラム開発における基本的なルーチンがしっかり機能するようにすること。それによってエンジニアの時間が本来やるべきことに使えるようになって、ガンガン開発ができるようしていくことに注力しています。

ビジョンを示すプロダクトオーナー

プロダクトオーナーはプロダクトのビジョンとマーケットに対するROI(投資対効果)について責任をもっています。プロダクトのビジョンを示していくには、お客様のこと、市場のこと、競合製品のことなどなど、大変たくさんのことを頭に入れて考えていかなければなりません。また、リリースしたプロダクトが市場に受け入れられるのか、何を改善していくのかなどを責任を持って取り組んでいきます。

もちろんプロダクトオーナーが全てを考えるのではなく、エンジニアチームやデザインチーム、セールス・マーケティンググループやカスタマーサクセスグループなどと議論して意見を取り込みつつ、それぞれのチームとビジョンの認識をあわせながら進めていきます。常に全体を考慮しながら進めていかなければならない、というとっても厄介な仕事です。

エンジニアと会話する場合は、技術的な会話になりますので、一定の技術的なスキルが必要になってきますし、デザイナーと会話をする場合は、UX/UXデザインに関するスキルも必要になってきます。
ときおり、技術的な課題があったときにエンジニアから提案された案に対して判断に迷ったときなんかに、CTOのところに泣きながら相談に来たりします(冗談です)。

そのほかには、各種ステークホルダーとの報告や交渉などを担当します。社内の関係者への説明は当然ですが、学術的な課題がある場合には大学の研究者とやりとりをして方向性を示していくことや、特許関連の手続きなんかを弁理士さんと進めていったりというように、活動範囲は多岐にわたっています。
簡単に言うと、エンジニアとデザイナがやらない仕事はみんなプロダクトオーナーがやっていることになりますね。

とても広範囲をカバーする役割なので、プロダクトオーナーというのはとっても難易度が高い役割となっています。

そして進化する開発チーム

今回はスクラム開発を取り入れたOKANの開発チームについて書かせていただきました。

一般的なスクラム開発の解説では、スクラムのフレームワークに関する解説は説明されているものの、具体的なデザインプロセスやエンジニアリングプロセスをどのようにしていくのかは、個別に決めていくこととされています。

OKANでは、デザインプロセスもスクラム開発を行うことによって、仕様書を作成するというゴールを目指します。同じようにエンジニアリングプロセスでも、プロダクトをリリースするというゴールを目指してスクラム開発を実施します。この二つのプロセスがうまく噛み合って機能することによって、ユーザーに継続的かつスピーディーに価値提供をしていくことを可能にしています。さらに、デザインチームとエンジニアチームが自律的に回ることによって、プロダクトオーナーはマーケットとプロダクトのロードマップに集中することができます。こうやって、プロダクトの未来を生み出していくことが相乗的に可能となっていくのです。

スクラム開発を取り入れてまだ半年弱なので、まだまだ進化の途上ではありますが、日に日にできることが増え、質も上がってきているなと実感しています。

OKANでは、こんな環境で働きたいと思っている仲間を募集しています。チームとともに自分を成長させていきたいエンジニアの皆さん、ぜひ気軽にお問い合わせください!

株式会社OKAN的招募
15 Likes
15 Likes

本週排名

展示其他排名