LoginSignup
5
1

エンジニア向け!ファーストワン駆動+締切駆動で個人企画アウトプットを量産する方法

Last updated at Posted at 2023-12-20

めちゃくちゃ釣りっぽいタイトルそのまんまのポエムです。

今回も、いらすとや さんには大変お世話になりました。

自分が考えたモノ/コトをアウトプットできてますか?

syasei_man.png

できてるぜ!という方は、この記事はおそらく何の足しにもならないです。面白い他の記事などへさっさと移動することをオススメします。

本記事では、下記のような方を対象として、個人企画のアウトプットのコツをお伝えできたらと思います。

  • 社畜エンジニアです。
  • あまり世の中に公表するようなアウトプットができていないが、そのうち何か企画して世に出したい。
  • 会社の仕事だけやってて本当に大丈夫だろうか?という不安がある。
  • コミュ障なので、誰かと一緒に何かを作るというのはハードルが高い。
  • 結構飽きっぽい。長時間同じことに取り組むのは苦手だ。

これ、まさに です。

アウトプットができてない、ということだけは、さすがにこんなネタ記事書いてるくらいなので、今では変わったのかな?と自分では思っていますが、それ以外の部分は今でも何も変わってないと思います。

このような私みたいな方でも、ほぼ100%個人企画をアウトプットできる方法 を紹介したいと思います。

ここで目指す「個人企画アウトプット」とは、下記のようなモノ/コトです。

  • 自分が思い描いたモノ/コト
  • 自分で計画して自分のペースでアウトプットするモノ/コト(それに付き合ってくれる仲間が居ればいいけど居なければ一人でやる)
  • 直接ビジネスを目指した企画ではない。(このメソッドはあくまで「単純にアウトプットすること」に最適化されているので、ビジネスに必要な要素はいろいろと抜けています。ただしあなたのアウトプットが将来ビジネスの種やヒント、きっかけになるかもしれない、というのは十分ありうる話です。)

なぜ個人企画を目指すのか?

エンジニアの原点というか、原始的な価値って、思い描いたモノが作れる人 だと思います。

ただ、現代の会社に所属するエンジニアの仕事って、チームでの作業が前提になっていることが多い気がします。

規模が大きくてスゴイモノが作れたりするのも事実ですが、プロジェクトのチームが大きくなればなるほど、一人一人の役割はかなり細分化されてしまいます。

pr1.png

↑かなり雑に役割一人ずつしか居ない感じで描きましたが、実際はもっと細かく分担が分かれていることの方が多いでしょう。

私も会社の仕事では、受託案件のプロマネをやることが多くて、チームメンバーにお願いしている様々な工程を自ら経験することは難しくなっています。

こういう偏った経験ばかりを繰り返していると、 思い描いたモノが一人では作れなくなっちゃてるんじゃないか? と不安になります。

こうした不安を払拭したいので、時々、いろんな工程を全部自分でやってみて、まだできるぞ と確認したくなります。

pr2.png

なので、その「やってみる」機会も自ら作っていく必要があります。

役割分担のある会社の中で、それをやるのは、たぶん迷惑な話なので、自分の時間を使って取り組むといいんじゃないかな?という話です。

もちろん、冒頭に書いたように、

  • あまり世の中に公表するようなアウトプットができていないが、そのうち何か企画して世に出したい。

という欲求がある方が対象です。

ただ、全てのプロセスを自分で計画して実施することになりますので、企画からアウトプットまで一連のプロセスを全て嫌でも経験することができます。

。。。と書いたけど、ちょっとマテ。個人企画も「ひとり」でやらなくてもよくなりました。

状況が一変

担当全部俺!を経験しよう!というようなことを書きましたが、個人企画でもソフトウエア開発PJの場合、最近下記のようなチーム構成が簡単に取れるようになってしまいました。

gpt.png

コイツ時々ウソつくけど、ポンコツエンジニアも普通にウソつくし....
ほぼタダで働いてくれるし、マジ神

ぼっちエンジニアによる個人企画こそ、chatGPTくんの力を借りまくりましょう!

概要:一言で言うと、モチベーションマネージメントの方法。

前置き長くなりました。本題に入ります。

ここで紹介する方法は、まず 目標設定によりモチベーションを爆上げし、それが冷めないうちにアウトプットしてしまう。
というメソッドです。

エンジニアが自分の欲望をどのようにマネージメントし、それをアウトプットにつなげたら良いのか?ということについて書きます。
技術を爆上げする方法については世の中に情報が溢れていますが、あなたが思い描いたモノ/コトを他の人に頼らずアウトプットするために必要なのは、モチベーションです。

やればやるほど、もっとやりたくなる

という流れができたら、あなたのアウトプットは止まらなくなるはずです。

流れは下記の通りです。

  1. ファーストワンを伴う目標を設定する
  2. いつ発表したいか?の期限を決める
  3. フィージビリティスタディでアウトプットの内容を決める
  4. 期限優先の考え方で必ず期限にアウトプットする
  5. フィードバックや、できなかったことを振り返って、次のステップへ生かす

こんな感じです。

fig1.png

開発プロセスのようにも見えますが、ところどころおかしな順番になっています。
作り手のモチベーションの最大化 と、アウトプットを確実に出し続けること にフォーカスを全集中した方法論なので、いわゆるサービス/製品の企画開発の一般的な方法論と違う部分も多いでしょう。

それでは、順を追って見ていきましょう。

1. ファーストワンを伴う目標を設定する

モチベーション管理の秘訣は、最初に 最高潮まで自分自身の期待値が高まる目標 を設定することです。
はっきり言って、それさえできれば、7-8割成功したようなものです。

ここで言う目標とは、アウトプットを出す時の発表内容 と捉えても良いでしょう。

この発表に、どれだけインパクトを盛り込めるか?で、それを達成した時の自分自身への期待値が変わってきます。
発表を彩るインパクトには様々な方法があると思いますが、とても効果の高い ファーストワン を伴う発表にする、それを目標にする、ということを強くオススメします。

ファーストワンとは?

ファーストワンとは、「世界初」「日本初」「業界初」など、●●発 のことです。
これらの中でも、もっともインパクトが高いのが「世界初」ですね!

ファーストワンの有用性については下記記事がわかりやすかったです。

ファーストワン” で差別化を狙え! 世界初、日本初、業界初… 知らないと損をするファーストワンの有効性

ファーストワンの効果

ファーストワンを目標に盛り込むことの効果は、外部へのインパクト以外にもあります。
それは、 時間的な制約が生まれる、という点です。

あなたが「これは日本初を目指せるだろう」というコトが見つかった時、余裕のある期限設定をしますか?
もしかしたら、他の人が後から同じ目標設定をして、先に発表されてしまうかもしれません。

そうなると、相当に悔しいですよね。

usagitokame.png

ですので、自然に発表時期は なるべく早く! となります。

ファーストワンを伴う目標設定のコツ

a. やりたいコトを選ぶ

いろいろな目標のタネをまずは列挙してみます。

このときに、ひたすらたくさん思いつくまで列挙してみても良いですが、本当にやりたいことは、あまり時間をかけなくてもでてくるはずです。
なので、実はたくさん洗い出す必要はないのかな?と思っています。

最初に思いついた3つ、とかで 十分じゃないでしょうか。
しばらく考えて、やりたいコトが1つしか見つからなかったら、それに取り組みましょう。

列挙した目標のタネを下記のような図にプロットしてみてください。

prot1.png

上下は興味、左右はあなたがやろうとしていることの新規性です。
もちろん、これらは、あなたの主観で置いてしまって構いません。

できるだけ右上にある目標を選びたいのですが、最初にプロットすると左上に偏ることが多いと思います。
一旦はこの状態でOKです。

b. やりたいコトに他の要素を組み合わせ「みたことない」を狙う

さきほどプロットしえみた目標のタネの中で、いちばんあなたがやりたいと思っているタネが残念ながら右上にあることは、よくあることです。
次にやってみることは、いちばんあなたがやりたいと思っているタネ に、他の要素を組み合わせてみることです。

意外に簡単に「いや、これは見たことないぞ」というモノ/コトは生まれます。

kumiawase.png

このように、組み合わせで「見たことないぞ!?知らないぞ!?」という組み合わせを見つけられたら、それは「たぶん世界初」に一歩近づいています。

「なぜか蛇口がついたノートPC」は、おそらく世界初じゃないでしょうか!?(強引)

prot2.png

上記は流石に例が雑すぎて、何に使うんだ!?とか、いや、使えないだろ!画面見えないだろ!とか、いろいろツッコミ所しか無いのですが、だいたい見たことのないモノへの最初の感想なんてそんな感じなので、あまり恥ずかしがらずに自由な発想で組み合わせてみると、いろんな「たぶん世界初」なんて簡単に見つかります。

このように、左上に堂々と配置できたものを目標として選びましょう。

c. 「たぶん世界初」でも先行事例はできるだけ調査する

ファーストワンを伴う発表をビジネスの場などでやろうとすると、エビデンスが必要になります。
エビデンスがないまま、広告やプレスリリースで世界初などと言おうものなら、虚偽広告扱いになり違法の可能性があります。

未知のものが、本当に未知のものなのか?を調べるのは「無いことを証明する」作業とほぼ同じになり大変な作業です。
「本当に世界初なのか?」といった証明は実質困難でしょう。

ただ、今回やろうとしているのは個人企画の話です。
もっというと、たぶん、多いにネタ要素の強いモノ/コトかもしれません。
あまり真面目に考えるのも馬鹿らしいはずです。

なので、言い方も下記のような内容になります。

見たことないから、たぶん世界初かもしれない。(私調べ)

うーん、ファーストワン駆動と言っておいてめちゃくちゃ弱いですが、悪魔の証明に時間を使うほうがもったいないです。

悪魔の証明とは【意味や使い方を事例でわかりやすく理解】ー「ない」ことの証明は容易ではない

あなたが、世界初かもしれない! と信じて(思い込んで)目標設定することがモチベーションマネージメントにおいて重要なのであって、それは後から本当に証明されて「世界初」になったとしても、ならなかったとしても、目標設定の段階では同じことです。何かに取り組んでいるその最中に世界初であることが証明されているわけではないのですから。

ただ、アウトプットを作り始めてから先行事例に気づく、ということもあります。これはかなりヘコみます。

「ちょっとは調べようよ、3日前の自分.....」という感じです。

もちろん、先行事例とカブらないように軌道修正しても良いのですが、できれば目標設定の段階で、調べられる範囲で先行事例や知財を検索しておきましょう。

そして、目標は早めにピボットを。未踏の目標はたくさん転がっている。と考えて、柔軟に切り替える のがコツです。

2. いつ発表したいか?の期限を決める

どんな「たぶん世界初」を目指すのか?が決まったら、次はその発表の期限を決めます。

期限設定のコツ

a. 小さくアウトプットすることを目標に

まだフィージビリティを開始していないので、実現方法は変わるかもしれませんが、発表時にどんな成果を発表したいのか?を最初にイメージします。

できるだけ 「発表に必要な内容」に絞って作る ようにしましょう。
世界初じゃない部分は、作る必要がない。と考えたら、世界初の部分のみにリソースを集中できます。

とはいっても、最低ここまでは作りたいな。という気持ちになるのがエンジニアのめんどくさいところです。

作りたいんだから、もう作るしかないんですが、アウトプットは他の人に届けるコトなので、うまく折り合いを考えて成果の内容や完成度(達成レベル)を決めましょう。

output.png

b. できるだけ直近を期限にする

無理のない、でも余裕すぎない日時を設定するのがコツです。

締切が3年後だと、最初の1年くらサボってしまうかもしれません。

あなたが 怠惰 な人だったり、飽きっぽい という自覚があるのであれば、なおさら期限は短く設定した方が良いです。

そして、あまり遠い期限を設定をすると、誰かに先を越されるかもしれません。
これは相当なリスクです。

何かの定期的に開催されるイベントなどを発表機会にする場合は、最短で成果が出せそうなイベント開催日をターゲットにすると良いでしょう。

見てくれそうな人が集まるという機会まで自分で作るのは大変なことなので、機会優先で期限を設定する方が良いです。

3. フィージビリティスタディでアウトプットの内容を決める

期限を決めたら、いよいよフィージビリティスタディです。

このフェーズの目的は、少し夢のような目標を「実際に作るモノ/コト」に落とし込むことです。
あなたが思い描いたモノ/コトの実現方法を明らかにしていきましょう。

フィージビリティスタディの流れ

目標設定した成果を実現するには、さまざまな小さな成果をパーツとして組み合わせて実現することになります。

そのパーツの入手、実現する方法が明らかな場合にはフィージビリティスタディは基本不要です。

しかし、未知のモノ/コトへのチャレンジにおいて、おそらくすぐに実現手段がわかっているパーツだけではないでしょう。

実現手段を明らかにするために、実現手段の案をいくつか洗い出して、それらのいずれの方法でパーツが揃うのか?を調べます。

そのために実施するのがフィージビリティスタディです。

下記のような流れで実施すると良いでしょう。

feasibility.png

実現方法が見えたら期限に達成レベルを合わせ込む

フィージビリティスタディによって、実現手段が見えました。
次に、作業日数の見積もりをしてみましょう。    

エンジニアならみんな自分の作業日数くらい見積もりできますよね!
詳細は割愛!

設定したアウトプットの期限までに間に合いますか?
もちろん、間に合うようならそのまま進めてもOKです。

間に合わないようなら?期限に成果を合わせ込む必要があります。

awasekomi.png

今回のメソッドで重要視するのは 決めた期限で確実にアウトプットする! という部分です。
検討を進めることで、当初の立てた目標通りに行かないことは多いですが、うまく行かなかったから出すのを先延ばししよう。という判断を繰り返すと、どんどんアウトプットできなくなります。

先延ばしする、という判断に慣れてしまい、モチベーションの低下につながるからです。

当初立てたのは、ファーストワンを伴う発表を行うという目標でした。

その「ファーストワン」の達成レベルは詳細に定義していなかったはずです。
達成レベルを調整して「ファーストワンを伴う発表を行う」という部分をできるだけ最後まで諦めないようにしましょう!

4. 期限優先の考え方で必ず期限にアウトプットする

フィージビリティスタディの結果を受けて、あなたは 確実に期限までにアウトプットできる内容 に、成果の達成レベルを合わせ込みました。
あとは、ストイックにそれを実行するだけ!です。

確実にアウトプットできる内容に落とし込んだことで、本来やりたかったことの一部が今回達成できななった可能性があり、そのぶんモチベーションも少し低下してしまっていることでしょう。

エンジニアは、ここからがモノヅクリという楽しい作業です。

成果をアウトプットするまで頑張って駆け抜けましょう!(少しづつアウトプットするモノ/コトが見えてきますので、モチベーションは少し戻るはずです。楽しんでください!)

それでもやっぱり遅れることもある。→期限に達成レベルを合わせ込む(再)

楽しい作業も、もちろんいつも計画通りに行くとは限りません。

人生いろいろなことがあります。ファーストワンプロジェクト以外にも、いろんなやることが発生してあなたの時間を奪うこともあるでしょう。

それでも最後まで諦めないでください。進捗に影響がありそうだ、という状況になったら、最後の最後まで達成レベルを調整してそれでもアウトプットできないか!?と考えて作業を進めてみましょう。

chousei.png

完成度を犠牲にするのは 妥協 ではなく、妥協なきアウトプットへの執着 です。
一番大事な目標以外、とことん切り捨てながら爆走しましょう。

最後の最後にダメだった時に期限を変更する

もちろん、最後の最後に、あなたが防ぎようのない邪魔が入ることも長い人生の中ではもちろんたくさんあります。

期限を変更せざるを得ない(例えばその日にどうしても発表会ではなく別の用事に参加しなければならなくなった、など)時は、しっかり期限を変更してアウトプットしましょう。

rikujou_hurdle_woman2.png

  • あなたが考えたファーストワンは、あなたが諦めたら世に出ないかもしれません。
  • あなたが諦めても誰かが出すかもしれません。

アウトプットしないと、それまでの取り組みがもったいないです。

成果発表を楽しむ!

「たぶん世界初!」と堂々と言いながら楽しく発表できるといいですね!

筆者が昔発表した「たぶん世界初」の時のスライドのキャプチャ
can.png
今見ても、何がなんだかわからんけど、「たぶん世界初!」が言いたかっただけ、というのはよくわかる。

5. フィードバックや、できなかったことを振り返って、次のステップへ生かす

終わった!
いや、終わってません。

ふりかえる

成果発表をすることで、いろんな変化や気付きがあるはずです。
忘れないうちにしっかりと書き留めておきましょう。

ふりかえり結果は、KPTのようなフレームワークを使って、postalkのような付箋メモでまとめておいても良いですし、github issueなどにまとめておいても良いでしょう。

糧を得る

アウトプットに漕ぎ着けると、アウトプットした人だけが体験できること がたくさん得られます。

得られることの一例:

  • 積み残し課題がたくさん(そのまま次のエンハンスネタになりますね)
  • 他の方からの、ポジティブ、ネガティブ、いろんなフィードバック (あるいは、まったく反応がない!という悲しい結果になることも。それも含めてフィードバック。)
  • 仲間ができた(同じような目標、分野に取り組んでる人とつながる)
  • 一人ボケツッコミのようにいろんなことに気づく
  • あれ、次の期限がもう?

こんなことが起こるでしょう。
もっといろんなことが起こります。

次へ

次のあなたの企画は、これまで進めた企画のアップデートでも良いですし、派生して新たな「たぶん世界初」を目指しても良いでしょう。

これまでの体験を通じて、もっと面白いコトに取り組める予感がしますね!

まとめ

読みにくい文章に、ここまでおつきあいいただきありがとうございました。

エンジニア向けに、ファーストワン(「たぶん」付きですが)を伴う目標設定をして、なんだかやたら締切にうるさい駆動方式で個人企画アウトプットの量産につながる最初の1回目をアウトプットする方法について書いてみました。

流れを振り返ると下記の通りです。

  1. ファーストワンを伴う目標を設定する
  2. いつ発表したいか?の期限を決める
  3. フィージビリティスタディでアウトプットの内容を決める
  4. 期限優先の考え方で必ず期限にアウトプットする
  5. フィードバックや、できなかったことを振り返って、次のステップへ生かす

fig1.png

これ一度やってみると分かるのですが、ファーストワンは、あなたがやりたいことをやり始めるための、あくまで最初のきっかけ作り、口実 でしかなく、最初のアウトプットをしっかり締切駆動で出すことができたら、それをエンハンスしたり、2度目のファーストワンを目指したり、といった欲求がさらに増えていることと思います。

やればやるほど、やりたいことが見つかって終わりません。という一種の泥沼にハマり込むわけです。

「たぶん世界初」は簡単に見つかるぞ

と感じるようになったら、あなたはもう変態の仲間入りです。

ようこそ!こっちの世界へ!

5
1
0

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
5
1