自分が「DX」について調べて「完全に理解した」ことのまとめです。
- DX、自分が使うときは「DX」という言葉を使わないほうが良い。「具体的に何をすべきか述べたい」
- でも折角業界を底上げしようとしてくれている言葉だから乗れるところは乗っかったほうが良い
その心は
1つ目に関してはこれ
2つ目に関してはこれ
Qiitaでも以下をはじめ「DX」のタグでいくつか記事がある。
私がDXを理解するために集めた情報
デジタルトランスフォーメーションにおけるシステムの俊敏性とは？を考える
社内エンジニアは見た! 技術的負債とDXの実際【DXレポート,レガシーシステム,デジタルトランスフォーム】
日本語の話の前提としてはこれ (go.jpなやつ)。サマリーだけ見れば良い。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～
デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2（中間取りまとめ）』を取りまとめました
しかし
引用: こちら 、ですよね...。
でその一方、ベストプラクティスなるものをdev.toにみつけた。
「具体的な項目」を「具体的にどうしたいか」がわかりやすい気がした。のでサマリする。
優れた開発者体験へのベストプラクティス
これができればDX（開発者体験）向上してDX（デジタルトランスフォーメーション）できるという「海外のDX話」です。
開発者体験とは？
- 開発者体験（ここでのDX）は、ソフトウェアやシステムのユーザーが開発者である場合のユーザー体験（UX）に相当する。
- 開発者体験は、クライアントライブラリ、SDK、フレームワーク、オープンソースコード、ツール、API、技術、サービスなど、開発者が製品を使用する際の体験等。
何故それが大事なのか?
- 開発者体験が重要なのは、優れたUXが重要な理由と同じ。
- 製品が優れた開発者体験を備えていれば、その技術のユーザーはより幸せになり、より普及し、より長く使える。以下、開発者体験に関する筆者のベスト・プラクティスのリスト。
コミュニケーション
- 優れたコミュニケーションは、開発者体験を成功させるための鍵である。
トーン: オーセンティックに、オープンに、そして正直に
- データ漏洩、バグ、ダウンタイム、データ損失などが発生した場合は、その旨を明確にすべき。ステータスページや連絡システムを作成し、コミュニケーションに利用する。時系列を正直に話し、事後報告やブリーフィングは迅速に行う。
- 製品のロードマップを伝え、開発者がその優先順位に直接貢献できるようにする。開発者を巻き込み、意見を聞く。
素晴らしいドキュメント
常に初心者であるかのようにドキュメントを書く。技術だけでなく、その技術のためのプラットフォームも初心者であるかのように書く。NPMモジュールのドキュメントであれば、そもそもNPMをインストールする方法や、コードを他のJSファイルにインクルードする方法へのリンクを含める。
ドキュメントの言語を統一する。ドキュメントの作成者が複数いる場合は、全員が「method」、「function」を揺れず使用しているか、「module」、「package」を統一しているかを確認する。「Log」ではなく「Activity Log」のように、自社製品に関連する名詞も同様。一貫性を持たせることで、読者が何を読んでいるのか分からなくなり、二度手間になるのを防ぐことができる。
ドキュメントの論理的なレイアウトと構造が重要。基本的なコンセプトを説明した「概要」と、インストールやセットアップを説明した「入門編」など。その後に何が続くかは製品によって異なるが、人々が何をすることを期待しているかに基づいて知るべきであり、その期待を文書化すればよい。
ドキュメントは時として最後に必要なもののように感じられるが、ゆっくりと時間をかけてドキュメントに投資することで、長い目で見れば配当を得られる。
優れたリリースノートとチェンジログ
- 何が新しくなったのか、何が壊れていたが今は修正されたのか、このバージョンのリスクは何か（例えば、これはxを壊すかもしれない）を明確に説明する。
- 詳細については、公開されているイシュートラッカーにリンクできるとなお良い。開発者がバージョンを追いかけるときに、リリースノートや変更履歴にすばやく目を通し、探しているものを見つけられるようにしたい。
- 「これはどのバージョンで廃止されたのか」、「xはどのバージョンで追加されたのか」、「私が経験しているバグはどのバージョンで修正されたのか」。これらの質問にリリースノートで答える。
- サポートのオーバーヘッドを減らすことができる。
プラットフォームのイディオムとツールセットを大事にする
- クライアントライブラリ、SDK、APIなどを作成する際には、業界やコミュニティの標準や、先人が残したプラットフォームの慣用句を尊重する。
- 筆者は本業でiOS SDKを扱っているが、その際、アプリ開発者には常に気を配らなければならない。使用しているXcodeのバージョンは？使用している言語は？Objective-CかSwiftか？どのようにすれば、そのどちらとでもこのAPIをうまく使えるようになるか？あくまでも一例だが、人々がどんなツールを使っているのか、それはどのようなバージョンですか？それらに違いはあるか？を知る。
プログラミングパラダイム
- 自分が好きなプログラミングのスタイルは、他の人も好きだろうと考えがちですが、必ずしもそうではない。
- 例えばあなたが関数型プログラミングが好きならば、ライブラリを関数型インターフェースで書きたいと思うかもしれないが、必ずしもそうはならない。例えば、プレーンなJSとFluent Interface、プレーンなRubyやSwiftと関数型API、Java Builderパターンと単なるオブジェクトの構築など、プレーンな、あるいはより伝統的な、あるいは標準的な方法で書き、さらに特定のスタイルのためのラッパーやファサードを提供する。
- そうすれば、誰もがそれを使うことができるし、あなたのコードを使うために新しいプログラミングスタイルを学ぶ必要もない。
一貫性
- 開発者向けのインターフェースでは、一貫性が重要。UXと同じ理由で、人々のミスを防ぐことができる。
- 他の人のコードに埋め込まれるコード（フレームワークやライブラリなど）については、自分のコードが問題にならないようにするのが一番。
メソッドアノテーションとドキュメント
- メソッドを公開する場合、アノテーションも使える。
ここで渡すものがnullになることがあるのか？もしそうだとしたら、それはどういう意味か？メソッドが返すものもnullになるか？これらが明示されていれば、開発者はこれらのケースを回避するために、より防御的なコードを書くようにスタイルを変えることができる。例えば、アノテーションを追加するだけで、ユーザーがNullExceptionなどを出さずに済む。
それぞれのパラメータやメソッドを丁寧にドキュメント化し、しっかりと名前をつける。初心者がアクセスしやすいように、内部の名前よりも良い名前を付ける。そのメソッドの使い方、必要な前提条件や後条件、動作のヒント、同等のものや重複するもの、副作用など、より多くのドキュメントが必要。
これは外部の開発者の助けになるだけでなく、内部のチームがコードに変更を加える場合にも、スピード感を持って対応することができる。サポートラインの電話が鳴らないようにするためである。
メソッドの削除と非推奨
- 非推奨とは、新しいものに置き換わる過程にある関数やクラスのこと。
- 単に関数を削除したり、動作を変更したりしてはいけない。
- まず古いものを非推奨とし、将来の、できればメジャーなバージョンで非推奨のメソッドを削除するべき。非推奨の期間は少なくとも1ヶ月は必要だが、数年に及ぶこともある。
衝突しない名前空間
- もしプログラミング言語が名前空間やパッケージをサポートしていない場合、コードにプレフィックスを付けてこれを回避する必要がある。これはObjective-Cではよくあることで、多くの提供されているクラスにはNS-やUI-というプレフィックスがついている。コンパイル時にコードが他のコードと同じ名前になってしまうというエラーのリスクを減らすことができる。
スレッド
- モバイル開発では、スレッドやプロセスの扱いに注意が必要。マルチスレッドにありがちな落とし穴を念頭に置いてコーディングし、慎重にテストする。
オープンソースであること (少なくともそうあるよう努力すること)
一部のコードがクローズドソースのままでなければならないことは認めるが、必要でない場合はオープンソースにしたい。オープンソースのベストプラクティスに従うこと、それ自体が良いDXの一部である。良いコミュニケーションに繋がる。
優れたRead Meには何が必要か？簡単に言えば、良い説明、インストール時の注意点、良い例（些細な例）、貢献のガイドライン、既知の問題点など。
オープンソースの取り組みに行動規範を設けることは非常に重要。ユーザーは誰でも、彼らの貢献は彼らが誰であろうと歓迎され、保護されるべき。彼らが価値を与えていることを忘れない。
可能であれば、そして意味があるのであれば、CIシステムもオープンにしたい。
バージョニング
- コードや製品を正しくバージョン管理する。
- バージョン管理をする際には、そのバージョンの影響を伝えられるように、本当はどのバージョン番号を使うべきなのかをよく考える。もし2週間かけて変更したとしても、それはまだパッチバージョンに過ぎないかもしれない。バージョン番号の意味はもっと重要である。
パッケージング
- ほとんどの言語では、コードを配布するための方法が1つ以上はある。JSにはNPMとYarn、RubyにはRubyGems、C#にはNuget、JavaにはMaven、iOSにはCocoaPods/Carthage/SPM（grr）、PythonにはPIP...
ベストを尽くす
- 開発者が使用するものを出荷する場合は、常に新しい開発者の立場でテストを行う。
- 新しいプロジェクトを作成し、それを統合してテストする。
- いわゆるドッグフーディング。
機能セット
- 何が足りないのかを尋ね、その重要なフィードバックを使って製品をより良くしていこう。
- 良い製品は、負荷に応じてスケールアップしたり、目的に応じてしっかりと作られている。
- 結論として、多くの開発者体験は、あなたが開発者であれば期待することをやっているだけである。
最後に: Have Fun
- すべてのやりとりを明るく、双方にとって楽しいものにしよう。
まとめ
以上、開発者にとって体験向上であるというもののリスト。
Side-note: The business people are already hijacking DX for digital transformation, so don't be confused if you just read DX somewhere and it doesn't make any sense :D
と、海外でも闇鍋化が進んでいるようだ。
そんなキラキラワード感のあるDXだが折角の機会であることは間違いないと思い「完全に理解した」ところのまとめでした。結果相変わらず読みづらいのはDXのせいにしつつ、なにがしかの参考になればさいわいです。