CodeNote

ポモドーロテクニック、ずっと食わず嫌いしていたんですが「SOFT SKILLS　ソフトウェア開発者の人生マニュアル」という本でオススメされていたので、実践してます。

続きを読む

2016年の振り返り。

続きを読む

とある企業から Tech Lead のポジションでオファーを頂いたので、改めて「Tech Lead って知っているつもりではいたけど、具体的には何をする役職？」と思い調べてみました。

みなさん、詳しくまとめられているので、とても参考になりました 🙏

続きを読む

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

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

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

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

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

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

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

• 引用元: メンター(めんたー)とは – コトバンク

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

• 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック – Qiita
• “居心地が悪い"くらいの優秀な人をメンターにせよ–人生の成功者になるためのルール – ログミー
• メンターに「学ぶことがあった」先輩は73％！もらいたいアドバイスとは？ – リクナビNEXTジャーナル

メンターってなによ

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む

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

• トランザクティブ・メモリー (Transactive Memory) – GitHub Gist @naoya

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

僕)

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

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

僕)

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

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

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

• 「トランザクティブ・メモリー」

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

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

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

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

良書みたいです。

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

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

以下、メール本文です。

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

概要

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

流れ

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

続きを読む