技術的負債

「保守や運用を考慮した開発」とは言うが、それが意図するところは思うより広い。ソフトウェアエンジニアとしてのその理解は、あくまでもソフトウェアエンジニアリングに閉じたものとなってしまいがちだ。 変更しやすいコードや、システムの安定した稼働は、無論、大切だが、バリューストリーム（value stream）という観点が抜け落ちることがある。そのペナルティとしてチーム間が密結合となってコミュニケーションコストが増大し、テスト容易性とデプロイ容易性を著しく損なう結果を招いたプロジェクトもある。 私が聞いた過去のあるケースでは、複数のアプリケーション間で一部の機能の共通化を進めたことでこのペナルティを支払…

久しぶりにウクライナが関係のない話。 エンジニア界隈で、技術的負債という言葉がある。 日本語版Wikipediaの概説を持ってくると、 技術的負債（英語: technical debt）、または設計負債、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである。 というものである。 言葉の理解 この技術的負債という言葉、エンジニアになった最初の頃は言葉を選ばずにいうと上品に担当部分の(自分を含めた)過去担当者を罵倒する言葉程度にしか思っていなかった。 …

で喋ってきた。 これ。 hatena.connpass.com カクヨムはここしばらく仕事で関わっているサービスで、正式なサービス開始から6年目に入っている。控えめに言って絶好調で、まだまだ終了はしそうにない。つまり開発も運用も続けることになる。 システム開発を始めてから5年もすれば相応に技術的負債も溜まってくる。このセミナーではそうした状況にどう対応して行こうとしているのか？ の概観と直近1年の実践を率直に発信できたのではないかと思う。 技術的負債はエンジニア界隈では人気のある言葉なので、対応事例はいくらあってもよいと思う。一つの参考としてみてもらえるのではないだろうか。

こんにちは、ライクル事業部 エンジニアの菊池@kichionです 現在、ライクルでは大きく2チームで分かれて開発を進めており、私は技術負債解消を行うチームでシステム改善を行っています ライクルでは早すぎたマイクロサービス化によりコードベースが30近いGithub repositoryに分散しており、システムツールのrepositoryを含めると50のrepositoryが存在していました。 アジリティ向上のため、コンテキストをまとめrepositoryを17個削ったのでその方法論を紹介したいと思います 背景 分散モノリスとの闘い 1. 重複コード・知識の分散を"なるべく"解消する 2. 使って…

ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負…

はじめに こんにちは、テックリードのかどたみです。 エンジニアの皆さんはエンジニア以外の従業員に業務内容を理解していただくために取り組まれていることはありますか？私は取り組みの１つとしてタイトルの通り社長と二人で技術的内容に関してZoomのレコーディング機能でラジオ収録を行い、Slackで社内に公開しています。 この記事では、なぜこのような取り組みを行うに至ったのかの経緯や内容、その結果としてどのような良いことが起こったのかを紹介したいと思います。 ラジオが始まった経緯 課題の共有 エンジニア以外に業務内容の理解がされていないとどのような問題が発生するでしょうか？ コミュニケーションコストが高…

はじめに 技術広報のyayawowoです。 いつもラクスのエンジニアブログをお読みいただき、またエンジニアイベントへのご参加、ありがとうございます。 今回は、6月に開催したラクスMeetupの発表内容をご紹介させていただきます。 rakus.connpass.com はじめに イベントテーマ概要 発表の紹介 新機能開発のアーキテクチャ選定 初コミットから3年たったので、負債について少し本気出して考えてみた 新規SaaSを創る際にインフラが考えること おわりに

はじめに お世話になった方々への謝辞 参考にしたブログ・その作者の方への謝辞 私のスペック なぜ米国大学院を志したのか まとまった時間でCS、エンジニアリングの勉強をしたかった 英語で学ぶという経験をしたかった アメリカで働いてみたかった ソフトウェア工学修士とは何か 計算機科学修士とソフトウェア工学修士の違い 大学院の選び方 専攻 何を専攻するか 研究するか？しないか？ 授業料 おわりに Appendix: そのほか参考になる記事 はじめに こんにちは、一昨年からアメリカの大学院への入学を目指し勉強してきました。 結果、アメリカのピッツバーグにあるカーネギーメロン大学のソフトウェア工学修士課…

2022年3月29日（火）に事業会社のアジャイル開発に携わっているエンジニアが集まり知見を共有しあう勉強会を開催。アジャイル組織を立ち上げた後、アジャイル開発を進めている中で得られたノウハウや課題を実例をもとに学びました。 登壇者はこの方々！※登壇順に記載フクイさん／某メーカー系サービス会社中野 涼祐さん／パーソルキャリア株式会社松榮 健至さん／株式会社 BuySell Technologies まずはフクイさんからいくつかのアジャイル組織立ち上げの具体例を伺いました。 アジャイル野良戦記 きっかけは｢アジャイルで残業ゼロ｣ 私は“野良アジャイル“を名乗っています。つまり会社組織に｢アジャイル…

テストコードを整備してテスト自動化を実現することで、何がうれしいのか。自分として現時点の見解を言語化しておく。 なお、自身の経験をもとにモヤモヤしていたところに、t-wadaさんの動画やpodcastによって、視界が開けたというのが正直なところです。 前提 ここでは、『テスト自動化』は、テストを自動的に実行できる状態にすることを言います。 テストコードをいつ書くのかはとくに限定せず、テストファーストやテスト駆動開発でもよいし、あとからテストコードを書くスタイルでもよい。 いずれにせよ大事なことは、人手を介さず自動的(手動トリガー含む)に同じテストを繰り返し実行できる状態であることです。 テスト…

技術的負債 (technical debt) は、ソフトウェア開発の用語で、手早い解決策を選択することで生じた潜在的な手直しのコストを指す。技術的盆栽 (technical bonsai) は、完成した技術を鑑賞し、また完成度の向上のために手直しを加える趣味を指す。技術的負債とは特に関係はない。定義はいま考えた。 「技術的盆栽」という言葉はここが初出ではなく、先行例が存在している（ことを Google が教えてくれた。）「文化的雪かきと技術的盆栽」というエントリで「ちょっとしたこだわりや調整にいくらでも情熱を注ぐことができる」ことが特色であると説明している。これは僕の「技術的盆栽」の解釈とも一…

さらっと目を通す価値がある本でした。 プレスリリースから書く、パワポではなく6ページの資料にまとめる等はある程度ググったから出てくるような内容かなと思います。採用に関しては正直何が新しいのか良く分からなかったです。評価基準周りは、普通の企業では見ていない指標を成長のために重視したとかのエピソードがあればもっと良かったと思います。中長期的な報酬設計ももう少し具体的に知りたかったです。シングルスレッド・リーダーはどの規模で作るのか、パフォーマンスが悪かったときどうなるのか、ソフトウェア上のマイクロサービスとどう関係してくるのか等々もう少し知りたかったですかね。 後半のキンドル/プライム会員/プライ…

会社で議論を進めていく上で、「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」を改めて目を通そうということになった。 もちろん書籍は知っていたが、恥ずかしながらきっちり読み切ったことがなかった。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon 気になったフレーズ Chapter 1 曖昧さを減らし、具体性や明確さを増やしていくことがエンジニアリング（が成すべき事） 本質的に分からないのは未来と他人 どんなに自分が正解だと思ってもそれは本人の認識においての話であり、他人（の認識）…

サーバーサイドエンジニアの森谷です。 Go Conference 2022 Springに"Go"ldスポンサーとして登壇してきましたので、その後日談記事になります！ 登壇内容 「創業以来のPHPシステムが生み出した混沌をGoへの移行で乗り越えた話」について発表しました。 gocon.jp （このブログ記事の執筆時にはまだありませんが、いずれ上記GoConページにアーカイブも上がってくると思います。） ヤプリは2017年から約3年をかけてCMSの大規模刷新を行いました。 その際にPHPからGoへと言語も移行しましたが、静的型付け言語への切り替えということで、特にDBからの値の取得にチーム一同か…

ost-zatu.connpass.com 今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていきます。 プロポーザルがない 缶バッジ 自分が原因で退職する辛さの話 理解と同意の混同 オンラインオフラインの境目 京都トーク 全体を通した感想 プロポーザルがない スクフェス大阪のプロポーザルを自分が思いつかないので、雑にアイデアを募集した所、色々とアイデアをいただくことができました。 プロポーザルを書く技術というプロポーザルを書く 沢山見ているセッションたちの感想を書く 新潟で出していなかったプロポーザルを出す もう残り少ないですが、もらったアイデアを基にしながらもう少しだけ考えてみよ…

modeling-how-to-learn.connpass.com こちらのイベントに参加してきたので、会の様子と感想を書いていきます。 会の概要 会の内容 プレゼンテーション 本の効用 対象読者 特徴 献本した方からの感想 各章の特徴 本のタイトルに込められた想い 執筆裏話 質問会 パッケージ原則は盛り込まれている？ 本を読むとバグハンターを攻略できる？ 技術的負債にどこからどのように手を付けるか？ 心を折れたコードは？ 実際に遭遇したコードが載っているの？ スキルの習得方法 リファクタリングと性能 みんなコピペをしているのですが。。 設計をする際にメンバーをどのように選ぶか？ コンテキス…

困ってはいませんか？私は困りました、というより、チームが困りました。 チームをどう配置させどう動くか 私たちの開発チームは0->1のプロダクト初期を乗り越え、これからビジネスとしてもプロダクトとしても大きくなろうとしているタイミングです。このときに、チームを分けるか？と唐突的な問いにぶつかりました。チームをわけないと、人を増やせない、はある程度の経験則ですが、 ほんとうに私たちのチームはチームを分けていくべきか そうすると、どう分けるか？ 分けてどう運用していくか？ といったことに解が出せませんでした。そこで手に取ったのが、「チーム・トポロジー」でした チーム・トポロジーの内容 一言で言うと、…

More Effective Agile “ソフトウェアリーダー”になるための28の道標作者:Steve McConnell日経BPAmazon アジャイル開発を学ぶためにこれまでいくつかの書籍を読んできた。 その中で学んだ知識には、現場で活かせるものもあれば活かしきれないものも合った。活かしきれない理由の一つに、アジャイル開発を進める上での前提となる組織との違いが制約となっていた、というものがある。 MoreEffectiveAgileではそんなアジャイル開発における理想と現実のギャップを埋めるためのヒントが多く紹介されていた。序盤で本書は、うまくいくことが実証されているプラクティスに焦点を…