Kさん、久しぶりにメールありがとうございました。お元気とのこと、何よりです。ご活躍中の様子が、行間からあふれていました。生産管理の現業をかかえた上に、新規システム導入プロジェクトのメンバーの一員としてアサインされたとは、たしかに大変だろうとお察ししますが、それだけKさんが周囲から期待され一目置かれていることの証左だと思います。
ところで、Kさんからメールをいただくたびに、難しい宿題を投げられたように感じるのですが、今回は格別です。『設計思想に関して』のご質問とは! なるほど、たしかに新しい基幹業務システムを考える出発点として、“その設計思想はどうあるべきか”を問うのは、とてもオーソドックスかつ当然の発想と思います。自分達が製品を設計開発するときも、成功した製品には明確な設計思想があった。だから、プロジェクトを成功させたければ、当然システムにも設計思想がなくてはならないはずではないか。--設計部門出身のKさんはそう考えられた。ですが、その「当然」がちっとも当然たりえないところに、わたし達の社会の根本問題がある訳です。 メールの文章を拝読したところ、ご質問は二点あるようです。わたしの業界の場合には、設計思想を話題にすることがあるのかどうか。そして、そもそも設計思想とは何を規定すべきものなのか、と。 まず最初の質問からお答えしますと、はい、たしかにわたしの本業=プラント・エンジニアリングの世界でも「設計思想」はあります。設計思想のことを英語でDesign Philosophyといいますが、プラントの世界では文字通り"Design Philosophy"というタイトルの文書を、基本設計の最初の段階で作ります。そして、(基本設計が固まった後に)入札が行われる場合も、それは仕様書の一部として位置づけられ、以後の詳細設計や調達など全ての作業に適用されます。ただこれは、ほぼ海外の顧客向けのプロジェクトの場合のみです。少なくとも自分の経験では、純粋に国内のお客さま相手の仕事で、設計思想が議論になったケースはありません。 では、その"Design Philosophy"とは何を規定したものなのか。じつはプラントの場合、Design Philosophyは何種類も作ります。Start-up Philosophyだとか、Maintenance Philosophyだとか、Shut-down Philosophyだとか。なんだか“思想だらけ”に見えるしょうが、事実です。こうしたPhilosophy文書は、別段格調高い文章ばかりという訳ではないのですが、プラントのライフサイクルを通して生き続けます。そしてプロジェクトの途上で設計上の論争が発生したとき、必要ならばDesign Philosophyに立ち返って、「ここにこう規定してあるじゃないですか。貴方の要求は、これに沿っていません。だから、どうしても変更せよと言うのなら、追加を払ってください」といった決着の基準になるのです。 では、どのような時に論争が起きるのか。たとえば、多重化の要求です。運転上の安全性のために、ここの機器やケーブルを多重化して冗長構成にしろ、との要望はよくあります。ですが当然、投資額は余計にかかります。運用保守の手間も増える。一括請負契約だったら利益に直接関わる問題です。このようなとき、その程度までクリティカルな部分を冗長化すべきか、Design Philosophyが規定していれば、無駄な論争で時間を失う事が避けられます。『クリティカルの度合い』を誰がどう決めるかも書いてあれば万全です。 あるいは、運転に対する反応の俊敏性と、運転の長期安定性のどちらをとるか、といった問題もよく起こります。車の設計で言えば軽量性と高速安定性みたいなものです。あるいは保守のしやすさと、コンパクト性の相反。さらに緊急シャットダウンの時に、何からどう優先して落としていくのか。危険物質や高温高圧を扱うプラントでは、この優先順位によって設計がずいぶん変わってしまいます。 つまり、設計思想(Design Philosophy)の文書とは、第一義的には、設計を決めるときに相反条件があって、あちらを立てればこちらが立たず、というトレードオフが生じる際の、判断の優先順位を決めたものである、とわたしは考えています。 もともと設計とは、目的とする『機能』をはたすべき『構造』を決める行為です。ところが、どんな製品・システム・サービスにおいても、求められる機能要件ならびに評価項目は、複数あるのが普通です。しかもそれらは、しばしば互いにトレードオフの関係にあるのです。また、空間的な形状・構造を考える際には、いろいろな選択の余地(自由度)があります。こうした、多数の自由度を持つ設計において、その方向付けをするガイドラインとなる方針、あるいはコンフリクトが発生したときに、優先順位を強く明確に決めたポリシーが、設計思想です。 いいかえるなら、設計思想とは価値観の表明に他なりません。とくに、トレードオフが生じる前に、「何を捨てるか」を決めるものなのです。価値観は自然科学や法則からは生まれません。だから思想の形で提起される必要があるのでしょう。これがKさんの第二の質問へのお答えだと思います。 トレードオフ問題は、特定の状況に付随して生じがちです。そのため、設計思想はしばしば「シナリオ」の形になります。プラントの場合だったら、Start-upとかShut-downとか、状況別に作成される訳です。では、情報システムの場合はどうか。もちろん、Start-up/Shut-down/Back-up/Archiving/Maintenanceなど運用的状況の他に、拡張やリリースアップなどもシナリオの対象でしょう。アクセス性とセキュリティの相反なども考えておく必要がありそうです。 この設計思想にまつわる誤解で、よくあるのが『設計条件』との違いです。設計条件とは、設計の境界条件あるいは環境条件を与えるものです。設置場所はどこで広さはどれくらいか、気温・湿度はどれくらいか、建物の床加重は、外部電源容量は、利用者数は、等々。これらは測定ないし想定の結果として、数字の列挙で示されるもので、「思想」ではありません。想定はある意味、思想の表現結果ですから、「想定外でした」という言葉は、“それは無いという設計思想でした”(あるいは“設計思想が無い状態でした”)を示している訳です。 ところで設計思想は、言葉で文書にしなければならないのでしょうか? わたしは必ずしもそうとは思いません。ただし、西洋人の感覚では、明確に文章に表現されて他者に伝わるものでなければ、思想とは認めないでしょうね。言葉にはならないが、リーダーやキーパーソンの間でなんとなく無言のうちに共有され、以心伝心で皆に広まっていく・・などというものを、彼らは「思想」とはよびますまい(強いて言えば、「文化」とか「習慣」と呼ぶでしょうが、これが製品毎に変わるとしたらちょっとヘンです)。まして、詳細設計段階で数十人から数百人が関わるプロジェクトの場合、以心伝心は、はなはだ頼りない伝達手段ではあります。 ある製品や仕組みやサービスに設計思想があるかどうか、外から分かるでしょうか? たぶん、ある程度は感じ取られると思います。それは、設計の「いさぎよさ」であり、あるいは「首尾一貫性」に表れるはずです。むろん、視覚的には直接見えない場合もあるでしょう(情報システムなどはその良い例です)。しかし、一貫した設計思想の元でつくられたシステムは、ユーザーから見て、構造や機能やインタフェースにGuess(推測)がききやすいはずです。 何年か前にKさんにお会いしたとき、わたしがまだHP-200LXという旧型のPDAを使い続けていることを覚えておられるでしょうか? あの製品は、明確な設計思想で作られた代表的製品だったと思います。携帯可能で、キーボードをそなえ、市販の単三乾電池で1ヶ月動く。そのかわり液晶はモノクロでバックライト無し、無線通信機能も無し。GUIも無し。それでも、わたしはあれを2台購入し、両方が壊れるまで10年以上も使い続けました。ですが、GUIをのせた後継機種は買いませんでした。設計思想に不透明さを感じたからです。 思想を持った製品は、ユーザの「好き嫌い」が強く出ることが、たぶんもう一つの特徴なのでしょう。逆に言えば、あらゆることに優等生的で八方美人な製品には、思想を感じられないのです。だから、設計思想とは、ある意味で『戦略』にも似ています。戦略とは賭けである、無駄な戦いを略すことである、と前にも書きましたが、それはつまり「何を捨てるか決める」ことだからです。 思想がなくても人は生きていけます。でも、混迷を打破して人をリードする力強さは、生まれ得ません。どうかKさんには、皆が納得のいくシステムの設計思想を作り上げていただきたいと願う次第です。
by Tomoichi_Sato
| 2012-03-26 21:48
| 考えるヒント
|
Comments(0)
|
検索
カテゴリ
全体 サプライチェーン 工場計画論 プロジェクト・マネジメント リスク・マネジメント 時間管理術 ビジネス 思考とモデリング 考えるヒント ITって、何? 書評 映画評・音楽評 English articles 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書」 「時間管理術 」(日経文庫) 「BOM/部品表入門 (図解でわかる生産の実務)」 「リスク確率に基づくプロジェクト・マネジメントの研究」 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||