[検証]やればやるほどやりたくなる、すごい成長ループを思いどおり作り出す

前回↓からの続きです。

人生において達成できたこと、できなかったこと一覧。共通項から理由を考察してみた。

 

前回は、共通項から「ブレイクスルー」のスイッチを発見することができました。理論上では、これを使えば、あらゆる分野でよい循環を作り出して成長することが可能なはず。

20代は、ほとんど「独立」することしか考えてませんでしたね。「会社を辞めて自由に生きたい、そのための力が欲しい」ってことで。

 

なのに、ずっと目標にしていた「独立（＝時間もお金も仕事も自由にできる生き方）」が達成できていません。

なぜか？

 

「社会」は「学校」ほどシンプルじゃない

みんなが同じことを”勉強”し、”成績”という明確なフィードバックが存在した「学校」と違い、「社会」にはそういう数値化できる明確な指標がないこと。

これが一つの要因であると思います。

私のブレイクスルースイッチは平たく言えば「周りよりデキる状況（＝優越感）」でしたが、会社に入ると、みんなそれぞれ別の仕事をしていて、評価軸も人それぞれ。何をもって「周りよりデキる」と判断していいかがわからなくなってしまったのです。

独立して一人になった後は、さらに輪をかけて難しくなりました。一人でやっているので「周り」は存在せず、スイッチも同時に消えてしまったのです。

 

本を読んでも、「何を幸せと定義するかは人それぞれ」とか、「年収が高くても自殺してしまう人がいる」とか、「人は見た目が9割」とか「自分の内面を磨き続けることが人生を豊かにする」とか、もう何をすればいいのか、全然はっきりしません。

 

30代、といってもまだ4ヶ月間ですが、私にとっては「自分の会社を軌道にのせる」がいま一番優先度の高い目標ではあるのですが、結局はイマイチ燃え上がらないまま、モゾモゾやってるに至ります。

 

私のブレイクスルーに必要なのは、「明確な評価軸」と「自分よりデキない周りの人」です。（最低ですねw）が、いまはどちらも欠落した状態、、、だからうまくいってないんですね。

 

ないなら、作ればいい

落ち込んでてもしょうがないので、ここからはどうすれば「ブレイクスルースイッチ」を作り出せるかを考えてみます。

 

目標どおりにいかない問題点の洗い出し

学校では「テストの点数」とか「偏差値」とか「クラスで何番目」とかにあたります。

共通しているのは、全て”数値”であるという点。あと、定期試験では範囲が決められており、何をすればいいのかが非常に明確です。手に負えないボリュームでもありません。

 

つまり、目標を「数値で評価できるもの」で、かつ「手に負えるボリューム」にすればいいと。（あれ、どっかで聞いたような話だなw）

つまり、何をすればいいのかが、目標を立てた段階で明確にイメージできていないとダメだと。

 

例えば、「自分の会社を軌道にのせる」ですが、これをもうちょい掘り下げたファーストステップが、「iPhoneアプリを3月末までにリリースする」でしたが、これではダメですね。

iPhoneアプリを作るのは初めての経験なので、どういう道筋で進めればいいかはわかっていても、テスト勉強ほど明確にイメージできていませんでした。

 

なので、さらにもうちょい細分化します。

1. iPhoneアプリの開発環境を整える
2. iPhoneアプリの設計図を作成する
3. iPhoneアプリを実装する
4. iPhoneアプリをテストする
5. iPhoneアプリをリリースする

これは、1、2は達成済みで、現在3で止まってます。2月からずーっと止まってます。死ぬ。

 

繰り返しになりますが、私にとって「iPhoneアプリを実装する」のは初体験であり、開発言語のSwiftも、総合開発環境のXCode（EclipseのMac版みたいなやつ）を使った開発も初めてで、何をどうすればいいのかは本やネットを都度参照しながら手探りで進めるしかありませんでした。「やるべきことが明確にイメージできている」とはかけはなれた状況です。

 

正直、SE時代にはJavaでのアプリ開発、SQLでDBをいじったりOSやネットワークなどの基盤っぽいことも幅広くやっていたし、このブログもイチからAWSで立ち上げることができたので、正直、「Swiftもなんとかなるっしょ」と甘く見ていました。

初心者用のSwift開発教本とかも買って最後のページまで練習課題もこなしたのですが、実際に自分がつくりたいアプリを実現することは全然できず。もっと高度な知識とテクニックが要求される水準であることがわかりました。具体的には、既存フレームワークやFireBaseなど外部システムとの連携の部分。

やってみると、エラーに次ぐエラーの連続で、もうすげ〜うんざりしちゃいまして。

うんざりしちゃって、しばらく放置（別の仕事を受注したり、遊んだり、ブログ書いたり、筋トレしたり）して、ある日ふと我に返って「これじゃダメだ！」とまたエラーに立ち向かい、返り討ちにされ、また旅に出て、、、の繰り返し。

気づけば、もう4月も終わりですよ。いい加減にしてください。

 

、、、あれ？なんの話だっけ？

そう。iPhoneアプリを実装する、と一口に言っても、やってみると越えなきゃいけないハードルが次々と見えてきたってことです。SEの人はわかると思いますが、「ハマる」と本当にかかる工数が読めなくなります。ある程度習熟してるまでは、「解決するまで」が見積もり工数としか言えません。

誰かが助けてくれるわけじゃないので、ひとつずつ自力で解決していくしかありません。そして、ちょっとずつでも慣れていくしかない。でも、ただ愚直に超えていくのでは今と同じなので、そうでなく「ブレイクスルー」を利用したい。

 

目標細分化：いま一度、「iPhoneアプリ作成」の目標を細分化してみる

「自分の会社を軌道にのせる」ひいては「（まずは）iPhoenアプリをリリースする」ひいては「（自分の設計した）iPhoneアプリを実装する」がうまくいっていない諸悪の根源は、要するに「ハマる」ことです。

では、ハマらなくなる、もしくはハマっても短時間で解決できるようにすればいい。

私のハマりポイントは、Swift言語が理解できないとかではなく、「既存フレームワークや外部システムとの連携」の部分なのはわかっているので、そこを解決する方向に細分化すればよさそうです。

 

たとえば、「FireBaseのリファレンスにひと通り目を通す」なら、読むだけなので、見積もり工数もそれほどブレたりしません。

まずはコレかな。焦りのあまり「必要になったら必要な機能だけ理解するのが最短ルートだ」と思っていましたが、よく考えたら、全体像がみえてないと理解とか不可能だし、なにより非効率な気もしてきました。

うん、急がば回れ作戦に切り替えた方がいいかも。

 

ということで、「iPhoneアプリを実装する」は以下のように細分化しました。

• FireBaseなど外部ライブラリのリファレンスをひと通り読む
  • 評価軸：読むのに割いた時間。多ければ多いほど評価が高い
• 自分のアプリに必要な機能を洗い出す
• ログイン機能を追加実装する
• デザインに必要な素材を集める
• 設計書通りにデザインを変更する

 

うん。リファレンスを読むだけなら、取り組んでいる自分の姿を明確にイメージできます。必要機能の洗い出しも問題なし。ログイン機能の追加実装も、リファレンスをひと通り頭に入れた後なら、確実に今よりも明確に「何をどうすればいいか」が見えそうです。

デザインでは、思い通りに変更できるかどうかでまたつまずく気がしますが、まぁその時はSwiftのUI周辺を重点的に勉強すればなんとかなるかな。たぶん。（ダメならまたその時考えます）

 

よし、細分化はこんな感じでOKとします。

最初のハードルであるリファレンス読みは、残念ながらPDF化されたドキュメントが見当たらなかったので、「iOS Full API Reference」のページを全てのノートPC4台の「ホーム」に設定しました。SafariもしくはChromeを立ち上げたら、最初にこのページが表示されます。英語なのでちょいキツイですが、まぁ1日1つのFreameworkに目を通すくらいならできそうです。

がんばろー！

 

ひとりの仕事で、「周りの人よりデキる」状況をどうやって作り出すか？

前述したとおり、私のブレークスルースイッチは「周りの人よりデキる」という状況です。この状況を作り出すには、明確な「評価軸」と「比較対象（周りの人）」が必要。

 

うーむ。

評価軸を設定する

まずは、「評価軸」から考えたいと思います。

細分化した目標の「リファレンス読み」なら、ページ数とか機能数とか時間で測れそうです。

しかし、実装の方で「ハマる」ことを考えると、数値化する要素を「時間」にするのはうまくいかない気がします。というか、現在進行形で失敗を実証済みです。なので、「〜日までにXXXする」とか「1日〜時間XXXする」ではダメ。

また、「1日あたりのエラー解決数」という手もありますが、エラーの内容によっては数分で解決できることも、何日も解決できないこともあるので、これも評価軸には適さない。難しい問題でハマればハマるほど評価が下がる（解決数が減る）のでモチベーションも下がってしまいます。

 

なので、実装フェーズでは評価軸を3つに増やすことにしました。

「作業時間」、「エラー解決件数」、「切り替え回数」です。

評価は、この3つの積で数値化し、値が大きいほど評価も高いということにすればいいのではないかと。

 

ちなみに「切り替え回数」というのは、「エラー内容でググって解決策を試す」までを1回とした回数と定義しました。「ハマる」と、SEはエラー内容でググって原因調査や解決策探しを行い、その後自分のローカル環境でデバックしたりログを確認したりしながらエラーが解消されたりエラー内容が変わるかどうかを試すのですが、ダメならまたググるところからやり直す、という繰り返しを解決するまで延々行います。（もっと効率のいい方法があれば教えてください）

難しいエラー解決の場合、時間ばっかり食ってエラー解決件数が落ち込むため評価に反映されず、モチベーションが落ちるのが問題だったのですが、この軸を増やすことで難しいエラーほど値が大きくなり、「評価」が高まります。

 

比較対象を設定する

隣の席で私と同じくらいのレベルの人が同じ作業をやっている、というわけでも同じアプリを作っているというわけでもないので、比較対象に「他人」を設定するのは難しそうです。AppleStoreでアプリのダウンロード件数、5つ星評価、レビューなどはありますが、あくまでアプリができてからの話なので今は関係ありません。

初めて作ったアプリがリリース後、いきなりダウンロード件数TOP10入りする、的な甘い夢ももう見れる年齢ではないので、その辺りを比較対象にしてもモチベーションはあがりません。

 

ネット上でのプログラミング大会とかはありますが、ぶっちゃけそんな時間も余裕もないので、比較対象は「自分」にするしか、今のところ思いつかない。

 

自分だけで、「優越感」に浸るにはどうすればいいのか？

難しいですが、過去の自分、、、しかない、ですよね、たぶん。これもどっかで聞いたような話で恥ずかしいのですが、昨日の自分の「評価」と比較してどうか、というのをチェックして、悦に浸るくらいしかないかな〜。

 

あ、、、

システム開発とかそういうのとは無縁の人たち（家族親族、配送業のバイト先の知り合いなど）に、自分がリリースしたアプリのURLを送りつけるのは、結構いいかも。イメージしてにやけられるし、お世辞でも「すごーい！」って言ってもらえれば優越感にも浸れます。

うん、そっちの方がいいな。

最初のアプリをリリースするまでは「過去の自分」と比較して優越感に浸り、リリース後は開発とか全然わかんない人たちに言いふらすことで、「周りよりデキる」という状況を作り出せそうです。

 

とりあえず、明日からレッツトライ。がんばります。

（なんか、今日の記事はめっちゃ独り言っぽくなっちゃいました。すみません。まぁ、暇つぶしにはあまり面白くないかもしれませんが、こんなことウダウダ考えてる奴もいるんだ〜、くらいに思っていただければいいかなと。）

それでは！