勉強会を振り返って
五ヶ市壮央（ごかちん）氏（以下、五ヶ市）：ちょうどチームの中でも「カヌーさんの話があるあるすぎて胃が痛い」とか「PMBOK読んだ！」みたいのがあって。shiratoriさんいますか？
shiratori氏（以下、shiratori）：はい。
五ヶ市：shiratoriさん、カヤックさんのセッションを聞いての感想を教えていただいてもいいですか？
shiratori：そうですね。やっぱりこのチームというか、組織と向き合うところに関して、やっぱり相当な覚悟や我慢が必要というところ。この今紹介してくれたのも3年かけてやっとここまで来たという感じだったと思います。やっぱりそういうところを経てやっとここまでいろいろ体制を整えたりできるんだなと思いました。
なので、やっぱりこういうのを、説明すると20〜30分で終わっちゃいますけど、やっぱりそこにこれだけの時間がかかっているんだなというところはひしひしと感じましたというのが感想です。
五ヶ市：高田さん、めっちゃうなずいていらっしゃいます。
高田一史氏（以下、高田）：実は、覚悟があったわけじゃないですよ。ただ私の性格上、身近な人が苦しんでいることに対して、やっぱりなにかしら作用しないと気が済まないたちでして。リーダーになったあとの原体験として、メンバーがどんどん疲れるとか辞めることがある種の起点とか強いモチベーションになっていて、3年続けられたのかなと、今振り返って思います。
と言っても結果を出せてたわけではありません。そのなかで私を同じポジションで据え置いてくれていた事業部長とか役員の人たちには、ほかに選択肢がなかったような気もしますけど（笑）。けっこう感謝すべきかなというのは今聞いてて思いました。
渡邉宇一朗（ういっち）氏（以下、ういっち）：それにちょっとカヌーが言い忘れたから補足すると、めちゃめちゃ人が辞めていたんですけど、この対応に変わってからPMチームは1人も辞めていません。
（一同拍手）
齋藤恵太氏（以下、齋藤）：すげぇ……。へえぇ……。
Michiko Sugai氏（以下、Sugai）：すばらしい。
shiratori：それはなにか、辞めていない理由みたいなのってどういうところにあるんですか？
高田：うーん……最初にあの青い画面で私の独断って入れたじゃないですか。あれ、今日聞いてるメンバー向けの注意書きなんですよ。正直、私はいろんな人に気を遣っちゃうタイプなので、「俺の主観だ！」って最初に宣言して自由にしゃべらせてもらいました。その前提で言うならば、やっぱりやっていることに手応えが出てきたのが大きいのではないのかなと思います。
つまり、PMチーム定例というのが起点になっているんですけど、その定例の中で言われたことを実践してみたりとか。定例の中で何か実践したことが、「あっ、意味があるんだ」ということが体感的にそれぞれ実感できているからこそ、たぶん私が旗振り役で「これやるよ！」って言ったことに対してみんな付いてくる、乗っかってくれるのかなというのが私の察するところです。
五ヶ市：ありがとうございます。
Sugai：じゃあ、私が1つ聞きたいことがあるのでいいですか？ すみません、感想というか、もうちょっと詳しく聞いてみたかったなと思うことがあって。
「知識のアップデートを行なう仕組みをつくる」というところが最後のスライドにあったと思うんですけれども、Goodpatch Anywhereも学びに関して貪欲で、勉強会をかなり頻繁に行ってます。カヤックさんの中でそういう勉強会だったりとか知識のアップデートというのは、何か工夫されていることや「こういうことやっているよ」みたいなのがあったら教えていただきたいなと思って。すみません、感想じゃないんですけど。
高田：大丈夫です。まず、私は勉強が大嫌いです。
Sugai：（笑）。
高田：新しい情報を仕入れるのが苦手で。ただ、案件が1〜3ヶ月のスパンで細かく変わっていくので、その案件の中でいろんな学びを得ているというのが、私の個人的なこれまでのキャリアです。
そんな私がリーダーをやっているチームなので、やはり現在の学びのもとは、それぞれのメンバーが経験した案件。その中で起きたできごとをみんなに共有することで、それを学びとしている。それに関連する新しい情報とかまた別のメンバーが共有することで、世の中の最新情報を知ったりすることがあります。
なので、今はけっこう無策には近くて。だからこそやり方をちゃんと考えなきゃなという思いで、ここの1行を書いたというところはあります。
Sugai：すみません。はい。
高田：エンジニアやデザイナーは、それぞれでけっこう勉強会を細かくやってはいます。
Sugai：ありがとうございました。
2つのクオリティ軸
齋藤：1個めちゃくちゃ難しそうな質問してもいいですか。
高田：はい。
齋藤：たぶんこういう活動のすべてがお互い制作をやっていて、作ったもののクオリティみたいなところに結びついていくものでもあると思います。カヤックさん的には「何をもっていいものとするのか？」みたいな基準ってありますか？
高田：これ、ういっちさんにパスしてもいいですか？
Sugai：（笑）。
高田：なにか確か用意してくれたはずなんですけれども。
ういっち：クオリティって何なのかみたいな定義の話だと思います。まず、クオリティには1つのラインがあると考えていて。お客様の要望のラインは、絶対に満たしていないといけない最低のラインです。その上でいかにプラスアルファの付加価値をつけるかというのがクオリティの勝負だと思っています。
付加価値というのは、そのプロジェクトでさまざまだと思っているんですよ。例えば、お客さんの要望はABCを一画面に表示することだった場合とか。意図を理解して見せ方を工夫して、Aを大きく表示するものというのも1つのクオリティアップだと思うし、なにかAにアニメーションをつけて強調するのもそうだと思います。他にも機能的に「ここはARで見れるようにしよう」とか、それもクオリティアップだと思うし。
だから、そういういろんなクオリティの概念があるなかで、バグがいかに少なくてパフォーマンスが高いかという面。いかにハイセンスでよいと思われるものを乗っけられるかという2つのクオリティ軸があると思っています。その両方を突き詰めていくのがうちが判断するクオリティかなと考えています。
あとはもう1個考えているところがあって、単なるクオリティではなくて、時間内クオリティを見るのが大切と言う点です。
時間をかけていいものを作るのはけっこう当たり前。我々がやっているのはプロジェクトなので、限られた時間内でいかにさっき言ったような2軸のクオリティを高められるかが重要かなと考えてプロジェクトを回しています。というのが答えですが、答えになってますかね？
齋藤：ありがとうございます。その2軸がマトリクスになっていて、このプロジェクトはお客さんの要求を満たしている。しかし、イケてるかというと「うーん……」みたいのがいろいろポジショニングされていて、そこに全体に対して時間だったりとかコストというところにもプレッシャーがかかっているみたいな考え方ですかね。
ういっち：そうですね。2軸というよりか、たぶんお客さんの要望というのはベースラインがあって、そこは超えた上でいかにおもしろいものを乗っけられるかどうか。お客さんの要望を感動に変えるかみたいな。イメージ的に、たぶんそこを超えていけるジャンプラインみたいな感じですかね。
齋藤：もう僕も完全に同じような考え方をしていて、やっぱり2階建てかなっていう感じはします。お客さんの要求しているものに対して最速で達成してから、あとはそこに遊びがつけられるかどうか。
とくにじゃあUIとかのインタラクションをちょっと小粋なものをつけれる領域って、完全にここでしかないと思っているので。あとは、なにが評価されるかみたいなところであったり、新しい何かを生み出せるのかみたいにジャンプアップをする領域がそのお客さんの最低ラインの上に乗っかっているみたいな感覚で見ています。
ういっち：そうですね。
齋藤：そこに最速で達成するみたいなところにいかないと、残りの期間もないしお金を使い果たしちゃうみたいのがあるから、時間管理めっちゃ大事と思っています。
ういっち：わかる。
齋藤：いやー、大変やで。
（一同笑）
Sugai：大変やね（笑）。
齋藤：はい、ありがとうございます。
チームの評価方法
ういっち：おっ、「カヌーさんに質問です」って書いてあるけど。
齋藤：おっ、どこですか？ コメント来ましたね。
ういっち：チャット、チャット。
齋藤：「カヌーさんに質問です。PMの評価やKPIなどはどのように設定？ 個々、またはPMチーム全体でなにか教えていただけると幸いです」。人事的な価値観でしょうか？ PMがどのように評価されるのか。
高田：これはたぶんお給料につながる人事評価ということだと思います。その前提で答えますと、弊社は360度評価という定性的な評価を採用しているというか、それがベースになってまして。最近またルール変わったんですけど、去年までは半年に1回（現在は四半期ごと）、例えば私が渡邉をコメントで評価したり、逆に渡邉が私をコメントで評価したりしていました。他にも、半年間の働きに対して自己評価を書いて、それに対して他者が評価してくれるスタイルで評価をしています。
その定性的評価をもとに給料ランキングがつけられて、それで給料が決まります。なので、人事的な評価という意味でいうと、明確な基準とか点数とかはありません。かなり定性的、感覚的な評価に近いです。
今PMチームとしてやっているのは、現在実行していることとしては、プロジェクトごとにプロジェクトの成功基準を明確に設定して、それでプロジェクトが成功か失敗だったかを定例で共有するようにしています。
失敗もまだまだ多いんですけど、失敗を責めるとかもありません。失敗からどういった学びをみんなに共有できるかというようなマインドで定例で共有しているというのが、PMチーム内の評価とかKPIに一番近しいといころです。
さっき展望の部分でお話しましたけど、現状はさっき話したような状態なのですが、ちょっとよりどころがなさすぎるよねとも感じています。PMだったら「レベル1はこれぐらい。レベル2はこれぐらい。レベル3、マックスはこれぐらい」みたいな3〜4段階ぐらいを定量的な基準で設ける。自分がPMとしてどれぐらいのレベル感にいるんだということを客観的に把握できるような、評価シートを現在、準備中です。
齋藤：プロジェクトの成功基準って、自分たちもしくは、チームで決めるんですか？ それともある程度ちょっとシニアであったりとかマネージャークラスの方が設定していくみたいなことですか？ それとも営業の段階で話をするとか。
高田：主にクライアントから与えられるものが最初に来ます。例えば、「何千ツイート達成したいです」や「PVは何PV達成したいです」とか。弊社が作るものがまだプロモーションで使われるものがけっこう多いので、そういったところは共通の成功基準としてあります。
社内、カヤックの内部的で設定しているのは、案件の納期です。これはどのプロジェクトでも絶対共通の項目として入ってきます。
その設定はPM自身が行って、ステークホルダーに対して「今回のプロジェクトの成功基準はこれでいいですね？」ということを確認とりましょう、ということにはしています。
齋藤：ありがとうございます。
