フリーランスエンジニアは「公式ドキュメント」で信頼を得よう

フリーランスエンジニアが仕事をする上で、クライアントからの信頼を得ることが重要であることはいうまでもありません。

もちろんフリーランスエンジニアに限らず、すべての人にとって仕事をする上での信頼関係は重要なのですが、特にフリーランスエンジニアは信頼関係に気を遣わなければならない事情があります。それは、クライアントやプロジェクトを転々とすることの多いフリーランスエンジニアにとって、少しずつじっくりと信頼関係を育てていく時間がないからです。
入社したあと、長年同じメンバーと一緒に仕事をするような正社員エンジニアであれば、自身の成長を年単位で見てもらったり、長期的な取り組みの上で成果を出したりと、「長い付き合い」の中でゆっくりと確実に信頼関係を構築することが可能です。

一方でフリーランスエンジニアは、プロジェクトにジョインした次の日からクライアントに信頼され、大切な仕事を任されるくらいでなければ、自分の求める条件の下で長期的な付き合いを続けることは難しいといっても過言ではありません。フリーランスエンジニアは正社員と違って「ゆっくりじっくり信頼してもらえるようになる」頃には、契約期間が満了となってしまうことも珍しくないからです。

このような「ジョインした次の日には信頼されている」状態を実現するための方法はとして、自分の書いたソースコードや技術記事などのアウトプットをWeb上に公開しておいたり、参加したプロジェクトの成功を見据えた提案を積極的に行なっていったり、といったものが考えられます。

それらとはまた別の手法として、この記事では「公式ドキュメントを根拠に発言する」ことの重要性について考えていきたいと思います。

ご存知の方も多いと思いますが、IT分野における公式ドキュメントとは、その技術の開発者自身が利用者に向けて書いたドキュメントのことです。公式ドキュメントには、「その技術が何であるか」「なぜそれを開発したのか」「どのように使うのか」などの情報が開発者自身によって網羅的に、常に最新の内容で整備されています。

公式ドキュメントはひとりでも多くのエンジニアがその技術に興味を持ち、正しく利用できることを目的に作られている場合が多いため、その内容についても少なからぬ工数と熱量が注ぎ込まれていることも少なくありません。

例えば私が仕事でよく使っているFlutterというフレームワークは、公式ドキュメントを開けば初心者でもわかりやすいチュートリアルやフレームワークの提供するAPIが網羅されたAPIリファレンス、またFlutterの内部的な仕組みを詳しく説明するドキュメントまで、さまざまな情報が用意されています。

https://flutter.dev/

これらを順番に読んでいくことで、Hello Worldからスタートして、ちょっとしたアプリを開発し、さらにはフレームワークの特性を理解した適切な設計ができるようになるところまで、幅広いレベルのエンジニアに重宝されています。

エンジニアが調べ物をする際、公式ドキュメントとはまた違った切り口で有用な情報を得られるのが技術ブログです。

技術ブログは、さまざまなエンジニアが、思い思いの目的、粒度、レベル感で自身の知見や知識を文章にまとめたもので、ちょっとした調べ物や技術への入門の際に便利であることはエンジニアであれば誰もが知るところでしょう。

公式ドキュメントと技術ブログの詳しい比較については以前にQiitaに記事としてまとめてありますので、一度そちらを読んでからこの記事を読むことで、より効果的にこの問題について考えられるようになるでしょう。

【新人プログラマ応援】公式ドキュメントも読もう | Qiita
https://qiita.com/chooyan_eng/items/cd0d3174b77ff1e02c3f

なお、この記事は公式ドキュメントを根拠に話すことの重要性について議論するものの、技術ブログが公式ドキュメントよりも劣っているということでも、技術ブログは参照しない方がいいということでもありません。

むしろ、それぞれの特性を理解した上で、適切なタイミングで適切な方を活用できるようになる必要があります。そして「クライアントの信頼を得る」ためには、公式ドキュメントを利用するのが効果的であることを、その理由を中心にここから説明していきます。

仕事をしていると、技術的、ビジネス的に何らかの意思決定をしなければならない場面に少なからず直面します。

新しく開発するシステムの言語やフレームワークはどれにするのか、Appleの審査を通過するためにどのような仕様にすべきか、目の前の機能を実現するためにどのAPIを利用すればよいのか——など、サービス開発は意思決定の連続です。

それらの意思決定に必要な情報のすべてを最初から知っているということは不可能ですので、通常は「調査」を行なった上で、そこで得られた情報を基に最適な判断をしていくことになります。

ここで必ず意識しなければならないのが、判断材料となる情報の「正確さ」です。誤った情報を基にした判断は、思わぬ結果を引き起こし、それは往々にして望まない結果であることが多いからです。そしてその「正確さ」という点で公式ドキュメントと技術ブログでは大きな差があります。

確かに技術ブログはさまざまなエンジニアが、さまざまな切り口で書いているために、うまく検索すれば自分の求める内容が自分の理解しやすいレベル感で書かれているものを見つけることができ、調べ物をする際に気軽に利用しやすいことがメリットです。

しかし一方で、技術ブログは公式ドキュメントに比べて「正確さ」が保証されないという点に注意が必要です。

詳しくは先ほどのQiitaの記事で言及していますが、技術ブログの書き手はその記事の正確さを追求するインセンティブが公式ドキュメントに比べて低いと考えられます。書いた内容に誤りが含まれていたとしてもせいぜいコメントとして訂正の指摘がくる程度で、それが原因で仕事上の不利益が発生することも考えにくいでしょう。

また同じ理由で、記事の内容が最新の状態に保たれている保証もありません。一度書いた内容が技術のバージョンアップなどによって古い情報となってしまったとしても、書き手に不利益がないからです。

一方で公式ドキュメントは、そのような誤りが含まれることは「利用者の減少」という不利益に直結します。

公式ドキュメントの通りに動作しない、公式ドキュメントの記述とソースコードの現状が乖離している、などの問題はその技術の利用者への不信感や開発の非効率化、さらにはシステムの不具合に直結し、最終的には「その技術自体を使わない」という判断をさせてしまうリスクにつながるためです。

構造的に「正確さ」を保証することへのインセンティブが高い公式ドキュメントを根拠に意思決定をすることで、その意思決定の精度を高めることができ、またそのような信頼できる情報をクライアントに提供することはそのクライアントからの信頼関係を構築するための大切な行動であることが理解できるのではないでしょうか。

ちなみに公式ドキュメントだからといって、そこにすべてが書かれているわけではありません。求める情報が公式ドキュメントに載っていないというパターンもよくあります。そして、その求める情報が他のエンジニアの知見として技術ブログにまとまっている場合もあるでしょう。

しかしここで考えるべきは、「やっぱり技術ブログの方が情報量が多くて便利だ」ということではなく、「公式ドキュメントに載っていない」こと自体が重要な判断材料になるという点です。

公式ドキュメントで言及されていないことは、時と場合によって変わりうる「不確実」な要素だと判断できます。

たとえば公式ドキュメントで名言されていない仕様は「実行環境やバージョンアップによって予期せず変わり得るリスクがある」ということを開発や検証の段階で考慮すべき部分だと判断できますし、また別の例としてアプリの審査のガイドラインで曖昧に書かれている部分などは、審査の担当者の解釈ひとつで結果が変わる部分であり、常にリジェクトと申請し直しのために余裕を持ったスケジュールを組むべきと判断できるでしょう。

不明な部分や不確実な要因に対してリスクヘッジをするのも重要なビジネス判断です。そのリスクヘッジを促すための「不確実な要素」を洗い出す材料として適切なのもやはり公式ドキュメントであるといえるでしょう。

クライアントとの信頼関係を築く上で、正確な情報を提供することは何よりも大切です。正確な情報はより精度の高い（そして間違いの少ない）意思決定を促すことができ、またその意思決定によってビジネスが成長すれば、そのクライアントとの長期的でよりよい条件での契約に結びつくことが期待できます。

そのための正確な情報源として、公式ドキュメントを提示することはとても効果的です。その技術の開発者自身が作成する公式ドキュメントには、正確で最新の情報が書かれている状態に保つインセンティブが働くからです。

わかりやすいという一点で、正確性も情報量も保証されない技術ブログに頼るのではなく、多少の時間と労力を割いてでも、公式ドキュメントから必要な情報を見つけ出すことが大切です。そうすることで正確性のある成果物をクライアントに提供することができ、結果、クライアントとの強い信頼関係を短期間で構築できるでしょう。