<< Object Oriented を考える オブジェクト指向→目的志向 | main | 設計の原則:モジュール化 >>

アーキテクトを考える

Bruce A. Tate 著、まつもとゆきひろさん監訳、田和勝さん訳の

「7つの言語 7つの世界」

を楽しみながら読んでいる。

最初のページの「読者の声」の、

「複数のパラダイムを理解すると、設計能力が大幅に強化される」by Dr. Venkat Subramaniam

に、はっとさせられた。

読み進めるうちに、この言葉の意味が、実感できてきた。
「異なるパラダイムを、実感してみる」と「設計の発想やセンスが変化する」手ごたえがあった。

9章「まとめ」に、プログラミングパラダイムを4つに分類した要約がある。

●オブジェクト指向 --> Ruby, Scala
●プロトタイプ型 --> Io
●制約論理型 --> Prolog
●関数型 --> Scala, Erlang, Clojure, Haskell

※「手続き型」がないのは、この本では C, FORTRAN, COBOL, BASIC, PHP とか、手続き系の言語を取り上げていないから。

すべてを言語やそのパラダイムを高度に習得する機会はないだろうし、またその必要もないと思う。
でも、Suramaniam さんが書いているように、設計能力のスキルアップには、複数のパラダイムを経験し、理解することが、すごく役に立つはず。

この本の筆者自身、本を書くために未経験の言語に触れたことで、専門の Ruby の設計スタイルが変化し、設計能力がアップした、と書いている。

本を読みながら、インストールにはまったり、自分勝手なコードを書き始めて、脇道に入り込んだりで、なかなか、先に進まない。

いまのところ、Ruby , Io, Prolog までチャレンジしてみた。
ここまでだけでも、自分の専門の Java に対する別の見方、設計のヒントが手に入った気がする。

Io のシンプルなオブジェクト指向は、ちょっと感動もの。多重継承を実際にできる言語は初めてだったので、とても面白かった。

Prolog の、「事実とルールを宣言すると、問い合わせに回答してくれる」というパラダイムは、データベースとSQL、RESTful スタイルの リソース指向アーキテクチャ(ROA)と、共通性が高い。if や for が存在しない宣言型の言語パラダイムですね。

複数のパラダイム

パラダイムとは、基本的な考え方や発想という意味かな?

パラダイムは難しい言葉。
「視点」とか「観点」と置き換えて、考えてみたい。

異なるパラダイムというのは、異なる視点や観点を持っているということ。
あるいは、重きを置く、視点・観点が異なる、ということなんだと思う。

プログラミング言語でも、純粋に一つのパラダイムに振り切った言語は無い。
実用的な言語は、手続き型、オブジェクト指向、関数型などのパラダイムが融合(ごった煮?)しているのが実際のところですね。

ただし、その中でも、重視しているポイント、こだわっているポイントに、その言語のパラダイム、あるいは、思想が感じられる。

もっとも、言語のパラダイム(思想)と、それを使う技術者のパラダイム(発想)が、同じとは限らない。

Java なんかは、C言語の土台の上に作られたので、いまでも手続き型で、Java プログラムを設計・コーディングする人の方が多い印象。
言語のパラダイム(思想)と、その技術者の実装パラダイムのインピーダンス・ミスマッチですね。
まあ、オブジェクト指向でほんとうにやりたいなら、そもそも、Java じゃ無理、という意見もあるでしょうが。

いずれにしても、複数のパラダイム(複数の視点、観点)を経験し、理解するほど、設計能力がアップするのはまちがいない。

特定のパラダイムだけ、特定の視点・観点(つまり思い込み)だけでは、設計の発想やアイデアは広がらない。
設計(技術的な意思決定)の判断基準が、どうしても偏ってくる。

いろいろな技術者と仕事をしてみると、設計能力の高さを特に感じる人がいる。

●世の中には複数のパラダイムがあることを知っている
●どのパラダイムにも、良い点もあれば、限界やクセがあることを素直に受け入れる
●目的を達成するために、適切なパラダイムを選ぶ、組み合わせる

という感覚を持って仕事をしている人。

「異なる分野や視点の情報を集め、実践してみて、ものごとを観察し、理解する」のが楽しいと思う、知的好奇心が旺盛な人。

こういう人との仕事はほんとうに楽しい。自分の知らなかった視点・観点に生で、わかりやすく触れることができる。

こういう人は、目先では役に立たない情報まで集めている人が多い。
仕事ができる人なんで、余計な(?)情報収集やりながら、目先の納期にもちゃんと間に合わせくるところがすごい。

「別の世界に触れること」が楽しいし、また、その価値を実感してきているから、それが、仕事の基本スタイルになっているんでしょうね。

プログラミング言語の複数のパラダイムを経験・理解するには、「7つの言語 7つの世界」は、ほんとうに良い本。

筆者が宣言しているように、インストールやAPIについての説明を割愛して、「その言語に特徴的な考え方・こだわりポイント」を、簡明に記述している。もちろん、その言語のパラダイムを、うまく実感できるサンプルコードも豊富。

いわゆる「言語入門」本ではなく、「言語のパラダイムに実際に触れてみる」ことに、徹していることがすごいし、この本の価値だと思う。

で、この本を読みながら、プログラム設計能力だけでなく、アーキテクトとして設計能力をアップするためにも「異なるパラダイム」に触れてみることが、いちばんなんだろうな、と思った。

異なるパラダイム、つまり、異なる視点や観点を、複数経験して比較してみることが、アーキテクトの設計能力アップに有効なんだろうなと。

で、いくつか頭に浮かんだアーキテクトとして腕を磨くための「異なる世界の経験の仕方」を書きとめてみた。

アーキテクチャスタイルの4つの世界

まずは、4つのアーキテクチャスタイルは、ぜひ経験しておきたいところ。

ネタ元は、Hohpe/Woolf の Enterprise Integration Patterns (EIP) の2章の四つのスタイル。
(この章を書いているのは、PoEAA のマーチン・ファウラー)

●ファイル転送(データファイルのバッチ式の処理)
●データベース中心 (データベース読み書きのアプリケーション)
●リモート手続き呼び出し (同期式の手続き呼び出し)
●メッセージング (非同期、疎結合のアプリケーション連携)

特に、この本の主眼である、「メッセージング」スタイルを経験し、理解すると、アーキテクトとして別の次元にステップアップできる気がする。

自分は、ソフトウェア開発の仕事をして長いので、最初のころは、データファイルのバッチ処理式が基本方式だった。

その後、データベース中心(DOA)に目覚める(?)。
このスタイルでの設計・開発が一番長い。自分の基本パラダイム、もっとも重視する体に染みついた発想は、データベース中心。

リモート手続き呼び出しは、RESTful スタイルのリソース指向アーキテクチャ(ROA)として気に入っている。
(まあ、ROA も DOAの仲間ですから)

RPC , CORBA , WS-* など、重量級のリモート手続き呼び出しスタイルは、だいきらい。
(開発効率、実行性能や、運用時の障害などでなんどか痛い目にあって、このパラダイムにはかなり否定的)
というか、手続き指向のパラダイムそのものがしっくりこない。
PL/SQL (Procedual Language ) で、いろいろ処理手続きを書くより、テーブル設計をがんばって、SQL 一発で答えがでてスタイルが良いと思っている。

メッセージングは、最近、取り組み始めたスタイル。
これが、非常に面白い世界。

「7つの言語 7つの世界」で感じたたような、異なるパラダイムを知る、という意味で、メッセージングは、良いアーキテクトになるための必須科目だと思う。

ネットワーク上でのイベント駆動アーキテクチャ(EDA)、非同期メッセージングの並行処理は、目先で使わなくても、ぜひ経験しておきたい世界。
おそらく、クラウドコンピューティングの基本パラダイムなんだと思う。

自分は、 ActiveMQ と、 Mule ESB で、いろいろ、非同期メッセージングスタイルにチャレンジしている。
EIP 本にあるように、性能、信頼性、整合性維持、エラー処理など、課題は山ほどある。

同期が絶対条件のメソッド呼び出しで、データベースを操作するパラダイムの世界とは、まったくことなる発想や課題がそこにある。

そういう異なる発想に触れることで、バッチ処理や、データベース中心のアーキテクチャの設計にも、いろいろ、別の発想が浮かんでくるようになる。

データベースの5つの世界

データベースも、リレーショナルデータベース以外のパラダイムの技術が、いろいろ実用的になってきた感じ。

KVS, カラム指向、ドキュメント指向、グラフDB。

自分は、リレーショナル以外のパラダイムは、ほとんど知らない。

グラフデータベースには、ぜひチャレンジしてみたい。
幸い、Spring Data Graph for Neo4J なんてフレームワークもでてきたみたいなので、近いうちにぜひ。
グラフ構造(ネットワーク構造)は、業務アプリの分野でも、応用範囲が広いと思っている。
いままで無理やり、リレーショナルにマッピングしてきた情報構造をもっと自然に扱えるはず。

グラフのパラダイムに触れることで、リレーショナルの設計にも、別の発想がでてくるはず。

KVS 、カラム指向、ドキュメント指向も、それぞれアイデア(パラダイム)としては面白そう。

リレーショナルは、「行」指向のパラダイム。

複数のデータを、行にまとめることが、基本の発想。

カラム指向は、たぶん、これを90度転換した発想。同じカラムを一塊にすることを重視。
特定のカラムのデータ集計なんかは、こちらのパラダイムの方が合理的。

KVS や、ドキュメント指向も、それぞれ、ある視点を重視し、ある視点は軽視したり無視することで、成立している世界のはず。

概念だけではなく、それぞれの世界で、いろいろ実践して、感触を得ておきたいところ。

こういう異なるパラダイムのデータベース技術を、実際に使うかどうかといえば、たぶん、自分の仕事は、リレーショナルデータベース中心のまま。
技術者キャリアは、リレーショナルデータベースまでで終えるかもしれない。

でも、他のデータベースの異なるパラダイムを知ることで、きっと、リレーショナルデータベースの設計・実装のスキルをアップできるはず。

ソフトウェアシステムアーキテクチャ(SSA)の6つの視点

アーキテクトたるもの、ソフトウェアシステム全体を、見て、構想する能力が必要。

全体を見ることが簡単にできれば、だれでもアーキテクトなわけだが、なかなか、そうもいかない。

自分が、まがりなりにも、アーキテクト的な仕事をしてこれたのは、「複数の視点」を持つこと、「視点の数を増やすこと」を意識してきたからだと思っている。

優秀だが、アーキテクトになりきれない技術者もたくさん見てきた。
彼らと私に違いがあるとすれば「視点」の数、あるいは、視点へのこだわり度の配分だと思う。

例えば、次の6つの視点の関心事に、それぞれ、ある程度の知識と経験があること。
そのうえで、それぞれの視点に、バランスのとれた目配りをし、技術的な検討と意思決定を行う。

ネタ元は、ロザンスキの「システムアーキテクチャ構築の原理」

●機能
●情報
●並行性

●開発

●配置
●運用

一般的なソフトウェア技術者だと、「機能」と「開発」は、それなりに経験する機会は多い。

「並行性」「配置」「運用」は、開発チームのメンバーの経験だけでは、知らない世界になりがち。

小さなシステムだと、6つの視点(分野)をすべて経験できるが、小さい規模だと問題にならない視点も多い。

「並行性」「配置」「運用」なんて、小規模で利用者が一人、二人なんてシステムとか、データ量やトランザクション量がスカスカの開発環境だったら、たいした問題には、ならない。

アーキテクトあるいは、ソフトウェア設計者として、腕を磨くには、ある程度の規模で初めて具体化する、「並行性」「配置」「運用」の関心事や、その解決方法の知識を持ち、経験を積むことが必須。

「7つの言語 7つの世界」の教訓は、「実際の開発では使わない」でも「とりあえず試して体感しておく」レベルで異なる世界に触れるだけでも、設計能力に大きな変化をもたらす、ということ。

Io 言語を使って仕事をすることは、まずないだろうけど、Io の簡明なオブジェクト指向や、簡明さへのこだわりは、多重継承が簡単にできてしまう世界は、新鮮だったし、ほんとうに勉強になった。 自分の Java の設計に明らかに影響があった。

アーキテクトとして腕を磨くには、自分が直接担当していなくても、配置や運用の課題に取り組んで、機能視点や開発視点以外の世界に触れることが、重要だと思う。

経験・知識が、開発に偏っている技術者は、継続的配置(テスト、ビルド、配置の自動化)とか、(開発環境の)運用監視の自動化という視点で知識と経験の幅を広げるのがいいかもしれない。

ソフトウェアシステムアーキテクチャ(SSA)の4つの観点

「視点」は、ある分野に集中して、他の分野を見ないことで、問題の明確化や解決策の立案を行う手法。

「機能」を考えているときに、情報、並行性、配置や運用まで考えはじめると、わけがわからなくなる。
純粋に機能のことだけ考え、機能分割しながら、機能体系を整理していく。

「情報」を考えるときは、情報の構造の分析・設計に専念する。

このような「視点」オリエンテッド、「分割統治」と「特定関心事に集中」というスタイルは、重要だし、開発者にとっては、なじみがあるやり方。

だけど、システムのアーキテクチャを考えるには、決定的な問題がある。
部分的には合理的かもしれないが、全体として、どうか、ということ。

6つの視点ごとに、ばらばらに、関心事を整理し、解決案を考え実践しても、良いシステムにはならない。

全体を見通すことも、並行して行う必要がある。

これが「観点」。

「視点」は狭いところに絞り込んでいく手法。
「観点」は、離れたところから、俯瞰する手法。

もちろん、観点も複数持つことが大切。

4つの観点。
ネタ元は、これも、ロザンスキの「システムアーキテクチャ構築の原理」。

●性能
●信頼性
●セキュリティ
●発展性

大量の情報を、さくさくさばけて、安定して稼働しつづけ、情報漏えいや不正使用を防ぎ、機能の追加や変更に柔軟に対応できること。
それが良いシステムだし、それを実現できるアーキテクチャが大切。

「性能」という品質を達成するには、上記の6つの視点の関心事を、横断的に検討し、意思決定する必要がある。

アーキテクトとして腕を磨きたかったら、(実践ですべてを経験できなくても)、「性能」「信頼性」「セキュリティ」「発展性」のそれぞれの観点の知識の仕込みと簡単な実験と観察、体験を続けること。

とっかかりは、ロザンスキの本が良い。
それぞれの「観点」ごとの関心事とその対応案が書かれている。知識の元ネタとして、とっても便利。

実際に、体感してみるには、アプリケーションサーバーや、データベースサーバーなど、ミドルウェアの管理者マニュアルを読む。
ここには、性能、信頼性、セキュリティ、発展性の課題に対応した、さざまな機能と、その設定方法が説明されている。

それらの機能は、そのミドルウェアを利用するときに、課題になる、性能観点、信頼性観点、セキュリティ観点、発展性観点のさまざまな現場の課題への回答例なわけだ。

そして、できれば、設定を変えてみて、性能テスト(負荷テスト)、信頼性テスト(耐障害テストや復旧テスト)、セキュリティチェックテストを、自動テストツールを使って、実験してみる。

発展性は、実感してみるのは、ちょっと難しい観点かな?
機能の追加、別プラットフォームへの移植、他のシステムとの連携機能の追加などを、仮想テーマにして、現在のアーキテクチャだと、どんな限界・制限があるか、洗い出してみる、などの思考トレーニングは有効だと思う。

統合する

視点が6つ、観点が4つもあれば、結局ばらばらになりかねない。
異なる世界をばらばらに経験しただけでは、良いアーキテクトにはなれない。

全体を統合する能力を身に着けることが必須。

それが、観点を束ねるためのメタ観点ともいうべき「合目的」という観点。

個々の課題には、やまほどの設計の選択肢がでてくる。
そして、その組み合わせは無限。

その時に大切なことが、「そもそもの目的に合致しているんだっけ?」という問いかけ。

その機能は、面白いかもしれないけど、本来の目的に必要なの?
この情報とその情報は、本来の目的から考えたら、重要度がだいぶ違うのでは?
そこまで、信頼性が必要なんだっけ?
その程度の性能で、目的が達成できるの?
....

すべての技術的な検討、意思決定は、そのシステムの「本来の目的」に合致しなきゃいけない。

この「本来の目的に合致」という考え方で、自分に影響が大きかったのは、 Evans のドメイン駆動設計( Domain-Driven Design : DDD )。
ソフトウェアの本来の目的は仕事に役に立つ道具。
ドメイン駆動設計とは、「本来の目的」を、丁寧に、謙虚に、深く、理解した設計を心がける、というだと思う。

アーキテクチャも同じ。というか、アーキテクチャこそ、ドメインの概念で駆動していくべき。

アーキテクトにとって、一番の重要な能力は、この「全体としての目的合致」という発想であり、判断力だと思う。
ビジネスアプリケーションであれば、そのビジネスの目的や方向性を理解することが、アーキテクチャ設計の前提だし、基本なんだ。

「全体としての目的合致」のトレーニングは、ビジネスで、そのシステムに責任を持たなければいけない人との対話が一番。その人に理解ができる言葉で説明でき、その人の話す言葉の意味・意図がちゃんと聞き取れるようになることが大事。

6つの視点、4つの観点に、技術者としての知識と経験を持って、そのうえで、ドメインを理解して「全体としての目的合致」を目指し、ビジネスの責任者ときちんと話をする、というのは、とんでもなく高いハードルだと思う。
実際、こんなことが、現場で、完璧にできちゃう技術者なんているわけがない。(見たことがない)

ただ、そういう方向に努力はしたいし、その方向で良い成果を出せるように、腕を磨き続けたい。

そのためには、自分が今まで経験していない「別の世界」をお試しでよいから、触れてみること。
異なる視点、ものの見方、価値判断の基準の違いを、体感すること。

それが、アーキテクトの腕の磨き方なんだと思う。

目先の仕事に直結しない技術を、お試しでチャレンジするのは、現実的にはいろいろ問題があるかもしれない。
遊んでいる?

でも、発展する組織ほど「目先の利益に直結しない情報も抱え込んでおける」風土の組織、という研究があるらしい。

個人の技術的な興味というだけではなく、組織やチームのためにも、目先で直接使わない技術的な知識や経験の仕込みを地道に続けるのが、技術者のあるべき姿だと思う。

そうやって、異なる世界の視点・観点に触れて、幅を広げることが、技術者個人にとっても、その組織やチームにとっても、パワーアップになっていくんだと思う。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM