第7回：ソフトウェアアーキテクトとプログラマ

みなさんこんにちは。システムエグゼの相田です。

ここ２回ほどヨコモジだらけの技術記事だったので日本語比率を上げようと思ったのですが、今回もヨコモジだらけです。すみません。

第七回目は、そう言えばこの連載タイトル「ソフトウェアアーキテクト四方山話」なのに「ソフトウェアアーキテクト」という言葉の説明をしていないなあと思い立ち、一度説明しておく事にしました。
弊社における現時点での「ソフトウェアアーキテクト」の定義と併せ「そもそもお前何者だ」という皆様の疑問にちょっとだけお答えしようかと思います。

なんとなく年末に相応しい内容ですね（？）

ソフトウェアアーキテクトのスキルセット

正直な所、日本 IT 業界において「アーキテクト」という言葉はかなり曖昧に使われています。

IT スキル標準（ITSS）や高度ITアーキテクト育成協議会（AITAC）が言う所の「IT アーキテクト」はどうもインフラ寄りの定義ですし。まあ「ソフトウェア」アーキテクトではないのでそういうものなのかもしれませんが。
どちらかと言うと Iasa の ITABoK なんかで定義される「IT Architect」の方がすっきりしているような気がします。もしかすると ITSS は徐々にこちらに寄って行くかもしれませんね。

弊社において「アーキテクト」を自称する技術者が現れたのは 2005年くらいです。ちなみに私です。当時私は実際の職位とは関係無く「アプリケーションアーキテクト」を名乗っていました。当時は ITSS バージョン 1.1 が公開されたばかりで、当時まだ私はその存在自体を知りませんでした。

私が「アーキテクト」を名乗った理由はただ一つ、私が Java プログラマ（※）であり、エンタープライズアプリケーションアーキテクチャ（PofEAA）等によるアプリケーションアーキテクチャ設計を専門としたからです。
私の心の師は Martin Fowler と Scott W. Ambler なのです。時代ですね・・・
（※ 憚りながら、英語原義における Programmer です。後述します）

その後社内で「アーキテクト」という仕事をコツコツ布教しつつ、そのスキルセットの整理を行いました。
原典としたのは IEEE 1471-2000 です。いわゆる『ソフトウエア集約システムのアーキテクチャ記述のための推奨指針（Recommended Practice for Architecture Description of Software-Intensive Systems）』ですね。

IEEE 1471-2000 のメタモデルに対し、当時 SI 業界で一般的だった開発プロセスや技法・手法、そしてオブジェクト指向開発文化から得た技法・手法を紐付け、ソフトウェアアーキテクトのスキルセットを定義しました。
私、その頃既に30代半ばを過ぎていましたので、大慌てです。「アーキテクト」になりたいのにちゃんとしたキャリアパスが存在しません。無ければ自分で作るしかありません。

やがて布教のかいあって、2013年頃には会社の目標として「アーキテクトの育成」が掲げられました。
さらにその後正式に「アーキテクト」という職位も認められ、私が整理したスキルセットがそのまま採用されました。約10年がかりの布教です。感無量です。

というわけで、弊社が採用している「アーキテクト」のスキルセットは、IEEE 1471-2000 メタモデルを元とし Java／オブジェクト指向開発文化が育んだ手法・技法の集合体として定義されています。

アーキテクトを育成せよ！

これで私は公式に「ソフトウェアアーキテクトです」と名乗る事が出来るようになりました。一安心です。
問題点としては、スキルセット定義真面目に作りすぎて、私自身も未だに全てを満たせない事ですね・・・人間一生勉強です。

さて、アーキテクトとしてのスキルセット定義とキャリアパスが出来上がったので、今度は実際にアーキテクトを育成しなければなりません。

実際問題としてアーキテクトは希少人材です。システム開発における全ての構成要素とプロセスを包括的に学ぶ必要がある職種です。
かつ、アーキテクトは「現実の課題」と戦わなければいけません。

オブジェクト指向をベースとしながらも、現実として存在する構造化手法やプロセス中心アプローチ（POA）、データ中心アプローチ（DOA）、伝統的な開発工程や開発プロセス、プロジェクトマネジメントや品質管理、ソフトウェア生産管理やソフトウェア工学についても知見を持たなければいけません。

全分野のスペシャリストになる必要はありませんが、少なくともこれら広範な領域における各概念を理解し、理想とする指向やプロセス、手法や技法との違いが理解出来なければなりません。
そうしないと現実のビジネスを進められませんし、現実の現場の改善が出来ません。

この話をするとオブジェクト指向好き、関数型プログラミング好きな若者に嫌われてしまう事が多いのですが、職業として「エンジニア」を選ぶ限りは仕方がありません。
IT エンジニアは工学の徒であって、技芸の人ではありませんので、コードだけ書いてれば良いというわけには行きません。仕事なんだから諦めて勉強しましょう。

諦めてもらったところで開始したのが、社内選抜メンバーに対するアーキテクト教育であり、以後も継続的に知見を共有するためのアーキテクトコミュニティ（※）です。
（※ 本コラムの第二回で紹介。アーキテクト教育対象者と各分野のスペシャリストが集まっています）

教材を整備し、社内セミナーを実施し、ビジネスチャットで様々な知見を常日頃から話し合い共有し、得られた新たな知見を教材や社内セミナーにフィードバックする、というループを２年がかりで構築しました。

プロフェッショナルとしてのスキルは座学だけで身に付くものでは無いですし、範囲が広いため才能がある人でも身に付けるのに何年もかかります。教育には継続的な取り組みが必要です。
長期的にかなりのコストがかかったとしても、アーキテクトの育成にはそれだけの価値があります。

セミナーの受講者全員がアーキテクトになってくれるわけではありませんが、こうやってコツコツを社内に種を蒔いています。
その成果として（少数ではありますが）アーキテクトを目指す若者も現れ始め、まずは胸をなでおろしています。

今「プログラマ」の皆さんへ

ここまで書いてなんですが、実は私ソフトウェアアーキテクトになりたかったわけではないのですよね。

私のキャリアの始まりは、今はもう無い某ソフトウェアハウスにおけるプログラマです。大昔です。
その当時はちょうど海外で Linux／OSS 文化が花開いてゆく時代であり「達人プログラマ（Pragmatic Programmer）」「本物のプログラマ（Real Programmers）」「ハッカー（hacker）」といった「理想のプログラマ像」が世界へ発信された時代でもあります。そういうヨコモジに単純に憧れました。この辺今の若い皆さんと同じです。私も若かったので。

プログラミングの勉強とともに、そりゃもう海外のテキスト（※）を読み漁りました。当時 Web で利用出来る翻訳サービスなんてありませんので、有識者の方の翻訳を探すか自力で辞書（物理）をひきながら一生懸命。
（※ 文字通りのテキストデータです。昔は HTML ですらない「テキスト」がいっぱいありました・・・）

結果「よし、本物のプログラマ（Real Programmers）になろう」と決心。

この文脈での「プログラミング」はコーディングだけでなく、設計や構成管理、テスト、現代におけるソフトウェア品質管理や生産管理など、システム開発に関する総合的なスキルセットです。

どれも今でこそコモディティ化しているものですが、当時は誰も彼もが手探りです。ググってもまとまった日本語情報なんてありません。というか最初の頃は Google そのものがありません。仕方なく希少な日本語書籍を読み漁りながらコツコツと勉強を進めていました。

そんな日々の中、ついに Java とオブジェクト指向に出会います。このインパクトが大きかった。オブジェクト指向の世界ではこれら「プログラミング」の構成要素が爆発的な進化を開始していました。UML モデリング、デザインパターン、コンポーネントモデル、アプリケーションアーキテクチャ、構成管理システム、自動テスト、TOC を元にしたリーンやアジャイルの思想など、目から鱗の概念に次々と出会えました。
Java の流行とともに日本語書籍もたくさん出てホクホクです。勉強が捗ります。

現在のシステムエグゼに入社してすぐに本格的な Java／Web 開発の時代に突入しました。それ以後はひたすらオブジェクト指向漬けの日々に。そして会社規模が大きくなるごとに（そして年齢を重ねるごとに）開発プロジェクトで統率するプログラマの人数も5人から10人、10人から20人、やがて50人、100人と多くなり。

それに合わせてプロジェクトマネジメントやプログラムマネジメント、各種見積もり技法、開発モデルの多様化に伴う開発プロセスエンジニアリング、大きなプロジェクトでは触れざるを得ない品質管理のあれこれや生産管理、内部統制含めた IT ガバナンスを勉強し。
仕事だから仕方ないのでとにかく片端から勉強しているうちに。

いつの間にか SI ベンダーのソフトウェアアーキテクトになっていました。

・・・あれ？

ええとですね。

今「プログラマ」の皆さん。本当の意味での「プログラミング」を勉強し続けると、いつの間にか辿り着くみたいなので「アーキテクト」を目指すのも良いですよ？

—————————————————————————

というわけで。

私の正体は「本物のプログラマになろうとしてたらいつの間にかソフトウェアアーキテクトになってた人」でした。
いや人生というのは分からないもので・・・
まあ、結果的にはこの年齢になるまでコードにも触れ、新しいプログラミングパラダイムも学び、いわゆる「技術」でご飯を食べる事が出来ているので、結果オーライという事で。

もちろん現代は伝統的な SI プロジェクト以外の開発も増えてきたので、ますますアーキテクトの出番は増えます。
伝統的な SI プロジェクトでもクラウドインテグレーションを意識しなければいけない時代ですし、伝統的な SI 以外の開発も増えてきました。レイヤード、モジュラーモノリス、マイクロサービスの使い分けも重要ですし、アジャイル開発ニーズも高まっています。

・・・興味のある方、誰か手伝いに来てくれませんかねえ？

お待ちしております・・・

それでは、また第八回（あれば）でお会いしましょう。

—————————————————————————