「突撃!隣の会社のプロジェクトマネジメント!!」第2回目は、ホームズくんでおなじみのLIFULL HOME’Sでデザイナーをされている小林さんをお迎えして、どのようなプロジェクト運営をしているか、チーミングの特色や、メンバの育成などについてお話いただくくことになりました。
まずは、小林さんについて。
小林武蔵さん
LIFULL HOME’S事業本部
開発されているアプリ
賃貸/売買物件・マンション・アパートなど不動産情報はLIFULL HOME’S/
ライフルホームズアプリ
小林さんについては第1回のゲストの千歳さんもインタビューされていました!
「HOME’S」の超高速改善プロセスの秘密とは?!大規模サービスにおける
プロジェクト管理の最前線を丸ごと聞いてきた
(こ)小林さん
(い)稲山
(も)森實
グラフィック 高柳
撮影 野村
■デザイナーというお仕事について
(い)早速ですが、どのようなデザインのお仕事をされているか教えてください。
(こ)以前はWeb畑でデザイナーをしていて、PC・モバイル(ガラケー)やエディトリアルデザインと色々な媒体で学ばせていただき、現在はネイティブアプリに注力しています。
(い)Webデザインはブラウザ、エディトリアルデザインやスマホアプリと色々な媒体に携われると、それぞれの媒体による違いに気づかれることがあると思います。それぞれの特徴にはどのようなものがありますか。
(こ)デザインの根本は同じだと思っています。ただ、媒体ごとの特色はもちろんありますので、Webデザインができる人でもアプリらしさを考える必要はあります。
(い)Webやアプリにより媒体自体に違いがあったり、制約から感じられるものでしょうか。
(こ)それぞれの制約が「らしさ」に繋がるかと思います。例えば、Webの場合はPC・スマホ・タブレットで閲覧できますが、それぞれのデバイスでユーザが期待することが少し変わると思ってます。スマホではサクサクと情報が閲覧できること、PCでは詳細な情報がたくさん載っていることなどです。
それを把握・考慮しないでアプリデザインをしてしまうと、Webからアプリに移しただけの評価になってしまいます。ユーザは手間を掛けてアプリをインストールしているので、Webよりちょっと何かよい体験を期待すると思います。
なので、アプリらしさを理解して作らないと、アプリにおける上手なデザインはできません。
(い)若いユーザ層のインターネット利用は、ネイティブなスマホアプリから入っているのでそういった期待は大きかったりするのでしょうか。
(こ)Webは「検索した結果を閲覧する」という使い方をします。アプリは「ユーザが自らインストールする」というステップがあるので、その手間に見合った付加価値を求めます。
若いユーザ層がアプリから入るのが普通なのであれば、今後は逆にWebでわざわざ検索しているのだから、という変化が起きるのかもしれませんね。
(も)インストールすることでユーザ自身が理由づけをして期待値も上げてしまっていると。
(こ)期待値はアプリの評価にダイレクトに返ってきますが、日本人の評価は厳しいとGoogleもいっています。なので、そういったアプリに対する期待はあるんだろうなと思います。
(い)アプリ開発でのチーム人数は何人くらいですか。
(こ)最小単位は2人で、デザイナーとエンジニアになります。少しでもユーザ体験に影響がある場面では、デザイナーも一緒に施策を進めます。
それとプロジェクト難易度により、プロジェクトマネージャ(以降PM)がジョインしたり、ディレクター・エンジニアを増員し、平均3−4人の体制で動くことが多いです。
(い)PMの方が入るのは3−4人になってから。
(こ)人数より施策の内容・難易度ですね。例えば最小単位が2人とお話したのですが、ユーザ体験に関わらないところでエンジニア1人で完結するときもあります。エンジニアもデザイナーも1人ずつでいいが、仕様や要件の影響範囲が広いときなどは、エンジニアとデザイナー以外の視点も大切なので、PMが入ってきて全体をコントロールします。
(い)開発したいものにより使い分けている。
(こ)2年ほど前にアジャイル開発を取り入れてますが、馴染むまで苦戦しました。修正や追加案件が出てきたら「次のスプリント」となるのは本来あるべき動き方なんですが、ウォーターフォールだとそれらを含めてやれていたので、それができなくなることでのメンバーのストレスや動きにくさに繋がる部分でもありました。
まずはそれぞれの開発の型にはめて動き「このチームだとどう開発していくのが一番効率いいだろう」をいろいろと試していきました。
結果としては、仕様やデザインはスプリントから外してウォーターフォールで行う。その後の開発をアジャイルで進めるようにしました。このやり方だと、みんながやりたいように動けてフラストレーションもそれほどなく、開発スピードも出ることがわかり、当時はハイブリッド型開発という呼び方をしていました。
とはいえ、このやり方がアプリ開発チームにフィットするまで、1年半くらい掛かっています。
(こ)過去に類似した施策があればその知見と、施策の影響範囲をみんなすり合わせることで、ある程度使い分けはできるようになると思います。
影響範囲が狭く、エンジニアの作業で完結するようなものであればアジャイル、各種調整が必要で、影響範囲も広い場合はまずはウォーターフォールで動き出しましょう、という具合です。
■継続的な改善について
(い)チームのメンバ同士で、開発や改修を通して繰り返し話題に登るテーマはありますか。
(こ)ナレッジが弱いという問題があります。全員が毎回同じメンバならドキュメント化は不要かもしれませんが、新卒も加わりますし、組織変更も考えられます。
属人化したり、ドキュメント化されないことナレッジが蓄積されないことに対して、解消していこうという流れはありますし、成果も徐々にでてきていますが、まだ最適化・きれいに仕組化されていないという状況です。
(こ)リリースしたら、ふりかえり会をKPT法で行っています。ただ、「ふりかえり会をやった」ところで終わってしまうという問題があります。Problemは直さないと次に繋がらないし、それをやらないとチームの成長に繋がらないと思っていますが、どうしてなかなか。
(い)KPTのProblemで出したProblemをTryにできていない。
(こ)Tryを出したら満足してしまっているのだと思います。本当にTryをしないといけない致命的なものは対応するのですが、それ以外は優先度が低く、取り組めなかったり、次のふりかえり会で同じTry項目がでるなんていうことも稀にあります。
(い)大切なProblemは改善できているけれど、それ以外まで手が回っていない。
(こ)はい。致命的なものだけが大事ではないとメンバも理解していますが、優先度が上げられない。
例えば、普通の操作でクラッシュしてしまったら「全員で即座に共有して対応する」というようにスピード感をもって対応できているのですが、普段、施策に取り組んでいるときは、作業時間を削ってまでTryに取り組むことが出来ていないのはチームの課題です。
(も)KPTのTryにAction planのAを付けてPlanまで落として回した方がいいというやり方があります。
(こ)そのActionのように具体的に何をすればいいかまで落とし込むことや、そうした取り組みのリーダシップを取る人を情熱リーダとして立て、Tryで出来ていないアクションを少しずつ改善していこうと取り組み始めています。
■チームの役割について
(い)チームを組むと価値観の違う人が集まってきます。エンジニアとデザイナーとは専門性が違いますし、エンジニアでもアプリとインフラでは専門性に違いがあります。そういう人達が集まったときにプロジェクトをやっていく上で何を大切にしますか。
(こ)一番大切にしたいことはユーザ体験です。収益や工数とかは一旦置いといて、どんな体験・価値提供をできるかどうかを考えます。その上で、もちろん後者についてもちゃんと考えます。
(い)何か、きっかけがあってユーザファーストになったのですか。
(こ)会社として、ステークホルダーを大事にしましょうという考え方があります。特にデザイナーという職業はBtoBやBtoCに関わらず「情報が正しく、わかりやすく、伝わっているか」を常に考えている人たちなので、相手を大事にしたモノづくりというスタンスは自然なものだと思います。
社是に掲げている「利他主義」は採用や評価でも最も大事な価値観としているので、それに共感する人しかいません。だからユーザー(相手)を大事にするという考え方がズレにくいのだと思います。それが結果として、売れるもの=ユーザが欲しいもの・必要なものとなって収益に繋がります。
ユーザファーストを大事にしていますが、掛けるリソースに対して少ないユーザの価値しか産めないこともあるので、そういった場合はユニット長が「本当にそれでいいの?」と助言してくれます。
(い)長は役割を果たされている。
(こ)おそらく常に注意を払ってくれていると思います。「いいじゃん」と褒めてもらえるときもあれば「どうなってる?大丈夫?」と停滞してしまっているときにお尻を叩いてくれる役もしてくれます。
メンバーが施策に熱中して、アクセルを踏み込みすぎて、ハンドリングがおろそかになるときがあります。そういったときに俯瞰して見てくれているPMがいると、心強いです。
■メンバの成長について
(い)チームの価値観は揃っているようですが、そうした中でも意識的に取り組まれていることはありますか。
(こ)施策毎に育成コストが掛かっても個人が成長できるように意識しています。
内製にこだわっているところにも関係するのですが、誰かが不在になっても、残りのメンバーである程度開発を回せるようになるのが理想ですね。
2、3年目のメンバに難易度の高い仕事を振りつつ、先輩が見て品質を確保するようにし、経験と知識を養っていくイメージです。その分コストは発生しますが、サービスを育てるのと一緒に人も育てていかなければならないし、育てていきたいと考えてます。
(い)エンジニアやデザイナーに関わらず、若いメンバに仕事を任せている。
(こ)僕は成長は筋トレだと思っています。今できる100%で仕事をこなしても成長しないと思っているので、105%の仕事をお願いするようにしています。この5%をクリアするために、やりながら成長しないといけない。そこはインプットしてもらうなり、アドバイスしてあげるなりしてやり抜いてもらう。それを繰り返して、当初の120%の力がついている、というスタンスでやっていいます。
ただ、時には気持ち良くやりきれないと楽しくないと思うので、100%の施策をお願いして、本人に「出来た」と実感してもらうことも大事だと思います。
(も)成長が感じられますね。
(こ)こちらとしても嬉しい瞬間ですね。逆に120%の施策をお願いすることもしてます。「まかせたよ!」と。ぶん投げることで、こんなに大きな仕事を任された、とワクワクしてもらえれば成功ですね。
(も)僕もそれをするとワクワクしてくれます。お話を伺っていると一人ひとりの意識が高いと感じました。
(こ)「自立して、自律して、自走する」ということをユニット長は強くメンバーに意識をさせています。仕事の作り方じゃないですけれど、そういった働き方に導いてもらっていると思います。
(い)仕事の作り方ですか。
(こ)例えば自分が作っているアプリでも改善できるところはあるはずです。だったら、自分で見つけて、ここが使いにくいからこうしたほうがよいから提案する、という考え方を持とうと。
■チーム運営について
(い)チーム運営で大事にしていることには何がありますか。
(こ)これは完全に個人的な考え方という前置きをして(笑)
敵を意識してもらうようにしています。好敵手としての競合もそうですし、空想上の「こんなチーム・働き方は嫌だ」を伝えて、方向性やあるべき姿を伝え、共有するイメージです。
(い)小林さんの考えはどこで身につけられたのですか。
(こ)小6からダンスを習い始め、たくさんのチームで踊る中で、同じ目標を共有できていないチームは成長しないと強く感じることがありました。大儀を共有できると一番いいのですが、そこまでのプロセスとして、方向性や意志の部分の負けん気だったりを共感するとうまくいくことがあったので、そのあたりですね。
(い)会社の文化であるユーザファーストがあったり、みんなが揃ってやっているなど良い会社だなと感じました。機会があればぜひ一緒にしたいですね。
(も)今の大事にされていることは観察眼がない人には出来ないことだと思いました。チームの中でコミュニケーションは測定してといっても測定出来ませんし、飴と鞭の使い処もその人をどう見ているかです。
意識はされないのでしょうけれど、僕たちはこうしていこうとアクションがなかなか生まれないことに対する1つの解なのかもしれません。
僕らは目標をどこに設定して、どこを目指そうとすることはとても大事だと思います。
片やアンチパターンというチームの悪を共有するのがありましたが、普通はこの2つを両立させないと僕は思います。
なぜなら、僕達はこれを目指しているんだといったらそのためにどうあるべきかを解こうとするから。どうあるべきかを解いてしまったとき、みんなはそれであることを求めてしまい自分で考えることを失ってしまうという意味でチーム自体がどうあるべきかを考えるようにしているからコミュニケーションが成り立っているのだと感じました。
(こ)その人の正義を知るより悪を知る方がコミュニケーションをする上で大事だと思っています。
その人の悪に触れずに上手に接することでコミュニケーションは円滑になると思うんです。必要であれば折に触れてつつきますが。
(い)相手の性格を知るってことですね。
(こ)そうですね!性悪説派なので、正しいってなんだろうを考えたいというのが根底にあって、そういった思考で物事を見ているんだと思います。
(い)相手を理解しようとしたことの行動が先に出ているのだと思いました。スマホアプリというプロダクトに携われているとSIerのエンジニアとはかなり違いがあることを気づきを得ることができました。
本日はお忙しいところありがとうございました。