「働き方改革」という言葉が頻繁に語られるようになりましたが、社会が変わる実感はまだありません。
受託開発企業の多くの場所では、エンジニアの疲弊の言葉がまだまだ聞こえてきます。当サイトのキャッチフレーズも「デスマーチが、なぜなくならないのか」と言います。
そんな産業構造の中、WESEEKさんでは全従業員の1日あたりの平均労働時間が6時間20分だそうです。「超ホワイト企業」だと自信を持って語られる代表取締役の武井さんにその仕組みを教えていただこうと、オフィスに伺うお約束をいただきました。
武井さん プロフィール
WESEEK, Inc. の代表取締役。
自らもエンジニアで、担当レイヤーはプレゼンテーション層からサーバーレイヤーまで。UI作りもビジネスロジック実装も好きなジェネラリスト。
早稲田大学在学中の2006年に WESEEK,Inc. を起業して以来、仕事をすることに没頭してしおり、結局卒業することなく現在に至る。
仕事をしてて一番楽しいのは、チームマネジメントやワークフローマネジメントを通して改善が進んだ時。
B to BとB to Cのプロジェクトをバランス良く振り分けている
大井田：
本日はよろしくお願い致します。武井さんはお話が上手なのでたくさんお聞きできるのではないかな、と思ってます。まず、御社ではどのようなプロジェクトがあるのでしょう？ スクラムに向いていないものがあった場合は、スクラムを使わないということもありますか？
武井：
当社の仕事は、大きく分けてB to BとB to Cがあります。B to Bでお客さまがプロダクトオーナーの場合は、そこそこスクラムがうまく機能します。一方、B to C でも、自分たちで2週間のスプリントの中でこれだけのことをやるということを決めちゃいますから、うまくいかないということはほぼありません。スクラム開発がしんどかったというケースで思い浮かぶのは、過去のゲーム開発ですね。
我々がプロダクトオーナーではなく、4社合同プロジェクトで、意思決定もばらばらでした。この4社合同というところをBとすると、言わば B to B to Cでした。リリースの日時を決めたら、4社間での「ここまでにこれだけやる」という距離と時間が決まります。が、このケースでは、そのスプリントを定義することが難しかったですね。
大井田：
御社の場合、ストーリーポイントを算出する手段はどうされているのでしょう？
武井：
プランニングポーカーでやっていますね。今日自分がやる1タスクあたり何時間というミクロな計測ではなく、チーム全体で2週間のスプリントの中で何ポイント消化できたのかという点を指標にしています。なので、2週間で30ポイント消化できたから、次の2週間もいけるはずだ、とか。
大井田：
ということは、スプリントごとのミーティングが重要になってくると思うのですが、そこで工夫されていることはありますか？
武井：
これも B to B と B to C で分かれます。まずこのスプリントはこういう性格にするのだと明確に決めるプロダクトオーナーが必要です。初めて一緒に仕事をする会社さんですと、「3か月後までにここまで完成させて」ということだけ言えばよいと思っていらっしゃる場合も多く、そうしたクライアントさんには充分に説明をします。
プロダクトオーナーとして、2週間ごとで何を優先するのか、終わらないといけないものと終わらなくてもいいものの区別などを自分たちでマネジメントして決めていかないと、チームというのは動かないものである、ということを分かってもらうところからスタートするのです。
大井田：
その場合、プロダクトオーナーたるクライアントさんの技量によってしまうことにもなると思うのですが、それについて個別にレクチャーをすることはあるのですか？
武井：
あえてそういう時間を取って、ということはないです。最初はわからないので、スプリント番号でいうと、スプリント0、スプリント1はうまく回らないだろう、ということを伝えておきます。そして、スプリント終わりの節目節目で、「今回はこういう動き方をしていましたが、この点は我々としてはアリだと思っている」、あるいは、「この部分は我々の進め方では許容できない部分なので、それは変えてもらわないといけない」といった意思の統一を図っていくんです。
大井田：
それを繰り返していけば、最終的にはクライアントさんにもスクラム開発とは何たるかということが伝わるという結果になるというわけですね。
武井：
そうです。そこはクライアントさんの性格によるところで、「なるほどそういうものか」「それでやっていこう」「そっちのほうがいいよね」と納得いただけるクライアントさんの場合は継続してお仕事ができるのですが、そうでない場合は１契約３か月で終わってしまうこともあります。
なので、そういったやり方の違いや、自分たちが許容できる範囲のあぶり出しという意味でも、やり方をそろえていったり、お互いの性格があっているのかを見ていくということが重要なのかと思います。
大学でプロジェクトマネジメントを学んだのがきっかけだった
大井田：
そもそもスクラムで、あるいはアジャイルで開発を進めようと思ったきっかけは何ですか？
武井：
きっかけは、私自身が大学でプロジェクトマネジメントの授業をとっていたことです。その時は、ウォーターフォールを中心に学びましたが、自分でいろいろ調べていくとソフトウェア開発には対抗の手法であるアジャイルがあると知ったので、これを実践してみようと思いました。
大井田：
初めてアジャイルを実践した時と現在では、手法はブラッシュアップされているという感じですか？
武井：
最初、アジャイルを始めた時、スプリントの定義をすることはうまくいきました。アジャイルをやっていようがやっていまいが、いつまでに何をリリースするのかを決めるということはやっていたので、スプリントの定義もすんなりと入れました。が、タイムトラッキングがうまく続かず、時間で測ることをあきらめて、ストーリーポイントやプランニングポーカーを取り入れた頃から自分たちなりのアジャイルがカタチになってきたと思います。
大井田：
あきらめたというのは、時間見積もりが正確にいかないなどの課題があったからですか？
武井：
はい、正確性にも問題はあると思いますし、仮に正確に見積もれたとしても、それが個々人の評価やモチベーションに繋がるのかどうかという問題があると考えています。アジャイルの憲章にも謳われているように、我々のアジャイルの出発点は「全員が全力を出さなければならない状態を作り出す」ということでした。全力を出したという点で、できる社員は同じ仕事を1時間で終えて、できない社員はそれに4時間かかるとなったときに、この仕事を最初に1時間の仕事として見積もるのか、4時間の仕事として見積もるのか、は大事です。
仮に時間見積もりを採用し、プランニングポーカーによるチーム内の合意で4時間と見積もった仕事があったとします。あるエンジニアがこの仕事を1時間で終えた場合、それをどう評価するのかが難しいんですね。自分たちの見積もりが甘かったと考えるか、それともその社員の全力が素晴らしいものだと評価するのか。後者のように見なすのは一時的にモチベーションは上がるかもしれませんが、それで評価されるのであれば、チームには「多めに見積もる」という癖が付きます。それでは全力で見積もって全力で走るということになりません。
ですから、時間見積もりではその目的を満たせないと判断し、ストーリーポイントという相対値で見積もり、各エンジニアの能力もポイント消化スピードという相対値で評価するやり方に変えました。
アナログが心地よいものはデジタル化しないほうがいい
大井田：
なるほど。かなり具体的にお話をいただいていますが、では具体的なツールについて伺えますか？ Redmineでbacklogのプラグインを使用しているということでしたが。
武井：
ツールについてはあるものを使っていくというスタンスです。ツール選定の際に自分たちに合うものが見つからないなと思いながらRedmineにたどり着いた感じですね
大井田：
ソース管理はGitHubに任せている？
武井：
ソース管理はGitHubが多いですね。バージョン管理システムとしては、Git、Mercurial、SVNを使い分けています。issue管理としてはRedmineとYouTrackを使いながら、それぞれ連携させてやっています。
大井田：
連携というのは、手作業でURLを貼ってですか？
武井：
そうです。以前は自動化していた時期もあったのですが、自動化をやめてみても、それに戻らないといけないといったデメリットはなかったので。
ところで、開発要員で語ると、九州に1人リモートメンバーがいて、このオフィスに9人いるのですが、2人は出向しているという構成です。
大井田：
その規模ですと、複数のプロジェクトをまたがっているという方もいるのではないでしょうか？
武井：
ほぼ全員がそうです。
大井田：
またがったプロジェクトでの進捗管理などが錯綜することが予想されるのですが、それについてはどのような工夫をされていますか？
武井：
創業当初からマルチプロジェクトで働いていけなきゃいけない、としてきましたから、むしろそれは当たり前になってますね。
大井田：
では、人によっては、あるプロジェクトのマスターになって回し、ほかで1メンバーとしてやっているという場合もあるのですか？
武井：
そうですね。すごく偏っているケースですと、稼働時間の1割はこのプロジェクト、9割を別のプロジェクトということもあります。1割の部分は状況把握が充分にできないのですが、それはチーム内で良しとする。
大井田：
ということは、全体ミーティングが大事ですよね。週次で行なって各プロジェクトの全体把握をしているのでしょうか？
武井：
いえ、各プロジェクトの全体把握はやっていません。全プロジェクトの進行状況を共有するための1時間～1時間半程度のミーティングを週に一回やっています。
大井田：
では、毎日のスクラムのミーティングはどういうものなのでしょう？
武井：
全員でやってますね。AとBとCという3つのプロジェクトがあったとして、一人はAとBのプロジェクトに参加しているとします。その人はCプロジェクトの進行は聞かなくてもよいのですが、我々としては、それをきちんと聞いて、誰がどのタスクをやっているのかということを追いかけるようにしています。
大井田：
なるほど。社内管理ならそのほうが良いですからね。
武井：
自分が参加していないプロジェクトの進行を聞くというのが効率が悪いということはわかるのですが、それを上回るメリットがあるだろうということで、このようになりました。これは概ね15分で終わります。
大井田：
ところで、壁に貼られている付箋の集まりは？
武井：
KPT（Keep、Problem、Tryの略）ですね。マルチプロジェクトでやっているので、スプリントの切れ目を各プロジェクトで統一できません。なので、確実に2週間ごとに1回やるというルールで機械的に実施しているものです。KPTをやる上で社員に言っていることは、ProblemとTryの関係性です。放っておくと、ProblemにTry可能なことを書いてしまいます。Problemというのは問題提起をしたいことであって、「ここが問題だからこうしたいと思っている」ということは全部Tryに書くようにさせています。KPTを前向きなものにしたいですから。
KPTというのは、チームにとって前向きな力を生み出すものでなければならないと思っています。自分が付箋を貼って、それについて自分がどのように考えているのかということを話し、周りがそれを聞くという一連の動作を重視しているのでデジタル化はしません。また、Problemが個人攻撃になってしまうと後ろ向きなものになってしまうので、あくまでもそれは自分がProblemだと思っていることであり、ほかの人がどう思っているのかというのは関係なく、聞く側も突っ込みを入れて反論するのではなく、まずは聞くということを重視させています。
言論統制じゃないですが、KPTが一番、こういうことは言ってもよい、こういうことは言ってはいけませんということを限定している会議ですね。すべて前向きにしなければならない。その代り、ほかのミーティングでは何でも言ってもよいですし、何でも言えるチームでなければならないと思っています。でも、この時間だけはお互いを認め合う時間にしています。
KPTの後には、感謝を表明するゲームをやっているんですよ。今週ぬいぐるみを持っていた人は、この2週間でお世話になった人に個人的に感謝していることでもなんでも、みんなの前で話してぬいぐるみを渡し、それをみんなで拍手して歓迎する。ここまで含めてKPTという形でやっています。
九州にいるリモートメンバーもただSlackに書くだけではなくて、実際に付箋に書いて、それを写真にとってSlackにあげるという、デジタルなんだけれどもアナログだという……。こういう儀式めいたことをやっていますね。
大井田：
KPTのミーティングにはどれくらいの時間がかかるのですか？
武井：
1時間くらいです。
KPT自体はかなり以前からやっています。かつて、忙しい時期に4週間もの間があいた時がありました。その時に、KPTをした後で、これは絶対に2週間おきにやらないといけないということを実感しました。普段から言えるようにしましょうという空気を作っているはずなのですが、どうしても言えないことが溜まっていきます。その溜まった「言えないこと」を、あえて言論統制された、前向きに考える時間であると定義された場で言うことで、普段言うと「何あいつは生意気を言っているんだ」と思われがちなことでも、「前向きに話をしようとしているんだ」とみんなが感じるんですね。なので、後ろ向きなことを言っているのにもかかわらず毒が抜けることがあります。
大井田：
それぞれの方が手書きしているのですよね。書記がいるわけではなく。ミーティングの時に書いて貼っていくというスタイルなのですか？
武井：
毎回2時から始めるので、開始までにみんなに書いてもらいます。そして、「あなたのKeepからどうぞ」がスタートですね。
毎回のKPTで、最初に前回のKとPは取って捨てます。Tryは右下に行って、その状態で2時までに書いて新しいものを貼ってもらいます。「そういえば2週間前にこう言っていたけど、結局できなかったな」とか「これは良くできたな」といったことを見ながら書いています。
大井田：
アナログでやることの一番のメリットはどのようなことだと感じていますか？
武井：
貼ってしゃべる時に、みんなの前に立つので、その人のほうを向くということがあります。スクラムミーティングの時は全員参加なのですが、みんな自分のパソコンを見ながらやっているんですね。
大井田：
チームでの仕事となると、それぞれのメンバーの力量や性格をマネージすることが重要になると思っているのですが、ああいった形で対面で、アナログ的なアクションをもって人の理解をするというプロセスは非常に有用だと合点がいきました。そのうえで、それぞれ違った力量・個性のある御社のメンバーをチームとしてまとめていくために取り組んでいることや、工夫していることをお聞きしたいです。
武井：
KPTを書くときのルールとして、自分ひとりのものにしないというものがあります。例えば、Tryに行動を書くときに、「その場しのぎのコードを書かない」ということを思っていたプログラマがいたとします。それ自体は誰が聞いてもよいことだと思うのですが、それを「自分が2週間でやります」としない。
自分が書くときには、自分ができているのかできていないのかというのは棚に上げて、それをチーム全体でやるTryだということなんですね。KPTで出てくるものは、チームがKeepできたこと、チームの中で自分がProblemだと感じていること、チームでやるTry、としています。例えば、自分はTryにしたがほかの人は興味ないと思っているということもでてきますが、それを貼った人がチームでやると決めたわけなので、自分で率先してこれをやり、それをチームに広めていけばいいんです。
KPTの場ではそれがルールです。日常でも「それはチームのためになっているか」ということはでてきます。が、自分の行動がチームのためになっているのかということは、なかなか実感することが難しいものです。それをあの手この手で、KPTを自分とチームの関係を推し測る場に仕向けています。いろいろなところで、「あなたはチームの一員であって、一人で動いているわけではない」ということを理解させるための工夫を、大きいルールから細かいルールまで、いろいろなところで差し込んでいるのですね。
「超ホワイト」のわけは、「仕事とは楽しいものであるべきだから」
大井田：
クライアントさんとの関係で悩まれたり、開発体制を見直すというケースはあるのでしょうか？
武井：
お仕事の需給関係に依るのではないでしょうか。ベストなのは、自分たちが気持ちよく仕事ができて、自分たちが欲しい技術を身に着けることができ、その仕事をやっているだけで幸せになれるということ。理想としてはそれに近づけたいと思っています。でも、その理想とは違った場合、どこまで許容して関係を継続していくのかという閾値がどこにあるのかというこのなのかな。
話を少し変えますが、ソフトウェア開発をやっている他社さんから炎上しないでやっていく方法をよく聞かれます。ソフトウェア開発は炎上するものだと思っている会社もあります。その人たちは、これをこの2週間で絶対にやらなければいけないと言って、プログラマにやらせます。が、そういうことをやっていると普通に8時間、9時間働くプログラマが出てきますよね。当社は、ソフトウェア開発をやっているのにもかかわらず、全員6時間20分くらいしか働いていません。
その違いが何なのかを考えた時に、プロダクトオーナーとどれだけ意思疎通が取れていて、どこまでやってどこからはやらないのかということのコンセンサスが明確に取れているかどうかだと思っています。「ここから先はこの2週間ではやりません」と最初に言っておいて、そのスプリントで合意が取れていれば、できていなくても追及されません。
大井田：
良いクライアントさんなのだと思います。スクラム開発を許可する受託案件は比率が少ないので。ウォーターフォールだとどうしても長時間労働の問題が出てきてしまって、それが当たり前に慣習になってしまっているというのは業界全体の問題なのですよね。スクラムの常識をいかに説明するのか、理解させるのかというハードルは現状まだあります。すごいうらやましいクライアントさんだと思います。
ところで、いままさにお話しいただいたのですが、超ホワイトだと。現状、フレックスで裁量労働制なのですね？ この話は勤怠管理なので、プロジェクト管理とは異なるのですが、勤怠はどのように行なっているのですか？ 時間管理はされていないのですか？
武井：
来た時間と帰った時間は打刻しています。ただ、それが評価を大きく左右したり、給料に影響を与えたりということはないです。残業をしてもしなくてもよいが、残業する人はそうしようと自分の意思でやるということは最初に確認しています。
大井田：
御社は20代の方がほとんどですね。
武井：
30前後ぐらいが多いですね。ぼくが最年長で33歳なので。33歳、32歳が4人くらい。若手で言うと、26歳、27歳。
大井田：
それでは、一番若い方でも開発を始めて5年くらいは経っているということですね。とすると、実際に開発にあたる際に経験が浅くて問題になるということは、現状のメンバーではないということですか？
武井：
中途で採用する場合はありますね。それでも、スキルがなかったとしても、先に文化になじんでしまいさえすれば、スキルは後からついてくると思っています。
大井田：
御社の文化で一番大切にしているのは何ですか？
武井：
一番というと難しいのですが、SEとして自分が日々やる仕事を楽しめるかどうかはとても重要視したいと思っています。「楽しいと思えることを探してきてやれ」と言っています。好きこそものの上手なれみたいなところがあると思うので、好きなものは伸びて、伸びた結果、あなたのためにも、チームのためにもなるというように思っています。
いかに好きなものを見つけるのか、と。与えられる仕事の中にも楽しくないものはあるはずなので、その時にどうしたら楽しい仕事にできるのかということを考えさせますし、それを可能にする自由度や裁量を与えるようにしています。
大井田：
では、改めてこのようなツールがあったら使いたいといったツールはありますか？
武井：
1年くらい前はPukiwikiを使っていたのですが、いかんせん古いシステムでしたので、Markdownで書ける今風な素敵なWikiがあったら良いという話をしていました。そちらは結局Crowiというシステムをフォークしてきて、自分たちでcrowi-plusという派生版を作り、今では社外にも公開しています。現状ですと、やっぱり、YouTrackとRedmineぐらいですね。チャットも昔は苦戦していたのですが、Slackが出てきて解消したので。ここ1年、2年で足りないと思っていたところがバラバラに保管されていったという感覚があります。あと、GitHubで、GitとMercurialとSubversionが全部使えたら良いなとは思っています。
RedmineとYouTrackの自分たちが良いと思っている部分を一度に満たすツールがあったらそれで満足ですね。
少し細くすると、GitHubのプロジェクトツールのカンバンとRedmineの看板で大きな違いがあります。ストーリーという単位で管理したいのですよね。GitHubの場合は、四角一個を移動させるだけで、この四角四つで、このストーリー終わり、という行の単位はない。その行の単位がないと当社のプロジェクト管理上は物足りないというか、管理しきれないというのがあって、そこは必須だと思っています。
あるスプリントの進捗をクライアントさんにもわかってもらうようにするためには、Redmine上のプロダクトバックログの中で、グルーピングされたタスクが見えるということが重要だと思っています。ここを重視しないと炎上すると思っているんですね。乱暴な話かもしれないのですが、うちの感覚では、RedmineとYouTrack以外のタスクを行で見られないツールを使うと、顧客に説明できる自信がありません。
「ここは重視してくれ」と言われた部分はそのようにしますが、そうでない部分は、最悪できていなくても「すいません。ここで工数がかかってしまったので、当初見積もっていたポイントよりも大変でした。なので、ここは次に回してもよいですか」と尋ねた時に、それまでのやり取りの中で「ここ」というのはそこまで重要でない機能になっていることが大事なんですね。簡単に「それが優先順位低いのはわかっていたので次に回していいですよ」と言ってもらえること。その結果、残業をしなくてもよいという、そういうことなのだと思っています。
あわせて読みたい…「Googleからシンプルで使いやすいタスク管理アプリがリリース！」
取材を終えて
「生産性を向上させる」とか「業務効率化を図る」とか、「チームを最適化する」とか、語られる言葉はいくつもあります。でも、実際は、その成果を語る人は少ないのが実情です。ですから、「生産性向上」の書籍はいつの時代もビジネス書のベストセラーの仲間入りをします。今回、武井さんからは実際に会社で実施している方法を存分に語っていただきました。もちろん、いくつかのプロセスを経ての方法なのですが、こだわってアナログで実施しているというKPTが強烈に印象に残りました。
多くの人にも参考にしていただける知恵があるのではないでしょうか？
TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。
