jfluteの日記 このページをアンテナに追加

2017-02-11

技術的負債の返済プロジェクトが失敗する 11 のワケ

|

序の口: フレームワークだけが負債だと思ってる
序二段: ビジネスサイドに理解してもらう努力がない
三段目: 技術で遊び過ぎてしまう
幕下: 太り過ぎアーキテクチャ
十両: 過去に目もくれず、現状だって見ない
前頭: 技術に詳しいだけでアーキテクト
小結: アーキテクトの知識と覚悟が足りない
関脇: スパンが長く、モチベーションが続かない
かど番大関: スパンが長く、人の入れ替えでチグハグ
大関: アーキテクチャデザインはどこへ?
横綱: 実は人間的負債だった

序の口: フレームワークだけが負債だと思ってる

みんな、フレームワークが大好き。
とはいえ、さすがにみんな、
「フレームワークが古いことだけが負債」
だなんて思ってないはずだが...なのに多くの人が、
あたかもそのような振舞いと判断をしてしまう。
潜在意識Big Issue だから?

o 信用できないテストデータ負債
o 現場フィットレイヤ こそが負債
o 凶悪な引数リモコンパターン がたくさん
o 本番のログぐちゃぐちゃで役に立たない
o ビジネスロジックがぐちゃぐちゃで直しづらい
o 兎にも角にも、あれこれ散らかってるだけ ☆これデカい

...もっといくらでもある。
フレームワークや言語が古いことは、負債の一部でしかない。
新しければ、より高度なことができる可能性は高いが、
その現場で苦しんでいる原因の多くは実はもっと低レベルだ。
アーキテクトってイメージよりももっと地味だよ。

...

普段の開発みたいに進めてはいけない

技術的負債の返済プロジェクトは、
普段の開発とは優先度と判断が変わる。

普段の開発では出てこないチケットがある。
普段の開発では許される妥協が許されない。
普段の開発とは着手する順番が違う。

リニューアルした後にもう一度リニューアルしたくなる
ようなものを作らないこと、が目的だから。

その現場の技術的負債は何なの?
そして、何を解決したいの?

それもわからず何か作ってるの?

序二段: ビジネスサイドに理解してもらう努力がない

案外、多くの人が努力をしていない。
(努力したからって報われるわけではないけど)

技術的負債が、なぜビジネス的にも負債なのか?

非常に結びつけるのは難しいことですが、
仕事で技術を追求し続けていたいのであれば、
それを追求する姿勢を見せ続けていかないと。
 =>  レビューしやすいコード (Reviewable Code) | jfluteの日記

"技術者がやりたいこと" と "(潜在的に)求められていること"
この二つを両立させてこそプロフェッショナル

それを目指さないのであれば、家で趣味でやればいい。

三段目: 技術で遊び過ぎてしまう

A. 問題を解決したいの?
B. 新しいツールを使いたいの?

どっち?

多少はOK。それも技術追求、回り回って役に立つ。
程度の問題。でも、放っておくとどんどん遊ぶ。
ぼくらはデフォルトでその気質を持っているようだ。

始まるのは、現場との乖離。
現場はそんな機能求めてないのに!

その繰り返しが産むものは...
技術的負債の返済プロジェクトの中断!

「はい、それやめー。
みんな現場入ってすぐに今の仕組みで画面作って」

当たり前だよ、遊んでたら。
ぼくらはいつだって、
プロジェクトを止められる立場にある。

幕下: 太り過ぎアーキテクチャ

ぼくらは理想を追い求めがちである。
これはこう解決できるじゃん、
あれはああ解決できるじゃん、
じゃあ解決しよう!

その繰り返しが産むものは...
仕組み自体のメンテコストが高い仕組み。

解決しなくても大きな問題にならない問題なら、
実は問題ではない。

仕組みを複雑にして、
近づきづらい仕組みができてしまうことの方が、
アーキテクチャを継続していく上で問題だ

ディベロッパーも少しずつ後ずさっていく。

アーキテクトチームって、
どんどん増やしていけるものなの?
(そんなお金があるの?)

もし、それならいいけど、
そんな現場はめったに見たことない。
よく我慢することもあるよ。

十両: 過去に目もくれず、現状だって見ない

過去の仕組みには大きな資産がある。
その現場を必死に支えてきたロジックがある。
その多くはこれからも必要だ。

でも、どうやらアーキテクトにとって、
過去の仕組みを探るのは退屈な作業のようだ。
誰もやらない。聞こうともしない。ソースも読まない。
そして、新しい仕組みを作って何か悩んでる。

「なに三年前と同じことで悩んでんの?」

そのセリフを言わざるを得ない。
まさしくこれだ。
 => 未来しか見ない人は過去に戻りたい? | jfluteの日記

自然デグレも発生する。
前に仕組みで密かに活躍していた機能がない!
しかも、そのデグレに気づかない。
三年前と関わっている人がガラリと違うことが多いから。

「なんで新しいアーキテクチャに、
 それを解決する仕組みないの?」

そのセリフを言わざるを得ない。
もちろん色々な事情で完璧は無理ではあるが...
解決する仕組みがない理由がないのはなんで?

そのアーキテクチャは、誰が喜ぶのか?

前頭: 技術に詳しいだけでアーキテクト

確かに技術に詳しくないと
アーキテクトにはなれないけど、
技術に詳しいだけじゃつらい。

アーキテクトのちから | jfluteの日記

技術力があるのは当たり前。
一方で、技術力は100点じゃなくてもいい。
もっと違うスキルも必要だから、バランスが欲しい。
複数人なら得意分野で互いに補完し合えればいい。

複数人のアーキテクトチームであれば...

o アーキテクトチームに対するマネジメント力
o アーキテクトチームに対する教育力
o 意見が分かれたときにまとめる分析力
o 意見が分かれたときに決断するリーダーシップ

誰か一人はこれができないといけない。
でないと、我の強いぼくらはバラバラになってしまう。

本来、アーキテクトを誰がやるか?非常に気を使います。
本来、アーキテクトチームの構成に非常に気を使います。

...

さらに、忘れてはいけない重要なスキル...

整理整頓スキル

技術的負債は、散らかった部屋のようなもの。
部屋を効率よく快適に過ごせるよう片付けられる人。

絶対に必要。
みんながとっちらかし性格だと、
新しく作った仕組みはまた負債になる。

小結: アーキテクトの技術力と覚悟が足りない

意外に、
技術的負債を返済できるレベルの技術力、
を持ったアーキテクトは少ないものです。

打ち合わせにて、
「さあ、どんどん技術的負債を返済していくぞー」
と、みんな意気込んでいたら...

「あれってこうなの?これってこうなの?」
「いや、これはこうで、あれはああで...」

と勉強会が始まってしまって先に進まない。

でも、案外そういうもの。完璧な人など誰もいない。
ただ、思ったよりもアーキテクトへの教育が必要だ。
最初から現場に、
アーキテクトに適任の人がいるとは限らない。
(というか、そうそういない)

それを見越して、アーキテクトチームを
マネジメントしていかないといけない。
一方で、アーキテクトはそのことを理解して、
土日でも夜中でもなんでも使って勉強しないと。

...

技術的負債の返済プロジェクトなんて、
そんなに経験することじゃない。
慣れてる人なんてほとんど誰もいない。
どのくらいの稼働が必要になるのかよくわからない。
ただでさえ、ビジネス的に理解がされにくいもの。

プラスアルファな時間で稼働していかないと、
技術的負債の返済プロジェクトは成り立たない。
技術的負債の返済プロジェクトはそんなに簡単じゃない。
人をたくさん集めればできるものじゃない。
スキルが足りなければできないだけだけだ。

...

ディベロッパーは平日の昼間は実装している。
アーキテクトは横断的な修正がしたくてたまらない。
土日や夜中はディベロッパーが休んでいる絶好のチャンス。

覚悟はあるか?

関脇: スパンが長く、モチベーションが続かない

技術的負債の返済プロジェクトは、
二年三年と続く、ながーいながーい戦い。

最初は...
「新しい技術にさわれるー、あれもこれも直せるー」
と意気込むものだが、
やってみると地味な作業がかなり多く、
ちょっとずつ熱も冷めてくる。

...

二年前は最新ツールだったけど、いまはもう違う。
でも今からそんな簡単に変えられない。
まだまだ他にやることいっぱいあるし。

「新しい技術にさわれるー、って...あれれ!?」

A. 問題を解決したいの?
B. 新しいツールを使いたいの?

アーキテクトのモチベーション、
時が経てば経つほど、
どんどん化けの皮が剥がれていく。
モチベーションのバランスは?
 => 独学のきっかけ、技術欲、問題解決欲、自己成長欲 | jfluteの日記

何をしたくてアーキテクトになったんだい?

かど番大関: スパンが長く、人の入れ替えでチグハグ

技術的負債の返済プロジェクトは、
二年三年と続く、ながーいながーい戦い。

アーキテクトチームの人も徐々に入れ替わり、
現場のディベロッパーも徐々に入れ替わり...

変わっていくポリシーや価値観。
でもそれまでに積み上がっているものがある。
より一層バランスを取ることが難しくなっている。

なんか色々と混ざってて中途半端!
チグハグが悪いわけではなく、
チグハグがマネジメントされていないことがつらい。

「もはや新しいアーキテクチャ負債では?
 やらないで古いアーキテクチャで
 改善していた方がよかったんじゃない?」

そのセリフを言わざるを得ない。

...

ビジネスサイドの人だって変わるかもしれない。

「その技術的負債の返済プロジェクト、
 なんのためにやってるの?」

ちゃんと価値を積み上げているか?
ぼくらはいつだって、
プロジェクトを止められる立場にある。

大関: アーキテクチャデザインはどこへ?

建築デザインは、〇〇さんに依頼」
「プロダクトマネージャーに、〇〇さんにが就任」

これらは、一般によく聞く言葉だが、

「アーキテクチャデザインを、〇〇さんに依頼」

というのはあまり聞かない。

アプリケーションアーキテクチャは、
ディベロッパーの住む家のようなもの。

アーキテクチャで、ディベロッパーの効率は変わる
アーキテクチャで、ディベロッパーの行動は変わる。
アーキテクチャは、空間である。
アーキテクチャデザインは、空間デザインである。

...

技術的負債の返済の「かたち」は一通りではない。
一つの問題に対する解決方法が一つとは限らない。
誰がやっても同じものになると思ったら大間違い。
優秀な人の解決方法が同じだと思ったら大間違い。

その事実を忘れて、
なんの思想もなくアーキテクチャを作り始めても、
バランスの取れた構造物にはならない。

その技術的負債を、どう返済したいのか?

A という思想の中で最適な手段である B,
C という思想の中で最適とは限らないもの。

アーキテクチャの思想は、
柔軟でありながらも確固たるものでなくてはならない。

...

その現場のアーキテクチャデザイン、誰がやる?

o 太り過ぎず持続的なアーキテクチャになるように
o 説得力と意義のあるアーキテクチャになるように
o 現場にフィットしたアーキテクチャになるように
o 現場から超喜ばれるアーキテクチャになるように

どんな思想で、どんな判断をする?

アーキテクチャ周りの「実装」ができることと、
アーキテクチャ周りの「判断」ができることは、
別のスキルである

横綱: 実は人間的負債だった

最強の理由。

もちろん、多くの問題は、
人の振舞いが問題で負債になるものだ。

ただ、
人間の限界を、技術で解決していくのは前向きだ。
人間の怠慢を、技術で解決していくのは悩み物だ。

先輩と後輩、教育と信頼関係がうまくいけば...
チーム開発、リーダーシップがうまくいけば...
縦割り組織、コミュニケーションを円滑にすれば...
各々のディベロッパースキルがもっと上がれば...
各々のディベロッパーがソースをもっと読めれば...

したら、要らなくなる機能たくさんないか?

人間の「あまりの」怠慢から生まれる変な機能、
作ってるアーキテクチャに入ってないか?
太り過ぎアーキテクチャの大きな要因の一つ。

もちろん線引きは難しい。
わかってても機能で頑張るしかないこともある。
ただ、
「解決策がアーキテクチャだけとは限らない」
ことを理解できないといけない。
組織的な提案もできないといけない。

どんなアーキテクチャも、
人間の「あまりの」怠慢は、
なかなか解決できない。

アーキテクトは、技術屋じゃない。
主に技術に着眼点を置いている問題解決屋だ。
でないと、アーキテクチャを守れない。

...

前のフレームワークも、実は使いこなせてないだけで、
もっと勉強して使えば多くの問題は解決できたりしない?

次のフレームワークの方が良いものだったとしても、
前のフレームワークを使いこなせていない人たちが、
次のフレームワークを使いこなせるか非常に疑問だ。

「使ってみたいから、入れ替えてるだけじゃないか?」

「実は、その技術的負債の返済プロジェクト自体が、
 人間的負債なんじゃないか?」

絶対に、そんな風に言われるなよ。

常にプレッシャーを与える

一つ一つの項目に、
もっともっと深いストーリーとエピソードがあって、
一つの項目だけで一つのブログが書けてしまいます。

もっと具体的なケースで、
どんな判断ロジックがあるのか?
どんなコツがあるのか?

まとめるのは、さすがに時間がかかるので、
機会あれば講演会などで話をしていこうかな。

...

執筆時 jflute は、
二つの現場で技術的負債の返済プロジェクトの
アーキテクチャデザインを任されています。
それぞれ、4,5人のアーキテクトチームの
顧問としてプロジェクトを進めています。

二つ同時って確かにちょと大変ですが...
(メンバーも組織も価値観も違うし)
でも比較ができて客観視がしやすいので、
互いの現場にプラスになっていると思うので、
これはこれで良い経験だと考えています。
アーキテクトたちをアーキテクトとして育てる、
というのにもチャレンジ。一番楽しい教育かも。

このブログに書いた内容は、両方の現場で、
アーキテクトたちに強く啓蒙しています。
ようやく説明資料ができてよかったぁ、みたいな笑。

【追記】
両方とも、Webサービス系の事業会社で、
スタートアップ&インクリメンタル開発の現場です。
運用しながらの改善というのがとても難しいところ。

...

片方の現場は、まだ始まったばかりで、
まさに今日書いたことを、
しっかり気をつけていかなければと。

もう片方は、すでにプロジェクトは進み、
幸いながらビジネスサイドの方からも高い評価を頂き、
jfluteとしても、大きな成功体験の一つとして、
もっと良い判断をしていくための分析対象です。
頑張ってくれたアーキテクトたちと、
献身的な現場のディベロッパーのみなさん、
そして仙人のようなハイパーDBAのおかげです。
本当にありがとう。
もちろん、まだまだ先長いので油断はできません。

さて、
この 11 のことを気をつけていたから成功した...???
いやいや、そういうニュアンスじゃなくて、

これだけのことをやって、ようやく

成功した...しかもギリギリ成功した。
そんな感覚です。
「それだけ大変なことなんだ!」
一層そう思うようになりました。
どんなに頑張ってもダメなときはダメ、
ってこともあるだろうし。

なので、jflute は、
気軽に「今のサービス作り直しちゃいましょ」とか、
気軽に「フレームワークを変えちゃいましょ」とか、
とてもじゃないけど、そんな感じでは言えません。

中途半端に進んで挫折したプロジェクトほど、
負債なものはないんですね。
「だったらやらない方が良かった」って。

場合によっては、
「現状の仕組みのままで改善を進めていく」
という提案をすることもあるかもしれません。
大抵みんないやがるんですけど(jfluteもいやだけど)、
確実に現実的な選択肢の一つです。
現状の仕組みでも考えれば幾らでも改善できるはず。

前に進むんであれば、じゃあ、
この「11のワケ」を覚悟していこうよ。
もう一つワケがあった。
「11の話を聞いても聞く耳持たない」
が12個目だ。

...

そして、なによりも...

「jflute よ、11 のこと常に心に置いてるか?
 一つの判断ミスで信頼は一瞬で崩れ落ちるよ」

と常にプレッシャーをかけているのです。

うわぁー、こんなブログ書いたからには、
もっと気をつけなきゃいけないじゃん(><。

f:id:jflute:20170101194349j:image