念願のワーカーホリックツール作った
これ作りたかったんですよ
１時間毎に、週、月の作戦を練るやつ
セルは全部ボタンになっています（重いｗ）
所要時間１時間
やっぱ月270時間労働行けますね！！（せやろか）
次は2色,3色にしたい
あなたは自動テストを信じますか？ 自動テスト懐疑論の解説
神を信じますか？ 自動テストを信じていますか？
- 自動テストに対する２つの派閥
- 自動テスト懐疑論
- よく言われる自動テストの効能
- 自動テストの本来の効能
- 自動テストせざるを得ない状況がある
- 自動テスト論の問題は、適用範囲の問題
- 「コードがきれいになる」のおかしさ
- テストコードを過信してはいけない
- 使い捨てで良いのでは？
自動テストに対する２つの派閥
自動テスト（Unitテスト）は二つの勢力があります。
信者
自動テストを書かないと地獄に落ちる派
懐疑派
自動テストのメリットを信じていない派
ちなみに最大勢力は「自動テストを信じているけど、今はやれていない派」です。
地獄に落ちないように、会社に対して呪いをかけることで精神の安定を保っています。
懐疑派はあまり声を大にして自動テストを否定しません。戦争になるので。
ただひたすらゴニョゴニョ言って信者を妨害します。
これらの戦いは、かれこれ20年以上は続いているのではないかと思います。
自動テスト懐疑論
冗談はここらへんにして。
私の最近の主張は「自動テストは良いツールだが、世の中の信者は期待しすぎている」です。
ちなみにこれはデザインパターン（MVVMとかMVPとかクリーンとか）に対しても同じ立場です。銀の弾丸はありません。
こう言うと、信者には「それは当たり前だ、でも自動テスト書いていないのはあり得ない」と言われるのですが、私の信じている自動テストはもっと狭い領域です。
よく言われる自動テストの効能
よく言われるものですが。
- 品質向上
- 速度向上
- コードがきれいになる
- 仕様書の代わりになる
ここらへんでしょうか。
これらについては非常に懐疑的です。温泉の効能くらい信じていません。
どうにも結果的に起きる副次効果でしかなく、これらの項目ってテストし辛いんですよね。
正直肯定も否定もしづらいです。
自動テストの本来の効能
- 大量のテストが可能
- 深い領域のテストが可能
- モジュール単位でテストが可能
これです。
自動テストについてまとめられた本やドキュメントなどには、普通にこのように書かれています。よく言われる、何か病気が治る的な謎効能は書いていないはずです。
自動テストせざるを得ない状況がある
テスト（手動、自動）というのはザックリ言えば、ある条件に対して入力と出力を得ることでチェックすると思います。
ですが、
- 手動では入力できない
- 入力が大量になってしんどい
- 何度も同じテストを行わなければならない
- モジュール毎にテストが必要
と言った状況が発生します。
この時にテストを使います。使わないというのは、テストしないということです。
自動テスト論の問題は、適用範囲の問題
問題なのは、目的となる効能が本来のものとは異なる点に置かれているため、本来必要性の薄い箇所にまで自動テストを適用してしまう点です。
なぜそんな厄介なことになっているかと言えば、おそらく
- ジャンルによって自動テスト必須対象の差が大きい（ほとんど全部だったり、ほとんど無かったり）
- 何が自動テスト必要かについてあまり語られていない（手動テストと分けられていない）
- 副次的な効能が、そもそも計測しづらい
- やらなきゃいけない雰囲気
ここらへんだと思います。皆混乱しているだけです。
特にバックエンド側の開発を中心にされている方は信じられないかもしれませんが、自動テスト必須とするような箇所が殆どないプログラムというのは結構存在します。
（※ここではUITestを無視しています。あちらはまた別の文脈になるので）
具体的に言えば、フロントエンドやアプリなどでは効果が薄いです。もちろんゼロではありませんが。
「コードがきれいになる」のおかしさ
ここらへんはTDDの話なのかもしれません。
自動テストが可能なコード ＝ 綺麗なコード
ではないし、綺麗なコードを書けば自動テストが楽になるわけでもないです。
両者は確かに少し被っていますが、人間はテストコードではないので、人間にとって読みやすいコードと、テストが読みやすいコードは違います。
却って難しくなるケースも多々あります。
もちろん難しくなるケースにおいて、テストが必須な対象であれば仕方ないのですが、テストが必須ではない対象なら難しくするのはむしろ品質と速度を落とすのではないでしょうか。
テストコードを過信してはいけない
私達は、コードに不安があるからテストコードを書くし、手動テストを書きます。
ですがテストコードのテストは基本的にされません。
手動テストであれ、自動テストであれ、正しさというのは限界があります。
数学的に正しいプログラムというのも研究されていますが、極狭い領域しか担保できないらしいです。用途不明だったり、大量だったりするテストコードは却ってプロジェクトの足をひっぱるかもしれません。（ただしそれを計測するのは難しいです）
使い捨てで良いのでは？
どうしても自動というと、「効率化」「品質向上」「速度向上」という側面が期待されてしまいますが、上で書いた通り本来の自動テストの効果は「テストができる」という点に集約されます。
結果的にテストの再利用が可能なこともあるでしょうが、基本的に自動テストは使い捨てする気持ちでいいのではないかと思っています。
コードの方だけ修正した時、テストが通るかどうか確認して、通ったら安心するというのはオカシイです。自動テストコードが正しいか、都度チェックしなければなりません。でもそうするとチェック対象が大量になるし、影響範囲がわけわからなくなりませんか？？ 技術的負債になると思うんですが。
あわせてよみたい
死ぬほど雑に東京を説明する
上京して8年位
未だに東京が謎です
山手線ですら多すぎる
引っ越しを検討するたびに徐々に覚えていってる気がします
新宿から秋葉原が7kmくらいなので、真ん中あたりにいれば自転車圏なんですよね。
でも大崎から大塚は13kmくらいなので、縦はそれなりに遠いです。
技術的負債に立ち向かう
ブログを読んだ人からTwitterで相談されたので、改めて考えてみました。
（※よく聞いたらちょっと事情違いましたが）
ちょっとまとめ方がまだ粗いです。非常に難しい問題ですし。
正直ここに真正面から取り組んだことはないのですが、これまでの色んな経験から述べてみます。（そもそも取り組めるケースが稀）
想定読者：エンジニア歴3年〜くらい？
0.議題
スタートアップ2〜5年目あたりの苦しいフェーズをどう乗り切るかという話題です。
特にバグがどんどん増えていく状況。ジェンガコードにどう立ち向かうか周り。
皆同じように苦しんでいる印象がありますが、苦しんだ末にどうにかなっているサービスと、どうにもならなくなったサービスがあると思います。
元になったのはこの話でした。
1.技術的負債とは何者なのか？
平たく言えば、開発における技術的な足枷であり、雪だるま式に増えていく複雑さだと思います。
負債とはよく言ったもので、実は開発リソースに余裕があるなら問題にならないことが多いです。
例えば「１億円の負債がある会社はダメなのか」と同じ話です。よく言われる話ですが会社が負債＝借り入れを持ってるのは当たり前で、制御可能なら問題ないわけです。
例えば大規模なプロジェクトだと、少しのコードを変更するのに１人月以上あったりします。
問題となるのは余裕が無いときです。
負債が1億円、年商が1000万円、だとしんどいのと同じで。
なので技術的負債がきつくなるのはベンチャーとか、開発リソースの少ないプロジェクトであることが多いと思います（まあ大多数はそうですけどね！）
継続期間が長いことも技術的負債が問題になる要因の一つですね。
1.1.技術的負債の単位は「困る度」
上で「複雑さ」と書きましたが、厳密ではないと思います。
非常に複雑なコードでも、それを後で触らないなら別に負債とは呼べないわけです。
負債となるのはプロジェクトにとって困るからです。
技術的負債はプロジェクトの都合に依存する
これ、結構語られないと思うんですがどうでしょう。
ただ一般的に、コード等が複雑であるほど困るので、複雑度に注目することが多いということだと思います。
（厳密に言えば「複雑」以外にも、「差し替えコストが大きい」などがあります。例えばDBの設計だとか。一言で表現しづらいですね）
ちなみに「新規開発して、納品して完了」な受託開発などは複雑でも困らないので、発狂するほど複雑度が高いものが出てきたりします。
それでこうなるわけです↓ 引き継ぐの人が死ぬ。
世の中の、仕事に困ってない一部のエンジニアは引き継ぎ案件を明確に拒否しています。それくらい面倒です。
1.2.プロジェクトはなぜ「困る」のか？
技術的負債というのは、それだけで複雑系です。
分解しないと議論ができません。
プロジェクトはどういうときに困るのでしょうか？
- 改修スピードを上げたい
- 仕様変更に対応したい
- バグを出したくない
- クオリティを上げたい
- お金をかけたくない
- スケールさせたい
でもできない！ そういう時ですね。
1.3.なぜ皆が技術的負債に悩んでいるのか？
プログラムというのが、指数関数的に複雑度が上がるのに、人員をふやしても作業量は線形ですら上がらないからです。
なので誰でも簡単にこの問題に遭遇ができます。
問題は線形で起こらないため、対処しないとどこかで詰みます。
1.4.一旦まとめ
混乱してきそうなので一旦話をまとめます。
こんな感じですかね？
「お金」と「スケール」は開発の場合意味が重複するため割愛。
2.技術的負債の返済方法
2.1.ゴリ押し
そもそもの目標はコードではなくプロダクトに紐付いていて、プロダクトはプロジェクトに紐付いているわけです。
なので、こういう事が考えられます。
- 負債の踏み倒し → コードを捨てる
- 負債の一括返済 → 最初から作り変える
これらが出来るなら、チャンスだと思います。技術的負債とちまちま戦うよりは楽です。
実際に「ベンチャー３年目でフルリプレイス」みたいなのはよく聞きますし。うまくいっていないプロダクトをクローズした例もよく聞きます。
真の目標はもっと上流に存在するはずです。
2.2.分割返済
次に考えるのは分割返済です。
例えばコードの一部を切り出して、そこだけぶっ壊して作り変えるという方法があります。これはよく見ますね。
私もしょっちゅうこれをやっています。
分割しやすさが問題になってきます。
2.3.それ以外の方法
たぶん、それ以外はまともに戦う方法になります。
ようやく本題です😂
3.「技術的負債≒困る度≒複雑さ」の主敵はなにか
これも一言で言うのは非常に難しいですが、乱暴に「状態数」と「依存関係」と言ってしまいたいです。
実はこれでQiitaに投稿しようと思ったんですが、テーマが重すぎて止まってます・・・
3.1.状態数が増えると複雑になり負債が貯まる
状態数が増えると複雑度が増して、負債がたまります。
簡単に言えば条件分岐が増えると考えてもらえばいいです。
状態数が爆発する要因は、属性が多いからです。
例えば「性別」でわけるなら2通りですが、これを「年齢」で5通りに分けたら状態数は2*5=10です。さらに住んでいる都道府県で分けたら2*5*47=470通りです。
このように属性を増やしすぎると簡単にテストできないほどの状態数になります。
こういうの、次元の呪いとか、組み合わせ爆発とか言ったりしますね。
問題なのは、例えば「性別によって◯◯を変更する」みたいな仕様追加されたた時、元の状態数が10通りなら20通りになるだけですが、1000通りなら2000通りになるということです。プラスN通りで増やしていると思っていたら、いつの間にか状態数が爆発していることがあります。
3.2.例外で更に厄介になる
もちろん、すべての状態が例外なくルールベースでプログラムされていれば軽症で済むのですが、例外を入れるとかなり厄介になります。
下の図で、左は2属性によって3x4=12状態に分割されたものとイメージしてください。
これはif else 文を2階層で書くことができます。
それに例外を2つ入れたのが右の図です。if elseの一部のブロックにもう一つ別の条件分岐が存在します。
こうなると、まず適切なテストのパターンを洗い出すのが難しくなってきます。今はまだ2状態ですが、右図は既に複雑の片鱗が見えています。これを3属性、4属性にしていったらどうなるか想像してみてください。
3.3.例外はどのように発生しがちか
- 特殊仕様「この時に限ってこれをこうする」
- ゴリ押し対応「この時だけバグるのでここだけ対応する」
これらはジェンガコードの温床です。
3.4.状態数が爆発したらどうなるか
- 見通しが悪くなる
- テストの漏れが多くなる
- バグの条件を切り出すのが難しくなる
- うっかり意図しない状態をいじってしまう
そしてジェンガコードが出来上がります。
3.5.状態数は仕様や要件に依存する
困ったことに、コードをどれだけ弄っても、状態数は結局仕様の複雑さに依存してしまうため、コードの中だけでは完結しません。
仕様の調整も必要です。
3.6.状態数が爆発させる火種
慎重に状態数を抑えようとしても、どうしても状態数を増やしてしまうものがあります。
時間・タイミング
例えば「ある時刻から1秒前か1秒後かで挙動が変わる」という仕様が、自分のコードではなくプラットフォーム状に組み込まれてしまったりします。
また、画面を遷移する直前、画面を遷移した直後のようなタイミングも似た要因です。
これによって勝手に状態数は爆発させられます。
割り込み処理・ユーザー
時間にも似ていますが、これらも同様です。
例えば「ユーザーが〜〜という処理をしたら」というのは際限がなかったりしますし、「端末のバッテリーが切れたら」「ネットワークが切れたら」のようなケースもあります。
外部のAPIやSDK
こういった自分のコード外に引きづられるケースもあります。
これらは組み込まないように注意するだけではなく、積極的に回避したり、どうにか工夫しなければなりません。
また、応用ですが、自分のコードの状態数が多いほどこういった外部要因の状態数爆発で更にひどいことになります。
3.7.依存関係も複雑さの原因の一つ
これもきちんと説明すると本一冊になりそうなのでざっくりと（誰か研究とかしてないんですかね？）
依存関係にはいろんな形があります。一番わかり易いのはcallerとcalleeの関係。他にもcall backの関係。継承の関係などがあります。
上図はcaller calleeの話ですが、上図のようなものはシンプルです。
下図のようなものは悪いです。何となく察しが付くと思いますが、観点としては「それを変更した時の影響範囲が広い」あるいは「未知数」という点です。
個人的に理想なのは下図のような状態だと思います。
ちょっと分かりづらいですが、要はブログと同じです。
タイトルがあり、章立てされていて、それが構造的である。内部で勝手に情報のやり取りはしない。こうするとコードを見たとおりの影響範囲で落ち着くようになりますし、可読性が上がります。
caller,callee以外の関係はまた少し難しいのですが、安易な自作クラスの継承はやめようとか、安易な共通処理はやめようとか、そういうことが言われていたりします。
依存関係を複雑にしがちなものに神クラス、神オブジェクトというものがあったりします。
簡単に言えば、何でもかんでも詰め込んだ数千行を超えるモノリスです。
3.8.依存関係はコードである程度対応可能
こちらはどのように現実の振る舞いをきれいにコードに落とし込むかという話なので、頑張ればコードできれいにできます。
ただちょっと難しいのと、現実がそもそも複雑というケースもあるので、何ともならないケースもあります。
4.技術的負債に立ち向かう
ここまでは「技術的負債って何？」をおおよそ適当に書きました。
ここからは現実的に技術的負債を解消する方法について考えます。
4.1.負債を解消できる人材が必要
当たり前ですが、大量に時間をかければ何とか出来る人材が居ないと詰んでます。
（つまりファイアリングも話の俎上に上がってくるんですよね）
4.2.負債解消には時間がかかる
「仕様を満たす」だけでは負債は溜まったままです。
負債解消には「仕様を満たす」以上に時間がかかります。
プロダクトの実際の振る舞いというのは、コードのほんの一部でしかなく、コードの品質が悪いと少し変更しただけでバグがいっぱい出てくるという状態になります（潜在バグ）。目には見えないタンスの裏をどれだけ掃除するか、みたいな話です。表層だけきれいにしていると身動きが取れなくなってきます。
つまり時間がなければ解消は難しいです。
負債をそのままにするといずれ開発スピードが遅くなって心停止するので、これはトレードオフとなります。
技術的負債を解消する時間 vs 開発スピードが遅くなるリスク＋バグが生まれるリスク
を何とか見積もり、ジャッジしなければなりません。
タイミングや方法が重要になってきます。
4.3.負債解消には個人差があり難しい
しかし実際、「技術的負債を解消しましょう」「でもなるはやでね！」とか言われても困るわけです。
「仕様を満たす」以上の、どの程度コードをきれいにするかは、非常に個人差があります。
そんなの無視して納品したほうが、非エンジニアからは「仕事が速いやつ」と見られて印象が良いです。だからこれはその人の主義とか思想依存なわけです。
プルリクエストやコードレビューで対応する事も考えられますが、個人的にはそれほど効果があるように思えません。
何故かと言うと、技術的負債を仕込みやすいのは設計レベルだからです。プルリクで「設計やり直し」と言うのは、言う方も言われる方もきついのではないでしょうか？
4.4.リファクタリング駆動開発で時間をとる（提案）
これは一つの提案 ですが、テスト駆動開発のような方法を取ると良いのかと思います。
- 仕様を満たすコードを書く
- ある程度のテスト
- リファクタリングをする
- きちんとしたテスト
リファクタリングの時間を設け、忙しいときにはその時間を減らし、余裕があるときにはその時間を増やす。そのような調整弁として存在していればよいのかと思います。
4.5.マージ後コードレビュー（提案）
すいません、名前忘れましたが、マージ前のコードレビューではなく、マージ後にコードレビューをしている人の話をどこかで見ました。
このメリットは
- 修正がきつい設計レベルの指摘を言ってもどうせ今は修正できないから言いやすい（心理的安全性）
- 実際に修正しないので、宗教論争になりにくい（答え先送り）
- 修正できないので、次からそう書こうと心に刻める
もちろん、「これは修正が必要だろう」というものは新たにチケットを切れば良いわけです。
4.6.技術的負債の要件を洗い出す（提案）
ここまで「負債」だの「複雑」だの「依存が」だの、ふわふわしたことを書いてきましたが、そんな抽象的なものでは実際にリファクタリングができません。
技術的負債を解消しているつもりだけど、本当に解消できているか不明というプロジェクトは非常に多いと思います。 計測が非常に難しいのでそうなってしまいます。
でもせめて、「このプロジェクトにとって技術的負債とは何か」みたいなものは洗い出せるはずです。観点リストですね。
例を書いてみます。
コードのトレーサビリティは良いか
ex：GOTOの排除、暗黙的入出力の排除
バグの箇所をすぐ検知できるか
影響範囲がすぐにわかるか
誤解の生まない表現であるか
記述する場所は適切か
名前は適切か
仕様が読み取れるか
単一責任になっているか
可読性はよいか
平易な書き方であるか（※チーム依存）
構造が複雑すぎではないか
理解するのに時間が掛かりすぎないか
混乱しないか
神クラス、神メソッドではないか
呼び出されすぎではないか
呼び出しすぎではないか
依存が複雑ではないか
機能毎に削除しやすいか
疎結合であるか
ベースとなるコードの抽象度が適切か
仕様追加で変更が生じないか
ベースとなるコードの具体度が高いか
一意に決まるか
仕様変更になった場合、困らないか
具体的すぎないか
削除できるか
密結合すぎないか
技術がバージョンアップしたときに困らないか
コメントは必要量存在しているか
不要なコードが放置されていないか
コードについて誰が知っているかが自明か
など
これの上流に位置する目標をもう一度貼っておきます。
4.7.素晴らしく難しいコード
あまり技術的負債とみなされていないものに、素晴らしく難しいコードがあると思います。例えば歴15年のエンジニアAと、歴2年のエンジニアBのコミットしているソースがあるとします。エンジニアAは熟れているので、一般的に最適かつちょっと難しい書き方、設計でプログラムを書きますが、エンジニアBは未熟なのでその書き方を知りません。毎回調べて苦労しながら改修していきます。
この時どうするべきでしょうか？
- エンジニアBはもっと勉強するべき
- エンジニアAはもっと平易な表現を用いるべき
これはプロジェクトの状況次第ですし、そのコード次第です。
ですが世の中の風潮は非常に１寄りです。
しかし、もう一度これまでの話を振り返ってみます↓
難しいコードによって、開発スピードが落ち、バグが生まれやすくなっています。
なのでその難しいコードは技術的負債です。
4.8.若手レビュー（提案）
つまり、技術的負債はチーム構成によってガラッと変わります。
これ理解できるでしょうか？
例えば、英語と日本語ができるAさんと、日本語しかできないBさんがいるとします。仕様書は当然日本語で書きますよね？
でも上の１の主張は「Bさんは英語を勉強するべき」という主張です。ちょっと意味がわかりません。
これは若手レビューでキャッチアップできると思います。
コードを見て「これは難しい」をジャッジしてもらうだけです。
アクションとしては３つ
- 確かに難しすぎる、あまり使わないようにしよう
- これは流石に覚えるべきだ（教える）
- 知らなくても大丈夫
どの結論を取っても、技術的負債は解消されます。
4.9.外部知識・暗黙知を避ける（提案）
これもあまり理解されないですが。
頭の中に、あるいは別のドキュメントに依存関係が書かれている場合、その人が知らないと対処不可能なので、思いもよらぬ挙動になったりします。
思いもよらぬ挙動にならなくても、潜在バグとして負債が残ります。
何かしらヒントがあれば良いのですが、世の中の数多の言語は、ノーヒントで書けるようにいろんな機能が用意されています。そしてそれは素晴らしいものだと言われているので、積極的に活用されてしまいます。
これらはgoto文の系譜です。
もちろんそういう機能が完全にNGというわけではありません。改修者が知らなくても大丈夫なものに使用するとか、ヒントを与えられたら良いわけです。ですがそれ以外の方法で使うとトレーサビリティが落ちます。
外部知識のもう一つ大きなものがデザインパターンです。
そのデザインパターンに精通しているメンバーだけなら良いと思いますが、それ以外の人が入るとそれは技術的負債です。技術的負債を解消するつもりで、技術的負債になっています。でも本人は解消しているつもりです。
結局状況次第なのです。
4.10.トレーサビリティと開発環境依存
例えばXcodeはメソッドを呼び出している箇所が追跡できます。
Xcodeを使っていないメンバーが居ると話が変わるわけです。
また、追跡できない書き方もあります。この書き方を用いられると、例えば10箇所の呼び出し部分のうち、2箇所だけトレースできないみたいなことになります。そしてバグを仕込んでしまいます。そうでなくても、調査に時間がかかってしまいます。
ありがちなのが、「このメソッドもう使ってないと思うけど、ひょっとしたら使ってるかもしれないから消せない」というものです。こういうのが増えるとどんどん重くなっていきます。
4.11.トレーサビリティと新規メンバー
もちろん新規メンバーほどトレーサビリティがありません。
プロジェクトの構造を把握できていないからです。大きいものだと把握するのに数ヶ月以上かかったりします。なので、もはや新規メンバーは技術的負債の温床と言っても過言ではないと思います。
人の入れ替わりが激しいプロジェクトは・・・恐ろしいですね。
人月の神話に繋がる話です。
5.更に闘う者たち
技術的負債は、仕様・人材・体制、その他諸々に影響を受けます。
つまりより頑張るためにはエンジニアチームの外をどうにかする必要があります。
5.1.エンジニアのコントロール
これわかりません。
要件としては、その人が技術的負債を解消できる人かどうかジャッジすることです。
わかりません・・・
監視するしか無いですかね？
監視したとして、ダメだったらどうすればいいんでしょうか。
5.2.体制のコントロール
できれば少人数でやりましょうとしか言えません。
これも難しいですね。
5.3.仕様のコントロール
仕様をシンプルに保つことが重要なので、仕様決定にはエンジニア（アーキ、リーダー）が参加しなければなりません。
仕様を決めるのは事業の都合なので、事業を理解していなければなりません。
事業の都合は業界やユーザー都合なので、業界やユーザーを理解しなければなりません。
よりコードがきれいになるように、代替案を出せなければなりません。
究極、プロダクトがシンプルなら、コードがカオスになることはありません。
最悪作り直せば良いわけです。
5.4.上長の理解
わかりません。
ここらへんは結構ググると出てきますが、「社長がエンジニアリングに理解がある人だった」以外の答えを見たことがない気がします。
あとは信頼関係ですかね・・・？
個人的には代替案でごり押したいですが
5.5.権限が必要
この話忘れてました。
技術的負債を解消するには権限がある程度必要です。
読めばわかると思いますが、どうしても作業フローの改善手続きが入ってしまうので、上司やチームリーダーやCTOなど、そういう人じゃないといけません。
もちろん権限がなくても練習はできますが。
5.6.議論より説得、質問
議論（ディスカッション）、つまり複数人で何かを決定するというのは、非常にコストが高く難しい作業です。
これを避けるには説得や質問の方が良いです。
開発でよくやりがちな過ちとして、抽象度の高い議論をしてしまうことです。
例えば「このプロジェクトにMVVMは適しているか」「ユーザー体験を向上させるにはどうすればいいか」「このコードは複雑だ」のような。
観点がありすぎて答えが出ないので、大体宗教論争でおわります。
「猫と犬どちらが素晴らしいか」みたいな話です。
より具体的な細かい話を、選択肢を出しつつ話すのがいいでしょう。
5.7.とは言え宗教論争は尽きない
宗教論争の一つの原因が、状況を絞れていないからです。
コードレビューなどの時に具体的に「ここに対して何が最適か」をリファクタリング要件と突き合わせて考えれば少しは話しが進むのではないでしょうか。
まあでも最後は多様性を受け入れろ、ってことになりそうですが。
6.おわりに
何か半分も書けていない気がしますが疲れたのでここまで。
忘れた気がする話
デザイン
やぐに
結合度、凝集度
改善をどのように指標化するか
時間がない時どうするかの話
どう勉強するか
他人を理解する（何を大事にしているか、何が負債と感じているか、何に興味があるか）
クソコード討論会
そのうちアップデートします
人生の軸足をどこに置くかという悩み
（最近愚痴が多い）
その人の軸足
ある人を理解しようとする時、その人の軸足がどこに置かれているかを考えると、非常に理解が進みます。
例えば会社Aの人と、会社Bの人が交渉する時、それぞれはそれぞれの会社の立場から物事を考えるでしょう。
軸足、ホーム、拠点、所属、呼び方は何でも良いんですが、これを意識するだけで、今まで理解できなかった価値観が理解できたりします。
「相手の立場を慮る」みたいな感じですかね。
最初にこれに気づいたのは10年くらい前だったと思います。
若手社員の主張と、ベテラン社員の主張のズレが気になったのですが、それはベテラン社員が会社より家族に軸足を置いていたからです。
家族の代表として社会に出てきているので、彼の言い分は彼一人の都合だけではないのです。
その所属する人の規模や、大切さや、責任によって、個人は時として個人の振る舞いができなくなります。
大企業の代表は、どれだけ相手にブチギレるような事を言われても、感情的に動いてはいけなくなります。影響は自分だけではなく会社全体、ひいては社員の家族にまで及ぶからです。
大勢が集まる会議などで議論がまとまらない時、この軸足が多様だからまとまらないということがあります。「皆自分の都合しか考えてない」などと言うのは簡単ですが、譲歩に対する影響はその背後の大勢に影響してしまいます。
最近、軸足がない
とかいう真面目な話は置いといて。
最近自分に軸足がないなーと悩んでいます。
独身フリーランスだと結構あるあるなんですかね？
フリーランスだと、どうにも会社に軸足を置くのが難しいです。いや、ぶっちゃけ言えば社員もフリーランスも大差ないです。私が正社員だった頃だって、果たして会社に軸足が置かれていたかと言うのは疑問です。
こういうのは家族を持つのが手っ取り早いのですが（以下割愛）
こういうのはコミュニティだけではなく、主義や主張に軸足を置くという手もあります。技術や思想、趣味、拝金だったり快楽だったり、育成だったり研究や学問だったり、何でも置けそうな軸足というのは存在すると思います。
要は行動となる基準があれば良いわけです。
そういうのをひっくるめて、どうにも軸足が見つからないです。
この感覚が出始めたのは、複業を始めてからです。
おそらく自宅で複数の仕事をやっている人達はより強い「軸足の無さ」を感じるのではないでしょうか。
理想を言えば、自作サービス、自作プロダクトに軸足を置きたいのですが（以下省略）
軸足がないことで生じる悪影響は、とにかく迷うことだと思います。そして常に付きまとう不安感。今の状態がしっくりこないけど、別の状態がしっくり来るかと言えばそうでもない。
ああ、そんな絵本が確か有りましたね。
そうそうこれ。
私はこれまで軸足の不足＝ピッタリ来るモノというのは分析と演算によって大体分かるはずで、分からないのはどちらかが足りないと思っていたのですが。
今は何の考察が足りないのか、それとも単に疲れているのか？
なんだか自分探しの旅をする若者みたいになってる・・・
（日記）会社立てます
最近、ブログやQiitaのネタを思いつくんですが、明らかに3時間は掛かるようなネタばっかりで書く気力と時間がどうにも追いつきません。
法人成りします
会社を立てますが、ほとんど税金対策です。
会社を立てるといっても、起業、開業、法人成り、と微妙にニュアンスの違う言葉がありますが、今回の場合は法人成りです。
去年売上が1000万円超えてしまったので、しょうがないですね。
本当は年末に立てようと思っていたんですが、税理士に相談したところ「一刻も早く立てたほうが良い」と爆笑されました。まあそうなんですよねー。消費税の件もありますが、給与所得控除がでかすぎる。
https://www.nta.go.jp/m/taxanswer/1410.htm
あと法人税は22％なので、今払ってる32％に比べたら10％お安くなってしまう・・・
ところで個人企業になったらフリーランスじゃないんですかね？？？
法人成りすると、ちょっと焦る
何かちゃんとやらなきゃ感が今まで以上に湧いてきますが、慌てても何も変わらないので落ち着こうと思います。
融資も1000万くらい可能なんですが、金有りきで動いても死ぬのが目に見えてますしね。今までと大差ありません。
業界、業種によって、事業化のリスク・リターンが変わりますが、ITサービスは明らかにハイリスク・ハイリターンですよね。受託はミドルリスクミドルリターンなんですが、競合も多いのでとにかく大変なイメージがあります。
資本金というのがよくわかってない
勉強します
（する時間あるのか？）
近況：まだ仕事探してます
findyという新興人材サービスから声がかかりました。
高単価限定らしいので今エージェントしてもらっています。どうなるかわかりませんが。
（ここであってる？複数サービスがあるらしいです）
今年1400万円は行きたい・・・どうだろう
ITフリーランスの、売上と収入について
そう言えばこんなの書きました。
ITフリーランスの実態と、勘違い？（私の認識）
https://anond.hatelabo.jp/20190313031524
何か単価に対する考え方が観測範囲とはてなでめちゃくちゃ開きがあって意味がわかりません。誰か教えてください。
引っ越し
6月に2年更新が来るので引っ越したいのですが、やっぱり渋谷〜新宿界隈は鬼のように高いですね。
より良い物件を探してスクレイピングはじめました。
参考
https://qiita.com/bottusan1073/items/2093b76ff7734d733879
簡単でした。ありがとうございます。
しかし高い。
最近喋っていない
業務効率化って味気ないですよね
最近なんだかそういう境地に・・・
いっそYoutuberになりたい（それでも独り言ってのは変わらない件）
アイコン替えたい
仕事用でも使えそうなアイコンにしたいんですが
しっくり来るアイコンがないですね
フリーナンスの仕組み、やっと理解した
FREENANCEというGMOのサービスがあります。
このエントリを見てる時点で説明不要だと思いますが、支払いの「即日払い」と「保証」を実現するサービスです。
どうやら流行りらしく、銀行など色んな所が似たようなサービスを打ち出しています。
平たく言えばキャッシングですね。
仕組みがよくわからなかった
それにしてもこれ、請求書を買い取る形になるんですが、間に入るのかなどよく分からなくないですか？ 登録して実際に見てみました。
請求書の振込先に、FREENANCEの専用口座を指定する
これを見て合点がいきました。
つまり「返済」が会社からFREENANCEの口座に入金される仕組みですね。なるほどと思いました。これなら先方に知られる必要もありません。
でもこれ、まず請求書を作成する時点で専用口座を指定しないと詰むっぽいですね。
あれ、でも手数料はどう払うんですかね？
ちなみにお得かどうか
手数料が3％〜10％なので、キャッシングとしてみればまったく得ではありません。
ただし保証・取りっぱぐれを防ぐという意味で言えば良いかもしれません。
でも3％〜10％だから、33回〜10回に1回取りっぱぐれが発生しないとやはりお得にはならないですかね？3％ならありかなと思いますが、3％になるには何度も取引しないといけないみたいです。
まあ何かあった時の転ばぬ先の杖程度に考えておいて良いかもしれません。
追記：訂正 取りっぱぐれについては保証していない
よく読んだら保証していないですね
🤔
