組織が記憶喪失になるのをどうすれば ～ ryuzee技術顧問にきいてみた - NTT Communications Engineers' Blog
何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった＆話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念：ADR ADRの実践：その1 何を書くか ADRの実践：その2 どこに書くか ADRの実践：その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ
Four Keys にはどうやら2つの意味があるらしい - bonotakeの日記
先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
社内受託にならないエンジニアチームのつくり方 | Social Change!
先日（といいつつ結構前になりましたが）、私が社外取締役を務める株式会社クラシコムのエンジニア向けトークイベントに参加して、出番を頂いて話をしてきました。 クラシコムは、ECサイト「北欧、暮らしの道具店」を運営する会社で、商品コンテンツだけでなくドラマや映画、ポッドキャストを通じて世界観を発信しています。そうした様々な活動を支えるためにも、エンジニアチームを抱えてシステムを内製しています。 今回のイベントテーマは「社内受託にならないエンジニアチームのつくり方」で、私も含めクラシコムのテクノロジーグループが取り組んできた経験を話してきたので、本稿では私の話したことに加えて補足をいれながら言語化してみます。 社内受託になりがちな内製エンジニアチーム まず一般的な話ですが、事業会社におけるエンジニアチームの立ち位置は、場合によっては、同じ社内にもかかわらず一括請負の受託開発のように、決めたものを作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design