Overview
『アーキテクトの教科書』を読んで、アーキテクトに紐づくソフトスキルの重要性について考えてみた。
本書は全体を通してソフトウェア開発においける「アーキテクト」とどういうもので、どういう役割、業務をこなしていくのかということがわかりやすくまとまっており、ソフトウェアエンジニアのキャリアの先に「アーキテクト」というものを目指してる人は一読する価値がある書籍だと思う。
実際断片的に知っている知識(一部は深堀りもしているかもしれない)が、アーキテクトという業務において点と点が線になるような書き方がされており、ソフトウェアエンジニアとしての業務経験が次のキャリアの礎になっていることを実感できると思う。
私自身は「アーキテクト」になりたいかと言われるとよくわからないが、それに近い振る舞いを業務ですることもあり、自分の業務内容の振り返りと、業務全体をメタ的に認知して自分の日々考えていることを抽象化してみようというモチベーションで読んでみた。
その結果、ソフトウェア開発におけるアーキテクトにはソフトスキルが否応にも求められるのではないか?ということを考えたので、その考えを備忘録として記載している。
ソフトウェア開発におけるアーキテクト
本書の最後の章、6章には以下のように記載されている。
アーキテクトはアーキテクティングを専門領域とするスペシャリストであると同時に、ソフトウェアエンジニアリング全般の知識や経験を有するジェネラリスト
そしてジェネラリストであるがゆえに「ソフトスキル」を一定有することが求められ、その習得についても記載されています。
アーキテクトとソフトスキル
本書を読むとアーキテクトの役割とソフトウェアプロダクトの開発にあたって最初から最後までアーキテクトが密に関わっていくことがわかりますが、その中の一つに「開発プロセスの平準化」の仕事があり、これがちょうど最近自分も読んでいた『Software Design 』のドキュメント回の内容とも重なっていたので、いくつか自分の頭にあったことを言語化して、その中で 「プロセスをチームに落とし込むにはソフトスキルが必要である」 という仮説に行き着きました。
Software Design のこの回でテーマに上がっていたのは、ドキュメントの課題を各社どう解決しているのか?ということだったのですが、ざっと目を通してみて、方向性は様々あれど、各社とも概ね各々ドキュメントを始めとした「開発プロセスの平準化」には取り組んでいて、それがワークフローとして組織の中で回っているのだろうな、ということはわかりました。
そのうえで、このプロセスをどうやって組織にインストールしたのか?ということが疑問だったのですが、結局のところこれは言い出しっぺ(多くはアーキテクトやテックリードといった上位職)がちゃんとワークフローとして組織に取り入れるまでコミットした以外にはなく、このプロセスの組織へのインストールというのはソフトウェアエンジニアリングのスキルではなく、その役割の人が持っていたソフトスキルに依存していたんじゃないか?と考えます。
なぜソフトスキルがあってこそそれができたと考えるのか?というと、 プロセスの導入は骨の折れる仕事で、言っただけでは徹底されず、日々の業務のワークフローとして取り入れ鉄の掟として守り続けるためのコミットメントが必須 だからです。
あくまで僕の一人のソフトウェアエンジニアとしての経験の上でのはなしですが、プロダクト開発(これはPdM側であれTech側であれ)において、何かしらのプロセスを導入しようとすると十中八九ハレーションが発生します。全員が賛成するなんてことはないです。なぜなら、プロセス導入し、 その事によって発生するオーバーヘッドを許容できない立場の人間が組織には一定数存在する からです。
「自由」を志向し開発プロセスと言った画一的な物事の進め方に対してネガティブな反応を示すたちがの人がいることを理解し、個人最適が全体最適にはならないことを徹底して説得、時には上位職(CTOや VPoE といった組織の意思決定権を持つ立場の人) の力を借りながら粘り強くプロセスを入れた際のベネフィットを伝えるコミュニケーションし、時には警察業みたいな嫌われ役を買って出ても組織にプロセスをインストールするにはソフトスキルがより大事になってきます。
ただやろうと言っただけでは人は動きません。鉄の掟を作るというのはそう簡単なことではないからこそ、開発全体に関わり、ソフトウェア開発のプロセスを俯瞰できるアーキテクトにこそできる役割なんだと考えます。そしてその役割をまっとうするにはソフトウェアエンジニアリングのスキルだけでなく、ソフトスキルも求められます。
まとめ
- アーキテクトはジェネラリストの側面がある。
- ジェネラリストである以上ソフトスキルからは逃れられない。
- 組織に鉄の掟を作るときにはコミットメントが必要。
- そのコミットメントはアーキテクトが発揮するべきである。
考えていたことはこんなことです。たまたま連続して目を通していた本の内容に良いつながりを見つけられたので文章に起こしてみました。