単純←→複雑（非自明）、簡潔←→冗長の軸の話
さざんかぬふ★なぜこの話を考え始めたのか？というきっかけがめちゃくちゃ想定外だった！
今朝書いていたようなことと似たような話題のなにかを見ている 「きっと何者にもなれない」あなたへ
これがはじまり...
そうか、浅い人間でも当たり前にわかるような事を主体的にやる構造を作れないとすれば、そもそも複雑という事なのか！
なるほど
なるほどだけど、そうすると、複雑な事とか、進む方向がわからなくて手探りで進む時にできる限りの全力を尽くす事とか、どうするのだ
コア的な意味での本質は、しょぼくてもわかるはずだし、それぐらいの明確さがないとモデルになれてないという事なんだな。
単純さと簡潔さの話、極端な形ではEAVがある。EAVはDBの見た目の構造(?)は簡単だけど、実際の構造は定義していないという事に近く、汎用性はあるけどデータの取り出し方やチェックは複雑になる。
ただ、DBに保存する時の形なので、それ以外で宣言的に定義されていればコードとしての問題はあまりないけど、普通はコードの中に宣言的な定義がなく、難しくなる。
汎用性と具体性の話になるとき、私は確実に汎用性を選ぶ指向性があるけど、使いやすいものというのは、単目的でデザインされている物も沢山あるし、特定の目的に使用する道具としては単目的の方がわかりやすいし使いやすい。
カスタマイズにも類似の側面がある。
見た目が簡潔で、考えれば使えるというものを自然に目指しがちなのだけど、使いやすさはその反対に答えがある事も多く、それを考えて目指すようにする。
10年前から見えていた答で、きっといろんな人が伝えようとしてくれたんだけど、本当にちゃんとわかるまで（トレードオフとかのてきとうな言葉じゃなくて言語化できるまで）は結局10年かかった。
それが私の能力のない部分だな。
単純←→複雑（非自明）
簡潔←→冗長
それぞれ単軸ではだいたい左の方が良いと思っているけど、この２つのトレードオフ的になったときに簡潔を選ぶと複雑/非自明になっていろんな負荷が生じる。
例えばテストケースを検討して間引いた場合であれば、頭を使わないと読み解けなくなったり、パターン対応できなくてケースを間違えたりする。これは私のコミュニケーションから作業まであらゆる場面のベースになっている。
また、冗長な方がヒューマンエラーをなくすというケースもある（単一障害点を増やすタイプの無駄に長い冗長ではなくて、同じ内容を並行させるタイプの障害点を減らす方の冗長）
簡潔な方が間違いが混入しにくいというのは原則としてあるけど、時間をかけることで間違いを減らすタイプの冗長性は設計に入れ込んでよい。
何にでも使える物が良いのか、何かにベストフィットして使える物が良いのか、みたいなことで、ソフトウェアに対しては私は前者のアプローチをしがち。
これを後者の視点でも見るようにする。
このことが、私の作業の中でミスが多い事とも関係している、というのがとても重要なこと。
多分、単一の作業精度みたいな事では私の作業精度は悪くないんだけど、簡潔に寄っているので一つミスると死になっている事が多く、かつ複雑にもなっているので、結果的にキレイだけど間違いやすいし難しいという事になる。
これが、おそらく開発参入障壁になってるんだろうな。
さざんかぬふ「朝考えていたこと」
スターとかイイネとかコントリビュートとか、私には決してできない事で凄い事だと思う一方、たしかにそれまで肯定される材料がなくていきなりそこだけ肯定されたとすると、中身が空虚に感じてしまい、常に能力を示し続けなければ死という事になるのかもしれない。
自分でこれをゼロから作り上げた、と言えるものがなかったら、他の人が作ったものに乗っかって作っただけという見方もできる（私個人はそれが必ずしも正しいとは思わないけど、可能性として。）
どこでも肯定されていないと、たしかにそのような状態になる事は考えられて、実際の貢献があろうとなかろうと、主観は大きく変わらないのかもしれない。
そういう場合の救いは全肯定以外にあるのかというと中々難しい。究極的には愛しかないように思う。
ビジネスでなければ、このEテレでやってたホームレスに炊き出しとかしてるNPOの牧師と同じようなやり方はある。
単位時間あたりの絶対的な貢献量など全く気にせず、ただ存在しているだけでいい。
実際にはそのようにはできない。のではないかと思っている。
思い出した、自分がやった事を多少抽象化して文字化するというテクニックがある。
特に、自分以外の人がやった事とか、事実とかと同じノリで、淡々と書くようにする。
そうすると、私の場合は自分自身という色眼鏡なしでやった事を見る事ができて、それによってたしかに貢献しているよね、となる。
あと、そのやった事が凄いと思うためのテクニックで、
・先とか将来を想像して、その第一歩と思う
・技術的な難易度を正確に評価して、それをできる人がどれぐらい居るかを計算する
・以前の自分、いつのタイミングの自分からそれをできるようになっていたかを考える
・新しくできるようになっていたら成長として喜ぶ、仮に昔できた事であればそれでもやらなかった理由を考えて、それが解決された事や乗り越えた事を評価する
これらを仕事でもやんなきゃいけないんだったな。私の一番得意な事でもあるんだった。
私は焦燥感は全くないけど、焦燥感を持つための振り返りとも似てる部分はあるんだよな。
具体的には、自分について
これはダメだと論評する人の視線でも振り返っている。ただし、「それでも認めざるを得ない事が何か」みたいな観点で見る事で、焦燥感駆動ではなくて確実にやった事を積み上げていこう駆動になる。
複数の視点、特に自分に批判的な視点で、「それでも許される成果は何か」と考えている。
こういう「何者か」ということとアイデンティティ、みたいな考察があって、さっきの話につながる。
これは採用とも関連していて、そこも地続きで考え続けている...
さざんかぬふ採用とかライフスタイルみたいなこと
自分の責任範囲をどう捉えるか、みたいな事は、プロとは何かということかなあ
プロフェッショナルとは何か、じゃないけど
仕事のイメージを逆に聞いた方が良いのか
どういう風に仕事をしたいと思ってますか、じゃないけど
ケーススタディ的なものを作っておくのかな、例えば自分が使っていた機能で障害が起こった時にどう振る舞うか・振る舞いたいかとか。緊急連絡を受ける立場で働きたいのか、そうではないのか。連絡つかない時間は当然あるにしても、極力24時間体制なのか、そうでないのかとか。
厳密に仕事の時間だけ仕事をしたいのか、それ以外の時間も仕事について考えたいのか。
業務時間中に瞬発的に全力を尽くしたいのか、ある程度余裕を持って試行錯誤も含みで取り組みたいのか。
業務から独立して勉強の時間を取りたいのか、業務で勉強ができれば十分なのか。
乱雑に発生する依頼に自分で話をきいて都度対応するのが楽しいのか、どこかで整理された依頼に対応するスタイルがいいのか。
・障害対応（緊急）
・障害対応（恒久）
・障害ではない使い方の相談
・怪しい事象の相談
・発生課題への対応サイクル
・新規か機能追加か
・労働時間
昔はこれらのことを厳密に聞くのが怖かったんだよな、多分
取り漏らしが発生するという懸念の方が大きかったし、とにかく人が欲しかった。
だから聞かなかった。
でも、結局失敗してわかったのは、そういう事のイメージを合わせないと失敗するという事で、だから聞きにくかった事を積極的に聞いておかないといけないんだな。
これは、この数年で従来無かった自信ができたという事もある。
特に去年うまく行った事が大きい。
少数であっても確実に存在はするし、そういう人とでないとしばらくはやれないから、ひたすら探す、それだけだな。
理想的には、仕組みとして緊急連絡ありの場合に給料を上げるとか、そういうことまできちんと持っていく事なんだよな。
運用課題としては、宣言していた事ができなかった場合にどうするかという事があって、それは四半期なのか半期なのかで振り返りをするのか、不定期でワークしていない時にチェックをするのか。
あと、宣言と実態があっているかのチェック方式。
宣言したことの通りにワークしていれば、それなりに不満が生じないのではないかという仮説がある。が、宣言のカバー範囲外に大きな不快要素が生じるという可能性はある。それは、都度調整ということになるんだろうな。
というスキームについて、事前に会話をして、合意してやっていくようにする？
さざんかぬふ一人の人間で回せるように簡潔になって、冗長な成分が排除されている、という事もある。
だから、私が今のやり方で少人数でやりやすいのは、ある意味での必然でもあって、スケールにおいて課題があるということなんだな（メリットもあるんだけど）
さざんかぬふ実装の難しさじゃなくて、仕様を説明するのに必要なコストで見積をした方がいいな？
単純or簡潔の考え方に対応する、簡潔さではない方の見積
これはブレイクスルーだな
説明量で見積をすべきなんだ
それが全てかは場合によるけど
実装するのにn時間→その時間を減らす圧力は簡潔さに作用（少なくとも私の場合は）
説明するのにn時間→その時間を減らす圧力は複雑さの削減に作用、システムの最終的な複雑さを下げる
懸念点は単独仕様が膨大になる事による把握のしにくさ
「なぜこの実装がワークするのか」「なぜ敢えてこのような実装（仕様）になっているのか」ということの説明コスト。
コードが短くても説明に時間がかかるという場合があって、それは（人によって）把握に時間がかかるという事でもあり、メンテコストに直結する。
もちろん、知識量ないし理解力がある人は説明なしで理解できるけど、そうでない人に負荷がかかるので属人性というかメンテに必要なレベルが上がる。
見積指標を作業時間にすると、どうしても簡潔側に作用しがち。それを単純側に寄せるような圧力を持ったKPI/メトリクスを用意する必要がある。
さざんかぬふ説明をしないといけないUIがイケてない（場合がしばしばある）ように、仕様についてもそうなんだな
仕様のUXを考えないといけない
自分が書く上でバグりにくいコードや、きちんと読めば確実に意味が一意になるコード、最小手順でメンテできるコード...などなど
と
いわゆる可読性のあるコード、読みやすいコード、理解力がなくてもメンテしやすいコード
の概念が違うので、それをどういうバランスでベストに据えるか。
さざんかぬふあああー、唐突にわかったかもしれないやつ
何をsimpleにして、何をeasyにするかなんだ
私のwebアプリの場合、運用でDBをチェックする事が多くて、DBをsimpleにしたい。パフォーマンス的にも、後で分析を考えるためにも。
それが、モデルのsimpleとどちらを優先するのかというのがあるし、モデルと一種のインターフェイスにもなるDBとどちらを優先するのか、そういう事なんだ。
あー、これで違和感の正体が大きく明らかになったかもしれない。
さざんかぬふもちろん純粋なトレードオフではないので、どちらもsimpleにする道がある場合もあるが、どこかでトレードオフになる場合もある。
DB（永続化手法）は一種のインターフェイスなんだよなー
DDDのインターフェイスってどうなってるんだっけ
さざんかぬふDBって原始的なAPIなんだよな
すごいわかった
webアプリの一番原始的なAPIであるDBの設計を、もはやDB単独では機能しないような複雑なものを作ろうとしていない私は最優先しているのだ
さざんかぬふDBの満たすべき制約が、必ずしもプログラムに反映されていなくて、それをDBを見て確認している。障害対応とか、柔軟なエクスポートとか。
それを完全にラップしてこなせる状態であれば、理論上DBはインターフェイスにならない。問題は、それに工数がかかるということだけ。そこに多分転換のポイントがある。
さざんかぬふ正しいDBの状態というものが頭の中にあって、それを使って障害対応や調査をしているが、それにどこかで限界がある、少なくとも人数的な意味でスケールしない。
システムの正しい状態がシステムの中で定義されていたり、データを迅速に扱えるものがあれば、DBは露出しなくてすむ。
さざんかぬふこれは、なぜユーザーストーリーなのかという事への一つの説明でもあるんだよな
つまり、ある一つの機能として成立させても、その集計とかを含むDBの構造とかが直ちに整理されるわけではないので、インターフェイスが十分定義されていないユーザーストーリー上必要な機能が残り、それを万能IFであるDBを使って暫定的に凌いで、必要な機能を検討してそれを入れるというのが私の開発サイクルなんだな。
だから単機能のデプロイはやたら早いし、ガチミニマルになるが、ミニマル過ぎてたりない機能を運用でカバーして、それを改めて必要な形に整理している。
その場合、万能IFがめちゃくちゃ重要になっている。
なるほどー