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

Architecture Programming

ワケ一覧

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

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

みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の 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 のこと常に心に置いてるか？　一つの判断ミスで信頼は一瞬で崩れ落ちるよ」

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

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