カテゴリー : Work

2016年を振り返る

2016年の振り返り。

仕事

2016年は開発以外の色んな仕事に携われた。

1-3月は自社倉庫の業務改善。4-6月はマーチャンダイジングチームの業務改善。いずれもエンジニアリングをベースにした業務改善で、業務ヒアリングして、開発要件を GitHub issue に作成していくという感じだった。業務ヒアリングしていくと今やらなくていい開発案件もあったりして、優先度調整や期待値コントロールの難しさを体験した。

7-8月はマーケティングチームの業務改善を少しだけやった。期間が短かったのは組織体制が変わるのと、業務改善よりも売上・粗利アップさせるための仕事に方向転換があったためだ。
この期間に、データ分析の真似事も取り組んだ。データ分析は未経験だったので、何冊か本を読んで参考にしながら取り組んだ。

データ分析のために読んだ本

SEOにも取り組んだ。開発以外で社内調整しないといけない部分が多くて、現状まだ上手くいってない。1-8月でエンジニアとしての開発業務から離れていたので、また開発をがっつりやりたいなと思い始めた。というわけで、CTOに相談して開発業務の割合を増やしてもらった。

9月以降は主にエンジニアとしてプロダクト開発に取り組んだ。半年以上、開発から離れていたので戻ってから最初の2週間ぐらいはリハビリ期間みたいな感じで、勘を取り戻すのに苦労した。

フロントエンド JavaScript に苦手意識があったので、Vue.js に苦戦した。

11月末から、熊本でリモートワークして年を越した。

メリットとしては、開発に集中できる時間が増える。

デメリットとしては、スタートアップならではの熱量が伝わりにくい。オフィスの空気感が分からないので、緊急性の高いタスクがあったときに Slack に @channel で叫ばないと (メッセージ) しないといけない。Google ハングアウトの設定やネットワークトラブル問題が尽きない。オフラインコミュニーケーションがグッと減るので、業務上関わりのない人とほとんど接点が無くなる。

自分からお願いしてリモートワークさせてもらってる訳だけど、デメリットの部分を理解して導入しないとストレス溜まるなと改めて感じた。

家庭

5月のGW中に家族が他界した。
必要なときに仕事を休めることの有り難みを感じた。

12月末に第一子が生まれた。立会い出産したかったので、それにあわせて11月から2月上旬まで熊本からリモートワークをしてる。
結婚式や出産などのライフイベントにあわせて、リモートワークをさせてもらえるのは有難い。「いつリモートワークしても大丈夫なように、週1〜2回ぐらいやって、体を慣らしておいた方がいいのでは?」というのがDevチームのトピックとして挙がっている。

勉強

英語学習は途中でやめてしまった。モチベーションが続かなかったので、時期をみて再開したい。

読書は月10冊を目標にしていたけど、実際は月2~3冊ぐらいしか読めなかった。以下の本はどれも、もう一年早く読みたかったと思える良書だった。この点は経験が先か、知識が先かの違いなんだろうけど。

リモートワークで、通勤時間が無くなるので浮いた時間を使って勉強に充てたい。

などを読み直してる。
インプットが多めなので読書感想文みたいなものを、このブログにでもアウトプットしていきたい。

プライベートコードを書く量が少なかった。

今年はまず、フロントエンド JavaScript のスキルアップをしていきたい。他の技術も幅を広げるか深めていくかしていきたい。

総括・来年

20代最後の一年だった。

来年は30歳なので、今まで以上に今後のキャリアやライフプランを具体的にイメージして日々を生きていきたい。

日本企業と米国企業の文化的な違いと知っておくべきこと5つ

会社の同僚の Alex が Tech Talk Tokyo #4 というイベントで発表した資料がとてもよかったので、記事として残しておきます。

以下の5つのトピックについて「日本企業だと◯◯だけど、米国企業は☓☓だよね」という Alex の個人的な見解を聞いて、「良いと思ったポイントを自分のワークスタイルに取り込みたい」と思いました。

  1. Emails
  2. Working Time
  3. Giving Negative Feedback
  4. Making Decisions
  5. Performance and Appraisal

詳しい内容が知りたい方はスライド(英語)を読んでみてください。

本人に「メンター制度をやる必要がある」という認識がないと良い結果にはならないのでは?

職場でメンターを引き受けるか考える過程で、メンター制度について調べたこと、考えたことを書き残しておきます。

まずは「メンター」という言葉についてです。

メンターとは、仕事上(または人生)の指導者、助言者の意味。メンター制度とは、企業において、新入社員などの精神的なサポートをするために、専任者をもうける制度のことで、日本におけるOJT制度が元になっている。メンターは、キャリア形成をはじめ生活上のさまざまな悩み相談を受けながら、育成にあたる。

次に、ネットで検索していくつかメンターについて書いてある記事を読んでみました。

メンターってなによ

メンターというのは、特定の分野において経験を持つ人が「世話焼き兄貴・姉貴」として、キャリアや仕事の進め方、トレーニング、コーチングなどをしていく人のことです。その対象のことをメンティと言います。
そのため、目的は対象となる人の迷いを取り除き、成長させ一人前にしていくことです。また、メンターを経験することでより大きな人数での指導的立場やサポートをしていくことの足がかりとしても大変有用です。

ここで重要なポイントは「メンティを成長させたいか?」という点だと考えてます。

対象のメンティの成長に関心がない場合は、メンター業務に対してモチベーションが上がることもないので、お互いのために引き受けるべきではないと思ってます。

ここでメンターに関して皆さんが具体的に出来ることをお話したいと思います。

ルール第1は、33%の法則です。皆さんの周りの人の33%は皆さんよりもレベルが低いです。皆さんは彼らのメンターになることができます。彼らを助けることで、皆さんは良いことをした、と気分が良くなります。皆さんよりも低いレベルの人がいると安心しますよね。
そして他の33%の人々は皆さんと同じレベルの人です。この人達は皆さんの友となり、仲間となる人達です。そして最後の33%は多くの人がその存在を忘れている人々です。彼らは10年、20年、皆さんの先を行っています。彼らは一緒にいると皆さんをすこし居心地悪く落ち着かない気持ちにしますが、これが皆さんには必要なのです。

覚えておいてください。よくある間違いは、自分より少しだけ優れた人をメンターに選ぶことです。自分も物事をよくわかっていないのに、同じ程度にしか物事をわかっていない人を選んではなりません。これを10Xルールと呼んでいますが、メンターには自分の10倍優れた人を選ぶべきです。100万ドル企業を築きたいのであれば、1000万ドル企業を築いた人にメンターとなってもらう。ものすごく成功した人にアプローチすることを恐れないで。彼らは直接会ってみると素晴らしい人ばかりです。

”メンターには自分の10倍優れた人を選ぶべき”なので、そうでない場合はメンティにとって効果は小さいと思うんですよね。

自分がメンティの立場だったら「少しレベルの高い人についてもらっても、何も変わる気がしない」と思いますね。

まとめ

メンターもメンティーの立場にもなったことがないのですが、どちらの立場でも本人に「メンター制度をやる必要がある」という認識がないと良い結果にはならないのではないでしょうか。

IT企業とはいえ緊急時の連絡手段はやっぱり電話

外資系の IT 企業で EC を主力事業としてやっているので日本とアメリカに倉庫があるんですが、たまにシステムトラブルが日本時間の深夜に発生しても寝ていて対応できないことがあるんですよね。

特に僕は寝るときに iPhone を「おやすみモード」に設定しているので、通知に気づけないのが主な理由です。

通知に気づけないと対応もできないので、”社内で一部のエンジニアの電話番号を共有してほしい” という要望があがってきました。

色んなコミュニケーションアプリがリリースされている昨今ですが、緊急時のコミュニケーション手段はまだ電話みたいです。

iPhone 「おやすみモード」の設定方法

iPhone の「おやすみモード」を設定しているときは、デフォルトアプリの「着信通知」と「メッセージ通知」のみ通知を受け取る設定ができるみたいです。

着信通知の設定についてですが、社内の他のメンバーの電話番号を登録していないのでそういう方は、[着信を許可 (Allow Calls From)] の項目を [すべての人 (Everyone)] に変更するのがおすすめです。(下記、画像参考)

iPhone おやすみモード

メッセージ通知の設定はまだ使えてないのですが、Slack の特定の通知を SMS で受信するとか上手く使いこなせるといいのかもしれませんね。

Apple が iPhone に「おやすみモード」のときにでも、特定のアプリだけから通知が届くような設定機能を追加してくれると嬉しいんですけどね。

ドキュメント化するとメンテナンスコストが掛かるので「社内の誰が専門家か?」だけ分かればとりあえずOK

いつかのアニメ鑑賞会で伊藤直也さんから教えてもらった「トランザクティブ・メモリー」の内容を、そのまま社内の日報メールで共有することがあったので、一部抜粋して記事にしてみました。

以下、日報メールの内容を一部抜粋したものです。

僕)

ノウハウが共有される良い文化が営業部にも根付いてきていて良いですね!

Hさん)
昨日、某氏とも話していたのですが、前例が参考にされないパターンってめっちゃあると思うんですよね。
Google ドキュメントにまとめていても検索しない、見つけられないなどありそうです・・・。
開発チームでなにか情報共有のノウハウがあれば教えていただきたいです!

僕)

組織全体が「同じ知識を記憶すること」ではなく、「組織内で『誰が何を知っているか』を把握すること」である

という考え方があります。

少し前に、エンジニア界隈の有名人 伊藤直也さんから教えてもらたことで、それが下記の記事です。

ドキュメント化ってメンテナンスコストが掛かるので、「社内の誰が専門家か?」だけ分かればとりあえずOKで、よくある質問は質問される人 or 質問した人が自然とドキュメント化していく流れが理想なのかなと思ってます。

僕も質問される頻繁が高い内容はドキュメント化しています。

営業部で Trello の運用がスタートしたと思うので、やりながら運用で困ってることを相談してもらえると嬉しいです。
僕が知っていればノウハウを共有できるのかなと思ってます!

その後、H さんは記事中に載っていた「ビジネススクールでは学べない世界最先端の経営学」という本を読んでその内容を共有してくれました。

良書みたいです。

「トランザクティブ・メモリー以外に◯◯という内容もとても参考になりました!」と教えてくれたのだけど、肝心のキーワードを忘れてしまいました。まあ、その人が知ってるのでその人に聞けばいいんですけどね。