新しい仕組みを作って何か悩んでる。「なに三年前と同じことで悩んでんの?」そのセリフを言わざるを得ない。自然デグレも発生する。前に仕組みで密かに活躍していた機能がない!しかも、そのデグレに気づかない。三年前と関わっている人がガラリと違うことが多いから。それを解決する仕組みないの?」そのセリフを言わざるを得ない。技術に詳しいだけでアーキテクト確かに技術に詳しくないとアーキテクトにはなれないけど、技術に詳しいだけじゃつらい。技術力があるのは当たり前。一方で、技術力は100点じゃなくてもいい。違うスキルも必要だから、バランスが欲しい。複数人なら得意分野で互いに補完し合えればいい。意見が分かれたときに決断するリーダーシップ誰か一人はこれができないといけない。ないと、我の強いぼくらはバラバラになってしまう。本来、アーキテクトを誰がやるか?非常に気を使います。本来、アーキテクトチームの構成に非常に気を使います。...さらに、忘れてはいけない重要なスキル...整理整頓スキル技術的負債は、散らかった部屋のようなもの。部屋を効率よく快適に過ごせるよう片付けられる人。みんながとっちらかし性格だと、新しく作った仕組みはまた負債になる。アーキテクトの技術力と覚悟が足りない意外に、技術的負債を返済できるレベルの技術力、を持ったアーキテクトは少ないものです。「いや、これはこうで、あれはああで...」と勉強会が始まってしまって先に進まない。完璧な人など誰もいない。思ったよりもアーキテクトへの教育が必要だ。最初から現場に、アーキテクトに適任の人がいるとは限らない。(というか、そうそういない)それを見越して、アーキテクトチームをマネジメントしていかないといけない。一方で、アーキテクトはそのことを理解して、土日でも夜中でもなんでも使って勉強しないと。...技術的負債の返済プロジェクトなんて、そんなに経験することじゃない。慣れてる人なんてほとんど誰もいない。どのくらいの稼働が必要になるのかよくわからない。ただでさえ、ビジネス的に理解がされにくいもの。プラスアルファな時間で稼働していかないと、技術的負債の返済プロジェクトは成り立たない。技術的負債の返済プロジェクトはそんなに簡単じゃない。人をたくさん集めればできるものじゃない。スキルが足りなければできないだけだ。...ディベロッパーは平日の昼間は実装している。アーキテクトは横断的な修正がしたくてたまらない。土日や夜中はディベロッパーが休んでいる絶好のチャンス。スパンが長く、モチベーションが続かない技術的負債の返済プロジェクトは、二年三年と続く、ながーいながーい戦い。最初は...「新しい技術にさわれるー、あれもこれも直せるー」と意気込むものだが、やってみると地味な作業がかなり多く、ちょっとずつ熱も冷めてくる。...二年前は最新ツールだったけど、いまはもう違う。今からそんな簡単に変えられない。他にやることいっぱいあるし。新しいツールを使いたいの?アーキテクトのモチベーション、時が経てば経つほど、どんどん化けの皮が剥がれていく。スパンが長く、人の入れ替えでチグハグ技術的負債の返済プロジェクトは、二年三年と続く、ながーいながーい戦い。アーキテクトチームの人も徐々に入れ替わり、現場のディベロッパーも徐々に入れ替わり...変わっていくポリシーや価値観。それまでに積み上がっているものがある。バランスを取ることが難しくなっている。なんか色々と混ざってて中途半端!チグハグが悪いわけではなく、チグハグがマネジメントされていないことがつらい。「もはや新しいアーキテクチャ、負債では?やらないで古いアーキテクチャで改善していた方がよかったんじゃない?」そのセリフを言わざるを得ない。...ビジネスサイドの人だって変わるかもしれない。「その技術的負債の返済プロジェクト、なんのためにやってるの?」ちゃんと価値を積み上げているか?ぼくらはいつだって、プロジェクトを止められる立場にある。「アーキテクチャデザインを、〇〇さんに依頼」というのはあまり聞かない。アプリケーションのアーキテクチャは、ディベロッパーの住む家のようなもの。アーキテクチャで、ディベロッパーの効率は変わるアーキテクチャで、ディベロッパーの行動は変わる。アーキテクチャは、空間である。アーキテクチャデザインは、空間デザインである。...技術的負債の返済の「かたち」は一通りではない。一つの問題に対する解決方法が一つとは限らない。誰がやっても同じものになると思ったら大間違い。優秀な人の解決方法が同じだと思ったら大間違い。その事実を忘れて...なんの思想もなくアーキテクチャを作り始めても、バランスの取れた構造物にはならない。いう思想の中で最適とは限らない。アーキテクチャの思想は、柔軟でありながらも確固たるものでなくてはならない。実は人間的負債だった最強の理由。多くの問題は、人の振舞いが問題で負債になるものだ。人間の限界を、技術で解決していくのは前向きだ。人間の怠慢を、技術で解決していくのは悩み物だ。先輩と後輩、教育と信頼関係がうまくいけば...チーム開発、リーダーシップがうまくいけば...縦割り組織、コミュニケーションを円滑にすれば...各々のディベロッパーのスキルがもっと上がれば...各々のディベロッパーがソースをもっと読めれば...したら、要らなくなる機能たくさんないか?人間の「あまりの」怠慢から生まれる変な機能、作ってるアーキテクチャに入ってないか?太り過ぎアーキテクチャの大きな要因の一つ。わかってても機能で頑張るしかないこともある。「解決策がアーキテクチャだけとは限らない」ことを理解できないといけない。組織的な提案もできないといけない。どんなアーキテクチャも、人間の「あまりの」怠慢は、なかなか解決できない。アーキテクトは、技術屋じゃない。技術に着眼点を置いている問題解決屋だ。ないと、アーキテクチャを守れない。次のフレームワークを使いこなせるか非常に疑問だ。絶対に、そんな風に言われるなよ。常にプレッシャーを与える一つ一つの項目に、もっともっと深いストーリーとエピソードがあって、一つの項目だけで一つのブログが書けてしまいます。具体的なケースで、どんな判断ロジックがあるのか?どんなコツがあるのか?まとめるのは、さすがに時間がかかるので、機会あれば講演会などで話をしていこうかな。二つの現場で技術的負債の返済プロジェクトのアーキテクチャデザインを任されています。それぞれ、4,5人のアーキテクトチームの顧問としてプロジェクトを進めています。二つ同時って確かにちょと大変ですが...(メンバーも組織も価値観も違うし)でも比較ができて客観視がしやすいので、互いの現場にプラスになっていると思うので、これはこれで良い経験だと考えています。アーキテクトたちをアーキテクトとして育てる、というのにもチャレンジ。このブログに書いた内容は、両方の現場で、アーキテクトたちに強く啓蒙しています。とも、Webサービス系の事業会社で、スタートアップ&インクリメンタル開発の現場です。運用しながらの改善というのがとても難しいところ。...片方の現場は、まだ始まったばかりで、まさに今日書いたことを、しっかり気をつけていかなければと。片方は、すでにプロジェクトは進み、幸いながらビジネスサイドの方からも高い評価を頂き、jfluteとしても、大きな成功体験の一つとして、もっと良い判断をしていくための分析対象です。頑張ってくれたアーキテクトたちと、献身的な現場のディベロッパーのみなさん、そして仙人のようなハイパーDBAのおかげです。先長いので油断はできません。ことを気をつけていたから成功した...???いやいや、そういうニュアンスじゃなくて....これだけのことをやって、ようやく成功した...しかもギリギリ成功した。思うようになりました。どんなに頑張ってもダメなときはダメ、ってこともあるだろうし。気軽に「今のサービス作り直しちゃいましょ」とか、気軽に「フレームワークを変えちゃいましょ」とか、とてもじゃないけど、そんな感じでは言えません。中途半端に進んで挫折したプロジェクトほど、負債なものはないんですね。「だったらやらない方が良かった」って。場合によっては、「現状の仕組みのままで改善を進めていく」という提案をすることもあるかもしれません。みんないやがるんですけど(jfluteもいやだけど)、確実に現実的な選択肢の一つです。現状の仕組みでも考えれば幾らでも改善できるはず。前に進むんであれば、じゃあ、この「11のワケ」を覚悟していこうよ。「11の話を聞いても聞く耳持たない」が12個目だ。一つの判断ミスで信頼は一瞬で崩れ落ちるよ」と常にプレッシャーをかけているのです。うわぁー、こんなブログ書いたからには、もっと気をつけなきゃいけないじゃん(><。既存のシステムがあるとします。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。