カテゴリー : Work

日本企業と米国企業の文化的な違いと知っておくべきこと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 に「おやすみモード」のときにでも、特定のアプリだけから通知が届くような設定機能を追加してくれると嬉しいんですけどね。

チームでタスク管理、共有、改善のサイクルを回そう ~ Trello + Toggl 活用事例

最近は主に「マーチャンダイジングチームの業務改善」に取り組んでます。ちなみに、1 ~ 3月は倉庫で配送業務を改善してました。

仕事で業務改善をやり始めて「同じチームで誰が何をやってるのか知らない」という声を耳にするようにしました。たまたま僕が開発チームで仕事をしていて、この辺のノウハウについて知見があったので、ご紹介させてもらいます。

続きを読む

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

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

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

僕)

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

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

僕)

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

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

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

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

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

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

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

良書みたいです。

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

サポートタイプのリーダーを目指すあなたにやってほしいこと

とあるチームの業務改善の一環で、そのチームのリーダー宛に送ったメールを一部編集して記事にしました。

以下、メール本文です。


チームの立て直しに関連して今後、◯◯さん(リーダー)にやってもらいたいことを、優先度順に書き出しました。
できること、できないことあると思いますが、ご確認よろしくお願いします。

概要

  • サポートタイプのリーダーなので、自分の時間を確保して業務キャッチアップして、把握できてないこと、できないことを減らしていって欲しいという考えのもとに書き出してます
  • 自分ができる業務は他のメンバーに任せても、最悪自分で解決できるので、時間の作り方としてオススメです
  • 僕も意識して開発メンバーに任せまくってます

流れ

  1. 自分の業務を手放す
  2. 元々、自分の業務だったものはフォローできる
  3. 空いた時間でキャッチアップ、勉強する
  4. チームメンバーの業務全てフォローできるようにする

サポートタイプのリーダーになるためにやってほしいこと

実務を早急にメンバーに引き継ぐ

実務を抱えてると時間が作れないと思うので、今までやっていたタスクはフォローできると思うので一旦、手放しましょう。
困ったらフォローする形でリーダーシップとっていくのが理想的です。

空いた時間でチームの業務を全てキャッチアップする

失礼ながら数字に弱い印象なので、扱ってる数字がどうなってるかは最低限、分かっていてほしいです。
その他、チームメンバーがやってる業務内容の概要を把握してください。
チーム内の業務で分からないことがあれば勉強してください。

チーム内の各業務 MTG にも時間の許す限り参加する

最初のうちは基本参加してください。

各メンバーの実務面での動きを見てないと、評価面談のときに何も書けないと思います。
メンバーのことを見ていない人に評価されても納得感がないと思います。

最後に、慣れてきたら MTG への参加頻度は減らしていきましょう。
MTG ばかり参加していると自分の仕事の時間が確保できなくなるからです。

他チームとの面倒な調整役を引き受ける

サポートタイプのリーダーが力を発揮できるポイントだと思います。
チームメンバーには各自の業務に集中できる環境を作ってあげましょう。


以上がメールに書いた内容でした。

最後に

「リーダーってどうあるべきだろう?」と悩んでいる方に少しでも参考になれば幸いです。

エンジニアは何でもできる魔法使いじゃないんだよ

タイトルで完結していますが、エンジニアの職種を最近やってる仕事を通して考えてることについて書いてみます。

まず IT エンジニアはざっくり下記のような職種がありますよね(順不同)。特にウェブ業界のエンジニアについて書き出してみたので「ここに書いてないけど◯◯エンジニアもあるよ!」という情報があったら、コメント欄で教えてほしいです。

  • Web エンジニア
  • UI/UX エンジニア
  • Android エンジニア
  • iOS エンジニア
  • ネットワークエンジニア
  • インフラエンジニア
  • データベースエンジニア
  • カスタマーエンジニア
  • セールスエンジニア
  • テストエンジニア
  • 分析エンジニア

「他にエンジニアの職種ってなにがあるんだっけ?」と思って調べてみると “ITエンジニアの職種と人材 | IT Job Gate” が細分化して書いてあったのでスクリーンショットで一部引用してみたのが下記の画像です。

ITエンジニアの職種とスキル

ITエンジニアの職種とスキルの一覧

改めて「エンジニア」という言葉で一括りにできないぐらい、様々な職種があります。これはエンジニアをやったことない人には分からないと思うので、例えていうと大学受験の5教科7科目ぐらいそれぞれの職種が違うと言っても過言ではないと思います。

この例に当てはめると、死語としてよく求人情報で使われる「フルスタックエンジニア」は全科目できる優等生になりますね。そんな優秀な人、ゴロゴロいるわけないのは明らかですよね。だいたいは、何かに秀でていて、何か苦手教科があるはずです。

そんな優秀なエンジニアを社内では「ツチノコ」と呼んでいます。

さて、自分の話になるんですが、上記の職種でいうと普段は Web エンジニアの仕事をしています。数年前は、Android や iOS アプリ開発もやっていました。最近は今週末にオフィス移転があるのでネットワークエンジニアみたいなこともやっています。

この記事で伝えたかったのは「エンジニアは何でもできる魔法使いじゃないんだよ」ってことです。Web エンジニアでネットワーク構築のこと分からない人もいるし、モバイルアプリ開発やったことない人もいます。

エンジニアという職種で一括りにして「IT や Web のことだったら何でもできる」という認識はしてほしくないなと考えてます。期待値コントロールは適切にしないと割を食うのは僕たちエンジニアです。

今の職場はいろんなことできて楽しくやってるので特に不満はないのですが、「なんだかなー」と思うことが最近よくあったので文章にしてみました。まあ、社内で浮いてる仕事は全て拾ってやっていくつもりなんで、結局は仕事が好きで「やります」って言ってるんですけどね。はい。

実績がない人の提案は、アイデアはあるけど実行できない起業家みたいなもの

定期的に日報で鋭い提案をしてくれる同僚に向けて返信したメールを一部編集して掲載しました。

以下、メール本文

先週でしたっけ?
Foo さん (仮名) と商品レビュー機能についての話をしていて、考えていることについて概ね同意だなと思いました。

個人的には、あとは「やる」or「やらない」の問題だと思っていて、開発チームだけで完結するものについては Hack day (Google の 20% ルールみたいな時間) 制度ができたのでドンドンやっていいと思います。

あとは他チームへの提案ですね。この部分は難しいですよね。僕もよく悩みます。
自分としては良い提案をしていても、相手が受け入れてくれないとそのチームのメンバーはなかなか動いてくれません。

ちょっと違うかもしれませんが、例えて言うと「アイデアはあるけど、実行できない起業家」とかでしょうか。

提案するのは1つアクションを起こしているので、何もしていないことにはならないですが、「誰もやらないなら自分がやるぐらい」の気持ちじゃないとたぶん実現されないと思います。

最後に「いろいろ言うけど、自分の仕事ちゃんとできてるの?」ってブーメランは必ずくると思います。
ぐうの音も出ないぐらい自分の仕事はしっかりやって、それをベースにして他チームの仕事に首突っ込んだり、提案していかないと発言に説得力がついてこないと思います。

Foo さんも実績を出してない人の話を特別参考にしませんよね?
そういうことだと思います。

お互い頑張りましょう。

確定申告を e-Tax で済ませるまでに参考にした情報まとめ

たった今、国税電子申告・納税システム e-Tax (イータックス)で確定申告を完了しました。

確定申告をするために参考にした情報を忘れないように書き留めておきます。

確定申告のやり方

誰しも最初は「確定申告って何からやればいいんだろう?」と考えるはずです。

確定申告する前に読むべきオススメ本

まず、確定申告にはどういう作業が必要なのかざっくり把握するために本を2冊読みました。

確定申告する前に読むべきオススメ記事

次に、実践編として e-Tax で実際に確定申告をする流れを e-Tax サイトのスクリーンショット付きで説明しているサイトを読みました。

e-Tax で確定申告

e-Tax で実際に確定申告を進めていくための情報として、「SiGT Web Studio」の確定申告手順がわかりやすくまとまっていてオススメです。

おまけ 収益元の企業と住所情報

グーグル株式会社
東京都港区六本木6丁目10番1号 六本木ヒルズ森タワー

アマゾン ジャパン株式会社
東京都目黒区下目黒1丁目8番1号
https://ja.wikipedia.org/wiki/Amazon.co.jp

楽天株式会社
東京都世田谷区玉川一丁目14番1号 楽天クリムゾンハウス
http://corp.rakuten.co.jp/about/overview.html

株式会社もしも
東京都新宿区西新宿3-5-1 新宿セントランドビル8階
http://www.moshimo.co.jp/information/move.html

まとめ

1年に1度、確定申告は必ずやってくるので、大変な作業にならないように日頃の準備が肝心要は好奇心ですね。

学ぶための質問方法

自画自賛ですが、我ながら良いメッセージを伝えられてたんだなと思ったので、忘れないように記事に残しておきます。

学ぶための質問方法

本当にどうしていいのかわからず、そのたびに社内のエンジニアの方に質問を繰り返す日々。当時の私はgrepの存在すら知らず、いま思うと「よくこの状態でインターンに応募したな」と我ながらあきれるほどです。質問をするときに私は「答えそのものを聞く質問」をしていたようで、「答えそのものを聞くんじゃなくて、答えを得るための方法を聞いたほうがいいよ」とアドバイスされたことを覚えています。

そして、この記事をよんだ同僚のデザイナーさんが Facebook にコメントしていた内容もとてもよかったので引用させて頂きます。

これは凄く良い事をいっていると思います。解っている人に答えを聞くは目の前の作業を素早く終わらせる事はできるでしょうが、長い目で見ると自分の為には全くならないし、何が解ってないのかが判らないままで終わってしまう。
それに加えて答えそのものを聞くって事は”自分は考える気ありません”って言ってるようなものだしね。もし答えの選択肢が沢山あるようなものなら考えさせるってコストを押し付けてることにもなると思いますですし

「自分で考えて、分からなかったら人に聞く」という基本的なことですが、適度なバランスで質問できるといいんじゃないかなと思ってます。