[2021]再読したい記事一覧

2022/1/15 20:032022/2/27 2:29

(順不同)

最後までやり切ること

昔、ある会社をクビになって惨めに追い出されたことがある。当時の私のポジションは、持ち株ほぼ0の雇われ取締役。長く経営不振が続いていた中堅メーカーで、同社のメインバンクの投資部長から、「大事な出資先なので、なんとか立て直して欲しい」と言って頂き、就いたポジションだった。それから6年余り。さまざまな施策を講じたが、最終的に自力再建に至らず他社の傘下に入るイグジットを選択することになる。

https://blog.tinect.jp/?p=71449

最近技術ブログ書いてないけど書きたい

質の高い技術文書を書く方法

大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれものでも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料会議の叩き台となる 1 枚ペラ本番環境に変更を加えるにあたっての包括的な情報や具体的な手順技術仕様を網羅的に説明した一連の文章おそらく皆さんが「ドキュメント」と聞いて一番に思い浮かぶものは一番最後の例(4.)だろう。各種サービスやソフトウェアにはこうしたドキュメントは必須だ。ただ、技術を実際に使えるものにしていくにあたって、それはどちらかというと最後のフェーズ（および運用フェーズ）で高い価値を発揮するものである。自分たち一介の技術者(開発者)にとっては、そのフェーズに持っていくまでをどうするかの方が日々の仕事では大きなウェイトを占めているのではないだろうか(少なくとも僕の場合はそう)。このエントリでは、どちらかというと 1,2,3 の様な、何かを前に進めるに当たって書くべきである document を中心に自分の書き方を解説していくが、同じ原則を 4 や他の document にも当てはめることはできるはずだ。文書から得られるアウトプットが明確で、読み手のレベルによらず一定に伝わることこの一文に大体このエントリで伝えたいことが集約できている。質の高い技術文書とは、誰が読んでもハッキリとした輪郭で必要十分な情報が伝わるものである。そもそも 1,2,3 の様な文書をどのように使うかだが、基本的には頭から読んでもらって、議論をしたのちに次のアクションを決める、といった形になる。Amazon ではミーティングの際にこうした文書を全員で黙って 15 分程読んだ後に議論を始める、というのがよく語られているが、僕が所属するチームでは大概のミーティングでまさにそれをやっている。質の高い文書は上に書いた様にアウトプットが明確で、読み手全員に一定に伝わるので、全員のレベルを短時間で揃えた上で議論を開始できるため非常に効率が良い。手順書の様なものは全員が揃って同時に読む必要はないが、必要なレビュアー達に明確に情報が伝わって的確にレビューしてもらって approve してもらうことが目標になるので、文書として見ると気をつけるべきことは大体同じだ。僕は Amazon に入る前はあまりこういう形で文書を使ってこなかったけれども、今ではこの手法なしに仕事を進められる気がしない。質の高い文書を書くコツのまず第一であり最も重要なことは、最初にアウトプットを定めることである。つまり、この文書を初めから最後まで読んだ人は一体どんな情報を得られるのか？ということを文書を書く前に決めるのだ。これは Amazon の"working backwards"そのものだ。 "Working backwards" from customer needs can be contrasted with a "skills-forward" approach where existing skills and competencies are used to drive business opportunities.

https://blog.riywo.com/2021/01/how-to-write-high-quality-technical-doc/

Off Topicのコンテンツはいつ、何回読んでも学びがある

NFTが作る、新しいインターネット

最後にOff TopicでNFTについて話したのは3月の記事で、その時はNFTの説明と何故NFTがデジタルコレクタブルなのかを解説しました。そこから1〜2ヶ月間、NFTバブルは続いたが、5月〜6月頃に取引額が下がったと報道されたり、NFTに対する熱意が下がったように見えた。実際に私も最初に購入したNFTでNBAのハイライトをNFT化するNBA Top ...

https://offtopicjp.substack.com/p/everything-about-nfts

中長期的な生産性について考える

斧を砥ぐことの価値｜深津貴之 (fladdict)｜note

仕事では日々の忙しさに追われ、根本的な問題解決に手が回らないことがよくあります。やらなきゃいけない大切なことがある。でも、日々の業務が忙しくて着手できない...このような問題を『のジレンマ』と呼びます。中長期で考えれば、未来への投資をするほうが正しいのに、短期視点では現在の作業に全リソースを投入せざるをえない。いわゆるパラドックスの一種ですね。 ...

https://note.com/fladdict/n/n14d18afc14ed

理想、単純な憧れ

生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで10年の軌跡 - Findy Engineer Lab - ファインディエンジニアラボ

ソフトウェアエンジニアの藤吾郎と申します。最近、 IC （Individual Contributor / 個人貢献者†）という言葉でキャリアが語られることも増えてきたように思います。この記事では、ソフトウェアエンジニアにおけるICというキャリアパスについて、自分の認識と経験を交えて次の点から解説していきます。 ICというキャリアパスがあることを、ソフトウェアエンジニアに知ってもらいたい ...

https://engineer-lab.findy-code.io/gfx

英語お役立ちノウハウ

英語ミーティングを乗り切るために身につけたバッドノウハウ - knqyf263's blog

周りを見ていると何の苦もなく英語社会に適応しているわけですが、日々苦しんでいる人の奮闘記があっても良いのではないかと思って書きました。残念なエピソードを晒すことで実は自分もこうやって乗り切ってましたという人が現れお互いに助け合えることを期待しています。 ...

https://knqyf263.hatenablog.com/entry/2021/08/04/211903

選択と集中の真意について(↑の人の寄稿)

苦手を捨てる決断により広がった世界 - 限られたリソースしか持たないエンジニアの戦い方 - Findy Engineer Lab - ファインディエンジニアラボ

サムネイルは筆者が住むイスラエルの写真。はじめまして、 Sukuda Peppei(@knqyf263) ...

https://engineer-lab.findy-code.io/trivy-fukuda

この連載に勇気をもらえた

白山文彦について｜父｜note

初めてnoteで記事を書くので、手習いとして自己紹介したいと思う。なお最新の情報は常にLinkedInにある。 https://www.linkedin.com/in/fumihiko-shiroyama-632045136/ これを書いている2021年11月現在、カリフォルニア州Sunnyvaleにある Amazon Lab126 でSoftware Development ...

https://note.com/fushiroyama/n/n3e1749241387

Post on X