アーキテクトのちから

ここでのアーキテクトとは？

こういうのは明確な定義はない言葉ですが、
ここでは割り切った定義をしてしまいます。

サービス開発・システム開発の現場にて、
ディベロッパーの開発や運用効率を向上、
アプリが抱える技術課題の解決のために、
実装の開発環境やフレームワークに加え、
現場適合な共通部品に実装ポリシーなど、
アーキテクチャをデザインする人のこと。

ちょっと、大それた言葉かもしれませんが、
「実装現場のデザイナー」と呼びたいなと。

ここでは、ちょっと現場寄りなアーキテクトを定義しています。
一方で先進的なアーキテクト、最先端の高レベルな技術に長け、
非常に難しい技術的課題を先進的な方法で解決する人もいます。
この場合は、アーキテクトよりギークという言葉が似合うかも。

jfluteは、残念ながら後者にはまっったく及ばないので、
今日の内容は、ちょっと現場寄りのお話になるでしょう。
「リーンスタートアップ・インクリメンタル開発」な現場での、
アプリ開発の現場での開発・運用効率の向上を担うことが多く、
どうしてもそこでの話に寄ってはしまいますが、
その他の現場でも通じる話ではあると思います。

ちなみに「人」と表現していますが、
正確には「役割」と言えるでしょう。
ひとりの人がすべてを担うとも言えないし、
逆に他の役割と兼任することもあるかなと。

なんにせよ、
アーキテクトという役割がもっと認知され、
アーキテクチャの大切さが伝わると同時に、
アーキテクトを志す人が増えて欲しいなと。

アーキテクト不足の時代

極端な話、数多くの開発現場にてアーキテクトはいません。
極端な話、そこはプログラマーとマネージャーだけの世界。

「システムを作ろう、
プログラマー集めて作らせよう、
だれだれさん管理してくれる？」

この感覚。。。

まあ、さすがにもうちょい彩るにしても...

「マネジメントはだれだれさんにやってね、
そしてＳＥとＰＧを集めてシステム作ろう」

昔から、そこにアーキテクトはいませんでした。
アーキテクチャが必要ないわけじゃありません。

ＳＥもしくはＰＧと言われる人が片手間で実装する。
その片手間作業は、予定・予算に含まれていません。
気の利いたプログラマーがとっても頑張るでしょう。
その人の負荷は非常に高くなるでしょう。

このだましだましを繰り返している現場をよく聞きます。
...さらに時代は進みます。

アプリに求められる技術的な課題の複雑化に加えて、
「スピード」がとても求められるようになりました。
要件定義やって設計やって、その後に実装、そしてテスト、
そんなウォーターフォールはあまり見かけなくなりました。

o リーンスタートアップ・インクリメンタル開発
o 一括受注にしても設計と実装は同時並行の開発

そこで求められる開発スタイルは変わりました。
アーキテクチャの持つ役割は増したと考えます。

それでも、アーキテクトという言葉を、
現場で聞くことはなかなかできません。
でも実は、だれかが身を投げうってやっているのです。
もしくは、非効率さを画面数で割って薄めているだけ。

アーキテクチャがコードを導く

建築の世界では、空間デザインという言葉があり、
空間により人々の行動が変わるという思想のもと、
空間をいかにデザインするか？

空間が、能動的な行動のきっかけにもなるし、
逆に行動の制限のきっかけにもなるでしょう。
デザインには人の気持ちを変える力が備わっている。

アーキテクチャは、実装世界の空間と言えるのでは？
アーキテクトは実装世界の空間デザインをしている。

そこがどんな空間か？
アーキテクチャによりディベロッパーが書くコードは変わるかも。
書くコードが変わることで、ディベロッパーの行動が変わるかも。
さらに、アーキテクチャによってディベロッパーが成長するかも。
直接的な働きかけではありませんが、きっかけにはなるでしょう。

もっと、細かい表現をしてみましょう。
どんなクラスどんなメソッド、どんなログを提供すれば、
予期せぬバグが少なくなるか？アプリ実装が速くなるか？
把握しやすいコードになるか？デバッグしやすくなるか？
ディベロッパーが有機的な働き方をできるようになるか？

究極は、これを突き詰めて仕組みを考えるのが、
アーキテクトの仕事と言えるかもしれませんね。

いささか大げさかもしれませんが、
そのくらいの意識でアーキテクチャをデザインするくらいで
ちょうどいいと思っています。そのくらい真剣に、集中して。

アーキテクトの三つの行動

さて、アーキテクトは何をするのか？
もちろん、これだけじゃないですが、
特に強調しておきたいものを三つ挙げてみます。

行動1. ヒアリング
行動2. プロトタイピング
行動3. フォローアップ

これら行動ができる人をアーキテクトに。
アーキテクトを目指すなら自ら積極的に。

行動1. ヒアリング

現場のメンバーへのヒアリング、
特にディベロッパーの方々への。

あらたまってヒアリングもありますが、
普段のコミュニケーションが大切です。
あらたまった言葉にできない得難いヒントが、
何気ない会話にこそ見え隠れしたいするもの。

そして、ディベロッパーの方から自然とフィードバック
してもらえるようなムード作りも、実は何気に重要です。
アーキテクトが、業務のすべてを把握するのは大変です。
すべてを把握して特徴を捉えてデザインするって難しい。
アーキテクトが持っている情報はとても限定的なのです。

いかに、ディベロッパーの方からヒントを引き出せるか。
それも、ディベロッパーの方にできるだけ負担かけずに。
ディベロッパーのみなさんの声は、アーキテクチャの宝。

行動2. プロトタイピング

ヒアリングの結果から実装のプロトタイプを作ります。
ヒアリングするためのプロトタイプを先に作ることも。
プロトタイプを作ってはヒアリングしてのスパイラル。
これは開発が進んでいる真っ最中でも、繰り返します。
開発が始まらないとわからないことたくさんあるから。

にしても、ここが一番楽しいところかもしれませんね。
でも、しっかりとした合意形成を意識していかないと、
技術都合一辺倒のアーキテクチャになってしまうので、
集中力は切らさずに。

ちなみに、このプロトタイピングという言葉、
建築家の藤村龍至さんの、
「プロトタイピング−模型とつぶやき」
に思いっきり影響されています笑。
でも、この本で紹介されていることのように、
実装デザインもやっていくのだと思いました。
今日のブログを書くきっかけにもなりました。

行動3. フォローアップ

プロトタイプをディベロッパーに横展開していきます。
わからないことがあれば、丁寧に説明をしていきます。
つまづくことがあれば、フォローイングしていきます。
伝わったかどうか確認コードレビューをしていきます。
なにか問題があれば、問題分析、そして、解決の支援。

単にアーキテクチャを構築しました、おしまい、
では、なかなかアーキテクチャは成功しません。
大量のドキュメントを作っても誰も読みません。
アーキテクト自らの行動で、
アーキテクチャをインスタンス化しないと、
ただのハリボテになってしまう可能性あり。

アーキテクトの五つのスキル

それらの行動を踏まえて、
アーキテクトに求められるスキルとして、
強調しておきたいもの五つ挙げてみます。

スキル1. 行動力
スキル2. 気づかい
スキル3. バランス感覚
スキル4. スピードリファクタリング
スキル5. 問題分析スキル

これらスキルを持っている人をアーキテクトに。
アーキテクトを目指すなら自らトレーニングを。

スキル1. 行動力

作業内容が多種多様でステークホルダーも多いので、
素早く積極的に行動に移すことがとっても重要です。
このスキル、他の多くの行動やスキルを促進します。

突発的なフォローイングが必要になることがあります。
すぐに行動に移せる心と体のフットワークが必要です。

スキル2. 気づかい

現場のディベロッパーに対する気づかい、
そのサービスのユーザに対する気づかい、
その気持ちがなければ大切なことに気づけません。
ヒントがあっても見逃してしまうかもしれません。

ディベロッパーのみなさんの表情や会話、
課題管理ツールやチャットでのやり取り、
そこで選ばれた言葉、当然ソースコード、
さまざまなアウトプットに目を配りつつ、
なにかしらの変化を感じとろうとします。
ただ、すべてを感じとるのは当然のこと不可能なので、
努力目標としかいいようがないですが、意識しないと。

観察力、そして、洞察力を研ぎすましておくこと。

また、先のヒアリングのフィードバックに関連しますが、
気軽に話しかけられやすいムードであることが重要です。
これは単に仲良くしようというありきたりな話ではなく、
とても大切なアーキテクチャの糧となる情報を得るため。

人への興味がなければ、なかなかスキルアップしません。
普段から働き方の積み重ねが大きく影響するところです。

スキル3. バランス感覚

様々なレイヤでのバランスと向き合うことになります。
開発フェーズと運用フェーズとのバランス、
アプリの技術要件と業務要件とのバランス、
ディベロッパーの効率と品質とのバランス。

技術欲求と実現すべきこととの狭間で、
多方のジレンマにたくさん襲われる中、
複雑な要因からいかにバランス取るか？
技術力もそうだし仕事の判断力もそう。

アーキテクチャをやり過ぎないことも重要。
仕組みの複雑化はディベロッパーへのおもりとなります。
アーキテクトは「直したくてしょうがない」と思っても、
致命的でなければ最適化しないという判断もありえます。
常に費用対効果のバランスを頭の片隅に置いておきます。

アーキテクチャに関わる、
様々なステークホルダーとの合意形成。
これがなかなか難しいところですから。

スキル4. スピードリファクタリング

単純にプログラミングができるのは言うまでもないですが、
リーンスタート・インクリメンタルな実装が求められます。
開発の最中アーキテクチャを構築していくことになるので、
要望やフィードバックは五月雨です。

ディベロッパーの実装を止めることなく、
素早く要望の「取り急ぎインターフェース」を提供し、
その間にさらに作り込み、暫定実装から仕上げ実装に。
すでに実装に始まっていて、別の作業もありますから、
仕上げは細切れの時間でやることに。

特にディベロッパーが実装している間、つまり日中帯、
そこでアーキテクチャを作ったり変更したりするのは、
なかなかやりづらいことです。
寝静まった頃に夜な夜な実装したり、
週末休日にリファクタリングしたり。

リファクタリングにまとまった時間を取れませんが、
リファクタリングこそそのときに求められています。
問題解決のスピードを高めるためには、
最後の「仕上げ実装」が欠かせません。
アーキテクチャの進化を止めてはいけないし、
アーキテクチャの将来を気づかってあげたい

スピーディーなリファクタリング、段階的なリファクタリング、
これらを普段の実装からトレーニングして現場に入りましょう。

スキル5. 問題分析スキル

言うまでもないスキルではありますが、
強調される理由があります。

アーキテクチャは様々なレイヤのものと関わりが強い。
一見アーキテクチャとは無関係そうな問題であっても、
奥底で密かに関わっていることも十分に考えられます。
実は、アーキテクチャ自身の問題を解決するためにも、
幅広く問題にアプローチしていく必要があるものです。

問題がこじれると、
アーキテクチャに対する信頼度は下がります。
アーキテクチャはアウトプットが目に見えにくいため、
「信頼こそが成果」と言っても過言ではないでしょう。

問題分析・解決のトレーニングで、常に集中力をキープ。
仮説思考や論点思考など様々な視点のプロセスを実践し、
感覚をじっくり養っておくとよいでしょう。
 => My Favorite Book: 仮説思考

アーキテクトの二つの心がけ

さて、アーキテクトのお仕事の特徴から、
二つばかり強調しておきたい心がけです。

心がけ1. トランザクションは細かく
心がけ2. 最大の本末転倒に注意

心がけ1. トランザクションは細かく

アーキテクトは、タスクが多種多様であり、
スパンの長いものから、短いもの様々です。

そしてなんといっても、
アーキテクトが作ろうとするアーキテクチャは、
ディベロッパーに直接の影響を与えるものです。
中途半端な状態のものを提供すると現場が混乱します。
完全にしあがってから提供だと現場は日が暮れてます。

最終的に10まで作らないといけないものがあるとして、
最初は3で提供し、次は7で提供し、9,10と仕上げる。
決して、3.7や6.8という状態で提供してはいけません。

連続した集中時間を確保できない中では、
何気にこれってなかなか難しいことです。
(やってみないとわからないものですね)

時には「いまこの時間で 4 まで到達しない」のであればなら、
3 で止めて別のことをやる、っていうコントロールが必要です。
どこで止めても結果が整合性のある状態にしておくことが大切。

極端な話、とある時点でその作業を止めるってことになっても、
その後の運用に差し障りのない状態にしておくことが理想です。

心がけ2. 最大の本末転倒に注意

アーキテクチャの都合で、

ディベロッパーのスピードを落とさないこと

これが鉄則。

本来ディベロッパーのスピードを高めるためのものが、
ディベロッパーのお仕事を止めてしまっては本末転倒。

これも難しいことです。
どうしても技術都合の制約が発生することがあります。
また、技術側に寄せたいと思うときがあったりします。
技術への投資は将来投資として重要な役割もあります。

これもバランス感覚が大切です。
「いま」のさじ加減を考慮した空間づくりもしつつ、
「将来」のために、どうしても必要ななのであれば、
ヒアリングとフォローイングによる合意を得て、
少しだけ、ディベロッパーに協力を依頼します。

ときには、
アーキテクトが好むやり方やツールと、
別の選択肢を取ることもあるでしょう。
両立することもあれば相反することも。
できるだけ WinWin の選択肢を探し、
アーキテクチャのバランスを気づかい、
ひとつひとつと真摯に向き合うのです。

アーキテクチャの押し売りにはならないように。

...ここは少しだけ裏技があります。
よくDBFluteで現場の要件とマッチしないとき、
土日のうちに実装して「ほら大丈夫だよ」って。
オープンソース活動はやっておきたいですね笑。

アーキテクチャの成果

とあるアーキテクチャが効果的だったかどうかって、
同じプロジェクトを二回やって、それを比べてって、
そんな社会実験をしなければ厳密にはわかりません。

また、プログラミングの世界で作られるアーキテクチャは、
物理的なものではないので目で確認がしづらいものであり、
そのアーキテクチャを体験するのはディベロッパーだけと。

そのアーキテクチャが良かったかどうか？
究極はディベロッパーの感想、と言っても過言ではありません。
でも、わりとどこの世界でもそうですよね。特にものづくりは。
アーキテクチャの近くにいるディベロッパーの声こそ成果って、
それはそれでわかりやすいのかもしれませんね。
世の中には、もっとわかりにくい壁と戦ってる
プロフェッショナルなひとたちもいるでしょう。

でも難しいのは、
そのアーキテクチャの本当の成果は、一年後二年後だったり。
その頃にフラットな判断できるかって永遠のジレンマですね。

自戒の意味も含めて

えらそうに書いちゃってと思われたかも!?
jfluteもまだまだ全然できてないですよ。

ただ、ぼくの失敗体験や成功体験、他の現場へのヒアリング、
そこから考えて、アーキテクトにはこういったちからがある！
そして、アーキテクトにはこういったちからがもとめられる！

そう考えて、こうできるようになりたいぞ！って意味も含めて、
休暇中に頭の整理をつけるためにも、じっくり書いてみました。

少しでもアプリ開発現場が楽しくやっていけるように、
少しでもビジネスがスムーズに運営していけるように、
アーキテクトという役割が語れるようになればなぁと。

「よーし、サービス作ろうー、
今回の開発の実装デザインは、
だれだれさんにお願いしよう」

そんな声が現場で聞こえる日を。

...
...

七日連続、ブログ更新中！