クラウドワークスCIOの大場です。
この記事はクラウドワークス コーポレートDiv アドベントカレンダーの23日目の記事です。

先日３歳の娘が、１ヶ月の練習で長いセリフのある劇や、前列と後列で動きの違うダンスと歌をクリスマス会で披露してくれました。感動です。２歳のときとは見違えるようで自然知能ってすごい！

スクラムとは

という説明はこういったところをよく見る人には不要でしょう。開発チームが同じゴールに向かって一体となって働くための方法論です。クラウドワークスの開発チームでも、関係する部門が多く位置づけが曖昧になりやすいチームを例にしてスクラムでいい感じにドライブしていくために取り組んだことをまとめた大浦さんの記事があります。

先日もアジャイル労働が話題になったり近年、システム開発の分野でここ10年ぐらい取り組んできたことが、ITの普及やITそのものがビジネスに直結するようになってきたことを背景に、他の分野にも応用されるようになってきたように思います。

個人的には、複雑で大規模かつ形のないソフトウェアという構造物を一人ではなくチームで制作するという困難に立ち向かうために培われた方法論の数々は、何かを成し遂げるために本当に必要なことが理論だって体系化されており精度が高く、ひとつのビジョンに向かって仕事するために役に立つプラクティスが多くあると感じています。

Facebook社など海外では非IT部門であってもコンピュータ・サイエンスのバックグラウンドが求められるようになっています。スクラムはシステム開発の方法論でありその他の業務には適用できないのではないかという声も社内では聞かれるなか、およそシステム開発とは縁がなさそうな総務や法務のチームに応用している話をします。

タスクの見える化

チームの中で誰が何をやっているかを知らないと協調して働くことができません。まずは各自が何のために何をやっているかを見える化するところからはじめました。Trelloを使ったり、Redmineを使ったり、付箋を使ったりと、道具の変遷はありますが大事なのは日々アップデートし続けることです。今は後述の計画と合わせてチームの状態を計測しやすいようにSpreadsheetにためたバックログと付箋の合せ技に落ち着いています。

計画

週次でその週に取り組むタスクを計画します。「アジャイルな見積もりと計画づくり」にあるように計画そのものより計画づくりを重視して、皆で計画を立て仕事を自分ごと化するのに活用しています。タスクの負荷について相対的なポイントをつけて見積もり、その週の業務負荷を可視化できるようにします。またタスクの担当もここで明確にします。

定常業務と将来のためにやる業務を分けて優先度をつけ、日々降ってくる仕事に押しつぶされないようにコントロールして大きな成果を出せる仕事に集中するという相反することを実現するために計画が大事だと考えています。

バックログとバーンダウン

タスクを見つけたらリストに記録します。これリストをバックログと言ってチームで共有します。

タスクを共有して進捗を追っていてもなかなか負荷が見えてこなかったりします。見積もりで割り当てたポイントを理想的にこなしていってるのかをバーンダウンチャートにして可視化します。

チームにどれだけの仕事を処理できるスループットがあるのかを実績を積み重ねて経験値として出せるようにします。その週の負荷によって中長期のためタスクを多めにふったり、リモートワークをして移動時間を減らし集中する時間を多く確保したり自分の働き方と出すべき成果をチームでコントロールしています。

計画と週の実際の仕事を繰り返すことで見積もりの精度が高まり仕事の質もあがっていきます。以下は差し込み業務があっても完璧にバーンダウンした先週の法務チームのチャートです。

朝会

司会をローテーションで回し「１．昨日やったこと」「２．今日やること」「３．課題」をひとりづつ話してもらいます。簡単に見えますが、はじめたころは朝会をしっかり機能するように実施するのがなかなか難しく「課題は特にありません」が繰り返されがちでした。実はこれは、小さな問題を見過ごしてしまったり、課題を課題として捉えられていない状態でした。

それまでは日々降ってくるタスクをこなすことに強くフォーカスしていたため、課題を考えること、問題を見つけ出すこと自体に慣れていなかったのです。そこで必ず１つは課題をだすことにして何気ない物事を課題として捉え直す練習をしました。回を重ねる毎に課題の精度があがっていき後々大きな問題になりそうな課題の早期発見やそもそも何故やるのかといった根源的な疑問からの見直しのきっかけになって行きました。今は朝会が盛り上がってしまい長くなりがちなのが悩みです。そのほか夕会もやってます。

振り返り

計画で決めたタスクについて振り返りその週に対応できたものできなかったものについて振り返ります。翌週の計画に回すタスクも簡単に洗います。加えて、KPTを出す振り返りを実施しています。Keep(良かったこと、続けたいこと)、Problem(課題)、Try(改善のためのアクション)をひとりづつ付箋で出してグループ化して改善策を考えます。計画してもなかなか計画どおり進まず、割り込みが多い中、計画の精度をあげていくために週次で行っていた振り返りを週２回実施にするように工夫しています。

自分たちで考えて動くために

スクラムなどの知見が先行して広まっている技術者界隈では、本当に作る意味があるかからゼロベースで検討して...ということには慣れている人も多いと思います。開発部門でない人たちは、直接的にものを作る仕事ではないし、ましてや間接部門であれば、降ってくる仕事にとらわれてしまいがちです。間接部門の仕事は定型的で見直しの余地が少ないというイメージがあるかもしれませんが、本当にやるべきなのかゼロベースで見直したり、システム化によってその業務自体を無くすことができないか挑戦したり、実際のところ創意工夫の余地が隠されている業務も多かったりします。そのような答えのない中で答えを探しビジョンに向かって改善の一歩を踏み出せるようにするのがシステム開発で確立された方法論です。

スクラムには他にも様々なプラクティスがあります。今の自分たちの仕事を短いサイクルで振り返ることで、良いところ伸ばし足りないところを補完できるプラクティスを応用したり自分たちに必要な改善を継続していこうと思います。目まぐるしく変化するベンチャーの働き方の中で変化する状況に合わせて自分たちも変化して成果を出せるようにしていきたいです。

このように、システム開発の良いやり方があれば開発部門以外にも応用していく、チームワーク重視のクラウドワークスは、エンジニアを含めて様々な職種を募集しています。