消耗品の買いだめ

柔軟剤がない。 先日洗濯物を回そうとした時のことである。

自分はプログラマの3大美徳にしっかり当てはまる怠け者なので、家事が嫌いである。
面倒くさい。
一番キライな洗濯は乾燥機付きのドラム洗濯機で解決し、次に嫌いな掃除をルンバで解決した。

しかしながら洗濯から乾燥までを1プロセスで完了できる文明の利器でも、自動で柔軟剤を買いに行ったりはしてくれない。
メイドロボの誕生が待たれるところだ。

ともかく自分は「在庫が減ってきたから買い足そう」が全然できない。
記憶力が足らんのか、集中力が足りないのか、はたまたマルチタスクができないのか。全部なのか。
毎日買い忘れるタイプだ。これが非常にストレスになる。

「あーまた今日も買い忘れた」が毎日続いてしまい、柔軟剤を買うためだけの外出が必要になってしまう。 何かのついでではない行動からは、非常にムダを感じる。

という事がずーっと続いてイライラが爆発したので、今週は消耗品をamazonで一気買いすることにした。
少々高いとかそんなものはキニシナイ。ストレスのほうがずっと高い。

  • つめかえ用シャンプー4個
  • つめかえ用ボディソープ4個
  • つめかえ用ボール型洗剤48個入りx2個
  • つめかえ用柔軟剤10個
  • トイレットペーパー12ロールx4個
  • ティッシュペーパー400枚(200組)x30箱
  • 麦茶2Lx12本
  • パック酒2Lx24本
  • ビール350mmlx24本
  • ツナ缶15缶

ついでに壊れかけのライトニングケーブルや前から欲しかったビールジョッキを購入した。

これだけあれば俺は暫く日々の飯以外特に買う必要がなくなる。
家帰ったら買い忘れてがっくり肩を落とす生活におさらばできるのだ。
非常に気分がいい。
気分は良いがしかし、この大荷物をどこに収納すべきかで悩むことになった。
ストレスが一つ減り、また一つ増えてしまった。

この世は一筋縄ではいかない。
この買物がストレスに対して無駄だったかどうかはもうしばらくしたら分かるだろうか。

プロダクトエンジニアの役割は

PM(プロダクトマネージャ)という言葉が、web界隈では流行っている。 及川卓也さんなんかがよく登壇したり記事になったりしているけど、色々読んでいった結果、「プロダクト品質、つまりユーザに提供する価値を決められる人」ではないかと思う。

自分は今社内で「プロダクトエンジニア」なんて呼ばれることが増えてきた。 エンジニア出身でプロダクトマネージャに近いところで仕事をする人、UXを考えられる人、という認識だろう。

人がエンジニアになる理由はいくつかに大別されるケースが多いと思う。技術が好き、人と話したくない、などなど。その中で言うと自分は「ものを作るのが好き」系のエンジニアだ。 なので、そのような素養をもっているとか、そのように行動していると言われるのはまんざらではないし、結構嬉しい。

プロダクトエンジニアの立ち位置

さて、プロダクトエンジニアとはどういうものだろう? PMとはちょっと違いそうだ。

PMは出身による違いが生まれる。エンジニア出身なら技術に造形が深く、ディレクタ出身ならまた違う能力が強めになるだろうし、デザイナ出身のケースもあるだろう。

つまり主にエンジニアリング側に寄ってそうだ。

軸を変えて、プロダクトエンジニアはエンジニアのキャリアパスの中ではどういう立ち位置か? エンジニアのキャリアパスは大きく3つあると思う。 1つ目は技術を極める人、2つ目はマネージメント能力を伸ばす人。3つ目はそれ以外の能力を伸ばす人。 プロダクトエンジニアは3つ目に該当する。

上記の点から、プロダクトエンジニアは以下の点をバリューにしやすい。

  • 多職種出身PMと違い、エンジニアとしての能力や知識でリードできる
  • 多系統エンジニアと違い、UX分野でリードできる

つまりエンジニアとPMのちょうど中間点にいる。これが強みだ。

プロダクトエンジニアの役割は

技術力は高いがそれをサービスに結び付けられないエンジニアと、サービスを考えることは出来るが、どんなことが今の技術で出来るのか想像もできない人を結びつけること。 これがこのポジションでは出来る。

自分がナチュラルにプロダクトエンジニア的なポジションにいたので気が付きにくかったが、技術ができない人はそもそもどんな技術があるのかすら知らない。

例えばエンジニアが火を使えても、エンジニア以外は火の存在を知らないか、存在を知っていても火がどんなものか知らない。 エンジニアは火を使えるけど、火がどんな価値を人々に与えるかを知らない、または説明できない。 こういうことが、多い。

つまり、プロダクトエンジニアの強みは「火をおこすことは出来ない。しかし火の効能を知っており、役に立てる方法を考えられる」ことだ。 エンジニア以外出身のPMは「火を使わずに寒さを凌ぐ方法を探す」が、エンジニア出身なら「火が寒さを打ち消せる」ことを知っている。 技術特化のエンジニアは「火を起こせるがその使い方は分からない」

今なら機械学習をサービスに活かす方法を考えられると言ったところか。

まとめ

正直な話、自分は技術もマネージメントも不得意な中途半端なポジションだと思っていたが、サービスを作れる能力は普遍的なものではなかった。 だれもが技術をサービスに繋げることはできないのだ。

同じように自分にできないことはいっぱいある。 例えば技術をユーザ価値に結びつけることは出来ても、それを収益化まで持っていくはビジネスサイドの人間が強いし、自分が知らない最先端の技術をキャッチアップするのは技術サイドがより強い。

PMがもてはやされたりしてはいるが、結局一人では何も出来ない。向き不向きはあるのだから、自分の強み弱み、チームメンバーの強み弱みをちゃんと理解して成長すれば、それが自分の役割になるのではないか。

という感じで締めにしたい。

人によって言葉の意味が違う事

最近、仕様とかプロダクトの方向性とか、色々なことをチームのみんなで話すことが多い。 その中で何度も同じ失敗というか、認識の齟齬を起こしているのだが、その一つに「俺が思っている言葉の意味と、彼の思っている意味は違う」がある。

言葉の捉え方は人によって違う

開発者なんてやってると「今週中に作って」等とよく言われると思うが、これに対して「今週中って翌週の始業まで?」なんてジョークで返すことも多いと思う。

これは、「今週中」の意味について、人によって解釈が違いやすい言葉だと認識しているからだ。 だから、こんな返し方をして意味のすり合わせをするわけである。

このような分かりやすいケースなら良いが、必ずしもそういうケースばかりではない。 例えば「評価」という言葉があるが、これも人によって意味が少々異なっていた。

言葉の意味が違うと話は噛み合わない

こんな会話があったとしよう。

A「上司とは言え、普段現場にいない人に評価されるのは納得できない」 B「上司なのだから評価するのは当然だ。現場にいるかどうかは関係ない」

上のような意見の相違によって話は平行していたのだが、話を聞いていくうちに、どうやらAさんとBさんの思っている「評価」の意味は、少々異なるものだった。

2人は評価の意味を次のように捉えて主張していたのだ。

A「上司とは言え、全く現場にいない人に「公の場で査定されて給与決定」されるのは納得できない」 B「上司なのだから「能力のチェックなどを」するのは当然だ。現場にいるかどうかは関係ない」

例なので少々雑なところもあるが、2人が思っていた「評価」の意味はこんな感じだった。 なるほど、話が全く噛み合わないのも当然だ。

ちなみに、言葉の捉え方が相違を認識した後のAさんとBさんは簡単に合意した。

A「一応上司なので少々能力のチェックなどされる程度はあると思う」 B「流石に現場を全く見ていない人に給与決定のための査定をされるのは納得感がない」

相手の性格等を意識したコミュニケーションを

人は性格や文化によって物事の捉え方が異なる。 ネガティブとポジティブ、繊細と大雑把、保守的と革新的?とか。

繊細な人から貰う小さなダメ出しと、大雑把な人から貰う大きなダメ出し。本当に問題が大きいのはどっちか分からない。

ポジティブな人の「大丈夫!」やネガティブな人の「危ない!」も「危険」の認識やハードルが異なっているからかも知れない。

自分が今付き合っている人々がどんな人なのか?

それを意識しながらコミュニケーションをすることで、より齟齬を減らしていけるのだと思う。

本当にコミュニケーションって難しいなー。

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

コードレビューに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票」などと言うべきでないと考えています。

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

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

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

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

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

捨て台詞を吐かない

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

長文を書かない

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

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

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

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

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

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

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

番外 レビュイー側

レビュワーを信じる

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

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

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

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

おわり

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

ブログをはじめる

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