![見出し画像](https://assets.st-note.com/production/uploads/images/68489440/rectangle_large_type_2_141fd78133e9e6dc0373059cbaa9bd7e.png?width=1200)
新しい時代のDevRel - 市民開発者に向けて
この記事は「DevRel Advent Calendar 2021」に参加しています。
はじめに
ここ数年、プロフェッショナル開発者に対して、「市民開発者」という言葉がよく聞かれるようになりました。
どうも「地域課題の解決を目指す開発者(その開発で収入を得ていない)」と、「業務課題をプロフェッショナル開発者に依頼せずにITを使って自ら解決しようとする人々」の2つのタイプがあるようです。
後者のタイプは、我々DevRel担当がお付き合いしてきた人たちとは違ったアプローチが必要かと思って、2021年の6月に開催された「DevRelCon Tokyo 2021」で私の知見をシェアしました。ここでは英語の登壇で、日本語ではシェアしていなかったので、年が変わる前にこちらに記しておきます。
なぜ今、市民開発者なのか
この問いについては、DevRelConとは別のカンファレンスで触れていますので、こちらをご覧ください。
簡単に言うと、DXの推進(特にここ2年間はオンラインコミュニケーションが強制的かつ急激に必須となっているため)によって、IT化のニーズが高まってきているが、プロフェッショナルの開発者の人数はそれほどまで急激には増加できない。そのため、できることは自分たちでやらなければならない、あるいはやった方が早いという状況になったということです。
「プロ」と「市民」の違い
「プロフェッショナル開発者」(以降、「プロ」)と「市民開発者」の違い、こんな感じではないでしょうか?
![](https://assets.st-note.com/img/1640438613832-rlLj80a5RD.png?width=1200)
プロは呼吸をするように、というか、コーディングすることがあまり苦ではなく、市民開発者はなるべくコーディングしたくない、というか、「まず勉強しなくてはいけない」とハードルの高さを感じています。
なので、今までのDevRelスタイルとは変えないといけない!と感じました。では、どうやって??
3つのポイント
必要なポイントを3つにまとめました。
✓ モチベーション
✓ サンプル、サンプル、サンプル!
✓ 幸せ視点
✓ モチベーション
![](https://assets.st-note.com/img/1640439062321-SkAaFUiZik.png?width=1200)
1)自信を持ってもらう
ハードルを下げます。難しいコーディングは少なく(ローコード)、あるいはノーコードで作れる(「開発」とも呼ばずに)ので、「自分で」できる体験をしてもらいます。
2)小さく始める
早めに成功体験を得てもらいます。ローコード/ノーコード、あるいはサンプルをコピーして、パラメータを変えるだけ、小さなものを作って成功してもらいます。
3)画像・映像を多用する
自分で手を動かす前に成功のイメージをつかんでもらいます。我々の今までの体験では想像が付かない箇所でつまずく可能性もあるので。
✓ サンプル、サンプル、サンプル!
![](https://assets.st-note.com/img/1640439518885-6zWwcRvtgS.png?width=1200)
1)ゴールを先に見せる
先ほどと同様に画像を多用しましょう。「どうなるか」を先に見せて理解してもらってからステップ バイ ステップの説明がいいでしょう。
![](https://assets.st-note.com/img/1640439652419-JU2itt1CZb.png?width=1200)
2)サンプル(ゴール)をいじってカスタマイズしてもらう
自分で作り上げるよりも、出来上がったものをいじってバリエーションを作ってもらう方がやり易いです。もし動かなかったとしても、問題はいじったところにだけあるわけなので、切り分けしやすいです。
![](https://assets.st-note.com/img/1640439694272-UZKwocPR4m.png?width=1200)
3)サンプルをくっつける
これは「いじってバリエーションを作る」のバリエーションですね。最初から複雑なものに挑戦しないで、シンプルなものとシンプルなものを組み合わせて、少しだけシンプルさを卒業してみます。自信も少しずつ増えてきます。
![](https://assets.st-note.com/img/1640439703833-jlrnycd0xm.png?width=1200)
✓幸せ視点
![](https://assets.st-note.com/img/1640440155582-1CpCcltWoc.png?width=1200)
1)ゴールは「課題解決」
モチベーションを持ってもらう、あるいは、維持するために有効です。複雑高度なアプリケーションを開発することにモチベーションはわきません。仕組みはシンプルでも日々の退屈なルーチンワークを解決してくれるものや、生産性が向上するようなものを作る方が「幸せ」です。「作ること」に評価されるわけではなく、業務で何を成したかで評価されるわけですから。
2)ササッとできるのが一番
これは1)と共通ですね。プログラミングやコーディングのスキルを付けることが目的ではなく、業務で成果を上げたり、いかに楽できるかが「幸せ」なのですから、そういった方法やツールを提供することでモチベーションを持ってもらえます。
3)特定の利益・利点を
一般的なサンプルよりも、より具体的で業務に沿ったもの、たとえば、経理処理でのルーチンワーク削減、マーケティングでの業務改善、営業担当の作業効率の改善など、得られる利益・利点がより具体的であればあるほど、モチベーションを持ってもらえ、提案するツールやソリューションにも興味を持ってもらえます。
まとめ
新しいタイプの開発者に対してのアプローチは、やはり新しいタイプである必要があるように思えます。私もまだまだ試している段階ですので、DevRelの集いなどでみなさんの体験や知見をシェアし合えれば幸いです。
![](https://assets.st-note.com/img/1640440908234-vBJg4oWbb2.png?width=1200)
みなさんのDevRel活動での幸運をお祈りします!
![](https://assets.st-note.com/img/1640440891634-uyUvZMinzz.png?width=1200)
この記事が気に入ったらサポートをしてみませんか?