創作について考えたけれど、お仕事プログラミングと相性悪いのかなと思った。
創作はゼロから考える必要があるけど、お仕事プログラミングはいろんな素材が転がっていることが多い。あとはそれをどうつなげるか、試して考えるだけだから。
お仕事プログラミングは要件が常に降ってくる。機能的要件を満たす設計を考えること。実装すること。実装方法は自由だけど、悩むことはかなり少ない。
だいたい2-3種類の実装方法を思いつく。愚直にやるか、苦労するか、楽するか。
まず愚直にやる方法を考える。これはかなりメリットがある。ワーストケースとして提案できるし、誰でも思いつく、誰でも作れることがわかる。一般的な処理フローの整理にもなるし、説明もしやすい。メリットデメリットもわかりやすく、他の方法との比較のために役立つ。
苦労する方法はちょっと頭をひねって、努力してごりごりプログラミングする方法。
かなり綿密に設計する必要があったり、チューニングに時間がかかる方法。性能的にはとてもよいかもしれないが、実現する可能性もあまり高くない。期間もかかるし、なんなら伸びることもある。トレードオフを説明するために有用だ。
最後は楽する方法。だいたいこの方法を推すために2つ紹介してすすめることが多い。
問題の前提を切り崩したりする。なんらかのシステム連携を作れ、と言われたら相手先のシステムの改修をお願いしたりする。説得という政治ができればこちらの負担ゼロであるから。
できなかったとしても既存のものを流用する、他のシステムに乗っかる、時期をずらしてみる、本当に必要なのか再考してもらう、別な手法に切り替えることで本質的な問題が解決できるようにするなどなど。
お仕事で新しいことをするときもあまり悩む必要がない。誰かのお悩みとか誰もみてなさそうな領域に気づいて、あとは何ができるか、自分の得意なこととかをちょっと手を伸ばせばできる。あとは軽い設計とどれくらいの期間でできるか、軽いデモができればめでたく担当になったり、他の人にやってもらえる。
お仕事のプログラミングでどうやったらいいのかというのをあまり悩まない。まあ難しくない簡単な仕事ばかりしているせいかもしれない。あまりクリエイティブな内容でもないから。
プログラミングは結果がはっきりしているのもいい。できるかできないか結果がはっきりする。うまく動くか動かないか。それだけだ。運用コストもバグも測定可能だ。主観的に作って入るけど、結果はすぐに客観的な数値などで表すことができる。
統計的なデータを取って説明するときも同様。仮説をたてて統計データを取得して、結果から導き出せることを説明できればいいだけ。わからない結果になったら素直にわからないといえばいい。そして、次の道を探せばいい。データに相関がなければ、そういうデータが得られたことがわかるだけ。結論がおかしいならデータが間違っているか、隠れデータなどがあるか、など道はいろいろある。
ただ、創作はなんというか…わからない。自分でなんか作りたいなーと思って始める。
なんとなく自分でいいか悪いか感覚で判断する。とても曖昧。
テーマもふやふやだし、まあ満足できればいいやと思って作る。だいたい満足するので終わり。満足のハードルは低めに。
自分の満足を求めるのか、他人の満足を求めるのか、創作は自分のために向いてたほうがいいとかいろいろ調べると出てきたりして混乱する。どっちがいいんだろう。
承認欲求はしんどい。Twitterに投稿したり反応もらえるかとか気にするのが大変。
仕事は簡単だ。承認欲求などどうでもいい。反応もどうでもいい。
単にささっと仕事が片付けばいい。なるべく手間いらずで、本質的な問題の解決ができればいい。もちろんコードを書かずに解決して、楽して椅子をぐるぐる回してぼーっとして業務時間が終わればいい。（やらないけど）
仕事はまあほんのり感情はある。気がいい人の仕事はいっちょやるか、となるし、面倒な人から来るとえー…と思いつつしぶしぶやる。でも別に結果は客観的かつわかる形になるので悩むことは少ない。
創作は結果得られるものがだいたいは自分の感情になる。仕事は基本的に自分がなにもしなくてもうまくいけば給料がもらえて一番良い。そこが大きく違う。
モチベーションが違うことが一番の問題なんだろうか。それとも何かを始めるときの素材が足りないんだろうか。それとも結果が測定可能でないことが自分にとってやりづらいことなのかもしれない。自分の満足度なんてまったくもって客観的でない。そして趣味でやっていることに客観性は必要ない。
仕事のやり方をうまいこと創作活動に活かせるといいのだけれど、目下その方法が見つかっていないのが困るところだ。仕事のやりかたを趣味に持ち込んでも息苦しい、趣味にならなくなるだけなのかもしれないが…
