構造設計
詰まっているところを図一枚で説明するのが構造設計です。どこが詰まりの元かが見えはじめると、人は誰かを責めるのをやめ、条件を話し合うようになります。
STABILIZER · 設計型
Systems Architect システム設計者
Systems Architectは複数の部分がどう噛み合うか、全体の枠組みを設計する人。
解くべき問題は十あるのに、その十が互いにどう絡んでいるかを描ける人がいません。システム設計者は、こういうとき問題を一つずつ片づけません。何が何に左右されているかを、まず紙に描きます。
周りではこのタイプを、抽象的だ、遠くを見すぎると言います。けれどシステム設計者がつくるのは、実際に使える構造です。個別の対応を繰り返すと同じ問題がまた起きると知っているので、構造から整えます。
人が替わっても仕事が同じ水準で保たれるなら、システム設計者が構造をうまくつくったということです。仕事が急ぐと、その構造にこだわり、現場の人の気持ちや現場の速さを気にかけられなくなります。システム設計者は成長しても設計を減らしません。よい構造を、実際に使いやすい形に直す仕事を加えるだけです。
核心
中心となる特性
システム設計者が扱う単位は、一つの出来事ではなく、出来事が繰り返される仕組みです。事故が起きると、誰がミスしたかより、どこでそのミスが起きるようになっているかを見ます。
要素どうしの関係を整理するのが、このタイプの判断の仕方です。そのため同じ報告書を読んでも、出来事ではなく、その出来事を生んだ条件を覚えています。
現場を知っているかどうかでシステム設計者を評価すると、要点を見落とします。見るべきなのは、システム設計者が設計することで、いつ同じ問題の繰り返しを防ぎ、いつ現実から離れたものをつくるかです。
強み
強み
関係の把握・問題のモデル化
扱うものが多いほど、関係の把握と問題のモデル化の値打ちは上がります。互いがどうつながっているかを整理しておけば、直す順序は改めて悩まなくても決まります。
長期安定・標準化
組織が大きくなるとき、長期安定と標準化が必要になります。人によって違っていたやり方を一つにそろえておけば、規模が大きくなっても品質が保たれます。
作動の流れ
どのように働くか
多くの要素を一つの構造に整理するのが、システム設計者の仕事です。次の四つの段階は、このタイプが複雑な問題を解きほぐし、長く保たれる仕組みをつくるまでの順序です。
散らばった要素のあいだの関係を見ます。
仕事が詰まるところを、構造で説明します。
繰り返せる基準と流れを設計します。
システムが長く保たれるよう単純化します。
偏りやすいパターン
調整すべきポイント
現場感覚、易しい説明、情緒への配慮が足りないシステム設計者は、よい構造をつくったのに誰も使わないという状況を経験します。構造が間違っているからではなく、使う人が理解できなかったからです。
現実を知らないから構造から立てるのではありません。目先の対応ばかり繰り返して、もっと大きく失敗したことがあるシステム設計者は、追い込まれるほど構造から立てようとします。その間に、現場の速さを見られなくなります。
設計したものを、実際に使う人に一度使ってもらえば、どこが難しいかがすぐに見えます。原則を捨てなくてもできる調整です。
関係 · 仕事 · 成長
関係と仕事での成長の方向
関係で
説明が抽象的に聞こえたら、例を一つ挙げてほしいと頼めば十分です。システム設計者は自分の説明を具体的な事例に置き換えた瞬間、すぐ伝わる話し方になります。
仕事で
繰り返す問題を断ち切りたいとき、人はシステム設計者を頼ります。設計に時間がかかる間に現場が先に疲れるので、今使える部分から出してもらう必要があります。
成長の方向
単純になることと、使いやすくなることは違います。システム設計者の成長は使いやすくなる方向にあり、よい構造を実際の人が使える形に直しながら成長します。
一緒に働くとき
完成した設計を待つと時間がかかります。今どこまでできたかを尋ねれば、このタイプは使える部分から切り分けて渡してくれます。
公開参考例
このタイプに近い人物
以下の人物は「この人がSystems Architectである」と診断するものではありません。公開されている役割や代表的な場面から、近い作動方式を理解するための参考例です。
イギリス
エイダ・ラブレスイギリスの数学者。
初期の計算機のアルゴリズムの構想機械の処理できる手順を想像し、整理した仕事は、抽象的な構造を設計する感覚そのものです。
イギリス
アラン・チューリングイギリスの数学者、コンピュータ科学の基土壌を築いた人物。
計算機械の理論 · 暗号解読チューリングは、どんな計算も単純な規則の並びとして実行できることを理論で証明し、まだ存在しなかったコンピュータの設計の基盤をつくりました。戦時中は暗号解読の機械の設計に加わり、その理論が実際に動くことを示しました。
アメリカ
グレース・ホッパーアメリカの計算機科学者、海軍の士官。
コンパイラとプログラミング言語の発展複雑な計算を、人の扱いやすい構造へ変えようとした仕事は、システム設計者の設計の感覚に近いものです。
アメリカ
W・エドワーズ・デミングアメリカの統計学者、品質管理の専門家。
品質管理の体系の広がり成果を個人の意志より仕組みの品質で説明した取り組みは、このタイプの構造的な思考をよく見せます。
イギリス
ティム・バーナーズ＝リーイギリスの計算機科学者。
ワールド・ワイド・ウェブの提案情報をつなぎ、たどり着くための共通の構造をつくった事例は、システム設計の公の参考点です。
同じグループの他のアーキタイプ
このタイプの相性
よくある質問
システム設計者とはどんな人ですか?
システム設計者は、問題を一つずつ片づけず、何が何に左右されているかを先に描く人です。設計という言葉は、技術の分野の外でも通じます。事故が起きると、誰がミスしたかより、どこでそのミスが起きるようになっているかを見ます。Beyond Personaは、こうした見方の習慣と、設計した構造を使いやすくする力を、36の特性で合わせて確かめます。
自分はシステム設計者でしょうか? どうすれば確かめられますか?
整理が得意というだけで、この原型になるわけではありません。やることをきれいに分けることと、同じ問題がまた起きないように条件を変えることは違います。無料診断の76問で最も近いタイプを確かめられ、288問の全体分析では、29の原型のどれにどれくらい近いかを順位で確かめられます。
システム設計者と職人はどう違いますか?
どちらもいいかげんにはつくりません。違うのは直す対象です。職人は、今手元にあるものを直します。システム設計者は、それをつくる順序と条件を直します。だから職人がいなければ今回の成果物が粗くなり、システム設計者がいなければ同じ問題が次にも起きます。
システム設計者はどんな反復に陥りやすいですか?
構造を描き終えるまで安心できず、まだ来ていない問題を先回りして心配します。見るものがいくつにも分かれていて一つにとどまりにくく、説明するより自分でやるほうが早いので、仕事を一人で抱え込みます。下の一覧の順序は計算で決めました。この原型の特性と、各反復を起こす特性が重なる度合いの大きいものから並べています。
システム設計者は一生変わらないのですか?
構造から見る習慣は変わりません。変わるのは、設計したものを実際に使う人に一度使ってもらうかどうかです。どこが難しいかを確かめておけば、同じ設計でも人が実際に使うようになります。原型を知ってから変わる人が多いのも、そのためです。
この原型とよく一緒に現れる反復
測定で見る軸が重なる項目です。人が選んだのではなく、測定ルールから計算しています。
自分の結果がシステム設計者にどれくらい近いか、確認してみてください。