アーキテクチャに対応する日本語がない
「アーキテクチャに対応する日本語がない」事実に関するラフなメモ書き。
【元ネタ】
Twitter / akipii: 昨日の話で驚いたのはアーキテクチャに対応する日本語がないこと。元は建築の様式でパルテノン様式とか高床式とかのイメージらしい。ではソフトウェアは何に相当するか?
Twitter / akiyama924: @akipii 方式設計がアーキテクチャ設計に対応する日本語かも。
元々、アーキテクチャは建築業界における様式の概念らしい。
ソフトウェア業界でこの言葉が使われ始めたのは、さほど古くない。
だが、欧米人がアーキテクチャという言葉で使い始めた意味、新しい価値について、日本語に相当する言葉がない。
だから、日本人は輸入された言葉をそのまま使わざるをえない。
アーキテクチャと設計は違う。
秋山さんが言われるように、アーキテクチャは方式設計と訳す方がいい。
「ITアーキテクト」という職種はITSSスキルレベル4でも定義されているし、最近の日本でも流布されているが、まだまだ胡散臭い職種と思われがち。
アーキテクトはどんな仕事をするのか、というイメージが湧かないからだ。
僕がアーキテクトの職種で一番分かりやすいと思った説明は、ソフトウェアプロダクトラインではアーキテクトは顧客(プロダクトオーナー)、開発者(チーム、プログラマ)、会社の上司(プロジェクトオーナー)の間でシステムを説明する役割を担うというもの。
システムを、開発者はプログラムの構造で捉えるし、顧客は自分たちの業務を自動化したり効率化する仕組みと認識しているし、上司はシステム開発の案件からどれだけ売上やコストが計上されるか、に興味を持つ。
それぞれの立場でシステムに対する認識が全く違うのだ。
アーキテクトはシステムを翻訳する役割を担う調停者である、と。
そのボタンを押したら何が起きるのですか?~アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索
オンサイト顧客が暗示したもの~プロダクトオーナーとアーキテクトの役割: プログラマの思索
今自分が考えていることは、アーキテクチャを業務システムの観点で捉えるために、DOAを用いてアーキテクチャを幾つかの観点で明確にして、現代のシステム開発に適用できるようにすること。
DOAのように、日本のソフトウェア開発は意外にも歴史があるにもかかわらず、アーキテクチャを明確に確立しておらず、開発現場ですぐに適用できるような知識体系にしていない。
だから、開発現場で同じような失敗を何度も繰り返しているし、顧客の言葉でシステムを説明できる道具をSEやPGは持っていない。
個人的には、アーキテクチャはパターン言語で表現した方が、開発現場で再利用しやすいと思っている。
また、アーキテクチャを重視する人達はWF型開発に囚われ過ぎで、昨今のアジャイル開発の潮流に乗り遅れている。
アーキテクチャとアジャイル開発は2つとも融合できるし、お互いに補完し合える。
クラウドやチケット駆動開発のような開発環境の整備のおかげで、アジャイル開発がアーキテクチャ設計をより実践しやすくしている背景もある。
だが、開発プロセスに囚われないアーキテクチャの本質というものもあるはず。
その辺りを今後まとめていく。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- DDPは品質管理に役立つのか(2022.12.13)
- 組合せテストにおける因子と水準はどちらを最優先で考えるべきか(2022.12.04)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
「パターン言語」カテゴリの記事
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- 「ハリウッドリライティングバイブル」のマインドマップ(2022.01.23)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
コメント