ライティングがシニアレベルやプリンシパルレベルのエンジニアとその他のエンジニアを区別する。コーディングだけでなく、複雑な技術概念、決定、推論を明確性と精度を持ってコミュニケーションすることが重要。これは高いプロフェッショナル能力であり、多くのエンジニアでは未開発なスキルである。
ジュニアやミッドレベルの場合、あなたの価値は、あなたが実装できることと結びついている。コーディングを書き、機能を実装し、バグを修正し、その影響はあなたのコード出力に比例する。但し、シニアレベルになると、状況が変わる。あなたの影響は、あなたが個別に構築することの遥か先まで及ぶ。システムの進化を形作るアーキテクチャの決定を下し、技術的な基準を設定し、コードをレビューし、他者が考えることを影響するコメントを書く。
コーディングだけに焦点を当てることはできない。あなたのアイデア、決定、推論を他者に響く方法でコミュニケーションする必要がある。大多数のエンジニアは、このスキルを開発するのに十分な時間を投資していない。デザインドキュメントを例にとると、いいドキュメントはチームの視点を変え、失敗を共有の学習体験に変え、非技術的な利害関係者から理解を得ることができる。
いいデザインドキュメントの特徴は何か。読者から始まる。誰のためのドキュメントか、読者は何を知る必要があるか。ピアエンジニア向けのドキュメントと非技術的な利害関係者向けのドキュメントは異なる。結論から始める。忙しい人たちは最初の段落だけを読むため、その段落を重要にする。オプションを提示するだけでは決定を避けるだけなので、オプションを提示する際には推奨事項を含める。
いいテクニカルライティングには、意図的に省略した内容も含まれる。オプションを却下した理由を説明することで、将来同じオプションが提案されることを防ぐことができる。また、短く保つ。目標は、明確性であり、包括性ではない。
このスキルを構築するには、まず、失敗したプロジェクトの事後分析を書くことから始めよう。何が起こったのか、理由は何だったのか、また将来それを再発させない方法は何か。こちらはエンジニアリング組織で最も価値のあるテクニカルライティングのひとつである。決定を文書化することも大切だ。短いアーキテクチャ決定レコードを書き、1ページに収めることで明確性を強いる。最後のプロジェクトのREADMEを書き、プロジェクトの内容、実行方法、背後にある重要な技術的決定について説明しよう。
また、テクニカルジャーナルを保持してみよう。1日に15分をかけて、解決したこととその方法について書く。技術的な推論を文章化する習慣を身につけ、パフォーマンスレビューまたは昇進の際に役立つ作業ログを構築することができる。
エンジニアリングの深化を目指す場合、支援するためのリソースはある。例えば、Xeitoは、スペインやヨーロッパ全域でシニアやスタッフエンジニアリングの職を探すためのツールを提供している。但し、最終的には、あなた自身が努力を払ってテクニカルライティングのスキルを開発する必要がある。
See what Xeito does end-to-end. Browse all features — application tracker, AI resume + cover letters, interview coach, 130+ job-board sync, built for remote-first developers.