エンジニアを目指すなら、アウトプットをクセにするため完成度の低い記事でも公開すべき

最終更新日

Table of Content
警告 読まずにタイトルだけ鵜呑みにしないでください。
公開するからには品質を高める努力に努めるべきです。

(技術ネタでカテゴリーをつけていたんですが、そもそも技術ネタだと考える事自体が意識高い系の印象があったので随筆にしました)

勉強会で共感した話です。
私は講師をやっていく中で「学んだ事を記事に書いて公開しよう=アウトプットを増やそう」という話をよくやります。
人に読ませなくても(公開しなくても)公開できる状態でノートを書こうね、と言っていました。

が、よく考えたらそれって活動障壁が高いんですよね。
学ぶだけなら何も考えずに書いたものを公開した方が、絶対に敷居が低いはずなんです。
アウトプットする事を称賛する、というだけなら簡単ですがそれでも勇気が出ないもの。
アウトプットのメリットは理解しているけど、アウトプットをどうやって促進するか?という観点でもお話ししていきます。

発端

近ごろサイボウズで流行ってる「敷居が低いLT」の話 2022-3-11 B-1
元サイトで動画を視聴: YouTube.
スポンサードリンク

ゲームもアプリもサービスも、完成度<出す事が大事

ゲーム開発でエターなった(開発停止、廃案)!という話をよく聞くと思います。
ゲーム出します!と言ってチームビルディングしていたら、チームメンバーの信頼も失う最悪の結果になってしまうので、推進役のカリスマ性やプランニングスキルが求められるものです。
また、チームメンバーのモチベーション管理も重要な仕事なので、ゲーム開発は難しいのです。

これと同様に、個人で完結するものも難しいです。
個人活動の場合、モチベーション管理をするのは自分だけです。
自分がチームマネージャーとなって、自分で作業をしなければならないので、チーム開発以上にモチベーション管理が重要なのです。

いきなりこう言ったことに挑戦するのは難しすぎるので、まずはアウトプットを増やす練習という意味で、書いた事を「未完成でも」公開するというステップが必要になります。

クオリティは後から上げる

繰り返しますが、完成度を高めて納期に間に合わないようでは、完成率は0%です。
納期に間に合うようにして、しかし改善の余地がある場合は、完成率は0%より大きいので、完成度を高めるより価値が高い、と無理やり納得させる事ができます。

システム開発のスケジュールも「とりあえず完成する事を目標」にして、それからクオリティアップを目指すでしょう。

たとえば、出来上がったプログラムを実行して「エラーになりました」というシーンを想像してみてください。
「コードが読みにくいから整形しよう」と思う前に「とりあえず動くようにしよう」とやりませんか?
これと同じ事を、ここでは言っています。

「読めるものを書こう」とする前に「とりあえず公開しよう」となれば、相当障壁は低くなるはずです。
「公開するために読める状態にしよう」というのが、一種のバイアスと言えます。
まずはこのバイアスをなくして、バンバン公開していくようにします。

大事なことをお伝えしておきます。
「後でやろう」はやらないです。
プロダクトでも「優先度が低いもの」はやらないです。
これと同じ事です。

Webで公開する方法

今手元に何もない事を想定します。
私も通った道です。

まず、完成品をイメージするのをやめましょう。
とりあえずすぐできるもの、動くものを探して自分が使えるような状態にします。
具体的にいうと、NoteやQiitaに登録してノートを転記して投稿します。
登録する内容が技術ネタなら、どっちでもいいです。Qiitaの方が若干楽しいかな。

NoteやらQiitaやらで書いていて思うところが出てきたら、他のサービスを考える頃合いです。
いきなりWordPressはやはり参入障壁が高いので、まずはWordPressについて勉強した事をブログに書いておきます。
勉強しながら環境構築を進めて、ある程度の段階で公開してしまうのです。

ある程度の段階とは、WordPressのプラグインを入れず、テーマも決めず環境構築して記事書いて内容が表示されたその瞬間を指します。
画像をアップロードしたり、マークダウンを使えるようにしたり、セキュリティを整備したり…と言った事は、いったん考えなくていいです。
ただし、WordPressの場合はデフォルト状態で公開して少し経つとBOTに攻撃されます。本格的に運用する際はパスワードを再度変えて、しっかりとアクセス制限を設けましょう。

なお、わかりやすくWordPressと言いましたが、静的サイトジェネレータを使用する場合はhtmlファイルを生成し、ホスティングサーバーを用意できたその瞬間です。

実務の話

今回はこういう話をする場所ではないんですが、実行力があるのはある程度権限や裁量を持っている方になるため、上長向けに書いておきます。
勉強中の方や、フリーランスの方は読み飛ばしてください。

新人研修や指導をしている時に、日報を書かせる文化が多いのですが、この日報は「報告書」であるため、所定のフォーマットや要件に基づいて作成する事を求められます。
上長は「報告書」を見ますが、研修という観点で見れば「報告書」より「本音」が知りたいのです。
日報という形式で本音を汲み上げようという思想がありますが、本当のところは見えません。

  • 公開範囲を限定する(当事者のみとする)
  • 書き手のために、じっくり時間を作る
  • ノルマを課さない
  • 聞き手は絶対に見るわけではない

というルールの元、運用していきます。
Webフォームにすると報告書の形式になりがちなので、Slackだとかチャットベースにします。
最初のうちはDMで捌いていって、同様の悩みを持っている人たちをなるべく同一グループにまとめてそれぞれに試行錯誤をするようにしていくと、レベルの高いグループとレベルの低いグループに分ける事ができます。
レベルの高い人をレベルの低い人のグループに入れる際に生じる「できる人の稼働が高くなってできない人は置いてけぼり」という問題を解消できます。

講師としては、できる人ばかりのグループとある程度できる人のグループと、全くできない人のグループで分類するべきです。
できる人とできない人を混成したグループにすると、できる人の負荷だけが高くなり、チームが崩壊します。
現場では全員ができる前提で、できる事をアサインするはずです。
なぜ研修の場では「できない人をできる人がフォローしましょう」なんて発想になってしまうのでしょうか。

シェアする