技術的負債の定義は色々あるが、大きく分けると、改修時に問題となるモノと、時間経過と共に問題となるモノの2パターン存在する。前者(改修時に問題となるモノ)は開発効率は落ちるが、必ずしも返済の必要は無いモノ。返済した箇所が今後の改修で、どれだけ使われるか読みきれないから。上手く付き合わないと不具合発生率が高くなる。リファクタリング(動作を変えずに作りやすくする事)は諸刃の剣で、自動テストのケース漏れか仕様理解が足りないと不具合を作るだけで、疲労感しか生まない。後者(時間経過と共に問題となるモノ)は必ず返済しなければならないモノ。今まさに問題となっている、または今後、問題が表面化しそうだと気付いたから。原因は異常系や負荷等の考慮不足の場合が多い。一概にエンジニアの問題とは言えない。経験不足や疲労で考慮できない事もあるが、スピードを優先して意図的にやらない事も多い。システムには必ず制限事項が存在する。実際、AWSや他のサービスにも存在していて、無限にスケール出来る訳ではない。人間は見たくないモノや理解出来ないモノは、無意識に見えなくなる。この行為と技術的負債の掛け合わせが、(勝手に命名しましたが)思考的負債だと感じている。スピート優先で作った人も、その不足を補う動きをした人も、制限事項を理解した上で、平等に称賛されるべきで、そうしないと、補う動きをする人は少なくなり、負債がどんどん大きくなって。(後は想像にお任せします)他も同じだと思うが、目立つモノに目を奪われてはダメなんだろうなというお話でした。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。定期タスクの管理・リマインダー(Slack・メールに対応)タスクをカレンダーや一覧で管理し、チームで共有できます。リマインドで、忘れやすい年次・月次タスクの実施忘れや、メンバー間の譲り合いによる実施漏れを防ぐ事ができます。公開リポジトリ・動作確認サイトnuxt-app-originhttps://nuxtapp.nightonly.com/rails-app-originhttps://railsapp.nightonly.com/自己紹介フリーランスから法人成りして、業務委託で上場企業の会計ソフトの開発(スクラム)と、副業で上場企業の社内システム(取引先等の管理やSalesforce連携等で業務改善)の開発や改善・提案、フォロー等を行なっています。両社ともフルリモートです。ECやモール連携、決済、動画のストリーミング配信、YouTubeのデータ分析等の経験もあります。AWSを主に使っています。日々、技術の積み上げを意識して、価値提供を目指しています。Flowを使っている案件に携わってみて、疑問を感じたので、どっちが(もしくは別の方法)が良いかを改めて考えてみました。RailsRuboCopにRSpecのルールを導入してみたRuboCopにRSpecのルールが提供されているので導入してみました。RSpecのルールはデフォルトだと厳し過ぎるのと、あえて従いたくないルールもあるので設定変更しました。半自動でマネ活・ポイ活:SBI新生銀行+住信SBIネット銀行、auじぶん銀行+PayPayチリも積もれば山となる。APIかRedux等を使って値を保持しようしたら、毎回初期化されたので原因を調べました。法人口座開設:初期・月額無料で、振込手数料も抑えたい(振込先の個人口座も)昔は簡単に作れたと思いますが、マネーロンダリング対策で審査が厳しくなっているようです。当然ながら、審査にも時間が掛かるようです。タスクをカレンダーや一覧で管理し、チームで共有できます。リマインドで、忘れやすい年次・月次タスクの実施忘れや、メンバー間の譲り合いによる実施漏れを防ぐ事ができます。