はてなブックマーク

背景 先日、デブサミの後に参加してきたQAイベントでの議論と、 その次の日の業後にあるマイクロサービスメインで扱われている企業のQA部長の方 とディスカッションしてきて感じた内容や発見をここに残す。 前提 ビジネスアーキテクトとして品質管理も担っている自分としては、 ビジネスサイドから品質を考えないなんて言語道断！というマインドがある。 エンタープライズアーキテクチャモデルの4階層を見てもらうのが一番早い。 私たちは、日々手作業のアナログな業務活動に加えて、 情報システムなどを使った業務プロセスと込みで、 全体としてサービス全体を成り立たせて、それをエンドユーザーなどに提供している。 BtoCだろうが、BtoBだろうが、この本質部分は一緒である。 そのビジネスの中で、「ここの連携早くしたい」とか 「この情報は、企業の存続のために死守したい」などという EAの最上位層であるビジネスアーキテク

前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」 という文が紹介されました。 つくっているプロダクトで得られる売り上げよりも、 変更などにかかるコストが上回っている状態なわけだから、 お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。 で、事前に負債解消