ワケ一覧
序の口: フレームワークだけが負債だと思ってる
序二段: ビジネスサイドに理解してもらう努力がない
三段目: 技術で遊び過ぎてしまう
幕下: 太り過ぎアーキテクチャ
十両: 過去に目もくれず、現状だって見ない
前頭: 技術に詳しいだけでアーキテクト
小結: アーキテクトの知識と覚悟が足りない
関脇: スパンが長く、モチベーションが続かない
かど番大関: スパンが長く、人の入れ替えでチグハグ
大関: アーキテクチャデザインはどこへ？
横綱: 実は人間的負債だった
序の口: フレームワークだけが負債だと思ってる
みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？
o 信用できないテストデータ も負債
o 現場フィットレイヤ こそが負債
o 凶悪な引数リモコンパターン がたくさん
o 本番のログぐちゃぐちゃで役に立たない
o ビジネスロジックがぐちゃぐちゃで直しづらい
o 兎にも角にも、あれこれ散らかってるだけ ☆これデカい
...もっといくらでもある。
フレームワークや言語が古いことは、負債の一部でしかない。新しければ、より高度なことができる可能性は高いが、その現場で苦しんでいる原因の多くは実はもっと低レベルだ。アーキテクトってイメージよりももっと地味だよ。
...
普段の開発みたいに進めてはいけない
技術的負債の返済プロジェクトは、普段の開発とは優先度と判断が変わる。
普段の開発では出てこないチケットがある。
普段の開発では許される妥協が許されない。
普段の開発とは着手する順番が違う。
リニューアルした後にもう一度リニューアルしたくなるようなものを作らないこと、が目的だから。
その現場の技術的負債は何なの？そして、何を解決したいの？
それもわからず何か作ってるの？
序二段: ビジネスサイドに理解してもらう努力がない
案外、多くの人が努力をしていない。(努力したからって報われるわけではないけど)
技術的負債が、なぜビジネス的にも負債なのか？
非常に結びつけるのは難しいことですが、仕事で技術を追求し続けていたいのであれば、それを追求する姿勢を見せ続けていかないと。
=> レビューしやすいコード (Reviewable Code) | jfluteの日記
"技術者がやりたいこと" と "(潜在的に)求められていること" この二つを両立させてこそプロフェッショナル
それを目指さないのであれば、家で趣味でやればいい。
三段目: 技術で遊び過ぎてしまう
A. 問題を解決したいの？
B. 新しいツールを使いたいの？
どっち？
多少はOK。それも技術追求、回り回って役に立つ。程度の問題。でも、放っておくとどんどん遊ぶ。
ぼくらはデフォルトでその気質を持っているようだ。始まるのは、現場との乖離。現場はそんな機能求めてないのに！
その繰り返しが産むものは...技術的負債の返済プロジェクトの中断！
「はい、それやめー。みんな現場入ってすぐに今の仕組みで画面作って」
当たり前だよ、遊んでたら。ぼくらはいつだって、プロジェクトを止められる立場にある。
幕下: 太り過ぎアーキテクチャ
ぼくらは理想を追い求めがちである。これはこう解決できるじゃん、あれはああ解決できるじゃん、じゃあ解決しよう！
その繰り返しが産むものは...仕組み自体のメンテコストが高い仕組み。
解決しなくても大きな問題にならない問題なら、実は問題ではない。
仕組みを複雑にして、近づきづらい仕組みができてしまうことの方が、アーキテクチャを継続していく上で問題だ
ディベロッパーも少しずつ後ずさっていく。
アーキテクトチームって、どんどん増やしていけるものなの？(そんなお金があるの？)
もし、それならいいけど、そんな現場はめったに見たことない。よく我慢することもあるよ。
十両: 過去に目もくれず、現状だって見ない
過去の仕組みには大きな資産がある。その現場を必死に支えてきたロジックがある。その多くはこれからも必要だ。
でも、どうやらアーキテクトにとって、過去の仕組みを探るのは退屈な作業のようだ。誰もやらない。聞こうともしない。ソースも読まない。そして、新しい仕組みを作って何か悩んでる。
「なに三年前と同じことで悩んでんの？」
そのセリフを言わざるを得ない。まさしくこれだ。
=> 未来しか見ない人は過去に戻りたい？ | 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 のこと常に心に置いてるか？ 一つの判断ミスで信頼は一瞬で崩れ落ちるよ」
と常にプレッシャーをかけているのです。
うわぁー、こんなブログ書いたからには、もっと気をつけなきゃいけないじゃん（＞＜。
