LoginSignup
4
4

More than 3 years have passed since last update.

@j5c8k6m8

金銭的なサポートによりモチベーションを維持できる!? 日本式最新開発手法「ZDD」とは。。

Posted at

⚠️ 本記事は テーブル設計を遅らせることでユーザー体験の最大化を狙える!?米国式最新開発手法「ADD」とは。。 に触発された ポエム です。本記事は、予告せず削除する可能性があります。

今までの開発でありがちな言い訳。。。

  • 技術もあって開発できるけど、マネタイズできないし :confounded:
  • 技術もあって開発できるけど、マネタイズできないし :sweat:
  • 技術もあって開発できるけど、マネタイズできないし :pensive:
  • 技術もあって開発できるけど、マネタイズできないし :worried:
  • 技術もあって開発できるけど、マネタイズできないし :rage:

なんでこんなことが起こってしまうのか :disappointed_relieved:

Done is better than perfect.
　　-FaceBook CEO Mark Zukerberg-

開発において、完了させるためのモチベーション は非常に重要です。

開発環境はツール/サービスが発展し、プログラミング言語自体も進化を続けています。
開発をしようと思うきっかけは、勉強や、興味、社会貢献など人それぞれだと思いますが、
開発のハードルが下がった ことで、個人開発を始める人も増えているように感じます。

しかし、個人開発で リリースまで辿り着く人は一握り ではないでしょうか？

勉強がきっかけであれば、 途中で目的を果たして中止 することもあるでしょう。
また、公開するための 金銭的なコストを考慮して、公開しない 場合もあるでしょう。
当初思っていたよりも 技術的なハードルが高くて断念 することもあるでしょう。
「誰が使ってくれるんだろう」と 悩み始め、開発が中止 してしまうこともあるでしょう。

もちろん、 公開するための環境も多様化し、利便性が向上 しています。
コードはGitHub、静的サイトであればGitHub Pagesを無料で使えます。
ライブラリ開発であれば、主要な言語のパッケージ管理システムは無料で使えます。
AWSやGCPのクラウド環境を利用すれば、無料の範囲内でもサービスを公開できるでしょう。

しかし、 インセンティブを得られるリリースのための環境は発展途上 ではないでしょうか。
広告収入は、収益が個人開発とは直接結びつかないため、敬遠する人も多いでしょう。
iPhoneやアンドロイドのアプリは、それぞれのストアへ申請/審査が必要です。
クラウドで決済サービスを実現する場合も、決済システムを組み込む必要があります。
収益化にこだわらなくても、GitHubのStarで承認欲求を満たすのは難しいでしょう。
公開方法の多様化がコミュニティの分散に関わる ことも一因でしょう。

つまり、マネタイズの難しさを嘆いている開発者は

開発をはじめるハードル <<< インセンティブを得られるリリースのハードル

を感じているのではないでしょうか？

開発でインセンティブを得やすい環境はどこにあるのか

情報を発信するプログラマーが対価を得られるように
　　　　　　　　　　　　　　　　　　　　　　-Zenn-

開発の成果物で対価(金銭的インセンティブ)を得る場合には、以下の2つの問題が有ります。

  • 完成して公開するまで対価が得られない
  • プロダクト作成で必要となったノウハウに対して対価が得られない

この問題は、 開発過程で得た情報を活用 することで緩和することができます。

つまり、技術記事を書くことによる アウトプット（情報の発信） です。
アウトプットをすることで、リリース前からインセンティブを得ることができます。
また、インセンティブがモチベーションの維持につながり、リリースへ近づくことができます。

Qiitaでは、対価を得る事は出来ませんが、 日本最大級のプログラマーコミュニティの一つ1 であり 「エンジニアは全員技術記事を書くことを習慣化した方がいいぞ - Qiita」 の記事中に紹介されているようなインセンティブを得ることができるでしょう。

また、対価が得られるアウトプット先 として 「Qiitaでお金が稼げるなら質の高い記事がもっと増えるのではないかという提言 - Qiita」 には、以下の3つのアウトプット先のメリット/デメリットが記載されています。

  • 個人ブログによる広告収入
  • note
  • Medium

2020/9/16 より、 対価を得られるアウトプット先の候補の一つとして、Zenn が追加 されました。
Zenn は medium とは異なり日本人主体 であり、 note とは異なり技術者主体 のコミュニティです。

how-it-works.png

また、Zennには対価を得られるという面以外に、 GitHub連携2をベースとしたコーディング環境 で執筆し、エコシステムを活用できる というメリットもあります。

ZDD は Zenn Driven Development(Zenn駆動開発) の略称です。[要出典]

つまり ZDD とは、金銭的インセンティブ のある、日本人主体 の 新しい コミュニティである Zenn と エコシステム をコーディング時に利用する 開発です。タイトル回収

具体的にZDDとはどんな物なのか？

Zenn駆動開発(ZDD) とはその名の通り、Zennでの執筆ありきの開発スタイルのことで、簡単に言うと 「Zennで記事や本を書きながら、コードを書く」 ことです。

ZDD に近い開発手法は、 README駆動開発(Readme Driven Development; RDD) でしょう。

「わかりやすい README駆動開発 - Qiita」 では、 モチベーションが高いときに書ける と説明がされてますが、 ZDD はモチベーションを維持しながら開発できる といえます。

記事や本をドキュメントと考えると、従来型のウォーターフォールモデルに近い開発のようにも思えますが、そうではありません。
ウォーターフォールモデルにおけるドキュメントは、コードの元となる仕様であり、設計書です。
それに対し、Zennのような読み手の評価によってインセンティブが変わるドキュメントの作成から得られるものは、 ユーザとの対話 や 変化への対応 といったアジャイルに近いもの でしょう。

また、他の開発手法と比較して、ZDD のユニークな点は、最終的に採用されなかった手法や失敗についても、整理し、フィードバックを得る ことができる点です。開発のプロセスや知見からも、インセンティブが得られることで、モチベーションを維持しながら 開発中でも改善点や新しいアイディアを探す 機会が増えます。結果として、成果物もより価値の高いものになるでしょう。

更に、README駆動開発 と同じく、コーディング環境内で記事や本を作成 できる点も非常に大きなメリットです。

ZDDでは、Zennの GitHub連携 と Zenn Cli(npm) の利用が前提 となります。
これらについては、以下の公式の記事を参照してください。
- GitHubリポジトリでZennのコンテンツを管理する - Zenn
- Zenn CLIをインストールする - Zenn
- Zenn CLIで記事・本を管理する方法 - Zenn

npm と GitHub が前提となることで、以下のようなエコシステムが活用されています。

  1. npmのパッケージ
  2. 開発用エディタのプラグイン
  3. GitHub Actions などの GitHubの機能

ここでは詳細は省きますが、具体例を紹介します。

一番多く利用されている例は textlint でしょう。
エディタに VS Codeを利用している人も多いかと思いますが、「textlint と VS Code で始める文章校正 - Qiita」 などを参考にすれば、簡単にセットアップできます。(npmのパッケージ と 開発用エディタのプラグイン の活用)
また、「zenn-cli + reviewdog + textlint + GitHub Actions で執筆体験を最高にする - Zenn」 では、プルリクエストを利用した校正が可能です。(npmのパッケージ と GitHub Actions の活用)

筆者によって ZDD のために開発されたnpmとして、 zmce(ジムチェ) があります。
「Zennの執筆体験を向上させるnpm「zmce」を公開した - Zenn」 で紹介されていますが、 コードをコマンド一つで記事や本に反映 することができます。

実際に zmce を開発する際には、以下のように、テスト駆動開発(Test-Driven Development: TDD) に近い ZDD を実施しました。

  1. 記事の雛形を先に執筆
    記事の構成を決め、コードや、入力ファイルと出力ファイルの期待値など、空のコードブロックを含んだ記事を先に執筆します。
  2. テストを書き、テストのIN/OUTを記事で参照させて確認
    次にテストを書きます(Jestを使用しています)。入力ファイルと出力ファイルの期待値をファイルで保持し、zmceコマンドで記事のコードブロックに反映させます。
  3. コードを書き、コードを記事で参照させて確認
    テストが通るようにコードを書き、コード自体もzmceコマンドで記事のコードブロックに反映させます。
  4. commit & pushして公開

実際にテストが通っているため、 記事に載せるコードや結果に対する担保 が可能で、仮にバージョンアップ等で仕様を変更しても、 コマンド一つで記事をアップデートできる 安心感がありました。
npmの公開等は手動で行いましたが、GitHub Actionsを使えば更なる執筆体験の向上が出来るのではないか？と考えています。
また、全て無料で利用できるにもかかわらず、金銭的なインセンティブが有るかもしれない？ということがモチベーションに繋がり 公開に至ることができました。まだ、金銭的なインセンティブは得られていませんが

なお、ZDD のためのエコシステムは、以下の理由により、今後更に盛り上がっていくと思います。

  • GitHubという非常に多くの開発者が使っている開発基盤と連携できる。
  • Zenn Cli自体が、OSSとして公開されていて3仕様がオープンになっている

Zenn では、記事ではなく本も執筆できるため、 本のためのサンプルコードを書いていたけど、使えそうだから公開しよう みたいな体験も増えてくるのではないか？と思います。

Qiitaを利用した最新の開発手法との比較

最近は、Qiitaでモチベーションを保つ方法として、 ジェイソン・ステイサムというタグを作り、はぐくむ4 という 画期的、かつ、非常に効果の高い開発手法 が紹介されています。

しかし、適応できる範囲が限定的というデメリットもあり、マネタイz

おや、誰か来たようだ。

  1. https://ja.wikipedia.org/wiki/Qiita ↩

  2. https://zenn.dev/zenn/articles/connect-to-github ↩

  3. https://github.com/zenn-dev/zenn-editor ↩

  4. https://qiita.com/twtjudy1128/items/e603e05abf6cb93a6594 ↩

4
4
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
4