Webエンジニアのメモ帳

技術的な話を中心に書いています。

【Mac】日本語入力の変換がおかしい時の対応

Short Answer

  1. 以下を実行

    killall JapaneseIM-RomajiTyping
killall TextInputMenuAgent

  2. PC を再起動

備考

日本語入力時に変換がおかしいという問題が起きていました。

(たとえば「t」と打ったら「onclick」が出るなど)

ChatGPT に聞きつつ、上記を含むいくつかのコマンドを打って解決したので、これが効いたのかどうかは確証はないですが、可能性は高いと思います。

なお、入力ソースから日本語入力を削除 → 再度追加という作業も行ったので、これが効いた可能性もあります。

また、コマンド実行だけではダメで、再起動が必要でした。(逆に再起動だけでもダメでした)

【要約】エンジニアリングマネージャーのしごと (O'Reilly)

オライリーの「エンジニアリングマネージャーのしごと」という本を読んだので、重要だと思った部分を章ごとにメモしておきます。

要約

1章 最初の仕事
  • 最初の章はマネージャーとして仕事を始める時にやることについて書かれていた
  • 1on1 を通してメンバー・上司を知ろう、というのが主な内容
    • それによって上司・メンバーとしか共有できていない、または自分しか気付けていない考えや認識を整理し、何に取り組むべきを明確化できる
2章 情報・仕事の整理
  • 前半は情報の整理に関して書かれていた
  • 具体的なテクニックとして、カレンダーは MTG や私用、作業時間のブロックのためだけに使う
    • 周期的に発生するタスクはカレンダーに入れず、TODO 管理のアプリを使う ( Asana など)
  • 後半はマネージャーの仕事に関する重要な話が書かれていた
  • マネージャーのアウトプット = 自チームのアウトプット + 影響を与えた他チームのアウトプット
  • マネージャーの仕事は情報収集・意思決定・ナッジング (議論に自身の観点を共有すること)・ロールモデルに分類される
3章 コミニュケーションについて
  • 前半は相手に合わせるとか、感情に左右されないとか、マネジメントに限らず一般的な話
  • マネージャーは求められる品質でタスクを完了させる責任 (説明責任) は負うが、実際の作業 (実行責任) は負わない
  • 上司と自身のパフォーマンスが何で、それがどう計測されるか決めておく
  • 上司に 1on1 の中で色々と質問をすることは、1つ上のレイヤーの視点が得られるし、影響の範囲を広げられてキャリアアップにもつながる
  • 逆にチームの状況を毎週知らせることも大事
4章 1on1
  • 初回1on1では、両者が互いに期待することを明確化する
    • どういうサポートが必要か、一緒に働く上でどういう問題があるか、などを話し合う
  • 基本的には質問から相手の話を引き出して、問題を発見する
  • 自分のタスクの共有などもアリ
5章 割り振るタスクについて
  • 人に合った仕事を提供することが大事
    • ちょうど良い難易度のタスクを提供する
    • 「発達の最近接領域」について触れられていた
  • 最終的な目標からの逆算でタスクを与える
  • 「伽藍とバザール」について言及しつつ、安定した環境がいいかカオスな環境の方が良いかの話が書かれていた。どちらを望むかは人によって異なるし、割り振るタスクも変わってくる
6章 評価面談
  • 評価面談は両者がパフォーマンスについて考える場で、それまでにも定期的にパフォーマンスについて話すことが大事
  • 先に面談用の資料を埋めておく
  • 昇給に関しては別の機会に伝えて、不満があるなら将来の話に繋げるのが良い
7章 採用に関して
  • 採用は、どういう人員が必要か考え直す良い機会
  • シニアを雇えば良いというものではない。衝突を生むことも
  • 一次面接で技術課題を解いてもらう、ただし試験のような雰囲気にしない
  • 一次面接であらかた決める。微妙なら通さない
8章 離職に関して
  • 残ってほしいが、出て行ってしまう人の話がメイン
  • チーム内での問題やキャリアアップに関する認識のズレなど、1on1などで信頼関係を構築できれば、ある程度は防げる
  • 辞めさせたい場合はPIP (業務改善計画) を使う
    • これは日本の場合は関係ない話かも
9章 社内での人間関係について
  • 社内でネットワークを構築することで、効果的な仕事ができたりキャリアップにつながったりする
  • 後半はメンタリングとコーチングについての話。コーチングでは指導だけでなく、相手に質問したりして聞き役になる
    • GROWモデルが紹介されていた
10章 社内での衝突について
  • 部下からは詮索・批判にさらされるもの。全てを掘り下げる必要はない
  • 上層部の混乱を吸収して下に伝えるのはマネージャーの仕事
  • チームのアウトプットが少ないのは、期待が非現実的だったり運の問題だったりがほとんどで、チームに問題がないことが多い。
  • アウトプットを出させたいなら、自律的に働かせること、スキルアップにつながると感じさせること、仕事の意義 (社会への影響) を感じさせることが大事。もっと働けと言ったところでモチベーションは上がらない
  • ダニング=クルーガー効果 (自分が実際より有能に感じること)・インポスター症候群 (前者の逆)はよく発生する
    • ペア作業や議論を通して気づかせることが大事。
11章 重要で締切がタイトなプロジェクトの話
  • 進捗を共有してフィードバックを求める。細かくリリースすることも大事
  • プロジェクト後に時間的ゆとりを与えて、技術負債の解消や学習に充てる
    • その時間を取れるようにマネージャーが戦わないと、離職などにつながるだけ
  • 会社が大きくなると生産性が下がるのは仕方ないが、原因 (単純なタスクでも、それによって難度が上がる理由など) は説明できるようにすべき
  • 2割程度を技術負債の解消に充てる、というのも解決策
  • 締切が迫ってスコープを落とさないといけないことがある。事前にタスクを分解して優先度をつけておくと良い
  • 作業の並列性を確認しておくことで、人員の追加により早くできるか判断しやすくなる
12章 社内の情報などに関して
  • 情報は存在自体を知られてはいけない、存在は知られても良い、中身も公開で良い、に分けて扱うことが大事
  • 後半は社内政治の話。個別最適的に動く個々を利用して全体最適を目指そう、という話
13章 タスク管理に関して
  • コントロールできるもの、できないもの、ある程度できるものの3つに分ける
  • 最後がマネージャーにとって重要。内部ゴールを設定するのが良い
    • 内部ゴール = 置かれている環境で現時点のベストを尽くすためのもの
  • 例 : 転職を思い止まらせたいと考えているなら、これは外部ゴール。そのために居心地の良い環境を作ることが内部ゴール
  • 何もしない時間を作る。このとき思いついたことは書きとめるだけにし、あとで考える。
  • マネージャーは緊急時に急にリソースを奪われることもあるので、できると思う仕事量の85%程度を引き受けるのが吉
14章 情報の共有について
  • 必要な知見がチーム間、メンバー間で共有されていない、というのはよくある問題。車輪の再発明のような事態も発生する
  • チームが機能ごとなら、チーム横断の、技術的に同じ関心を持つグループ (ギルド) を作る
    • コーディングやUIの統一性を持たせる、などの効果が期待される
  • マネジメント側への意見を誰でも匿名で書けるような場所が必要
  • チーム状況 (コードの健全さ・開発プロセス・楽しさや学び・サポートが得られているか等) を定期チェックする。他のチームとも比較してみる。
15章 キャリアアップの話
  • マネジメントとインディビジュアルコントリビューター (IC) の2つの方向がある
  • ICは開発者。高い質のコードを書くことに加え、メンターとしてもスキルが高かったり、周囲に受け入れられるような提案をしたりする。
    • また再利用可能なコードの開発によって開発速度を上げたり、速度改善やアーキテクチャの作り直しなどの大規模な開発により、ビジネスの損益に直接的に影響を与える。
  • キャリアアップ表の例の紹介があった (p.280)
    • これだけで昇進の判断をするものではなく、キャリアアップに関する会話を行うための手引きであるため、項目は主観的なもので良い
16章 ダイバーシティー・リモートワークの話
  • 特に面白い話はなかった
17章 スタートアップでのマネージャーの仕事
  • スタートアップでの最初のマネージャー (VPoE) の仕事は、エンジニアの評価や採用。リソース配分に加えてコードを書くことも
  • 小規模な組織でも、どんどん開発をするだけだと将来的に破綻するので、スピードのバランスを取ることが大事
  • そのためマネジメントのスキル (この本に書かれていたような知識) は小規模な組織でも重宝される
18章 キャリアに関して
  • 10年後の理想を考えて、そこから逆算でやることを決める、といった内容
  • 仕事に関して、何を楽しいと思ったが、何が嫌だと思ったか考えるのはヒントになる。また仕事のことに限らず、色々な視点で想像する

感想

自分は今はマネージャーではありません (リーダー業務をやるという話はある) が、マネージャーが実際にどういう仕事をすれば良いのかを中心に書かれていたので、マネージャーの仕事に対する解像度が高くなって良かったです。

マネージャーって実際何をしているんだという疑問が正直あったのですが、これは2章にあった仕事の分類を読んで理解ができたと同時に、これを意識して動けるかでパフォーマンスは相当変わってくるだろうなと思いました。

また10章の「アウトプットを出させたいなら、自律的に働かせること、スキルアップにつながると感じさせること、仕事の意義 (社会への影響) を感じさせることが大事」という内容は強く印象に残りました。なぜなら、今の会社が実際にそうはなっていないからです。

マネージャーになる前からでも、彼らに働きかけてそういう組織へと変えていくことはできます。そういう動きはしていきたいなと思いました。

また最後の章、これは仕事に関する話というより人生そのものに関する話かもしれないですが、将来からの逆算で動く、という考えは自分には足りていないなと思いました。もっと将来の理想の解像度を上げていきたいと思いました。

関東IT・大久保健診センターで健康診断を受けてきた

大久保健診センターで健康診断を受けてきたので、諸々のメモです。

行き方

JR 池袋駅から向かう場合、山手線の 3号車 か 4 号車あたりに乗って新大久保駅で降り、地上に降りたら左に向かうと着きます。

健診の流れ

2F と 3F を往復する形になります。

ウォーターサーバーは 3F にしかないですが、検査の途中で立ち寄ることは可能でした。

なお、採血を横になって行う場合は 5 分待たされます。

周辺で作業できる場所

健診センターの受付に椅子はありますが、居座って作業するのは現実的ではない感じでした。(人の出入りが受付の人に見られているため)

自分は昼食 (後述) まで近くのドトールで作業し、Web 会議のためにつつじの里児童遊園という公園に移動しました。こちらは野外ですが椅子が 2 つあります。 石段のようなところに座っている人もいました。

昼食

一人でサムギョプサルが食べられるという情報があったので「カントンの思い出」という店に行きましたが、鉄板で焼いてくれる感じではなく、定食のような感じ (ハンサン) で出てきます。

味は普通に良かったです。副菜のニンニクが強かったのか少し具合が悪くなりましたが...

サムギョプサルを食べるなら2人前を食べる手もありますが高くつくので、それ以外を食べるのが良いかと思います。

でりかおんどる (1号店・2号店があります) は 10 時からランチを出しているので、上述の児童遊園で作業でもしてからここに行く、というのが良いかなと思います。

前の年にこちらでサムギョプサル (同じく定食での提供) を食べた時は肉の量が少なく微妙だと思いましたが、それ以外のメニューは普通に良さそうです。(評価も高いですし)

【Amazon】保証期間内だが返品期限が切れた商品を返品する方法

Amazon でスマートウォッチ (TicWatch Pro Ultra 3) を買ったのですが、半年ほどで急に電源が入らなくなりました。

機械の保証期間は通常1年ですが、Amazon のシステム上で返品ができるのは120日までなので、手順がかなり煩雑になります。

結果的には返品できたのですが、その手順がかなり煩雑だったので、今後のために記録をまとめておきます。

目次

結論

結論としては、以下の手順で進めるのが良いです。

  1. メーカーにメールで問い合わせて、故障を認めてもらう
  2. Amazon に電話で問い合わせる
  3. メーカーとの問い合わせのスクショを Amazon に送る
  4. 返品手続き用のリンクがメールで送られてくるので、通常の返品と同じく手続きをして完了

ただし、海外のメーカーだったりすると意思疎通がうまくいかず、この手順通りにいかないものです。

そうしたイレギュラーなケースも踏まえて、各ステップの詳細を以下に説明します。

手順1. メーカーに問い合わせ

メーカーの問い合わせ先は自分で調べるしかありません。

私が買った商品 (TicWatch) は Mobvoi というメーカーが作っていたので、Mobvoi の公式サイトの問い合わせフォームから連絡をしました。

https://www.mobvoi.com/jp/products/support/supportwarrantyHome

なお、問い合わせ先が分からない場合に Amazon に聞いても良いですが、正しい問い合わせ先を教えてくれるとは限りません。私も実際に全く違うリンクを教えられました。

ここからメーカーとのやりとりの往復になりますが、ここで交換の指示をもらえればベストです。

というのも Amazon に問い合わせた際、メーカーから交換の指示を受ける (初期不良だと言われる) ことが必要と言われたからです。

しかし私の場合、やり取りを続けた先に「製品の故障だと思われるなら明言してください」と送っても復旧の手順を教えられる (しかも最初の返信に書かれていた内容と同一) など、担当者から期待する返信を得られませんでした。

私の場合は、Amazon 側にその旨を伝えると「今回は特別」とのことで返金してもらえましたが、交換の指示を得られるまでやりとりを続ける方が確実だとは思います。

手順2. Amazon に連絡

メーカーとやりとりした内容を Amazon に伝えます。

電話・チャットの両方が可能ですが、自分の経験上、電話の方がすぐにオペレーターとつながり、通話料もかからないのでオススメです。

電話の方法ですが、まずは以下のリンクを開きます。

https://www.amazon.co.jp/hz/contact-us/foresight/hubgateway

すると買った商品の一覧が表示されますので、対象の商品を選びます。

あとは画面に従って選択をしていくと、最終的に「カスタマーサービスへ連絡」というボタンが表示されるので、これをクリックします。

すると電話番号を入力する画面が開きます。入力するとすぐに電話がかかってきます。

手順3. メーカーとのやりとりを Amazon に伝える

私の場合は、Amazon との電話をした際に、メーカーとのやりとりのスクリーンショットを以下のアドレスに送るよう指示を受けました。

moreinfo-cs@amazon.co.jp

このアドレスは、電話の直後に飛んでくるメールの本文に記載されています。

ここにスクショを添付して送れば OK です。(自分の場合、上述の通りメーカーからまともな返答を得られないと伝えていたので、この内容を確認されたかどうかは不明ですが...)

手順4. 返品の手続き

あとは通常の返品の流れと同じです。

自分の場合は買った商品が Amazon 上でもう売られておらず交換は選べなかったのですが、商品によっては交換も可能とのことでした。