エンジニアは神様でも奴隷でもない

最近はチームに恵まれているので使う機会がないが、私がよく使う言葉に 「エンジニアは神様ではない」 がある。

これは別に「俺は神様じゃないから何でもできる訳ではない」 の意味ではない。

エンジニアと一緒に働くエンジニア以外の人種は、大きく2つのタイプに分かれていると感じている。

  • エンジニアを使うタイプ
  • エンジニアにお願いをするタイプ

私がこの言葉を投げかけるのは、主に後者のタイプへ、である。

人はどんなチームで働きたいのか

後者には続けて、このような説明をする。

「そんな一々頭を下げて自分に作業をお願いをするような事をしないで欲しい。 私とあなたの間に上下関係があるならまだしも、特にそういうものはない。 (なんだったらあなたの方が若干ポジション的には上とも言える。) 私は問題解決の手段としてプログラミングというちょっとレアかもしれないスキルを持っているだけだ。 ただそれだけの理由で、チームメイトからお願いされるような立場になりたくない。 フラットに、それぞれがそれぞれのスキルを駆使して物事を解決するチームでありたい。」

私がこう思うのは、純粋にその方が物事は上手く解決できるし、風通しもよく働きやすいからだ。

本当のところ「お願いされるような状態」が発生するには、色々理由もあるだろう。

  • エンジニアの工数が極端に足りておらず、お願い合戦になっている
  • エンジニアの立場が非常に高い職場である
  • 面倒くさい人だと思われており、できるだけ面倒が起きないように扱われている

どれも根深そうに見える。 が、そうでもない。 「俺はお願い合戦とか非効率だと思ってるから」「エンジニアの立場が異常に高い職場だと思ってるけど、それ行き過ぎだと思ってるから」「俺が面倒くさいかどうかはさておき、お願いとかされるチームで働くの嫌だから」 と言い続けると、案外これらは解決する。

だいたい、解決したあとのほうが働きやすいし、チームの団結もできる。

何を言いたいのかというと

神様みたいに扱われてる職場では、自分、及び所属チームの力を発揮できていないと思うぞ。 それは周りのパフォーマンスを出し切れていないからだ。 それは逆に奴隷のように使われている職場でも同じだ。 声のでかい奴が偉そうに君臨して、周りのパフォーマンスを落としている。

チーム全体が最高のパフォーマンスを発揮している所でこそ、自身のパフォーマンスも、成長も有るのだ。

あなたの職場のリーダーって何をする人ですか?

タイトルの通りなんですが、リーダーって何なんでしょうね?
wikipediaさんによればこんな感じ。

leader 先頭となるもの。
グループ、集団を代表、指導、先導、統率する存在

役職としてのリーダーってのもありえるんでしょうけど、僕はこれ、納得できていません。

職位が上がればリーダー

昇進するとリーダー職になる。
みたいなのってありますよね。 でもこれおかしいなって思ってます。

僕にとっては、リードしてる人=リーダー と思っています。
技術的にリードしてるからリードエンジニア。
プロダクトの行く末を常にリードしているから、プロダクトリーダー。

リーダーって役割じゃないですよね。

リーダーになるためにはマネージメント力が必要?

リーダー職はマネージメント力が必要。みたいなところありませんか?
これもおかしいですよね。
マネージメント能力が有ることと、何かをリードしていることは全く別のものです。

また、マネージメントできるからリーダーというのもおかしな話です。
現場管理はできるけど、プロダクトグロースは何も出来ないタイプの人もいますよね。
ひたすら調整が旨いとか、資料作りが旨いみたいな。
それを否定するつもりはないけど、チームのリードはできてないじゃん。みたいな人結構居ます。
こういう人たちをリーダーって呼びたくないんですよね。リードしてないから。

リーダーは任されるものではなく、自然に呼ばれるもの

リーダーになりたかったらリードすればよいと思います。
その分野で誰にも負けたくなく、最先端にいたいと思い、常に意識を向け続けることで、
「あの人はリードしている。リーダーだ」と認識してもらえるはずです。

リーダーって役職がある会社は、その実態が伴っているか確認しましょう。
伴っていないなら、その呼称変えませんか?

「貯金を食いつぶす企画」という考え方

先日、「アプリで続きを見る」という導線しか無いサイトがプチ炎上していたのを見て思ったことがある。
それは「貯金を食いつぶす」という考え方だ。

浅はかな施策だ

この施策はつまるところ「アプリでしか読めないコンテンツを用意することで、アプリのDL数を上げる」ことが目的と思われる。
この施策によっておそらくアプリのDL数は爆増しただろうことは明白だ。
さて、これによって「売上」は伸びただろうか?

答えはマネタイズポイントによるだろう。
たとえばこのアプリが広告による売上のみであれば、伸びただろう。
単純にアプリの起動回数、起動UUが増えればこの手の売上は伸びる。
そういう意味ではこの施策は正しいと言える。
だが、浅はかだ。

マネタイズ手法によっては、ただの悪手

だが、マネタイズポイントが別なら話は変わってくる。
例えばこのアプリがECアプリなら、何かを買ってもらわなければ意味がない。
何かを買いたいと思っていないユーザが別の理由でアプリをDLしたとしても、それは売上にはつながらないハズだ。
というか実際同様の事例を生で見たが、繋がらなかった。

KPI至上主義が産んだクソ目標

自分がみたプロダクトでは、チームが複数に分割されており、それらのチームは別々のKPIを目標として持たされていた。
当然、各々のチームは目標のKPIを当然追う。
他のチームのKPIを気にしなくなる。それが本質的に追わなければならないKPIだとしても。

あるチームが「会員登録数」のKPIを目標設定されたとしよう。
他のチームのKPIもなにも無視して彼らは「会員登録数」を追いかける。
そこで出たアイデアは「会員登録しなければ、情報の一部が見えなくなる」施策だ。
この施策は大当たりする。

クソみたいな目標でも達成されればそれでよい。誰も大局を見ていない組織

会員登録数を数倍に伸ばしたこの施策は大きく社内で評価される。
担当チームのメンバーは大きな発言権を手に入れ、年収を上げる。
だが、組織の利益はおろか、売上すら伸びない。

無理やり登録させた会員は、売上に寄与しなかった。
とにかく人数がいればよいというようなモデルであれば売上も上がったかもしれないが、そうはイカなかったのだ。

崩壊するモラル。バカだけが生き残る

彼らはこれまでプロダクトが育ててきた「信頼」という貯金を食いつぶして自分の評価を上げたのだ。
くだらない錬金術だ。これまでプロダクトを育て上げた人たちの努力を食いつぶしただけだ。

この時起きた問題は重大だった

  • この無駄な施策によって無能が評価されて他のチームのモチベーションが下がった
  • 既存のブランドが大きく毀損された
  • チームのKPIさえ達成すればなんでもよいという文化が生まれた
  • チーム間に溝が生まれた
  • 売上は長期的には下がった

当然だが、こういう組織からは、優秀な人から順に居なくなる。

本質的な目標を設定しよう

その数値は何のためにあるのか?
会員登録数はなんの指標なのか?
しっかり考えるべきだ。
自分たちが欲しい会員は、自分たちの事業に共感し、納得し、このプロダクトを利用したいと考えている会員であって、コンテンツを読みたいだけの会員ではない。 このプロダクトを利用したいと思わせるためには何をすべきかを考えて、施策を打つべきだ。
つまり、追うなら「一度以上購入してくれた会員数」などだ。これをKPIとすべきだ。

単純なこと

僕らはプロダクトを利用するユーザのためになる施策を打ち続ければいい。
「KPIを伸ばすため」という考え方をすてて、ものづくりの本質を考えていけば良い。
余計なことを考える必要はないのだ。

コードレビューで気をつける言葉や行い

コードレビューにstashを使ってます。
こいつはgitのブランチ間の差分に対してコメントをつけることができるツールです。
ただ、ネットを介したコミュニケーションって何故か気が大きくなってしまったり、感情が見えづらかったりで誤解を生みがちです。
特にコードレビューって間違いを指摘するとかあんまり楽しい会話をするわけでもないので、言葉には気を使わないといけません。
今日は自分が気をつけている言葉や行いを上げてみます。

否定しない

def get_name(name)
  @user.find(name: name) 
end

☓:getは軽量なアクセッサとして使うのが常識なのでやめて下さい。

◯:findしてることが分かるメソッド名が良いです

いちいち否定する必要はないです。素直にどうして欲しいか書きましょう。

否定しない2 「けど〜」

def search(name)
  @user.find(name: name)
end

☓:悪くはないと思うんですけど、find_userがわかりやすいと思います。

◯:ユーザを見つけて返すことが分かるメソッド名がいいですね

けどがコメント中に出てきたら要注意です。
相手に気を使って持ち上げてるつもりでも、けどが出てきた時点で相手は否定されたと受け取る可能性があります。
これも否定せず自分がどうしたら良いと思ってるかだけ書けばよいです。

比較しない 「の方が〜」

☓:find_userの方がわかりやすいと思います

◯:ユーザを見つけて返すことが分かるメソッド名がいいですね

いちいち他と比較しないでいいです。
これも見方によっては否定に見えます。
これをやる場合はある程度根拠を明示した上でやりましょう。

余計なことを言わない

def saerch(name)

☓:typoしてます。searchです。最近確認が甘くありませんか?

◯:typoです

余計なことを言わない。 完全に喧嘩売ってますね。
上下関係があったとしても、コードレビューの範疇から逸脱しています。

命令しない

☓:このコードは汚過ぎでリリースさせることはできません。直して下さい。

◯:口頭で行うこと

ツール上でコメントするという一方的なコミュニケーションが発生しがちな環境下では、命令と受け取れる言葉はうかつに使うべきではありません。
一方的に命令して言い訳も聞き入れないような人にはもう見てもらいたくなくなるものです。
そのようなことがどうしても言いたければ口頭で時間をかけて「説明」して下さい。

本を有効に使う

users.each do |u|
  u.save
end

☓:uではわかりづらいのでuserとしましょう。

◯:リーダブルコードの24pにもあるように、省略形を使うときはチームメイトが理解できるものが良いですね。

著名な本に書いてあるというのはそれだけで説得力が有ります。
レビュワーが勉強していることも伝わって一石二鳥です。

趣味やフィーリングでレビューしない

☓:この書き方は良くないです

◯:個人的な感覚で申し訳ないのですけど、この書き方はあまり一般的でないきがしてます。

なんとなくこの書き方は良くない気がする。
良い方法は提示できないけど、このコードは良いと思えない。 本にも載ってないんだけどこの書き方は一般的でない気がする。
個人的にこの記法は趣味ではない。

たぶんこの手のケースはいっぱいあると思います。
その感覚や考えはちゃんと伝えましょう。 なんの根拠もないのに良くないと言われても、どうしたらよいかわからないですよね。 炎上しがちで結論がうまく出ない系なので、できればお互いに対面で話し合ったほうがよいです。

具体的に提示しすぎない

☓:このメソッド名はfind_userがわかりやすいと思います

◯:ユーザを見つけて返すことが分かるメソッド名がいいですね

特にメソッド名やらクラス名などの命名に関してあまり具体的に提示しすぎないほうが良いと思っています。
というのも命名は本人の趣味や感覚などが出る部分です。
具体的に「これ」と言われると前述の命令にように見えたり、押し付けがましく感じることもあります。
またレビュワーとレビュイーで趣味がぜんぜん違うと大きなストレスになります。
コーディング規約が守られていないとか一般的な命名から大きくズレているような場合はそのことを伝えてあげればよいです。。

設計レビューは先にやる

コードレビュー時に設計についてグダグダいうべきではありません。
やられた相手は「今更言うなよ」とか「設計レビュー時に言えよ」とか思うわけです。
よほど酷いとか品質に問題があるのであれば指摘もやむなしですが、その場合も一方的にならず対面でお互いの合意を形成すべきです。

他の人の意見にのっからない

レビュワーが複数人いる場合に起こるのですが
まずはじめにレビュワーAが何か指摘したとします。
その意見に乗っかって「俺もそう思う」「その意見に1票」などと言うべきでないと考えています。

これは結構賛否有ると思うのですが、

  • レビューは多数決ではない
  • 誰がどう考えているかは重要でなく、付いた意見自体が大事

と考えるからです。
もちろん意見が対立した場合やチームの他の人の意見が必要だとなった場合はある程度多数決になっても仕方ないと思います。
また、先に付けられていたレビューの根拠が薄かったり足りなかったりする場合に補足的なレビューをするのは良いと思います。   

意見が割れたら対面で話し合う

レビュワーの指摘がどうしても理解できない、納得出来ない、今回はできないと思うことはあるでしょう。
このようにレビュワーとレビュイーの意見が割れた場合は、ツールでのコメントをすぐにやめてお互いの目を見て話をし、合意を形成しましょう。
コメント合戦になると大体醜く炎上します。

捨て台詞を吐かない

決まったことに対して「でも俺は良くないと思う」とかコメントしてはいけません。 とにかく最後に自分が言い返して終わらないと気がすまない人っていますよね。
やられて気持ちいいわけないです。絶対ダメ。 レビューに限った話でもなんでもないですね、これ。

長文を書かない

一つのコメント内に何回もダメ出しをしてくる人、何度も同じところを多角的にダメ出しする人。
ネチネチグダグダ。やめましょう。
説明は大事ですけどできるだけシンプルに指摘を。
文章が長いとそれだけで説教臭さがでてきます。 どうしても言いたいなら口頭で。

指摘が通らなくても切れない

自分の指摘が通らないとブチ切れだす人。
切れるとまでいかなくても、ものすごい長文レスで返してくる人。 ダメです。
上にも書いたように意見が割れたら話をして下さい。

良いコードを見つけたら良いと言おう

良いコードを見つけて、それをチームで共有するのはよいと思うのです。
駄目だしばっかしてても気が滅入るだけですしね。

大事なことだからもう一度いう。お互い向き合って目を見て話せ

これが一番大事なこと。
シンプルな指摘で解決しない問題があれば、それはもうレビューツールで解決するべきことではない。

番外 レビュイー側

レビュワーを信じる

☓:お前の指摘は信じられないから直さない。どうしても直してほしかったら御意見番の◯◯さんに正しいか確認をもらってこい!

これをやり始めると常にご意見番がいないとレビューできなくなります。
チームとして機能してないですね。これは。
もちろんレビュワーもレビュイーを信じていないとレビューが機能しません。

自信がない部分は先に伝えておく

自信がないところについては先に伝えておくと話がスムーズになります。
人って相談されるの好きですから、先に伝えておくと指摘がマイルドになります(経験則ですが)

おわり

なんか最後の方はグダグダな気もしますが、いろいろ気をつけてます。
本当はお互いに殴りあってから友人になるような屈強なチームになれたらいいのかもしれないですねー。

ブログをはじめる

エンジニアとして勉強してアウトプットする場所をつくろうと思った。