07

05

アーキテクトとは

2011.07.05(22:08)

自分が読んでいるメーリングリストに投稿があって、それに対して回答を書いてみました。あまりに長くなってしまったので、自分のブログに書いて、そのURLをメーリングリストに投稿しようと考えました。メーリングリストに投稿された方の許可がいただけたので公開します。

> 暑いですので、15%節電モードのスーパークールビズで投稿させてい
> ただきます(意味不明)。

暑いですねえ。ただただ暑いですねえ。暑いと聞いただけで思考一旦停止してしまいます。

> 今年の大テーマ(まだ詳細化していないのを大テーマと言って誤魔
> 化している?)は、「アーキテクト」です。
>
> テーマ選定の背景は置いておいて(って説明不足!)、アーキテクト
> をネタにして、委員の間でディスカッションしています。
> それをこちらにも飛び火、じゃなくて、コメントをいただければと思
> い、投稿させていただきました。
>
> お聞きしたいこと(・・・ってこれじゃ、警察の取調べ!)
> (1) アーキテクトとは?その役割は? ITSS のアレでいいのか?

10年使えるアーキテクチャを作れる人じゃなくって、10年使えるアーキテクチャを作り続けるチーム作りができる人。

> (2) 組込み系アーキテクトとは?他と違うのか?
>   メカ・エレキを除いたソフトアーキは存在するのか?

システム設計全体、ソフト部分だけ、パッケージだけ、タスクだけ、いろいろな単位で考えることができるでしょうけれど、どのレベルも相似形な気がします。できる人はどのレベルでも考えられるし、考えられない人はどのレベルでも難しい。10000行のパッケージでできない人は、50万行のアーキテクチャは作れないし、500万行はとても無理。システム設計への提言も難しい。

まず10000行のパッケージでやってみましょう。きっとできます。

> (3) アーキテクトはプロジェクトのどこからどこまで関係するのか?
> 責任はどこまで持つのか?
>   コンサルタントなのか?それとも最後まで責任を持つのか?

アーキテクチャ考える人と製品リリースを最後までデバッグする人と別組織にできるほど大きな会社じゃないので全部責任を持ちます。

> (4) アーキテクトの成果物は?具体的には何?

レビューシートみたいなものかな。レビューするときにチェックすることとか、レビューの進め方をまとめたもの。それとレビュー途中のアーキテクチャ資料。

結局、できちゃったいいアーキテクチャをいくら残してもいくら説明しても役にたたない。いいアーキテクチャを作る途中が大事でそこを残すのが成果物。どんな場面でどう判断してどういう順番でモデルが変化し最終的にどうしてこのアーキテクチャが選ばれたのかのほうがずっと大切。

> (5) アーキテクチャとは?

1人のひとが作ったモジュールだけきれいにできていて、それにつながっている残りはぐちゃぐちゃ、というのはだめ。全員のプログラムがきれいに書けるように、その隙間にあるしくみがアーキテクチャ。

それに加えて、現実のどろどろした、矛盾した要求、矛盾した非機能要件まで解決できて、アーキテクチャ。きれいごとだけで済まないのが、アーキテクチャ。そもそも2人以上のお客様に買っていだだくんだから。

> (6) アーキテクチャの維持管理はアーキテクトの仕事?

実際問題、アーキテクチャは作ることよりも、壊れるのを防ぐほうがはるかに難しい。

なぜか、「できちゃう」と、レビューやらなくなるチームが多いです。

最近はDSMとかいろいろな計測で崩れるのを検出することができるようになってきたけど、やっぱり難しい要求が来たときに、アプリだけで対応するか、アーキテクチャとアプリの両方で解決するかは相談してもらいたいな。

> (7) アーキテクトは会社の役職としてあるのか?報酬は?

ノーコメント。

> (8) 専任仕事としてやれるのか?兼業農家なのか?

完全兼業農家です。アプリを作れてテストまで書けるアーキテクトじゃなきゃアーキテクチャ作れない派です。

> (9) アーキテクトは個人なのか?チームなのか?

個人はありえない。同じモデルをいろいろな見方で別々にレビューしてくれるメンバーがいてくれて成立するもの。

私はプロダクトライン開発という一方向の見方で見ることができるだけ。なあんにもわかっちゃいません。だからあなたがいてくれないと困るんです。

> (10) アーキテクトの育成は?そもそも育成できるのか?

1にレビュー、2にレビュー。3、4がなくて、5にレビュー。たとえば、他のメンバーが作ったモデルのいいところをきちんとほめてあげることができればアーキテクトとして一人前。

> (11) アーキテクトが学ぶ本は?分野は?具体的には?

去年はブルース・ダグラスのリアルタイムUMLワークショップがよかったです。状態マシン設計についてここまで深く考えさせてくれた本はなかったです。今年だとDDD本がよかったです。UMLではかえってわかりにくくなることもあることに気づきました。

アーキテクト向けにいろいろいい本あります。でも本も読むけどソースコードも読んでほしいな。いろいろなオープンソースを各バージョンごとに読んだりすると、当初思ったとおりにゆかなくてアーキテクチャを試行錯誤した歴史がわかったり。やっぱり現実のある程度複雑な要求に応えている大規模クラスライブラリとか読んだほうがおすすめ。組込みならRTOSのソースコードとかもおすすめ。

> (12) アーキテクトはプロダクトマネージャ(または企画)の夢を見るか?

できるチームはほんとうによくできる。こんなに少ない人数でこんなにたくさんの機種を生み出せるなんて!

そういうチームは意志決定が早い。プロダクトマネージャの判断を待ったりしない。というかプロダクトマネージャが一緒にアーキテクチャやアプリを作っていたりする。

> (13) アーキテクトにプロジェクトマネジメントは・・・

一度にひとつしか考えられないので私には無理。

> (14) テストアーキテクトは?通常のアーキテクトと別に必要?

いろいろな見方でやることが大切という意味では、これまで通り、別にも必要。

自分が設計したものは自分でテストしなければ設計部内品質保証ができないので、やはり設計者自身アーキテクチャ自身が、同じクラス図にテスト用クラスも足して、さまざまな製品や環境でテストを繰り返せるような設計ができなきゃ。

継続的インテグレーションは設計部のお友達。

> (15) テストアーキテクチャは共通?プロダクト別?分野別?

継承を使ってもいいけど機種毎に派生クラスを作っていてはだめ、というのはテストクラスにもいえるので、そのレベルの設計努力はテスト設計でもすること。

でも、製品の場合はできるだけ共通部を再利用したいけれど、テストの場合それを最優先にするのはちょっと難しいかな。いいんです重複していても。モデル駆動にならず手作りが残っていても。どこまでもそっくりなシミュレータを現実の時間内に作るのは無理。

> (20) アーキテクトのスペルは?

アーキテクチャって使ってもらってなんぼ。たくさんの製品に使われてなんぼのもの。お客様はアーキテクチャの善し悪しで買ってくれたりはしない。アプリがよくなきゃね。アプリを作りやすくして、アプリをさらによくするための工数を生み出すのがアーキテクトの仕事。

お願いです。ほんのちょっとでいいので手伝っていただけないでしょうか。毎日が平身低頭。

> 皆様のご意見を末永くお待ちしております。
>
> # 15%水増しして書いていますので、実際の JEITA の委員会は真面目です。きっと。

回答も15%背伸びして書いていますw。

コメント

やはりドメイン別に考えるべきでせうか?

五味です。

毎々、お世話になっております。
今日も関東南部は暑いです。
ガリガリ君が定食に出てこないのは間違っていると思うくらい暑いです。

私の質問に回答をありがとうございました。
これに対して、コメントを書くやはり膨大な量になりますので、別方面のコメントを書かさせてください。

というよりも、最初の抽象的な質問に対して、具体的な内容を含んだ回答をいただきましたので、ここで、アーキテクトの対象領域を想定しておかないと具体的な話になればなるほどずれていくかと思いました。

例えば、新規開発で今後10年間使われるシステムのアーキテクチャと、過去営々と作ってきた製品のたぶんつぎはぎだらけになっているアーキテクチャでは、具体的な話になってくると違ってくるかと思います。
他にもその要因としては、開発規模であったり、製品分野であったりすると思います。

と書こうとしていましたが、昼休みも終わりに近づいてきましたので、また後日改めて、書かせていただきます。

どうもありがとうございました。
また、このブログをお読みの方で興味を持たれた方は、気楽にコメントをお願いします。・・・・て人様のブログで勝手なことを!

コメント

Re: やはりドメイン別に考えるべきでせうか?

> ここで、アーキテクトの対象領域を想定しておかないと

そうですね。アーキテクトが10人いれば、対象領域は10あるでしょうからね。

私のイメージしたアーキテクトが対象としているのは、

ソフトリアルタイム系の組込みシステムで、
大規模ソースコード(数十万行~数百万行)で、
多人数開発(数十人)で、
長年にわたる派生機種開発で使われていて、
複数の機種ラインナップを並行して開発している
量産製品向けの
単一アーキテクチャ
です。

コメントの投稿

非公開コメント

プロフィール

島敏博

Shima Toshihiro 島敏博
信州アルプスハイランド在住。HaskellとElixirが好き。組み込みソフトウェアアーキテクト、C++プログラマ、山歩き、美術館巡り、和食食べ歩き、日本赤十字社救急法指導員、インデックス投資、クラシック音楽、SESSAME会員、状態マシン設計、モデル駆動開発、ソフトウェアプロダクトライン、Rubyist、実践ビジネス英語

■ ツイッター
http://twitter.com/saltheads
■ Facebook
http://www.facebook.com/saltheads
■ Qiita
http://qiita.com/saltheads

印刷する場合は、ブラウザの印刷メニューではなく、このページの上から3cmくらいの青いところにある、「印刷」を押してみてください。少しうまく印刷できます。まだ完全ではないのですが、これで勘弁してください。


カテゴリ
最新記事
月別アーカイブ
最新コメント
検索フォーム
リンク
sessame
RSSリンクの表示