i-plug TECH_BLOG

若い人材の可能性を拡げるOfferBoxとコレカナを開発している株式会社i-plugの開発ブログ

セレクトボックスの課題と、選びやすいUI設計

f:id:mayumi-matsuda:20210628173415p:plain

こんにちは。OfferBoxのUIデザインを担当している中野です。
日頃Webやアプリで、セレクトボックス(Pickers)をよく目にしますね。
そんなセレクトボックスはUIの特性上、選ぶ負荷が高いのでは?と考えています。
この記事は以下についてUIデザイナーの考えを書きます。

セレクトボックスは選ぶ負荷が高いと考える理由

選択肢を予測しづらいため

セレクトボックスは次の3点からユーザーにとって予測しづらいものであると考えています。

  • 選択肢の項目を予測しづらい
  • 選択肢の順番を予測しづらい
  • 選択肢の数を予測しづらい

f:id:mayumi-matsuda:20210624172949p:plain

上のイメージを見てわかるとおり、セレクトボックスは選択肢を予測しづらい性質がありますね。
一方でラジオボタンは選択肢が表に出ていて明らかです。

すでに選択肢を知っているデザイナーとは違い、ユーザーはセレクトボックスを押しドラムロールバーをスクロールするまで選択肢を知りえません。
そのため、デザイナーが想像している以上に選ぶ負荷があると考えています。

選択の法則に沿わないことが多くなるため

選択肢が多いほど、人は覚えにくく選択を遠ざけてしまう法則があります。
以下は代表的な法則の2つです。

選択の法則1.「マジカルナンバー4±1」

「人が短期的に覚えられる数は3〜5個」だという法則があります。
心理学者のネルソン・コーワンさんの研究です。

この法則は日常生活によく使われています。
たとえば電話番号は11桁を3〜4桁 × 3つの塊にして、覚えやすくしていますね。

区切りなし:00000000000
区切りあり:000-0000-0000
選択の法則2.「ジャムの法則」

人は選択肢が多いほどストレスを感じる法則があります。
行動科学者のシーナ・アイエンガーさんの研究です。

この研究では、とあるスーパーに24種のジャムを置いたエリアと、6種のジャムを置いたエリアで購入率に違いはあるか?を調べたものです。
結果は6種の方が24%も購入率が高かったそうです。

これらの法則からわかるように、選択肢が多いほど、人は覚えにくく選択を遠ざけます。
セレクトボックスはUIの特性上、数を詰め込んでしまえるので、選ぶ負荷が高くなる傾向にあると思います。

iOSでは推奨されていないのかもしれないため

iOS Human Interface GuidelinesのPickersページに以下の記載があります。
意訳すると「選択肢を予測できない場合は、他のUIも検討してください」と書かれています。

Consider using a picker to offer medium-to-long lists of items. If you need to display a fairly short list of choices, consider using a pull-down menu instead of a picker. Although a picker makes it easy to scroll quickly through many items, it may add too much visual weight to a short list of items. On the other hand, if you need to present a very large set of items, consider using a list or table. Lists and tables can adjust in height, and tables can include an index, which makes it much faster to target a section of the list. For guidance, see Tables.

Use predictable and logically ordered values. Many values in a picker may be hidden when the scrollable lists are stationary. It's best when people can predict what the hidden values are, such as with an alphabetized list of countries, so they can move through the items quickly.

文章内で提案してくれているUIは次のとおりです。

f:id:mayumi-matsuda:20210624173125p:plain

基準 採用を検討するUI
選択肢の数が少ない場合 Pull-Down Menus
(iOS14から用意されました)
選択肢の数が中くらいかつ、
項目を予測できる場合
Pickers
選択肢の数が多い場合 Tables
選択肢が日時の場合 Date Pickers
(iOS14から用意されました)

よくよく考えればAppleが提供しているアプリ上で、セレクトボックスを見かける機会は少ないかもしれませんね。

選びやすいUIを設計する

選びやすいUIに導くために、以下2点を主に意識しています。

1.選択肢を絞る

自分たちがユーザーに提供したいと考えている選択肢は本当に必要なのかな?と根本を問います。
そもそもの課題はセレクトボックス以前に、選択肢が多いことです。

選択肢を増やすのはかんたんで、企画時についつい追加しちゃいがちなんですよね。
特に日本人は網羅性を優先して、ダブりを許容する国民性があるのかなと思っています。
とはいえ、整理できなかったことをユーザーに押し付けるのはおかしな話です。

まずは目の前の選択肢を疑ってかかります。
必要最小数まで絞り、理由を言語化したら、デザインの意思決定に関わる方へ共有する。

選択肢を絞れると、ラジオボタンなど負荷がすくないUIを採用できるようになります。

2.選択肢の情報構造を整える

選択肢をどうしても減らせないケースもありますよね。
そのケースでは選択肢を把握・選択しやすくするため、内容を分解・構造化します。

情報にはグループ関係や親子関係、規則性、優先度があります。
その中からユーザーの利用文脈を想像しながら、わかりやすい切り口を探します。
考え方として近いのはIAのLATCH法です。
doburoku.com

たとえば都道府県などは減らせないタイプの情報ですよね。
そのため、旅行系サービスなどは工夫がたくさん見られます。

旅行サービスの例

f:id:mayumi-matsuda:20210624172954p:plain

アプローチ方法 アプローチ例
タスクコヒーレンス 「最近選んだ空港」で各ユーザーごとに適正な情報を提供し、選びやすくしています。
マジョリティ 「主要空港」グループを配置し、大勢の人が少ない負荷で選べるようにしています。
グルーピング 地方でグルーピングし、ドリルダウン式に選びやすくしています。
マップを活用したサービスの例

f:id:mayumi-matsuda:20210708102019p:plain

アプローチ方法 アプローチ例
マッピング マップ上から、直感的に選択肢を選べます。
サジェスト 利用文脈を考慮して、近場のスポットを案内しています。
親切な補足 何分かかるかなど計算しておき、選ぶ際の判断をしやすくしています。

ここで取り上げた工夫は一例です。
情報の切り口を考えると、選びやすいUI設計につなげれますね。

セレクトボックスを採用するケース

とはいえ、セレクトボックスを採用するケースもあります。
ぼくは以下の条件に当てはまれば、採用を検討しています。

  • 選択肢の項目を予測できる
  • 選択肢の順番を予測できる
  • 選択肢の数をなんとなく予測できる
  • 入力値を固定にする必要がある
  • 情報をコンパクトに収めることを優先する
ECサービスの例

f:id:mayumi-matsuda:20210624173006p:plain

ECサービスでは購入商品の個数を選択する際にこのようなUIも使われています。
ただしネイティブアプリケーションでは独自のUIを提供していることが多く、
Pickersよりも一覧性が高いです。
このように工夫はたくさんできそうですね。

おわりに

弊社はサービスの性質上、セレクトボックスを多く用いているのが現状です。
そのため、改善できるユーザビリティはたくさんあります。

ユーザーは選択肢から選ぶためにサービスを利用してくださってるわけではありません。
また集中して使ってくれているわけでもないと思います。
ユーザーの状況や負荷を汲み取って、適正なUIを提供し、すばやく価値を得てもらいたい。
そんなUIデザイナーの取り組みとして、セレクトボックスへの考えを言語化してみました。

他にもこんなよい考え方があるよ!などありましたら、Twitterで教えてくれると嬉しいです。
@inumoarukeba_na

読んでくださり、ありがとうございました。

中野 直(UIデザイナー)

2020年にi-plugに入社しました。
入社前は約8年Web制作会社でWebデザイン、フロントエンド、CMSカスタマイズなどに従事。
入社後はUIデザインを主軸に、新規事業開発、既存サービスをAtomic Designにて再構築、UXライティング、ディレクション、ユーザーリサーチなど色々取り組まさせてもらっています。HCDスペシャリスト資格も取得しました。

新任マネージャーのメンバーを支える評価の工夫

f:id:mayumi-matsuda:20210112160028p:plain

今回はマネージャー目線でチームメンバーへの評価の向き合い方について紹介します。
私は2019年11月にマネージャーになったので歴は1年程度です。
就任当初から評価は色々と工夫してきました。

評価を行う側の方にとっては参考になる部分があるかもしれません。

i-plugの評価制度

i-plugでは社員の成長促進のため細かくPDCAを回し、3ヶ月単位で評価をしています。
各人の能力や役職に合わせた期待役割を設定し業務の実績を評価しています。

どんな気持ちでマネジメント、評価に取り組んでいるか

評価に限らず、マネージャーであることの重みをよく考えています。

ーー親と上司は選べない

世間では、そんな言葉をよく耳にします。自分もそういうことを言われかねない立場だと感じるたび、身の引き締まる想いです。自分の振る舞いや仕事のアサインなどがその方のキャリアに影響するので、真剣に考えても考えすぎることはありません。
そのため納得感がある評価をおこなうのは当然のことです。評価を機会にその方のキャリアにいかに活かすかまで考えて運用をしています。

具体的に評価においてどんな工夫をしているか

1.こまめにFBしている

1つ目の工夫は簡単なことですが、定期的に1on1を行いこまめなFBをしています。
評価のアンチパターンあるあるに
「もっとこういうところを頑張ってほしかった」→「それその時言ってよ〜」とか
「あなたの仕事ぶりをこう評価しています」→「えっ、私の仕事の評価低すぎ?」
といった例があるかなと思っています。
こういった例は、評価を一発勝負にしているから発生しています。
こまめにFBしていればまず起こらないはずです。

マネージャーには、チームとしての成果を挙げることと、メンバーの成長を促すことが求められます。
FBを後出しにするのはこれらに反することです。
もちろん限度はありますが、可能な限りオープンマインドで
「この辺りは物足りないのでもう少し頑張ってください」
「この辺りをクリアできれば良い評価にできそうです」
というやりとりをします。
こまめにすることで評価される側も納得感を得られますし、パフォーマンスをきちんと発揮してもらうことができます。
弊社の評価期間は3ヶ月と短めですが、一発勝負にしないことはどのような制度でも重要だと思います。

2.評価するだけでなく支援をしている

これは評価だけではなく日々の接し方にも通じる姿勢かと思います。
メンバーの業務について後出しで評定を返すだけではなく、むしろ活躍する(=良い評価を出す)ためにはどうすれば良いかを日々一緒に考えることを大切にしています。
先述の通り、マネージャーはメンバーの能力を活用してチームの成果を挙げることが役目です。
メンバーが活躍して良い評価を得ることは、すなわち自分がマネージャーとして仕事をできている証明になります。
もちろん良い評価を得るためには、難易度の高い仕事をこなす必要があります。
だからこそ価値があるので本人の努力やマネージャーの力量の見せどころかと思います。
一方、評価結果については他者からのダブルチェックが入るので、えこひいきではなく妥当性のある内容でないと意味がないというのは論をまたないでしょう。


マネージャー歴が短いながらも色々と工夫している点を書きました。
結局は「自分の上長にはこういう風にしてほしいな」と思っていることをメンバーに実践しているというのに尽きるかと思います。
幸いながらメンバーにも恵まれ日々の業務も評価も乗り越えられています。
取り組み方を工夫することで評価を、上司vs部下の荷が重いタスクから、メンバーと共に成果と成長を目指すワクワクする仕事に変えてみませんか?

社員紹介Vol.3 i-plugのサービス提供を支える基盤開発・大黒

f:id:mayumi-matsuda:20201221105018j:plain

テックブログを見ていただき、ありがとうございます。今回ご紹介しますメンバーはSREグループ リードエンジニアの大黒(だいこく)です。OfferBoxのインフラ基盤を支える屋台骨でもあるチームやメンバー、自身のキャリアについて聞きました。

役割と所属しているチーム

初めまして、SREグループの大黒です。SREとは「Site Reliability Engineering」の略で、サイトの信頼性向上を目的としたエンジニアリング手法の一種です。日本で広く知られるようになったのは2015年にメルカリ社がインフラチームを改名しSREチームを発足してからでしょうか。SREグループでは目的のために以下の向上に取り組んでいます。

  • 可用性や耐障害性:障害に強い仕組み作り
  • パフォーマンス :時にはアプリのソースコードを追って、問題を修正する
  • セキュリティ担保:定期的な診断を行うなど、トレンドをいち早く取り込み、対策する
  • 環境整備    :開発者が望む環境やリリース手段などを素早く用意する

さらに具体的に言うと、インフラのモニタリング、最適なシステム構成や処理方法の提案、新しい技術などの検証・適用、それらを実現するための基盤作りを行っています。

SREグループには私含めて3名が在籍しています。各々は元々アプリ側の開発をしていたプログラマでしたが、OfferBoxが提供するサービスが大きくなるタイミングでよりインフラやアプリのコア部分の開発に特化したチームを組成することになり、私はそのタイミングでi-plugに入社しました。

メンバーそれぞれがこれまでの経験や専門性を活かしており、一人はインフラ構築を中心に汎用的な基盤開発を担当しています。お若いですが、フルスタックに活躍ができる方です。もう一人は機械学習などアカデミックな知見を武器とし、より専門性が必要な検索基盤の開発や、DB、ログ、インフラ構築を担当しています。

私はこれまでのインフラ・SREの経験を活かし、施策の打ち出しや技術支援、メンバーのマネジメントをしています。

i-plugに入社する前の経歴について

前職は広告業界でDSP(※)サービスの提供会社で、私はそのサービスのインフラ基盤開発をしていました。トラフィックが大きく、高負荷な状態が続くので、それに耐える仕組みを整えないといけません。中途半端な改善では通用せず、高度な技術が要求されました。

他では味わえない環境で開発を経験したことに加え、社内のエンジニアも尖った方が多かったので、そんな中で切磋琢磨できるのは良い環境でしたね。とてもやりがいを感じていました。

(※)Demand Side Platform デジタル広告インベントリの購入者が1つのインターフェイスを介して複数のアドエクスチェンジおよびデータエクスチェンジアカウントを管理できるようにするシステム。(Wikipediaより)

i-plugに惹かれた理由

i-plugで働く前は、広告やエンタメ業界のインフラ基盤開発に携わってきました。

転職のきっかけはプライベート面での環境変化によるものが大きな要因です。希望は、成長期にあるベンチャー企業。自身の経験を活かして会社の成長に貢献していくことが好きでした。また、東京から関西への移住を考えていたため、関西にある企業を探していました。

i-plugを知ったのは、知人の紹介によるものです。新卒採用でミスマッチを解消させるためのプロダクト「OfferBox」は、より社会に貢献できる仕事に携わりたいと考えるようになっていた私にとって興味深いものでした。私自身、新卒で入社した会社では大きなミスマッチがあり、就職活動をするなかで企業の情報を知ることがなかなか難しいことへの課題感や、情報格差を感じていたことも強い動機となったと思います。

さらに、入社前にCTOの青木やメンバーと話すなかで、一緒に働くメンバーにも魅力を感じましたし、業務内容としても検索ロジックの改善やユーザーが増えるに連れて早急なインフラ基盤を改善が必要と聞き、自身の経験が活かせると考えました。

どういった組織、プロダクト開発にしていきたいか

究極の目標は「全エンジニアメンバーがインフラを意識して開発できるようになること」でしょうか。i-plugでは現在はSREを切り出して独立したグループを組成していますが、いずれはまた集約されるのではないかと考えています。クラウドサービスを始め、様々なサービスが登場しているので、インフラ開発自体が属人化するものではなくなっていることも、そう考えている大きな要因です。フルスタックという言葉がありますが、エンジニアメンバーみんながそうなるべきだと考えています。

私個人のキャリアとしては、やりたいことがまだまだたくさんあります。直近では「検索周りのスケーラビリティを確保する」、長期的には「開発組織全体の技術力向上に貢献する」ことですね。セキュリティやアプリのコア部分も携わりたいと思います。 

社員紹介Vol.2 データサイエンスでプロダクトの課題を解き明かす・藤田

f:id:mayumi-matsuda:20201208101846p:plain

弊社テックブログを見ていただき、ありがとうございます。弊社サービス開発部には、プロダクトの課題を仮説検証し、探索的に課題解決を図っている「グロースチーム」があります。今回はグロースチームに所属している藤田をご紹介します。

所属しているチームと役割について

初めまして、UXグループグロースチームの藤田です。チームでは主にOfferBoxを利用した学生と企業のマッチング数の向上にコミットするための活動をしています。そのなかで、私はデータサイエンティストとして、主に以下の活動をしています。

  • 論点を設定して仮説構築し、分析すべき問題を定める
  • 企業や学生がOfferBoxで活動したデータを収集
  • データからそれぞれの行動を分析
  • プロダクトの質的改善に繋がる施策の立案

データサイエンティストといえば、データ分析が主な仕事と思われがちですが、実際にはその前段階である分析テーマの企画にも携わっています。

施策を打ち出す際には開発した機能のABテストを実施し数値を測定しながら効果検証をおこないます。私が入社する前も統計的仮説検定を用いた検証は既に行われていました。これに加えて、私がテスト前検証や効果量を考慮した必要サンプルサイズの推定などを導入したことで、より慎重に効果検証が行われるようにしています。

i-plugに惹かれた理由

f:id:mayumi-matsuda:20201208100841p:plain

i-plugに入社する以前は、大手化学メーカーでデータ分析の業務を担当していました。どちらかといえば機械学習による予測タスクの精度向上をメインに仕事をしていましたね。

当時からデータサイエンティストとして働いていましたが、まだ自分のスキルには不足している点を感じていました。データサイエンティスト協会が開示しているデータサイエンティストの3要件には、「データサイエンス力」「データエンジニアリング力」「ビジネス力」があります。私はこの中でも、ビジネス力を伸ばしたいと考えていました。

i-plugと出会ったきっかけは、i-plugがランチスポンサーをしていたデータコンペティションです。登壇内容を聞いているうちに、i-plugでの業務内容に興味を持ちました。

また、i-plugが運営する「OfferBox」は新卒採用の課題を解決するために生まれたプロダクトだと知りました。私自身も新卒で入社した会社で苦労した経験があります。i-plugは就職活動の仕組みを変える会社ということで、入社して自分のように困っていた学生を助けることができたら良いなと思い、選考を受けることにしました。

選考過程でOfferBoxの現状の課題を聞き、問題としてはかなり難しいものに挑戦しているなと思いました。特に難しいのは、企業と学生の2つの軸で課題と解決策を考えないといけないところです。両者のニーズが噛み合うように最適化しないと良い改善ができません。

一方で、私自身には解けないことが濃厚な問題や簡単な問題は自分の成長に繋がらないという考えがあるので、非常に挑戦する価値のある課題だと感じました。

どういったプロダクト成長を目指したいか

結果ありきの成長はしたくないと考えています。KGIにしても、達成するための過程が大事だと思います。考え得る施策を手当り次第に実施し数値達成することは良い課題解決とは言えないでしょう。

良い課題解決とは、プロダクトに求められる要件を見定め解決策を練り上げていくことにあります。そのためにユーザーのニーズを見極めていくこともデータサイエンティストには求められますし、勘や経験則に頼った解決策ではなく、データに基づいて何が必要なのか、足りていないのか、課題はどこにあるのかを炙り出していきたいですね。

今後のキャリアについて

先述しましたが、現時点ではよりビジネスサイドの知見を深めたいと考えています。これまで機械学習やデータ分析はしてきたものの、ビジネス課題を特定・解決する能力がまだまだ足りていないですね。仮説を証明する力としての分析だけではなくてその前工程部分をもっとできるようにしていきたいと考えています。

i-plugが、スクラム開発を導入するまでの話

f:id:iplugsakai:20201127110658p:plain

はじめに

今回は、i-plugがスクラム開発を導入するまでについて書きたいと思います。

i-plugでは、いくつかのチームが、それぞれにミッションを持ってOfferBoxの開発に取り組んでいますが、それぞれが、スクラム開発をベースにした開発プロセスを作っています。

その中でも、私が所属しているチームは、最初にスクラム開発を導入したチームがベースになっていて、2019年4月に導入して以来、1年半スクラム開発を継続しています。 (開始が少し前後していたり、スプリントを実行していない時期もありましたが、先日スプリントが80を超えました!)

  • 負荷の集中する人、そんな傾向のあるチーム
  • 名ばかりチームで、孤独に仕事をしていることに違和感を感じる人
  • 実際にスクラムを導入したい人

そんな方々に、今回のお話が届けばと思います。

自己紹介

サービス開発部 UXグループ エンジニアリングチームでチームマネージャーを務めている堺と言います。

i-plugでスクラム開発したいって言い出した張本人です。

前職では、サーバ・DB管理を主に、開発・運用全般に広く浅く顔を突っ込む人をやっていましたが、関西のアジャイル界隈で有名な方の入社がきっかけに、スクラム開発を学び、前職を飛び出して、i-plugにジョインしました。

i-plugでは、ディレクターをやったり、チーム横断でスクラムマスターをやったり、スクラムマスターとプロダクトオーナーを兼任したりと紆余曲折あり、2020年4月、新型コロナ禍の中、スクラムマスターとプロダクトオーナーを兼任したままチームマネージャーになりました。(1人3役超しんどi(ry

現状は現状で学びがあるので、いつかまとめて記事にしたいと思っています。

チームとしては、

  • OfferBoxのプラットフォーム価値を上げるための土壌作り
  • アプリケーションレベルでの信頼性の向上
  • ユーザーのニーズに対するソリューションの提供

をミッションに、日々開発に取り組んでいます。

なぜ導入したいと思ったか

入社当時のi-plugの開発体制&プロセス

f:id:iplugsakai:20201127105237p:plain

  • ディレクター:要件定義〜仕様策定、受入テストの実施、進行管理、他部署折衝
  • エンジニア:設計、実装、テスト。案件にもよるけど、1案件1エンジニア→1エンジニアが複数案件抱えることも
  • デザイナー:1デザイナー複数案件

※他部署からの依頼とかは一旦除く

複数案件を管理するディレクター、デザイナーによるUIデザインが完成しない辺りがボトルネック。要件定義に注力すると、受入が進まない。受入に注力すると、要件定義が進まない。

MTGは容赦なくやってくる。

また、エンジニアの手を空けないよう、さくっと要件定義できる案件を用意したりするが、 そういうのは、さくっと実装が終わって、受入確認待ちが増えて、ディレクターの首を締める。 もしくは、準備不足で途中で進められなくなって、ディレクターの確認待ちに戻り、首を締める。

たまに、ディレクターが知らない内に、エンジニアに直接案件が割り当てられる。

ざくっと、まとめると・・・

  • ディレクターへの負荷集中
  • 案件の属人化
  • 全ての職種がマルチタスク
  • ディレクターが、自分の使えるリソースを完全にはコントロールできない

という状況でした。

問題

このような状況では、以下の問題が生じます。

  • ユーザーへの価値提供の遅れ
  • 純粋に、自分がしんどい

理想の状態ってなによ?

理想の状態を考えるとたとき、以下を考えていました。

f:id:iplugsakai:20201127105133p:plain

  • 特定の職種に負荷が偏らない
  • 誰かがいなくても仕事が進む
  • 誰かが困っていたらヘルプができる
  • 優先順位の高い案件に集中する

要は、チームとして優先されるべき課題に一丸となって対応しようよ、ということですね。

えー、でもこんなの簡単にいうけど、難しいよー。

いや、なれるんだよ。そう、スクラムならね。

スクラム導入前にやったこと

スクラム開発なら解決できそうだとはいえ、今ままでのi-plugの開発とは違う価値観・やり方。「やれよ」で出来るものではない。ということは身を持って知っていた(参考)ので、段階を踏んで、導入します。

1.アジャイルコーチによる支援

まずはアジャイルコーチをお呼びし、自分たちのしごとのボトルネックを見える化しました。 ボトルネックを解消するために様々なプラクティスを紹介いただき、導入します。 例えば、開発プロセスのボトルネックを見える化するために、一緒にバリューストリームマップを作ったり、振り返りをうまくできるように、様々なフレームワークを使ってファシリテーションしてもらったりといったものです。 加えて、これまでの開発プロセスにおける困りごとについて、相談・客観的に答えてくれる相手がいなかったことも課題でしたので、壁打ち相手にもなっていただきました。  

2.カンバンの導入

続いて、カンバンを導入しました。 これまでアイプラグではJIRAを使っていましたが、オフィスの壁にふせんを貼って管理するように変えました。

これにより、優先度・進捗が可視化されたばかりでなく、同じフロアにいる他部署にもインパクトを与えられたかと思います笑

3.朝会(デイリースタンドアップ)の導入

これまで実施していなかった朝会も実施。導入したカンバンを使い、メンバー同士の状況を共有しました。メンバーの状況を把握することで、より優先度の高いタスクを終わらせるための相談も実施できるようになりました。 朝会は全員が立ちながらおこないましたので、やはり他部署へのインパクト(ry

4.ふりかえりの導入

週に一度、ふりかえりの時間を設けました。自分たちの仕事の仕方を自分たちで見直すことで、以下のようなメリットがありました。

  • チームの中だけで課題とアクションを考え、改善し続けることで、自己組織化が促される
  • 頻繁に実施することで、以前に決めたアクションが正しかったか、次になにをするか、を早く決めることができる

5.受入テストを、エンジニア主導に

以前の開発部では、受け入れテストをする際にディレクターが環境立ち上げ・テストデータ準備をしていました。これを、エンジニアが実演する形へ変更し、以下のような改善が生まれました。

  • 開発に使っていた環境・データがあるので、すぐに、もしくは、簡易な準備で実演することが可能となった
  • ディレクターの工数負荷を下げる
  • 案件の受け入れテスト待ちの時間自体が減る

6.タスクのバックログ化

タスクを優先順位付け、リスト化しました(=バックログ化)。 これにより、チームとしては、リストの上から順番に対応していけばいい、という状況になりました。

7.イテレーションの導入

集中して目の前にあるタスクに取り組めるようイテレーションを導入し、一週間でやることを明確化させました。また、週の終わりには前述の振り返りをおこないました。

8.デザイナーとの関わりを調整

従来の開発方法では、デザイナーが抱えている開発部以外のタスクが可視化されていない状態で、要件が決まったものの、そのUIを実現するデザイナーのリソース不足がネックでした。 そこで、前述のカンバンでタスクを可視化し、さらに早めに要件を共有し、イテレーションの計画に盛り込んでもらうことで、UIデザイン待ちとなる時間を減少させました。

満を持してスクラム導入

導入だけでなく、スクラムを浸透させるためにも、メンバー1人1人と1on1を行い、やり方や期待するものを説明しました。

で、何が変わった?

エッセンスを事前に取り入れまくったので、やっていることは、実はほとんど変わっていません。(^_^;)

問題は解決した?

これらの取り組みによって、以下の改善が見られました。

  • メンバー間のコミュニケーションが増え、助け合いが増えた
  • 1人で孤独に案件を進めることも、1人でいくつも抱えることもなくなった
  • リリース件数自体は変わらないが、重要な案件の歩留まりは減った

みんなHAPPY?

実はそうでもありませんでした。 確かに、「作ること」自体は改善しましたが、

  • 何を作るか
  • 作ったものが正しかったのか

という、当たり前のところにまだまだ問題を残し、本当にユーザーが欲しているものを正しく届けられているか、は不明なままだったのです・・・

しかし、優先順位を落としているものの、バックログに大量に積まれた要望を前に、抜本的な改革が中々図れず、ユーザーに正しく価値を届けるためにグロースチームが発足することになったのです。

この続きは、小西さんの「i-plugでのグロースハックって何やってんの?」をご覧ください!

itbl.hatenablog.com

堺 祐輔

3人の子どもの父親で、はっちゃけた成人式で有名な北九州出身で、ビールが好きで、家でも仕事でもチーム活動がスムーズになるようにふらふらしてる人。色んな技術領域を、広く浅く、ところによりちょっとだけ深くカバーしている人。前職でアジャイル・スクラム開発に出会った後、i-plugに入社、開発プロセスの改善に携わり、右往左往しているうちに今に至ります。

社員紹介Vol.1 自律的な行動を促し成果に結びつけるスクラムマスター・堺

f:id:mayumi-matsuda:20201109192418j:plain

弊社テックブログを見ていただき、ありがとうございます。i-plugの開発部では、Webアプリケーション開発エンジニア、データサイエンティスト、機械学習エンジニア、Webデザイナーなどのメンバーが在籍しています。

縁の下の力持ちを担う開発部の社員紹介企画第一弾。

各々がどのようなバックグラウンドを持っていて、なぜi-plugに入社したのか、どんな役割を担っているのかをご紹介できればと思います。今回はエンジニアリングチームマネージャー兼スクラムマスターの堺をご紹介します。

役割と所属しているチーム

UXグループエンジニアリングチームマネージャー兼プロダクトオーナーの堺です。i-plugでは以下3つの役割を受け持っています。

  • スクラムマスター
  • チームマネージャー
  • プロダクトオーナー

i-plugに入社しスクラム開発(※)を導入して以来、スクラムマスターを担当しています。チームが自律的に行動し、成果を出せるような気づきを与えていくことを意識しています。

(※)ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つ。

チームマネージャーとしてはメンバーの評価や育成も大事な役割です。プロダクトオーナーとしてはプロダクトバックログ(開発したいもののリスト)を調整しながら、チームが開発するモノを整理して、成果が最大になるようにしています。

3役を兼任するうえで、場面に応じた立場の転換を意識しています。1週間に1度の振り返りをするタイミングはスクラムマスター、リファインメントをする際にはプロダクトオーナーといった具合です。

そんなポジションで業務に取り組んでいるわたしが担っているミッションは以下となります。

  • ユーザー理解を深めるため、OfferBox上での情報収集体制の構築
  • プラットフォームとしての提供価値の向上
  • OfferBoxの信頼性向上
  • アプリケーション上のセキュリティ改善
  • バグ、不具合の減少
  • 既存データの構造変更によるデータ分析(導線分析)の平易化

エンジニアリングチームの業務内容

エンジニアリングチームはわたしを含めて、バックエンド開発エンジニアが4名、フロントエンド開発エンジニアが1名在籍しています。

主な業務は弊社の主力サービスであるOfferBoxのアプリケーション面での基盤の向上。例えば、リプレースをしてメンテナンス性やセキュリティ面を向上させたりといったところです。

それ以外では、技術負債の返済をして開発しやすい状態を作ったり、ユーザーを理解するための情報収集をしやすいデータ構造の整理をしたり、新しいデータを作ったりといった業務にも取り組んでいます。一方で顕在化している課題を解決するための開発も欠かせません。

i-plugに入社する前の経歴について

f:id:mayumi-matsuda:20201109192422j:plain

関西の大学を卒業後、東京にあるコンサルティング会社に就職しました。ITコンサルティングを主に請け負っていた会社で、わたしはシステムエンジニアとして、プレイガイドや銀行に常駐しシステムの保守・運用を担当していました。

その後、家庭の事情で関西に戻り自社ECサービスの開発・運用をする企業に転職。ECサービスの会社では、自社システムの新機能開発や保守・運用・社内インフラの整備などを担当しました。この時に出会ったのがアジャイル開発です。アジャイルコーチと共にアジャイル開発をおこなううちにその良さを体感したのち、2018年にi-plugへ入社しました。

i-plugに惹かれた理由

ECサービスの会社で新卒を初めて採用したのですが、2年ほどで全員退職。その後もミスマッチを起こす人がいる現状を目の当たりにして、新卒採用市場自体にモヤモヤしたものを感じていました。

もっと就職活動時に学生と企業がダイレクトに繋がれる世の中になれば良いなと思ってました。そんな時にi-plugの募集に載っていた以下のメッセージが心に響いたのです。

「将来、自分たちの子どもたちが良い会社と出会い、良い就職をするためのサービスをつくりたい。当然ですが、本当に良い物じゃなきゃ、自分の子どもには勧められません」

自分の子どもたちが良い企業に出会うための手助けができるのは、社会的意義が大きいと思いました。

どういった組織、プロダクト開発にしていきたいか

一人ひとりのメンバーがこのチームにいたことで成長した、と言えるようなチーム作りをしていきたいです。もちろん会社である以上、チームのミッションや目的は事業方針を無視した計画は実現できません。

ですから、マネジャーとしては本人の目指すキャリアの方向性を重視しながら会社の目指す方向性とすり合わせ、メンバー各々が望むキャリアを実現する手助けをしてあげたいと思います。いわば、サーバントリーダーシップのような形ですね。

プロダクト開発としての展望は月並みかもしれませんが、ユーザーが望むものを素早く価値提供していけるチームになりたいと思います。

おわりに

チームの重要な役割を担いながらも、プライベートでは3人の父親でもある堺。フリーロケーションやフレックスタイム制度を活用しながら、仕事と家庭の両立を図っています。

スクラム開発をチームに取り入れ、文字通り一丸となってユーザーに高い価値を提供し続けるエンジニアリングチームの今後にご期待ください。

勇者と魔王の世界観で語るKPI

f:id:iplugtatemi:20201014190822p:plain 今回は「最高の結果を出すKPIマネジメント」という本を読んで得た要点を、勇者と魔王のファンタジー世界観になぞらえて書いていこうと思います。

はじめまして。プロセスソリューションチームの立見です。

いきなりですがチームの紹介から。 プロセスソリューションチームは社内業務を効率化することでサービス価値を向上させるミッションを持ったチームです。主に社内業務に関する技術的サポートや社内業務を通じてサービス価値を向上させる提案から開発まで行います。

今回、チームのミッション達成度合いをどのように測るかを考えまして、KPIによって実現できるのでは無いかと思い下記書籍を読みました。

「最高の結果を出すKPIマネジメント」 https://www.amazon.co.jp/dp/4894519844

この本を読んで得たことを、勇者と魔王のファンタジー世界観になぞらえて書いていきます。 なぜわざわざファンタジー世界観を使うのかというツッコミは無しでお願いします。固い言葉が並んでいると眠たくなるからです。

勇者と魔王のファンタジー世界観

f:id:mayumi-matsuda:20201027155751p:plain

ーーここは人口1,000人ほどの小さな村。 この村は魔王とその配下である化け物によって平和を脅かされています。 このままでは村の人間が絶滅してしまいます。 魔王を討伐して平和を手に入れ、人類を繁栄させるべく勇者が立ち上がりました。ーー

ゲームでよくある世界観ですね。

果たして何がどのくらいになればこの村の人類は繁栄できるのでしょうか?

KPIを設計して数値管理してみましょう。

まずKPIとは

KPIとはKey Performance Indicatorsの略で、日本語にすると「重要業績評価指標」と呼ばれるようです。 書籍では以下のように説明されています。

KPIとは、「事業成功」の「鍵」を「数値目標」で表したもの

私はKPIという文字自体はなんとなく知っていたものの、事業の重要な数字が並んでいるものくらいの印象しかありませんでした。

何も考えずにKPI設計してみる

さて、何がどれくらいの数値であれば、この勇者と魔王の世界において、この村の人類は繁栄できるのでしょうか? うーん・・・、魔王によって平和を脅かされているし、たぶん以下の要素が重要なのではないでしょうか。

  • 勇者の強さ
  • 勇者の武器の強さ
  • 勇者の防具の強さ
  • 勇者が行動するためのお金の量
  • 魔王の強さ
  • 配下の化け物の量

これらをそのままKPIの項目にしよう!全部重要そうだし。

勇者の強さ 武器の強さ 防具の強さ お金の量 魔王の強さ 化け物の量
? ? ? ? ? ?

あとはそれぞれの項目の目標数値を決めれば完璧だ!!!

この時点でイケてないKPI設計をイケてるKPI設計にする

残念ながら、この時点でイケてないKPI設計なようです。 なぜ?全部重要に思える項目なのに!

その理由は、以下の3点が原因です。

  • KGIに繋がるように設計していない
  • CSFが不明
  • KPIがたくさんある

では、イケてない理由の詳細と、どのように解決したら良いかを見ていきましょう。

イケてない理由その1「KGIに繋がるように設計していない」

KGIとは、Key Goal Indicatorsの略で、最終的な目標数値です。 最終的に何がどのような数値になっていれば良いのか?を表すものです。数値という言葉どおり定量的な指標が望ましいとされています。

また、KPIはKGIにつながるための指標にしなければなりません。

今回の世界観のKGIは何か?

KPIをKGIにつながる指標にするため、まずはKGIを確認しましょう。

魔王を倒せば平和になって人類は繁栄できるのだから、KGIは「魔王の生存数=0」でしょ! と思われる方もいるかもしれません。

しかし本当にそうでしょうか? 最終的に達成したいのは村の人類の繁栄ですね。 ですので、KGIは村における人類の繁栄を数値に置き換えたものになるはずです。

人類の繁栄を数値に置き換えると何になるでしょうか?人口?文化の発展度?村の魅力づけ? 色々あると思いますが、この記事ではKGIを「人口=2,000人」にしたいと思います。 実際の業務でのKGIは、事業の戦略資料に書かれていたり、事業計画資料に書かれていたりするはずです。確認してみましょう。

KPIがKGIと繋がっていない?

さて、KGIを「人口=2,000人」としました。 改めて、先に設定したKPIを見てみましょう。

勇者の強さ 武器の強さ 防具の強さ お金の量 魔王の強さ 化け物の量
? ? ? ? ? ?

今のKPIはKGIと繋がっているでしょうか? 勇者が強くなれば人口は増えるでしょうか?人口の減少が止まるでしょうか? 関係はあるかもしれませんが、直接繋がっていないように思えます。 これでは、今のKPIをどれだけ管理しても、人口にどのような影響があるかわかりませんね。

イケてない理由その2「CSFが不明」

続いてのイケてない理由は、CSFが不明である点です。

CSFとは、Critical Success Factorの略で、重要成功要因です。 KGIを実現するための様々なプロセスの中で、最も重要なプロセスのことを指します。プロセスですので、これは定量に落とし込まなくて構いません。

では、この世界のCSFを見ていきましょう。

今回の真のCSFは何か?

イケてないKPIでは、魔王によって平和を脅かされていることで繁栄を阻害されているのだから、CSFは「魔王を討伐すること」であると考えました。 本当にそうでしょうか? 今回のKGIは「人口=2,000人」です。現在この村には1,000人ほどしかいませんから、あと1000人増やす必要があります。

人口が増える方法を探るために、まずは人口が増減する要因について冷静に分析してみましょう。 その結果、人口増減の要因が下記のようにわかりました。

人口増減の要因

増加要因 f:id:mayumi-matsuda:20201027193712p:plain
  • コウノトリにお願いするたびに子供が生まれる。現在は毎月だいたい6人くらい赤ちゃんが生まれている(コウノトリお願い率)

減少要因
f:id:mayumi-matsuda:20201027193723p:plain
  • 魔王や魔王の配下によって危害を加えられた人が平和な村へ引っ越す。月にだいたい3人(魔王の影響による引っ越し率)
  • 怪我や病気で隣町の病院へ入院する。月にだいたい5人(入院率)
  • 第二の人生を平和な街で過ごすために引っ越す。月にだいたい2人(余生まっとう引っ越し率)

これらを人口に与える影響として数値化させます。

増加要因
コウノトリお願い率
6人 / 1000人 = 0.6%

減少要因
魔王の影響による引っ越し率
3人 / 1000人 =0.3%

入院率
5人 / 1000人 = 0.5 %

余生まっとう引っ越し率
5人 / 1000人 =0.2%

どうやら魔王やその配下による影響よりも、それ以外の部分が大きく人口に影響を及ぼしているようです。 人口がどのように成り立っているのか式で表すと下記のようになると思います。

人口=生存者数+生存者数×コウノトリお願い率−(生存者数×魔王の影響による引っ越し率+生存者数×入院率+生存者数×余生まっとう引っ越し率)

1ヶ月後の人口予想をこの式に当てはめると

人口=1,000+6−(3+5+2)=996人

になります。 もし魔王を倒してその影響が無くなったとしても

人口=1,000+6−(0+5+2)=999人

と、減少の一途をたどってしまいます。

どうやらKGIの「人口=2,000人」を達成するためには、下記の要因のほうが重要なようです。

  • コウノトリにお願いし生まれる赤ちゃんを増やす
  • 病気や怪我を予防して隣町の病院へ入院する人を減らす
  • 老後の引っ越しを認めないようにする

この中で「老後の引っ越しを認めないようにする」は、不可だと思うので外します。コントロールできないことをCSFにしてしまうとどうしようもありません。 とすると残った「コウノトリにお願いする」ことか「予防する」ことがCSF候補として考えられます。

赤ちゃんは現状ではだいたい月6人生まれるのに対し、入院者数は現状だいたい月5人、かつ入院率よりもコウノトリお願い率のほうが人口への影響が大きいため、今回のCSFは「コウノトリにお願いする」にしようと思います。書籍によると、CSFを一つとするのは重要なようです。なぜ重要かは後述します。

イケてない理由その3「KPIがたくさんある」

ここまでは、KGIとCSFを確認しました。いよいよ、KPIに挑みます。

現在、イケてないKPIでは項目が6つあります。 なぜそれがダメなのでしょうか?

KPIがたくさんあると・・・

書籍では、KPIは信号だと例えています。 KPIが達成できているのであればそのまま進め、KPIを達成していないのであれば何か問題が起きつつある。KPIが大幅に未達であれば今の戦略や戦術を見直す必要があると判断できます。

しかしKPIがたくさんあると、今のままでいいのか何か方針転換したほうがいいのか判断しづらくなります。 例えば勇者の強さは達成しているが、お金の量が足りていない場合、どうすればいいのでしょうか。 このまま進むことで本当に目標を達成できるのでしょうか?判断に迷いますね。

改めてKPIを考えてみる

kpi

初めの方でKPIの説明を書籍から引用し下記のように書きました。

KPIとは、「事業成功」の「鍵」を「数値目標」で表したもの

ここでいう「事業成功」とは、KGIである「人口=2,000人」 「鍵」とはCSFである「コウノトリにお願いする」と決めました。

KPIとは「鍵」を「数値目標」で表したものなので、 KPI項目は「コウノトリにお願いした件数または率」となります。

CSFが多くあるとそれに従ってKPIも多くできてしまうので、CSFを1つに絞ることは重要なんですね。

数値目標
人口=生存者数+生存者数×コウノトリにお願いした件数−(生存者数×魔王の影響による引っ越し率+生存者数×入院率+生存者数×余生まっとう引っ越し率)

であるならば

例えば1年(12ヶ月)で「人口=2,000人」を達成するのであれば、コウノトリお願い率を7%くらいに引き上げれば達成できそうです。

f:id:mayumi-matsuda:20201027155335p:plain

最終的なKPI

これらのことから、人類の繁栄を達成するためにKPIを「コウノトリお願い率を7%にする」ことにしました。 勇者は魔王を討伐するより、コウノトリの魅力を布教するほうが、結果的に人類の繁栄に貢献できるわけですね。勇者とはいったい・・・ウゴゴゴ・・・

まとめ

  • KGI=最終的な目標を確認する
  • CSFを1つに絞る
  • KPIは、KGIを達成できるCSFの数値目標
  • KPIが多くあるものは良くない

最後に

今回は書籍にかかれているうちの一部をファンタジー世界になぞらえてまとめてみました。 まだまだ本稿に書ききれていない良い部分は多くあります!

立見 洋樹(プロセスソリューションチーム マネージャー)

10年くらいアプリケーションエンジニアでした。最近はマネジメント一辺倒です。過去エンジニアリングに極振りしていて、最近はビジネススキル習得のためにアンラーニング中です。「怠惰」「短気」「傲慢」をモットーに日々生きています。

i-plugでのグロースハックって何やってんの?

f:id:mayumi-matsuda:20201014104811p:plain

今回はi-plugでのグロースハックの取り組みについて紹介します。 i-plugのプロダクト開発はいくつかのチームに分かれてしていますが、グロースチームではプロダクトの質的改善を探索的に行っています。まずはグロースハックを始めた背景や実際の取り組みの概要について言及します。

自社サービスの開発/運営をされている方にとっては、開発プロセスの改善やビジネス貢献につながる案件の考え方の面で参考になる部分があるかもしれません。

自己紹介

グロースチームのマネージャーをしている小西と申します。 2018年2月に未経験エンジニアとして入社し、2019年10月にグロースチーム発足と同時にマネージャーに就任し、今もそのまま仕事をしています。

ABテストやデータ分析を通して、プロダクトや顧客について新しいことがどんどんわかっていく瞬間が好きです。

グロースチーム発足の背景

チームが組成される以前は、事業そのものは成長しているものの、プロダクト側から大幅な質的改善ができていないという状況でした。そこで、2019年10月にグロースチームを発足。以来、開発だけでなくマーケットやデータサイエンスなどの見地も織り交ぜることで、ユーザーや市場を理解した上で機能を開発しサービスの改善に取り組んでいます。

なので、グロースチームの目標は、ユーザーのニーズを理解したうえでプロダクトを最適化しビジネスに貢献することです。 現在のメンバー構成は私とエンジニア2名、データサイエンティスト1名の計4人です。

まず案件の質についての考え方を改めた

本題に入る前に、グロースチームでは案件の質について改めて考えるようになりました。 案件の質というのは「その案件がユーザーにどの程度の価値を提供できるか(施策効果)とその確率(施策確度)」のことです。

きっかけは、限られたリソースの中で結果を出すためには、見込みの薄い案件を実施してしまうのはロスが大きいと気づいたためです。

では、どのように見込みの施策効果と施策確度を判断しているのか。グロースチームでは、「起業の科学」という書籍に出てくる課題仮説、CPF、PSF、MVP/MVFという考え方を非常に参考にしています。

f:id:iplugkonishi:20201013160040p:plain

要は、

  • ユーザーの課題について仮説を立てて(課題仮説の設計)
  • それに当てはまるユーザーが存在することを確認して(CPFの検証・完了)
  • そのユーザーに刺さりそうな施策を検討して(PSFの検討)
  • 小さくテストして検証して(MVP・MVFによる検証)
  • 本実装ややり直し、撤退の判断をする

ということをそれぞれの案件について実施しています。

これらを実施することで価値のありそうな案件を効率良く提供することにつなげています。

開発プロセス/業務サイクルについて

ここでようやく、グロースハックとは具体的に何をしているのかという話になるのですが、

  • 課題仮説、CPF、PSF、MVFの流れを
  • エンジニア、データサイエンティスト、デザイナーなどで協業しながら
  • 柔軟に意思決定しつつ実行する

というサイクルを早くたくさんこなすというところに尽きるかと思います。

OfferBoxは新卒採用における学生と企業をつなげるプラットフォームでして、彼らがどんな学生/企業と出会いたいと思っているのか、そのために何を参考にどう判断/行動しているのか、そうなるのは何故なのかを理解できないと的を射た機能改善はできないという発想で業務を行なっています。

これは課題仮説という言葉の通りで、施策ありきではなくあくまでユーザーの課題やニーズありきで物事を考えているということになります。

ただ、筋の良い仮説を立てたりユーザーの心理/行動を理解したり、的を射た施策を打ったりするためにも様々な専門性が必要になるので、色んな職種の人が集まって協力をしながら案件を進めています。

前述のとおり、もともと当社における開発のプロセスでは、課題仮設からMVPによる検証のサイクルを実施できていませんでした。フローを比較すると、以下のような差がありました。

f:id:iplugkonishi:20201013155848p:plain
※検証サイクルが出来ていない開発フロー

f:id:iplugkonishi:20201013192350j:plain
※課題仮設からCPF、PSF、MVP/MVFを重視するフロー

今回は初回ということでざっくりとグロースハックの取り組みの背景や全体像についてご紹介しました。今後はもう少し各論の案件の作り方、異なる業種での協業の仕方、仮設検証の仕方、データサイエンティストの活躍などをご紹介できればと思います。

最後までご覧いただきありがとうございました。