構造的に物事を考える(T.O)
構築現場や保守において、トラブルだったりテスト指針を作るときに
いつも立ち止まって考えることがあるので、今回はそれを紹介したいと思う。
実はあるとき、ある２人の人と別々のタイミングで、一緒に仕事をすることになって、
"構造的に考える。ということが本当に必要なのである。"という事に気が付いた。
しかし、"三つ子の魂100まで"である。。。
咄嗟の時にはなかなか実践できないが、煮詰まっている・・・と感じるときに、
立ち返る基点となった。
さて、以前の私は以下のような状態であった。
(いまも構造的に見れていない時はあるので、発生しがちではあるが)
====================
○トラブルや問題に対してその部分だけ見ていてなかなか解決しない。
○構築時に手順ミスで誤った設定をしてしまい、修正をする。
しかし、後々になって別のミスを発見し、修正する。(無限ループ)
○テストを実施するために、抜け漏れなく充足しているのか、
資料を作っても第三者には伝わりづらい。
====================
確かに、どこの現場でもありがちな事かもしれない。
では、構造的に考えるとどうなるのか。。。は、
すぐ解決、ミスしない、伝わる。。。と単純明快である。
前置きが随分と長くなってしまったが、
構造的に考えるということを実践していくためにはどのようにすれば良いのか。
私が気をつけている点を記載していく。
====================
○全体像を把握する(登場人物を把握する) -> 俯瞰する、鳥瞰する、時間軸も入れる
○全体像の中をグループ化する ->
○全体像の中の関係性を把握する
○個を具体化していく
====================
である。なんだか、ちょっとずれているんじゃないのかな。とは思われるかもしれない。
しかし、
トラブルの時なんかは
全体像を把握して、しかるべき人に伝える。ということが重要で
全体像を把握すると言うことは、"事象・影響・原因・子因・対応策"の5大要素の内、事象と影響が判明する。
私自身、何かの製品に長けている訳ではないので、お客様・営業・SE・サポート部門に上記を伝えている。
そうすることで、全体で正しい状況を共有でき、トラブルが起きているシステムの関係性を把握する事で
調査対象を絞り込み、関係箇所を調査することで、行き当たりばったりの調査を行うことを避けることができる。
構築時のミスについても
ミスすると言う事象がどうしておきてしまったのか。と言う全体像を把握することで
意外な真因(手順書で変更パラメータが別記されておらず、分かりづらい)が判明し、手順書のフォーマット変更で
ミスを減らせることができるかもしれない。
また、資料作りの際は
全体感を提示して、グループ化、関係性の提示をすることで
当時その場に居た人だけではなく、後からプロジェクトに参加した人にも当時考えた経緯などが分かる資料となる。
テスト仕様書等の資料については、システム全体を把握し提示することで対象のスコープ範囲を明示し
それぞれのグループ、関係性をマトリックスを使って提示し、サーバ内のプロダクトについても同様に整理、具体化していくことで
漏れなく確認していくことが可能である。
なお、構造化についてあまり本などでは紹介されていないように思うが
"ロジカル・シンキング"という本の中で、[グルーピング]という部分をたまに読み返す。
https://www.amazon.co.jp/%E3%83%AD%E3%82%B8%E3%82%AB%E3%83%AB%E3%83%BB%E3%82%B7%E3%83%B3%E3%82%AD%E3%83%B3%E3%82%B0%E2%80%95%E8%AB%96%E7%90%86%E7%9A%84%E3%81%AA%E6%80%9D%E8%80%83%E3%81%A8%E6%A7%8B%E6%88%90%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB-Best-solution-%E7%85%A7%E5%B1%8B-%E8%8F%AF%E5%AD%90/dp/4492531122
最後に、、、
実作業者をやりながら、構造的に考える、、、というのは私にとってはまだまだ難しい。
個別具体的な対処を行ってしまうと、どうしてもそこだけに着目してしまい俯瞰することができずにいる。
本当だったら幽体離脱か二重人格化するなどして、自分で2役こなせればよいのだが、
いまだそのような能力は身につけられていない。
そういった時は積極的に第三者に助けてもらうか、実作業を第三者にやってもらうようにしている。
どの現場においても俯瞰している人が居る。という事は全体最適化、トラブルの早期解決としては大事だと考えている。
