技術導入についての覚書 - Qiita
先日、『技術を的に当てる技術について』という話をした。これに関連して、影響範囲のある技術を途中から導入するときにこのあたりは一定抑えるのが大事かなあと思ってるポイントがあるので、現状認識のスナップショットとしてちょっとまとめておく1。 最初に確認したいこと2 その技術はどのような課題を解決しようとしているか？それはどのように要素分解できるか？ その技術を入れることで確実に解決される “重要な課題” はあるか？ 初動 その価値が利用の増大に応じて複利的に利くようなものである場合、最初の根を張る必要がある 早い段階で価値を感じられるように、具体性の高い問題解決を行うのが定石 技術を整備したり使う人が理解するのには一定のコストがかかる このコストをリターンがちょっとでも上回るようになることを最短で設計するということが重要 初動を終えた後 そこまでの手応えを振り返り、進むか撤退するかを決める 定常
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
