DX に必要な DevX とその向上に研修ができること
もくじ
コロナ禍でさらに DX の需要は急増
コロナ禍を機に「 DX（デジタルトランスフォーメーション）」の需要が高まっています。メディアでの DX に関連するニュースはコロナ禍を機に倍増し、皆さまがご覧になるメディアでも「 DX 」にまつわる記事を見ない日はないでしょう。
| 月 | 記事数 |
|---|---|
| 2020 年 9月 | 157 |
| 2020 年 8 月 | 111 |
| 2020 年 7 月 | 102 |
| 2020 年 6 月 | 104 |
| 2020 年 5 月 | 54 |
| 2020 年 4 月 | 57 |
また、メディアでの露出増加だけでなく、検索ボリュームも 2020 年 4 月から 6 月で増加率が 80 ポイント以上と、急増しています。
| デバイス | 2020 年 6 月 | 2020 年 4 月 |
|---|---|---|
| computer PC | 46,885 | 25,660 |
| smartphone mobile | 27,115 | 14,840 |
ちなみに、 ERP や CRM のような、どちらか SoR ( System of Record ) に近いキーワードの検索ボリュームは若干増えているものの、 DX ほどの伸びは見せていません（ ERP は 19 ポイントアップ 。 CRM は 23 ポイントアップ ）。
コロナ以降も IT 需要は減らないという見通しはあるものの、当たり前ですが、分野により増加幅はまだらです。
コロナ禍と DX の関係
なぜ、コロナ禍を境に「 DX 」の需要は伸びているのでしょうか。
コロナ禍によってもたらされたものは、人と人との接触を抑え、極力オンラインで完結することが求められたことです。これにより「全業種で全業務のオンライン化」が検討され始めました。
- オンライン会議
- オンライン授業
- オンライン契約
- オンライン営業
- オンライン製造
- オンラインコラボレーション
- オンライン…
オンライン ○○ は、まだ最適解が見つかっていないことが多く、まさしく「 IT の浸透が、人々の生活をあらゆる面でより良い方向に変化させる」というデジタルトランスフォーメーションそのものです。
先程の SoR の代表格として挙げた CRM はコロナ禍以降でも使用目的・効果にほとんど変化はありませんが、その顧客獲得までを支援する SFA はオンライン商談などでまだ最適解が見つかっていないため、コロナ禍を境に検索ボリュームは増加し、増加率で 54 ポイントアップしています。
このようにコロナ禍により、より一層 DX が求められるようになりました。
もう一つの DX Developer eXperience が DX に効く
DX のように最適解が見つからない場合、従来の SoR と同じように答えからシステム化する方法では開発できません。
最適解が見つからないときには、たくさんの解法を作って試して失敗して、改善・ピボットを繰り返し、その繰り返すスピードを速くして、最適解らしきものを見つけるしかありません。これが SoE ( System of Engagement ) の開発スタイルです。
例えば、 TikTok の前身 musical.ly は、当初 Twitter とオンライン教育を組み合わせ、短い動画で学ぶことができるアプリを開発・壮大に失敗し、資金の 8 % しか残っていない状態から、ピボットして musical.ly を 30 日間でスピード開発しています。
この改善・ピボットを繰り返すスピードを速めることに効くのが、もう一つの DX 、 Developer eXperience (開発者体験) です。
ここではこの 2 つめの DX Developer eXperience を DevX と呼び名を区別して呼ぶことにします。
この DevX 、開発者体験がよいと、気持ちよく開発が進められ、自然と開発スピードが上がります。一方で、開発体験が悪いと、開発が躊躇われ、自然と開発スピードが遅くなります。
関連記事
DX: Developer Experience （開発体験）は重要だ – Islands in the byte stream
この DevX の改善が開発スピードを生み、改善・ピボットのスピードが上がり、結果として DX の成功率を高めます。
DevX に求められるもの。プログラマの三大美徳
DevX を向上させる前に、そもそも開発者が望む、よい体験を知る必要があります。
その原点とも言えるのが、プログラミング言語 Perl を開発した Larry Wall が定義したプログラマの三大美徳です。
- 怠惰 Laziness
- 短気 Impatience
- 傲慢 Hubris
怠惰とは、とにかく無駄なことをしたくない、省力化したい、という気質です。そのために面倒でも自動化プログラムを書いたり、ドキュメントを書く、という行動をとります。
例えば、毎日 10 秒で終わる手動のタスクも、 1 日 1 週間でもかけて自動化したい、という行動を起こしたりします。
短気とは、（コンピュータの）パフォーマンスが悪いときに感じる怒りです。機能仕様を満たすだけでなく、処理速度を気にしたプログラムを書こうとします。
例えば、デプロイやテストなどが遅いときにイラッとして、ワークフロー設定ファイルやテストコードなどを見直して書き直したりします。
傲慢とは、他から文句を言われないようなプログラムを書くという矜持です。意図がわかりやすい、読みやすい、拡張しやすい、コードを書こうとします。
例えば、ハードウェア性能に起因する問題をバグと言われたり、コードレビュー時にクソコードと揶揄されるようなことには敏感なので、厳禁です。
原則的に、開発者がもつ 3 つの衝動が発動しないシステムであれば、 DevX が良いと感じることでしょう。
なお、 DevX がイケてる環境ほど、この 3 つの衝動に忠実な、凄腕の開発者が集まりやすくなります。
研修から DevX の向上をサポートする
DevX の向上の原則に触れたところで、研修担当者ができる具体的な施策を考えてみます。
とはいえ、研修担当者は新しいツールを購入したり、開発環境を決定できるわけではありません。
では、どのようなことができるのでしょうか？
エンタープライズ向けシステム ( SoR が多い ) の開発者の多くは、 DevX を向上させる CI / CD, DevOps, Orchestration, MicroServices などを業務で使うことはおろか、研修などを通じても触ることは稀です。
DevX は experience (体験) というだけあって、百見・百聞は一触に如かず、です。業務でも研修でも触れない現状では、多くのエンタープライズ向け開発者は DevX に興味が湧きにくくなります。
このため、これまでは DevX に興味をもったひと握りの開発者が業務時間外や休日を使って、 Web サイトや書籍、勉強会などを通じて学び体験する、細々としたもので、 DevX の向上は個々の開発者のモチベーションに完全に依存していました。
ただ、逆に、一触すれば、開発者の 3 つの衝動が発動しない、 Dev X が向上するシステム・ソフトウェアに興味が湧くことでしょう。
今までは、個々の開発者の興味やモチベーションに依存していましたが、企業のリソースを使えば、この一触の機会をスケールさせることができます。それが DevX 向上に研修担当者ができることです。
まずは DevX 向上につながる CI / CD, DevOps, Orchestration, MicroServices などに触れられる研修を用意しましょう。
特にコロナ禍により、密を避けるための「リモート開発」はお客様にもメリットがあります。リモート開発環境に必要な Git/GitHub or GitLab, Docker などから入ると、学習コストは低く、成果が得やすいものになるでしょう。
そして、気軽に触れられる雰囲気をつくりましょう。
たとえば、研修を受講するために長々と説明させるような稟議書などはなしにして。これも立派な DevX の向上です。
infoお知らせ
SE プラスでも DX 関連コース、はじまってます！
