欠けている思考と抽象化
欲しい人の次元でイメージするチカラで書いた「欠けている思考」で必要になるスキルはものごとを「抽象化」するスキルなんですが、思ったよりできる人が少なぁと感じています。欠けている思考に必要な抽象化するスキルは、対象の事柄から共通的なことを見つけるために利用するため、所謂、上流工程で重要なスキルになります。
なぜ重要なスキルなのに身につけているシステムエンジニアが少ないかというと、抽象化についてはあちらこちらで取り上げられていますが、抽象化するスキルが重要と取り上げられるのは、課題から業務要件やシステム要件を期待する解決策に適合するようにエッセンスを蒸留することが易しくないからです。
この抽象化するスキルは、生まれ持った先天性の性格に由来するスキルなのでしょうか。それとも後天性のなんらか学習することで身につけられる性格に分類できるスキルなのでしょうか。
対象の事柄から共通項としての抽象化のパターンを気づくことのドライバーは先天性の性格の要素が影響すると思いますが、抽象化するスキル自体は、後天性の性格、つまり、学習と訓練により後から身につけることができると思っています。
＃そうでなければ、ワタシが上流工程を経験していく中である程度の抽象化 ーアーキテクトに突っ込まれながらも設計としてOKが出るー ができていることが説明できなくなるからですが。
ワタシの場合、その抽象化するスキルはどのように身につけたかというとこんなことをしてきたような気がします。ちょっと弱気に気がしますと表現しているのはこれで大丈夫と言い切れないほどいろいろな経験が作用しているんだろうなぁと少しだけ気にしているからです。まぁ、誤差の範囲なんでしょうが。
自分だったらどう抽象化するかを書く
門前の小僧です。今担当している工程が「みんな大好き詳細設計！！」なら、インプットとして前工程の設計書があるはずです。この場合は、基本設計が前工程でインプットとなる情報です。設計書はインプットを整理し、次工程のレベルの要求レベルに合わせて詳細化、具体化を経て情報を変換する作業をします。
であれば、詳細設計のインプットの基本設計書を読むと要件定義をインプットとして基本設計書を書いているはずです。それを見ることで前工程の担当が要件から何をどう捉えてシステム機能仕様としたか読み解くことができるのです。
で、それは前の工程の担当がその人の頭で考えたことを表現したものです。なら、自分で設計しても同じ結果になるのでしょうか。それは知勝ちますよね。だって別の頭で考えるんですから。図表の整理の仕方、言葉の選択と語調など如実に表れますよ。それは表現する自分自身が一番わかっていると思うのですが。
だから、そのインプットとなる基本設計書を読み自分ならどう抽象化するかと課題を与えて実践してみましょう。
担当になって実践する
一番良いのは実践することです。これ以上身につける方法で近道で確実な方法はありません。
バックグランドを持つ
とはいえ、早々都合よく担当になったりすることはなかったりするかもしれません。また、参考にする基本設計書の出来が悪いかもしれません。いや、悪い方が勉強になるかもしれませんが。
手軽なのは技術書の中でも上流工程向けの本を「たくさん」読むことです。２−３冊では足らないです。１０冊以上読むのです。
その読んで本に書かれている内容を自分なりに解釈して、本に書いてあることは１つでも実際の仕事に適用してみることです。その際、本に書かれていることをそのままやろうとすると書かれていることと同じ状況を探そうとして同じ条件がなくてやらないとならないように気をつける必要があります。
自分なりに解釈して、と書いたのは、そこで抽象化して普段の生活でも仕事でもいいから実践してみよう、という意味合いが強いからです。そうした繰り返し経験することとそこから得られる自分中でのフィードバックするループを作り、習慣に変え、自分で経験値を詰めるエコシステムを作り上げるのです。
ライト、ついてますか―問題発見の人間学
posted with amazlet at 15.10.17
