つくること

この記事はnote.comからの転載です。

https://note.com/yamarkz/n/nca9bf8d4b7f7

これはただのポエム。

パッケージを作るにあたって、いくつか試したことがあった。 考えたことを整理したくて書いてます。

半歩先の課題を解く

"半歩先の課題を解く" というのは、"今はまだ解けていなくて、解いたら良いインパクトが生めそうで、頑張れば今の自分の能力でも解けそうな課題を解く"ということ。

この見極めが上手く、忍耐強く行動できる人が、研究者であったり、起業家であったり、オープンソースの開発者などで大きな成果を上げている人たちだなと思っている。

なにかを大きく伸ばす、あるものを広めるときには、"未来から逆算して考える" というのが、考え方の基本原則だったりするが。対して、なにか全く新しい価値を作り出すときの基本原則は、"半歩先の課題を解く" ではないか。

もちろん天才的な発想で、何もないところから発明してしまう人もいるかもしれないが、大抵の凡人が何か新しい価値を作り出すときには、愚直に現在地から半歩先の課題を解いていくことを積み重ねていくしかない。

この感覚というか、見極め自体をコントロールして、ある程度狙って出せるようになれると面白そう。イメージはバッティングを極めて、ヒットを重ねたイチロー選手。すごく難しいけど。

検証から入る

パッケージを作る上で最初にやることは、検証すること。 コードを書くことではない。

自分がイメージしているものが実現できるのか？ 実現できるとしたらどういったアプローチで実現するのか？ の検証を行い、実際に動くコードの70%程度の解像度で、解決アプローチが描けているところまで持っていく。

例えば、最近作ったタイムテーブルのUIを実現するパッケージでは、以下のようなイシューに答えられるようにした。

・ダイアゴナル(斜め)なスクロール動作を実現することは可能なのか？ ・動きに追従して、縦と横のカラムを動かすことは可能なのか？ ・時間軸に矛盾なく、イベントを表示することは可能なのか？

"ぱっと見、できそうかも" と思うイシューばかりだが、「できそうだけどやり方はわからない」という状況から、「できそうで、たぶんこういうアプローチを取る」という状況まで落とし込む。

落とし込むプロセスでは、自分の手で実際にコードを動かしてみたり、既にある解決アプローチを覗いてみたりする。

解決方法は複数のプロセスを模索するが、そもそも解決自体が難しいイシューだと判断した場合には、仮説自体を変えるなり、機転を効かせる。

イシューを解決できるかどうかというのは、その時点での自身の実力や前提条件に依存することが大きい。なので、自身の力量を見極めるのは大事。

実力が原因で解決できなかった時の歯痒さや悔しさは、力を伸ばす原動力になる。何に昇華させられるかで真価が問われていると思う。

動くもの => 使えるもの => メンテしやすいもの

実装の順序は、動くもの => 使えるもの => メンテしやすいもの。

最初から動いて・使えて・メンテしやすいものをつくれることが理想だが、そういった力が乏しいのであれば、動くもの => 使えるもの => メンテしやすいものという順序で、泥臭く開発を進める。普段の新規開発も基本この原則に則る。もちろん経験値が活かせる場面では、最初から最高のアウトプットを出す様に心がける。

一般的に"実装力"と言われるものは、この"動くもの・使えるもの・メンテしやすいもの"に、"速さ・正確さ"を追加した要素で構成されており、各要素の掛け算で算出することができる。

動くものというのは、文字通り動くもの。 動かなければ何の価値もない。使いやすさやコードの綺麗さなどは一旦置いておいて、自分が思い描いた状態になっており、動いて価値を体感できるものを作る。ここが一番大変。

動くものができあがったら、次に使える状態のものにもっていく。 使える状態というのは、自分以外の誰かに見せたときに、使えるイメージがもてるかどうか。もしくは、自分自身がそれを使う側だったらどういう形であってほしいかで判断する。

パッケージなどのOSSの場合、この段階でやることは"制約を設けること"。具体的には、インターフェースとデータ構造を定義して、使う側が詳細な実装を意識せずとも、提供する機能を容易に扱える様にする。一般的には"インターフェースに対して実装する" といった呼ばれ方もしている。

最終段階のメンテしやすいもの、これは所謂リファクタリングのこと。 最悪なくても良いが、あって越したことはない。 特に長く運用するなら必須。個人的には、最低限データ構造とアルゴリズムが適切に分離され、直感的にわかりやすい構造化がなされていれば、それで十分だと思っている。 抽象化しすぎて、汎用性が高いが直感的ではない構造化は逆に意味不明になる。カッコ良いとは思うが、ここはセンスによる。

動くものを作る際に、使えるもの、メンテしやすいものを同時並行に意識して作れることそれ自体が、速さや期待値への正確さに繋がり、結果的に10Xエンジニアになるのではないかという説。

モノづくりの基本的な考え方は、ゲームプロデューサーの米光一成さんの考え方に強く影響を受けている。 (会ったこともないけど、勝手に師匠だと思ってる)

以下の記事内容を無意識化の行動に落とし込めるくらい読み込んでる。 自分の考え方の基礎になっている。

完璧を目指さない

作っているとついアレもしたい、コレもしたいというアイデアが浮かんでくる。それらを取り入れたら良いものになる感じはするものの、堪えてまずは最初に決めた内容を作り終えることに集中する。

そもそも、完璧などないという前提に立つ。 ただし、ここだけは譲れず、絶対に解決しているという自信が持てるポイントは持つ。それが持てない場合は、イシューの定義がまちがっているか、解決のアプローチがズレている可能性が高い。

完璧を目指すと精神的にもよくない。 完了していることは精神的な余裕を作ってくれる。

機会の出会い方

"つくること" が記事タイトルだが、つくることの大前提に、機会の出会い方があると思っている。

言い換えるとチャンスの掴み方。それ自体、色々とあると思うが。 自分が数ある出会い方の中で大事にしていることは、"先端を知ること"。

これは最初にあった"半歩先の課題を解く" にも通じる話だが、先人の歩みを辿り、その延長にある現在の課題を知ることが何よりも大事。

現在何が課題で、将来(半年とかで良い)にどういった状況になりそうかを想像してみる。この将来象と現在地にある差を認識し、その中で自分が解ける or 解きたいと思えるものを探すのが、機会との出会い方。 その距離感として、半歩先ぐらいがちょうど良いというのが先の話。

いずれその時がくるとか、たまたま運がよかったということもあるかもしれない。けれど、凡人が自らの意思で機会を掴み取っていくには、現在と将来のギャップ認識し、それを意識的に見極めることが必要だと思う。