はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 先日、デブサミの後に参加してきたQAイベントでの議論と、 その次の日の業後にあるマイクロサービスメインで扱われている企業のQA部長の方 とディスカッションしてきて感じた内容や発見をここに残す。 前提 ビジネスアーキテクトとして品質管理も担っている自分としては、 ビジネスサイドから品質を考えないなんて言語道断！というマインドがある。 エンタープライズアーキテクチャモデルの4階層を見てもらうのが一番早い。 私たちは、日々手作業のアナログな業務活動に加えて、 情報システムなどを使った業務プロセスと込みで、 全体としてサービス全体を成り立

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 DX案件など含めたあらゆる案件や 様々なイベントのファシリテーションをやってきた中で気付いた重要ポイントについて記述します。 要約すると【ファシリテーション】がプロジェクトの成否を決めるということ。 対象読者 ・いつも会議が無駄な集会に終わって困っている人 ・あちこち議論が飛び交っていて良いアイデアが出なくて困ってる人 こんな経験ないでしょうか？ 複数のステークホルダーが集まる貴重な場での収集つかない議論。 認識が合わない・何言ってんのかわからない。 抽象度が違う話でモヤモヤ。時には口論みたいにもなり、 そしてただただ時間だけが過