〜仕事の属人化をなくし、「目の前の仕事に追われる」現状を変える。1人ひとりが主体性を持って業務改善に取り組むための、アジャイルHR実践法〜

市場、働き方、テクノロジーが急速に変化する現代においては、企業の基盤を支える「人事」の仕事にも進化が求められている。その中で注目されているのが、「アジャイルHR」という概念だ。

「すばやい」「敏捷」といった意味を持つ「アジャイル（agile）」という言葉は、もともと開発手法のひとつとして親しまれてきた。

アジャイル開発では、短い「計画と振り返り」のサイクルを繰り返し実行する。すると、状況に応じて柔軟に優先順位を変えることが可能になり、リスクを最小化しながらスピーディに問題解決を行うことができる。

アジャイルHRについても同様で、従来のように長い時間をかけてひとつの制度を作り上げるのではなく、組織の課題を特定し、小さく実験・実践を繰り返すことで、組織の進化を導いていく。

※「アジャイルHR」についての詳細はこちら

まだまだ日本では具体的な事例は少ないが、そんな中、クックパッド株式会社の採用グループでは、2018年10月よりアジャイルHRを導入。

同社の人事本部長を務める高井 直人さんは、アジャイルHRの導入によって業務の属人化が解消され、1人ひとりがより主体性を持って仕事に取り組めるようになったと話す。

今回は高井さんに、エンジニア以外の職種でアジャイルを実践することの難しさや、導入後の具体的な成果について、詳しくお話を聞いた。

エンジニア採用における「課題感」から、アジャイルHRを導入

2011年に、バックエンドを担当するエンジニアとしてクックパッドに入社しました。入社後は開発をする傍ら、GitHub Enterpriseの全社導入や、マイクロサービスアーキテクチャの推進などに取り組みました。

その後、当時クックパッドと資本関係のあった別の企業にCTOとして出向したことをきっかけに、仕事が徐々に組織寄りに移ってきまして。クックパッドに戻ってきてからも、全社的なエンジニア組織の構築や広報などに関わり、仕事の領域を広げてきました。

現在はコーポレート部門に所属し、エンジニアだけではなく全社的な人事・広報を見ている立場になります。

このように、エンジニアから人事へとキャリアが変わってきたわけですが、CTOを経験してから組織の方にどんどん興味が出てきていたので、個人的には自然な流れでした。

現在、人事部には15名ほどが所属しており、採用グループ、労務・ワークプレイスグループ、組織開発グループの3つに分かれています。その中の採用グループで、2018年10月からアジャイルHRを導入しています。

その背景としてあったのが、採用に関する課題感です。

我々のようなベンチャー企業の場合、「どれだけハイスキルなエンジニアを採用できるか」ということが、事業的にも非常に大きな意味を持っています。一方で、エンジニアの獲得競争は激化しており、その中でいかに競争力を持つかということが非常に重要です。

また、視点を自社の方に移してみると、新規事業もおこってきていますし、研究開発も盛んになっている。それに伴ってエンジニアへの要求も高度化し、また領域も多岐にわたるようになっています。

このように市場・競合・自社を見た際に、これからどのように採用をしていくべきか、ということは大きな課題だなと感じていました。

アジャイル開発の導入で、エンジニア組織を改善した原体験

アジャイルHR導入経緯の前に、その背景として、関係会社に出向していたときの経験について触れさせてください。当時はCTOという役割を務めていたのですが、そこで大きな学びがあったんです。

出向していた会社はいわゆる「B to B to C」型のビジネスモデルで、ビジネス的なニーズが非常に強く、案件が発生するたびにエンジニアがアサインされていました。

エンジニアは、日々その対応に追われていた感じで、技術的な投資や継続的な改善が後回しになってしまう状況にありました。またそれに加えて、機能ごとに担当者が分かれていたので、仕事が属人化しているという課題もありました。

エンジニアたちは一生懸命に頑張っているのだけれど、目の前の仕事に追われて、なかなか全体的な仕組みの改善ができない。だから効率的なやり方ができない、という悪循環に陥っていたわけです。

「どうしたらこの状況を脱することができるんだろう」と悩みに悩んで、アジャイル開発の手法を取り入れることにしたんです。

アジャイル開発では、通常1〜2週間程度の開発サイクルを「スプリント」と定義して、その期間の最初にプランニングを行い、最後に振り返りを実施します。

プランニングでは、やるべきこと一覧を定義した「スプリントバックログ」の中から優先度の高いものを選び、エンジニアがその仕事に自らサインアップします。そしてスプリントの終わりには、プロジェクトオーナーに完成したものをレビューしてもらいます。

また、「つくったもの」の評価だけではなく、その「つくり方」にもフォーカスして振り返りを行います。成果物と開発プロセスの両輪で、改善していくやり方です。

これがとても上手くいって、チームの生産性を大きく高めることができるようになりました。

最終的には、プランニングのミーティングに、サービス開発に関係するほとんどの社員が参加するようになって。また、役員も振り返りのミーティングを「サービスの動きが全部わかるミーティングだ」と言って、積極的に参加するようになっていました。

※当時のお取り組みの詳細は、RubyWorld Conference 2016の発表資料でご覧いただけます。

採用の仕事を観察し、見えてきた課題は「属人化」と「細分化」

そして、クックパッドで人事部を見るようになり、まずは採用の仕事をどのように進めているのか観察してみたんです。

すると、まずは現場の部署から「こういう人が採りたい」というニーズが出てくるんですね。それに対して、担当者をアサインして進めていきます。

また、候補者の方に直接対応する「フロント」と、日程調整などを行う「アシスタント」に役割が分かれていました。さらに「新卒か中途か」「ビジネス職かエンジニア職か」といった募集の職種によっても担当が分かれていて、仕事が細分化されていました。

採用は個人情報を扱うということもあって、情報の共有を工夫する必要があり、特定の候補者に対して「担当者しかわからない」といった状態にもなりやすいんです。すると、時期によってすごく忙しい人とそうではない人に分かれてしまうという問題もありました。

仕事が細分化されて、サイロ化されている。結果的に、「属人化の極み」のような状況になってしまい、仕事が忙しい人と忙しくない人がいる。全体的な目線で考える機会が少なく、長期的な改善まではなかなか手が打てない。

これ自体は、よくある話だと思うんですね。ですがこのような状況に、皆フラストレーションが溜まっていた部分がありました。

そういう課題が見えてきたときに「これって、どこかで見たことがあるぞ」と思ったんです。まさに自分がCTOとして出向していた会社の、エンジニア組織が抱えていた課題と一緒じゃないかって。

そこで、職種は違いますが、同じようにアジャイル開発手法を導入してみようと考えました。アジャイル開発手法のうち、スクラムという手法を基本にしています。

導入は完全にトップダウンで、社内のブログにアジャイル手法の進め方を書いて、「これでやります」という形でいきなりスタートしました（笑）。

▼実際に社内に公開したブログ記事

アジャイルの「型」は簡単だが、その「習得」は難しい

アジャイルって、型としては非常に簡単なんです。スプリントのサイクルを定めて、その最初に計画をして、毎日進捗を話し合って、最後に振り返る、ということを繰り返すだけです。

ただ、習得がすごく難しくて。実際にやってみると「計画のときに休みの人がいたらどうするのか」とか「飛び込みで仕事がきた場合はどうするのか」とか、色々と疑問が出てきます。

でも、アジャイル開発手法ってあくまでもチームの自主性を尊重する手法なので、細かい部分まで全部やり方が決まっているかというと、そうではないんですね。言ってしまえば「最後はチームで話して決めてください」という発想なんです。

ですから、型としては簡単でも、それを実際に自分たちのチームにフィットさせて運用し、生産性を上げられるかはチーム次第になってしまうので、使いこなすのがとても難しいです。

そこで、書籍「アジャイルサムライ」の翻訳などをされている角谷 信太郎さんにコーチをお願いしました。実は出向していたときも、角谷さんに手伝ってもらって、すごく助けていただいたという経験がありました。

アジャイルは難しいので、実行していく中でどうしてもわからないことが出てきてしまい、「どうすればいいんですか」と「答え」を聞きたくなるんですよね。

そういった際に、角谷さんはしっかり「問い返し」をしてくれるんです。「こういうチームだと、こういうことをしている場合もあるけれども、あなた方はどうしたいんだろう」といった形です。

アジャイルを実践する上では、このように「自分たちでしっかりと決めていく」ことが非常に大切になります。

これって、1人ひとりがオーナーシップを持って仕事を進めていくってことなんです。仕事も誰かがアサインしてくれるのではなくて、自分でサインアップして取り組んでいきます。

ですので、もともと持っているマインドセットを大きく変える必要が出てきます。「自分たちで、自分たちの仕事のやり方を決めて、それで成果を上げられるんだ」という確信が必要になるのですが、それって結構難しいことなんです。

角谷さんがコーチ的にその部分を支えてくれていることで、導入の部分ではかなり助けられました。

アジャイルHRの導入によって、変化に強く、主体性のあるチームに

今では、毎週水曜日にプランニングを行い、火曜日に振り返りを実施しています。また、チームの席にホワイトボードでつくった「カンバン」を置いていて、それを見るとメンバー1人ひとりが「今どの仕事をしているのか」がわかるようになっています。

▼ホワイトボードのイメージ図（編集部作成）

チームの中で、この仕事に対してどのような施策を打っているのか、他の人が今何をしているのか、といった情報を皆で共有できるようになり、とてもわかりやすくなりました。

毎日ホワイトボードの前に集まって朝会を実施し、仕事の進捗を共有するようになったことも良かったですね。

以前は、進捗を共有するためのミーティングを週次で設けていたのですが、お互いに「用意してきたものを読み上げるだけ」になりがちで、実際には他の人の仕事の内容まできちんと理解できていませんでした。

それが今では、随時、情報を共有しながらアップデートするというスタイルになっています。

また、1人ひとりが「これをやります」と自らサインアップをして仕事を進めるので、主体性も大きく変わりました。振り返りの時間があることによって、「次はこういう風に変えられるんじゃないか」と、チームの仕事のやり方を常に見直して改善することもできます。

いわゆる「アシスタント」の役割を担っていた人も、スプリントを回す中で徐々に役割を広げられるようになっています。日程調整のように必要だからやるという受け身の仕事だけではなく、自分で考えて工夫をしていく仕事の割合を増やしていくことができています。

「ツール」や「手法」を導入することがアジャイルではない

ただ、やはり人事でアジャイルを導入するのは難しい部分もあって。エンジニアであれば「機能が完成した」という形で、仕事の「完了」を定義しやすいんですよね。

そこをどうやって人事の仕事に適応させていくのかは、もっと考えていかなければならないし、まだまだアップデートの余地があると思っています。

人事はルーティンも多いですし、「調整する」「面談する」みたいな形で仕事がタスクベースになりがちです。そこはできるだけ、成果物をベースにコミュニケーションするように意識を変えていっています。

単に「やりました」ではなくて、「達成したいものがあって、そこに対して何をやったから、完了した」といった成果ベースで振り返りをするようにしています。

アジャイルソフトウェア開発宣言の著者の1人であるデイブ・トーマスさんが講演で、「『自分たちがどこへ行きたいのか』『自分たちがどこにいるのか』『どうやったらその位置を改善できるのか』、このサイクルを回していくこと、それこそがアジャイルだ」とおっしゃっていました。

つまり「こういうツールを導入すればいい」「こういう手法でやればいい」という話ではないんですよ。自分たちの仕事をどう変えていきたいのかを考えて改善していく、それを愚直に繰り返していくしかないんだろうな、と思っています。

採用に限らず、コーポレート部門の仕事って意識をしないと受け身になりがちですし、毎年同じことを繰り返していると感じやすいんです。

そうではなくて、きちんと自分たちのやったことを振り返って、自らアップデートしていく。これが環境変化のスピードが早くなっている現代で、すごく重要になっていると思います。（了）