「下手だなあカイジくん…!技術的負債の返済の仕方が下手…!」 ちゃんとシステムを構築しないと後で多く利子を払うことになる

「あなたの技術的負債はどこから?」 「私は前任者から _(:3 」∠ )_」
207
米村歩@日本一残業の少ないIT企業社長 @yonemura2006

「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。

2020-06-24 07:49:11
Yuta Kashino @yutakashino

(´-`).。oO( スタートアップ創業者コーディング問題というのがありまして….非エンジニアの創業者が最初エンジニアを雇えないため自分でコーディングした部分が最後まで技術的負債となりリスクを生むけれど,創業者自身はコーディングできることを最後まで外に吹聴しまくるという… )

2017-08-27 16:05:45
えむばーど @m_bird

技術的負債のことをなんと呼ぶか?という話で、すぐに「そびえ立つ糞」って声に出してしまうのでもっと上品な表現を……と模索した結果、 「弊社の動く糞」 という言葉がひりだされました。同僚にはゴミを見るような目で見られました。

2017-06-02 07:57:49
てるるー @terurou

「あなたの技術的負債はどこから?」「私は前任者から」

2020-06-25 19:50:02
yukito ohira@システム開発おじさん @yohira_dev

下手だなあカイジくん…!技術的負債の返済の仕方が下手…!カイジくんが本当に欲しいのは、1からの作り直し…!だけどそれはあまりに時間がかかるから、こっちのしょぼいリファクタリングでごまかそうっていうんだ…!

2017-05-16 21:59:06
henrich @henrich

技術的負債ではなく、「連帯保証人」にされるのが辛いのでは

2019-12-23 09:48:38
henrich @henrich

技術的負債(Technical Debt)、最初の人は借金してることすら気づいてなくて利子が複利で来てるのを、後からきた人が保証人にされて返済させられるのが多いのでネガティブワードになったのでは

2020-06-25 10:07:09
wataru kubota @wkubota

技術的負債あるある。 技術的負債を残す人(残す判断をする人)と技術的負債を返済しなくちゃならなくなる人はたいてい別。

2017-08-30 09:08:31
リンク GIGAZINE 「技術的負債とはどういうものなのか?」をテトリスに例えるとこうなる テトリスは落ちてくるテトリミノを積み上げ、横一列に並べて消すという有名なゲームですが、そのテトリスを例に「技術的負債」がどういうものかたとえた記事を、エンジニアでありコンサルタントでもあるというエリック・ヒギンズ氏が公開しています。 280 users 1182
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

技術的負債の話が非エンジニアに通じにくかったら、使っていいよ。 どうやって解消していくかは、本を読んでみてくださいね。 #技術的負債 #randomに使っていいよ #エンジニアリング組織論への招待 pic.twitter.com/BQEzSmXdW9

2018-06-12 11:57:23
拡大
米村歩@日本一残業の少ないIT企業社長 @yonemura2006

一度技術的負債を抱えてしまうと、それを返済するためにも工数(お金)が発生します。その返済額の大きさによっては元金は返済せずに今後も利息を払い続けるという選択をする時もあります(ちなみにエンジニアはこれが嫌い)。どちらにしても余計にお金が出ていくので技術的負債は良いことありません。

2020-06-24 07:49:12
米村歩@日本一残業の少ないIT企業社長 @yonemura2006

エンジニアは技術的負債を嫌いますが、これを作り出すのはエンジニアです。無茶な納期や金額でシステム作れと言われたら、技術的負債という借金を借りてきてシステムを作るしかなくなります。その莫大な借金の利息を払い続けるのは顧客です。目に見えないけど無茶な要求は自らの首を締めます。

2020-06-24 07:49:12
米村歩@日本一残業の少ないIT企業社長 @yonemura2006

普通に作られてたら10万円の費用で済む簡単な改修を、技術的負債を抱えてしまっているせいで100万円かかってしまうということもあります。しかも技術的負債を返済しない限り、そのシステムの運用を続けてる間そんな非効率がその後もずっと続くのです。初期構築費用だけで判断してはいけない理由です。

2020-06-24 07:49:13
リンク t-wadaのブログ 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ システム開発の世界において「技術的負債(Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward C 1077 users 176
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

部屋を片付ける権利が家主になくて、いろんな荷物が順番に送られてくる。ゴミも出せないし。 部屋が汚くなっていくので掃除をさせてというと、費用対効果は?と聞かれるから困ってなかなか足の踏み場がなくなって二進も三進もいがなくなるまで放置される。 要はこれが技術的負債です。

2018-12-13 11:14:26
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

だから、なんでこんなもんが問題になるかというと、 1、家主に片付ける権利がないことと、 2、荷物を送りつける人が部屋を観に来ないこと 普通のことなんですけど、システムだからわからないと思う人がいるだけ。 なので情報の非対称性からくる問題なのですよ。という。

2018-12-13 11:32:22
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

僕が「技術的負債」という言葉を使うとき、その正体は「ソフトウェアの複雑化による開発出力の低下」そのものでなく、その認識を意思決定者と共有しづらいという視界の非対称性にこそあると考えていて、対策はその観点から行われるとうまくいくことが多い。 pic.twitter.com/iSyROQqiH5

2018-09-25 09:04:12
拡大
まろ@関数型言語作曲機械学習勉強してない @_marony

技術的負債の話の時に、たいていはむちゃくちゃな設計や改修につぐ改修での混乱が例に出されるんだけど、「優れた人が周りに周知せず導入した言語やツール」もかなり大きな負債だというのは声を大にして言いたい

2017-03-25 10:51:16
ミノ駆動 @MinoDriven

技術的負債は知覚が困難なのが問題。 知覚できる人は、 ①「く、苦しい…この苦しさの原因は一体なんなんだ?」と自律的に原因に立ち向かった経験のある人 ②あるべき設計を学んだ人 ぐらい。 それは天と地ほどの差で、知覚できない人からは「これの何が問題なわけ?」と目をパチクリされるのだ。

2020-06-21 17:48:38
神速 @sinsoku_listy

一般的なエンジニアは既存コードを参考にコードを量産する。その結果、技術的負債はメンバー数の複利で増えるし、既存コードを良いコードに書き直す(負債を返済する)エンジニアは評価されづらい。

2019-06-28 12:12:25
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

ベンチャー、うまくいってる時は成長が全てを癒してくれて、小さな個人的対立も意識することなく楽しい。徐々に成長がサチるころに、新しく入った人に先にいた人が防御、回避、攻撃的反応をするようになり摩擦が起きる。時を同じくして技術的負債が問題となり、「つまらなくなった」と初期メンが辞める

2018-03-27 09:22:07
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

先にいた人は、人数が少ない時は理想のホラクラシー組織だと楽しんでいて、マネージメントを放棄。その結果産んだ組織のせいで苦しみ、辞める。因果は見えにくいけど、面白く無くなったのではなく、面白くなくしたと考えた方がいい。

2018-03-27 09:24:58
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

じゃあどうしたらいいの? 「エンジニアリング組織論への招待」を読んでください。お互い。

2018-03-27 09:29:23
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

この本は、私は何も知らない。それどころか何も知りえない。他人も未来もわからない。わかりえない。しかし、自分の行動はコントロールできる。そこから出発した内省の本です。何かを知るためでなく、何も知らないのだと知るための本です。そして、それがエンジニアリングの全て。

2018-03-27 09:42:24

コメント

saku @sakuuuuuuune 2020年9月20日
安い給料で雇ってきた駆け出しや、フルスタック(笑)が適当な設計と勢いで作ったコードは負債になる 1番の問題は、保守するエンジニアは効率が下がって苦しい思いをするが、開発を理解していない経営から見ると「すでに安定して動いてる」ために、「リスクを冒して、さらにコストをかける」ようにしか理解できないことだ
29
Dan Kogai @dankogai 2020年9月20日
負債でもないものを負債なんて呼んでるからダメなんだよお前ら。確かに単式簿記では負債と不良資産は見分けがつかないが、なんで現代の会計は複式簿記なのかわかっとる?
13
Wa @0000548C 2020年9月20日
そのジェンガの画像がまさに古い勤め先に蔓延した合理化のあるべき姿だった。ほぼ全員バカだからそもそもジェンガめいた構造が悪いと理解できない
8
柳瀬那智●11/1ベルサール神保町「おもしろ同人誌バザール」参加 @nachi_yanase 2020年9月20日
sakuuuuuuune 「今は若いし健康診断の数字も何にも問題ないのに、どうして今のうちから食生活に気をつけたり苦しいダイエットなんかしなきゃいけないの?」ってのと同じようなものなんですね。なるほど……。
39
白石玄人 @ShiraishiGento 2020年9月20日
>うまくいってる時は成長が全てを癒してくれて、小さな個人的対立も意識することなく楽しい。徐々に成長がサチるころに、新しく入った人に先にいた人が防御、回避、攻撃的反応をするようになり摩擦が起きる。  昭和から今に至る日本国の縮図のようだ…。
11
白石玄人 @ShiraishiGento 2020年9月20日
こういうもっともな或いはもっともらしいことをさんざん述べて、最終的に自著に誘導するやり方は(健康食品ドキュメントCM的なものを感じて)個人的に好きではないなぁ…。
44
むう @nyal1999 2020年9月20日
ジェンガはガタガタのテーブルの上ではやらんだろ
2
doipo @doipo 2020年9月20日
技術的負債の話で嫌だなぁーといつも思うのが、前任者がとか他のメンバーがとかいうのがすぐ出てくる所。リアルタイムに自分も負債を生み出し続けてることは棚に上げて攻撃しやすい所を叩くとこ
20
[30]Kirara@ありがサンキューツアーズ @Kirara1314 2020年9月20日
非常にわかりやすい技術的負債の例 ドコモ口座・7pay
6
K53YA (NE) @mabuenoe 2020年9月20日
つーても最初からシステムをきちんと端から端まで考えて組める人ってのもなかなか居ないのではなかろうか。どうしても継ぎ接ぎになってしまうと言うか、必要にならないと気付けない問題というのが存在する。そこまで予見&対策はできないまでも経験則から余裕あるスペースを確保するぐらいなら…俺ら凡人にも出来るかも。それすら何度も失敗しないとムリっす。
21
K53YA (NE) @mabuenoe 2020年9月20日
まあ失敗できない仕事は普通にあるね。重責と申しますか金融系で仕事してる人すごすぎ。
7
両棲装〇戦闘車太郎 @d2N5Q4GciZtsa2e 2020年9月20日
ああ、中央官庁の慣例もモノの見事に技術的負債だわ
0
白石玄人 @ShiraishiGento 2020年9月20日
保守とかサポートの仕事って、問題なし・平常時には「何もしてない」とか「楽してる」とか思われがちだし、緊急事態には「さっさと直せ」とか「お前が悪い」みたいに言われがちななかなか得をしない仕事だよなぁ、とは思う…。 まとめ内の「見ることができない」画像の左側(顧客、上役等)が右側に言いやすいってのがまた厳しいとこ。
10
Calucifer🌲💉💘🐕🍵 @Chigami 2020年9月20日
安物買いの銭失いということわざがありまして
3
海◆eoxyl9RE @umi_eoxyl9RE 2020年9月20日
医療系の法令が絡む会計ソフトの場合、システム作成当初は予想しえないような新法令が国や自治体から後から後からできて、それに対応しないとならない。結果予算が足りなくて新機能実装まで追いつかない
1
CAW=ZOO @CAWZOO 2020年9月20日
MOTER2を一から作り直したいわっちの事かな?w
0
BugbearR @BugbearR 2020年9月20日
当時は最新の技術でもプラットフォームと同時に陳腐化して死ぬ、なんてのが常態なのだから、最初からうまく作れば技術的負債がなくなるみたいなのは幻想。もう POSIX で作るしかない!(白目)
13
yuki🌾㊗️5さい🎉⚔ @yuki_obana 2020年9月20日
そもそも負のれんですら理解できる経営者は少ない(´・ω・`)
0
ktgw1014 @ktgw_1014 2020年9月20日
大企業の一大プロジェクトならともかく、スタートアップがやるプロジェクトで技術的負債の予見まで済ませてるところ無いだろ。「最初からやっとけ」なんて無理だ無理。そんな理想の通りに固めた成長企業が日本のどこにあるんだどこに。理想の通りに行かなかったから本文の人たちもこの考えに至ったんだろ。
9
鹿 @a_hind 2020年9月20日
これ負債抱えるのは発注側・受注側ともになんだよねえ。 作った側も納期に間に合わせるためだけに手順省略して適当にやったりすると後々保守効かなくなるから。 作った人がいつまでも在籍して面倒見続けてくれるならいいけど作った本人も忘れるしね。 終わった筈の案件に延々手入れ続けても金は入らないから会社的にも旨くない。
0
anineko @ANINEKObySYSTER 2020年9月20日
COBOLを負債扱いするが、当時の環境ではすごく適合してて良かったんだよ。ソースコード長いって、そりゃドキュメントを内包して一体化してるんだから長いに決まってる。今の言語でもドキュメントまで入れれば量は同じようなもんだろ。 コンパイル後の実行コードは短いから当時のメモリの少ないコンピュータにはありがたかったんだよ。
2
カズマサみんC @mskazumin 2020年9月20日
なんだか理想論が過ぎるように感じてしまう。ガンダムでいう全人類がNTならこんなこと起きないはず!みたいな。
4
anineko @ANINEKObySYSTER 2020年9月20日
いやつい。うちには初期の大型コンピュータのメインメモリユニット、「磁気コアメモリ」のジャンクがあるんだが、記憶容量は基板一枚で256bitだ。256bitだぞ?よくこれで動くプログラム作ってたもんだと、当時の人々の技量と努力に驚くしかない。
0
gaheki @gaheki 2020年9月20日
客側も最初から完璧な要件伝えきれないのも大きいな でもそのくらい最初から言えよ!ってレベルの事もあるけど
0
まさかず @mskz_iwmr 2020年9月20日
現在のトレンドではないとか、単に自分の趣味じゃない物までそう呼んでるケースもあるような気がするけど。 それに、設計・構築当時はそれが最善の策だったという事もあると思うので、ちょっとモヤっとするな。
3
anineko @ANINEKObySYSTER 2020年9月20日
磁気コアメモリはドーナツ型のフェライトコア一つを1bitのメモリとして磁気化の方向で1/0を記憶する。これが256個+パリティビット分のフェライトコアが並んでるのが肉眼で見える。コアを一つ一つ手作業で並べて配線通して配線で固定されて宙に浮いてる。bitが物理で目に見えてる。こんなのGbitの量で用意しろとか無理だろ。コスト的にも場所・体積的にも根性的にも。
0
anineko @ANINEKObySYSTER 2020年9月20日
こんな環境下でもなんとか目的を果たせるコード書いてたんだから悪く言われるのは心外だ。とっととアップデートしたらいい。作り直せばいい。無理に維持しろなんていっとらんわ。
1
犬だよ @yaju5123 2020年9月20日
BugbearR  マジでこれ セキュリティ系で言うとゼロデイ攻撃を事前に予知した防げと言ってるようなモン それが出来るのは狂人かエスパーだけや
1
anineko @ANINEKObySYSTER 2020年9月20日
フェライトコアの直径は約1.5mm、厚さは約0.4mmと見た。配線バラしたくないからノギスで測るとか出来ないんで目測だけどね。これを斜めに傾けて、3本の銅線を通してある。x軸とy軸のアドレス線と256個すべてのフェライトコアを数珠つなぎに貫通するデータ線(書き込み(磁気化)/読み出し線)だ。その見事な細工と配線はもはや工芸品だよ。
0
anineko @ANINEKObySYSTER 2020年9月20日
gaheki 昔はコンピュータの事を知らない人の方が多かったからな。コンピュータに必要な要件、最適化した要件なんて説明できないのが当たり前で、そこはコンピュータ技術者がヒアリングして「相手の仕事」を理解するしかなかった。明確化して明文化してコンセプト化して設計してコード化する。これ全部コンピュータ技術者側のお仕事だった。あ、ドキュメント書いてまとめるのも忘れるなよ? 使う人もコンピュータ知らないんだから導入トレーニングもしてやらないと動かないぞ?・・・という時代でした。
0
anineko @ANINEKObySYSTER 2020年9月20日
まあ、昔はそこまでやってたから、そういう仕事ぶりを当たり前として今時の人材コンサルタントに説明すると、「あんた(IT系)コンサルタントだ」と言われる。いやでもこれが出来なきゃ動くシステムが出来ない無いし、そして稼働もさせられなかったんだよ? これで普通の仕事ぶりだったんだよ?
0
ma08s@フォロー外からごめんなさい @bygzam_ma08s 2020年9月20日
技術系の格言で、「難産の子は育つ」って奴かな?(ビミョーに違う気もする)
0
anineko @ANINEKObySYSTER 2020年9月20日
さらに工場なんかだと複数のコンピュータ(現場の機械制御用コンピュータ、生産計画管理やら実績情報から報告用帳票プリントするホスト役のコンピュータやらその他)をつなぐ時は通信プロトコルの設計からやってた。当時のプアなメモリと当時の速度のCPUに重たい標準プロトコルなんて乗せたら、通信してるだけでCPUが100%いっぱいいっぱいになっちまって、肝心の仕事の処理が全く動かない。
0
Yeme @yer_meme 2020年9月20日
技術的負債って別に言語が糞とかそう言うことではなく、行き当たりばったりだったり設計やソースが汚かったりドキュメント無かったりして後から直しづらい奴の事っスよね? それが積み重なってドンドン悪化して最終的に破綻するのを借金に喩えたのが最初だったと思うっス。
0
anineko @ANINEKObySYSTER 2020年9月20日
当時のメモリに収まって、処理が少なくて軽くて、それでいて安定した通信(必要なエラー対策は入ってる)を現実的な処理時間を行える最適化したプロトコルを設計して実装して。・・・まあそもそもイーサネットプロトコルもまだ無かったけどなw 無いもんは自作するしかない。今の人から見ればそりゃ「なんだこのへんてこプロトコル」だが、メモリも無い処理速度も無い、余裕も無い出来合いも無いの無い無い尽くしの中でちゃんと動くもん作ってたんだよ。
0
aa @aa60006342 2020年9月20日
使い続けるシステムである以上はいずれ現在の目的とは違ったコードが出てしまうので技術的負債を発生させないってのは不可能で、定期的に返済していく必要がある
5
anineko @ANINEKObySYSTER 2020年9月20日
とか、たまに昔語りしとかんと、当時の事情なんて記録に残らんし、当時のレガシーが手抜きじゃないことも判らないだろうね。・・・いや、昔のアレな状況をぼやき・・いや、何とかした自慢も入ってるが・・を書き散らしてるだけでもあるw
0
cocoon @cocoonP 2020年9月20日
コード側のリファクタリングによってインフラ設計に支障をきたす例とかもあるのでまあ。全体を同時に完璧にみられる人なんていないので。
0
乾也春海 @kanbaru 2020年9月20日
この話は何もプログラミング周りの話だけではなくて、企業内の一般的な事務処理方法などでも多くある話です。私はこの辺の改善で雇われることも多いので、企業等の様々な負債で食べている感じです。
0
cocoon @cocoonP 2020年9月20日
yer_meme いや ANINEKObySYSTER さんも述べておられますが「当時は最適でも今となっては負債になっている」ものもあるので、行き当たりばったりだったわけではなくても時間の経過とともに技術的負債になることはありますよ。今時画面遷移のあるWebアプリのインターフェイスが残ってるサイトとかあるじゃないですか。
5
かーぽ @xi8442 2020年9月20日
ジェンガは後からプラスして積み重ねないから、テトリスの方がたとえとしてはしっくりくる気がする。
1
lion @lion55571 2020年9月20日
工数が瀑上がりするのを修正するのはリファクタリングというか再設計かなぁ。それと陳腐化とはまた別だろうね。
0
Wa @0000548C 2020年9月20日
"ちゃんと設計されていないシステム"を"リソース制限の厳しい昔の環境"とだれも読み違いはしていないし、制限なりに妥協・割り切り・将来を見込んだ上手な設計や運用方法とは当然あるものであって。
1
Wa @0000548C 2020年9月20日
磁気コアでもNANDフラッシュ100枚重ねでもきれいと汚いはあるということ。
1
yamadataichinokiseki @yamadataichino1 2020年9月20日
vueやらnuxtやらのキラキラフレームワーク使ってる時点で負債だよな。
0
anineko @ANINEKObySYSTER 2020年9月20日
あ、見返してると説明不足が。磁気コアメモリのフェライトコアの形状はドーナツ型だよ。今のコイン型磁石でもたまに穴をあけてるのがあるけどそういうの。5円玉みたいな。その穴に3本の銅線を通してある。・・・これの組み立て作業って毛糸の編み物編んでるみたいな感じだろうな。特にデータ線は一本で全部のフェライトコアの中を通さないと動かない。手順を計画して丁寧に作業しないと途中で金属疲労で銅線が切れてしまう。これをGbit分作ってと言われたら辞表書いてその場で逃げるよw
0
Earwax @Earwax97409510 2020年9月20日
班長にその口調で言わせるなら返済の仕方じゃなくて負債の作り方でしょうに。良い方に導いてどうする。
0
bluemonkshood @bluemonkshood 2020年9月20日
自宅をリフォームする時に、トイレットペーパーホルダは、いちいち芯を外すタイプが一番安いが、労力と時間と、芯をなくす金額を考えると、ちょっとお金を余分に出して、片手で交換できるのが、いいよと勧められました。そういうメンテとか、時間や人でを節約する効果も考えないといけないってことですかね。
0
anineko @ANINEKObySYSTER 2020年9月20日
ちなみにこの磁気コアメモリが使われてた時代が、銀行でオンラインシステムが全国稼働した時代だね。それ以前は口座残高はそれぞれの支店の帳簿にしかなく、他の支店ではリアルタイムの引き出しとか不可能だった。これを口座情報を一式のコンピュータシステム上に入れて全国共通として、各支店(来客)からの引き出し要請やら残高確認に即座(当時レベル)に応える事を実現していた。256bitのメインメモリ基板、何枚実装してたんだろ?
0
anineko @ANINEKObySYSTER 2020年9月20日
このメインメモリ基板の大きさは今のデスクトップPCの拡張スロットに入れる基板のほぼ倍の長さ。幅はだいたい同じ。昔のISAバス基板ぐらいだね。それで一枚256bit。
0
anineko @ANINEKObySYSTER 2020年9月20日
銀行口座に支店番号が付いてるのはまさに前オンライン時代のレガシーだね。
0
anineko @ANINEKObySYSTER 2020年9月20日
「一式のコンピュータシステム」と書いたのは、この当時からすでに故障で止まらないように二重化とかしてたんだよ。一台じゃないから一式と表現してる。フォールトトレラントと呼んでいた。
0
anineko @ANINEKObySYSTER 2020年9月20日
ISA・・・あれ?EISAバスの方だったか?長いでかい基板の方・・・あ、やっぱEISAの方だわ。訂正します。
0
金山幸一 @KYMKouichi1993 2020年9月20日
>「弊社の動く糞」 肝心な箇所が上品になってない!
0
08_Reader @08_Reader 2020年9月20日
技術者じゃないオタクに分かりやすく喩えるなら、ソシャゲのFGOがもう何年も最初期のクソ仕様の改善を繰り返しているようなものだな。
0
Yeme @yer_meme 2020年9月20日
cocoonP あー、そっスね、訂正するっス。最初の実装がどうだったかは負債かどうかとは直接は関係なく、作った後にどう改善されてきたかが重要っスね。
0
Yeme @yer_meme 2020年9月20日
むしろ原義からすると、どんなコードだろうと負債になるっスね。 違いは品質(=利率)。出来るだけ低利で借りて予定通りに返し(=改良)つつ新たな融資で投資(=新規開発)のサイクルを回すのが重要って事っスね。
2
キケリキー @KIKERIKI17 2020年9月20日
負債に関わるものは2つの側面がある。事業内容の変化への柔軟性と、技術進化への変化の柔軟性で、どっちも初手から完璧などありえなくて、変に気取って意識高く作る方がベタ書きよりも負債率は高い。大体の変化に対応できるけど、定義が面倒なシステムとか、「運用上の不具合」を生みやすかったしな。
0
キケリキー @KIKERIKI17 2020年9月20日
ほんとうのところ、「当時適当に作られたか」とか「無茶な納期」なんて負債にとっては小さい要因で、2億かけて構築したAS400の処理系を、スパッと捨ててクラウドに移行できるか、とかそういう経営判断の方が大きいんだよなぁ。みずほ銀行とか、まさに負債の塊だが、それぞれのシステム系は、きちんと金と時間かけて作られてたろうしな。
9
anineko @ANINEKObySYSTER 2020年9月20日
>定義が面倒な あー、うん。そういうのもやむを得ず作ったよ。引数組み合わせで5次元配列変数とかね。 ※ 配列変数の引数が配列変数という入れ子構造。2次元配列変数の二つの引数が両方とも2次元配列変数。
0
anineko @ANINEKObySYSTER 2020年9月20日
ドキュメント書く時も紙は2次元だから5次元配列変数マップを書くのに苦闘した。 自分でもちょっと日数経つと判らなくなるというか、脳みそを5次元配列対応モードに切り替えるのを苦闘したり。 数年後にシステム拡張の発注が来た時に、既に転属してた私の後を引き継いだ後輩も理解するのに苦闘してた。 ※ 苦労じゃなくて苦闘w
0
anineko @ANINEKObySYSTER 2020年9月20日
しょうがねえじゃん。当時のマシンパワーで要求の処理をこなすには、そういう設計でしか処理速度を実現できなかったんだよ。 それでもCPUは常時100%に張り付いたままで、メンテ用のコンソールのキーボード入力もちょくちょく取りこぼすので、画面見ながら入力が入ってるか確認しながらになるという状況。
0
anineko @ANINEKObySYSTER 2020年9月20日
でもバッファオーバーフローとか原理的に起こらない設計を透徹してたからメンテフリーで停電とハードウエア故障以外では止まらない堅牢さだったよ。 お客もコード理解が死ぬほど大変なのは許してくれたし、堅牢さこそ望むことと高く評価してくれた。
1
山の手 @Yamano_te 2020年9月20日
後半のベンチャーの話。初期メンバーはまだ運用開始しておらず顧客も掴めていないので色々な実験と失敗ができます。そこで経験を溜められる。後から入ってきたメンバーは既に客がいて会社の評判があって、それを守ることを求められる。実験や失敗という経験が積めないのに「お前達は挑戦意欲が無い」「俺たちの若い頃は」などと不当に低く見られるパターンがままあります。
0
山の手 @Yamano_te 2020年9月20日
スタートアップでどんな使われ方をするかを最初に予見できる技術者も経営者もいないのでは?例えばザッカーバーグは「Facebookは世界をオープンでより繋がったものにするという社会的ミッション達成のために作られた」なんて大層なこと言ってますが、これは後付の主張にすぎず最初は単に大学生同士の交流システムだった。
0
Web屋Layzy @layzy_glp 2020年9月20日
まあ、こうならないために「余所はどうやって作ってるのか」って情報入れないといけない
0
山の手 @Yamano_te 2020年9月20日
この社長前からTwitterでIT業界のクソビジネスと人月商売と残業の批判に熱心で、それはまあご結構なことなんだけど、株式会社アクシアの年収データ見ると残業時間0でも行きたい会社じゃねえなあと感じてしまう
9
kumonopanya @kumonopanya 2020年9月20日
どんなときでもすべてを捨てて0から作ったほうが安上がりなのに、元からあるのを活用しようとするからうまく行かなくて嫌われる。サンクコストを理解できなかった自分達が悪いのに・・・
1
さとうあきひろ @akihirosato1975 2020年9月20日
きちんと設計したシステムでも、ミドルウェアや言語の互換性問題なんかが原因で結果的に技術的負債が発生することもあるので、気をつけていても回避できない場合ってのもあるからなぁ。ぶっちゃけJava、おめーのことだ。
3
mmm1969mmm @mmm1969mmm 2020年9月20日
ちゃんとした会社は開発費かけるほど保守費も取るよね 作ったら終わりと思ってる会社ほど負債が増えてるんじゃないかな
0
000 @qgatmdgtwd 2020年9月20日
この手の話題はIT系ばかりが目立つが、製造業の設備の技術的負債はもっと根深く、闇が深い。
6
汝、翼を与える@ばってん先に翼ばくれんね イベント・・(出た、出たが最初から居るとまでは・・・) @ryunosinfx 2020年9月20日
残念ながら、避けられない未来の側面が強いので生物的解決、即ち生と死が重要なのでは?
1
anineko @ANINEKObySYSTER 2020年9月21日
qgatmdgtwd 10年そこら前にやった仕事は昭和に設置された生産ラインの改造でした。生産品が変わっていくときに設備も配線もソフトも改造していってるんですが、私が来た時には設置当初のドキュメントしかない、その後の改造は何やったかまるで分らないという状況。現状設備の仕様の確認、配線の追っかけと今回の生産品に合わせた改造、ソフトの作り直しとドキュメントの作成、一通り・・・全部一人でやりました。
0
しゃけ @shakeflake1223 2020年9月21日
qgatmdgtwd 大昔に導入した機械に合わせて設計したシステムによって最新機器の性能を引き出せない足かせになってるみたいな状態とかあるあるですよね。そういえば最近DOS時代のソフト(加工PG確認ソフト)を社内開発で更新したけど涙がでるほど使いやすくなりましたよ(@加工PG作成者
1
000 @qgatmdgtwd 2020年9月21日
shakeflake1223 ANINEKObySYSTER ま、そういうのもあるけど、そもそも設備構成部品の材質と環境とのミスマッチによる摩耗とか腐食とか、狭いスペースに設備を詰め込み過ぎてクレーンが入れないとか、そういう泥臭い問題で年間数千億〜一兆くらいの損失が出ているところもある
0
ゆーくりっど / ひのき @euclid890 2020年9月21日
仕様的負債を技術的負債で補っていたので、後任者は死ぬ程大変だろうなと思ってます
0
kisara @kisara50 2020年9月24日
レガシー(遺産)て呼称が既にあり、そっちのが適切。遺産はプラスとマイナスを含んでて不満なら相続放棄しろプラスが欲しけりゃ文句いわずにマイナスも払えって話なのに負債だけ強調するってエンジニアリング組織論とやらで一儲け企んでる連中がでっち上げたバズワードだろ。使う気しないね。
0
kisara @kisara50 2020年9月24日
akihirosato1975 JAVAの立ち位置もアレだよな。未来の言語だ古臭いWintelを駆逐するぞ→JAVAこそレガシーだ→Androidで復活。JAVA登場時に否定派でやっぱレガシー化したじゃないかと思ってたらマサカの復活で驚いたよ
0