eviry tech & service blog

「株式会社エビリー」の社員ブログです。弊社では、クラウド型動画配信サービス「millvi」、ソーシャル動画データ及び分析サービス「kamui tracker」、YouTube総合メディア「かむなび」を開発・提供しています。https://eviry.com/

トップ > マネジメント > 書籍の一文から拡げる技術陣マネジメント001

書籍の一文から拡げる技術陣マネジメント001

マネジメント 技術的負債

これは旧eviry tech blogから移行した記事です。

参考書籍

背景

  • 個人的な経歴として適切なマネジメントを受けてきたという認識/自覚がありません

  • なので「マネジメント」の意味する事柄/振る舞いが具体的になんだかわかっていません

現状の不足分を認めること

書籍「ベ」第17章「頭を使いなさい」にはこのようにある

要点▶ あなたの間違いとひどいコーディングの判断をみとめてください。そこから学んでください

上記はプログラマに向けられたものであるから「コーディング」という技術用語が用いられている。
それではマネージャに向けられたものとしてこの語を「マネジメント」に置き換えて考えてみる。

要点▶ あなたの間違いとひどい「マネジメント」の判断をみとめてください。そこから学んでください

ここから具体的に「なにが行われる」と「ひどいマネジメント」になるのか、
また「なにを行わない」ことが「ひどいマネジメント」につながっていくのか、
「ひどいマネジメントの判断とは一体なんなのか」を振り返ってみる。

過剰 : 「技術的負債 」という虚像

不足分の前にチームに過剰に分泌/浸透されている要素も理解しておく必要がある。
この語「技術的負債」はまさに過剰に分泌され、浸透しているといえる状況にあった。
その理由は以下によるものでそれなりの正当性を見ることができる。

  • 現行のプロダクトのコードが場当たり的発展を遂げ(続け)ており謎めいた複雑性を帯びている
    • テストコードがないまま発展してきてしまったし、現状の構造ではテストを書くことが難しい
  • 当時の経緯や仕様がチームから失われてしまっている
    • こちらもテストコードがないことは一つの理由になりそう
    • ただテストコードは開発場外の経緯を伝えてくれるわけではない
  • 見積もりが大きくぶれる
    • おもに上ぶれしビジネス的意思決定に影響を与える

これらは「技術的負債」でありそれらがもたらすものである。

技術的負債という語を理解する

書籍「エ」 Chapter 5 技術力組織の力学とアーキテクチャ / 5-3. 技術的負債の正体

の冒頭では筆者は以下のように「技術的負債という語が現場においてどのように使われがちか」を説明している。

これは、技術組織をもつ経営者にとっては理解しにくく、
またエンジニアにおいても「古くなってしまったコード」や
「わかりにくいコード」全般のことを技術的負債と呼び、
それをもって何かを説明したかのように考え、
修正や作業を要求するということも多く存在します

ここで言及されている 経営者にとっては理解しにくく という点がその後に

このような状態のプロダクトへの追加開発は、
本来はこのくらいでできるはずだと予想しているのに時間がかかってしまう、
というソフトウェアの中身を知らない人々の感覚と、
実際にソフトウェアを書いている人々にとって必要な作業との時間間隔に差が生まれることになります。
その認識の差は、しばしばエンジニアの能力的な問題ではないかとか、
努力の不足ではないかという邪推を生み出し、多くのハレーションが現場レベルで引き起こされます。

という形で発露されると続けている。ウォード・カニンガムが提唱した概念である「技術的負債」はこのような対立を解消し双方に現状を正しく認識させる便利な用語となる、はずだった。 はずだったというのは「理解できた気にさせる」というのが最終的な弊害になるということである。

その結果、「技術的負債」という言葉の存在で何かを説明したと思いこむ人々や、
ソフトウェア開発における経営上の問題について関心を抱かない経営者によって、
「技術的負債」という言葉は、
むしろコミュニケーションを断絶する言葉になってしまっているケースがあるように思います。
そもそも「負債」という言葉は、どのように解釈されているのでしょうか。
経営者ではない多くの人々にとって、「放っておいていてはいけない」「定期的に返済すべきもの」として、
負債という言葉が用いられています。
(略)
ところが、経営者にとっての「負債」という言葉には、資本としての意味合いもあります。
(略)
経営者にとっては、負債を多く借り入れることができることは、
信用度の高さを意味していて、
「借金」という日常語的な理解よりもポジティブな意味合いを見出しています。

見えぬけれどもあるんだよ

さらに書籍「エ」の筆者はフィリップ・クルーシュテンの4象限を引用する。

         見える   見えない
                
プラスの価値      新機能   アーキテクチャ
マイナスの価値       バグ  技術的負債

ここでは「内部構造を理解していない人に対して可視化されないマイナスの価値すべて」を「技術的負債」という語に押し込んでいるのがわかる。筆者はさらにこう続ける。

ここでいう「見ることができない」は、表面的な機能から発見することができないということを意味しています。
ソースコードの中を然るべき人がじっと見れば、読み解くことができるが、
システムの表面的な機能だけを見ていては、知りうることができないということだと解釈できます。

上記を踏まえてこのように考えた。

  • ソースコードへの理解可能性で区別する
  • 読み解ける人は開発者
    • 技術的負債解明の最低条件を持つ人
  • 読み解けない人は非開発者
    • 技術的負債解明の最低条件を持たない人

ここから以下に発展できるだろう。

  • 技術的負債の説明責任を持つ人
    • 開発者
  • 持(た|て)ない人
    • 非開発者

すると少なくとも「マネジメント」の文脈においては

  • 技術的負債の説明責任を
    • 果たすことがマネジメントのひとつ
    • 果たさないことはひどいマネジメントのひとつ

と言えそうだ。

上記を真とするとひとつのつまづきを得る。 「わたしたちは、これまで漠然と『技術的負債』と呼んでいたものが、将来においてどれだけの恐れを持つのか知らぬ」ということである。つまるところ「なにがどう負債なのかわかっていないにもかかわらずただ技術的負債だと言っていた」ということだった。技術職である開発者がその説明責任を果たしていなかった、そのように仕向けるマネジメントができていなかったというのが本エントリのまとめである。

次の予定

  • 説明責任に向けた下準備としての「技術的負債」可視化の仕組みについて