Structured Approach

会社員になってから、割とコロコロと業務が変わってたもんで、行き当たりばったりな日々にモヤモヤとしていたところ、Tumblrで良い記事に巡り合った。

こちらのブログ記事自体は2年も前のものだけど、かなり普遍的な話だと思う↓

Structured Approachができる人、できない人

どんなイベントでも、
(1)計画を立てる
(2)事前の準備をする
(3)本番を実行する
(4)終結作業をする
の4種類の作業が必要だ。だから、最初にすべきことは「計画立案」だと分かる。そして、言うまでもなく、ちゃんとしたパーティをやるためには、必ずまともな計画が必要なのだ。


スポンサーリンク


(中略)

何らかの仕事を始めるときに、まず作業の全体像を考え、計画に着手するという作業が習慣として身についているかどうかが、ここではポイントである。いきなり店を探したり、参加者を確認してみたりからはじめても、もちろん30人程度のパーティなら、なんとかなるだろう。しかし300人規模のパーティとなったら、もう、そうはいかない。その規模の仕事では、きちんとした計画を立て、やるべき作業をリストアップし、サブの幹事も頼んで共同で進めていかなければならないだろう。つまり、仕事の組立てを考えた、系統的・構造的な進め方(Structured Approach)が必要なのである。

ちなみにStructured approachの反対概念は、トライ&エラー、別名『出たとこ勝負』である。まず、何かをやってみる。その結果や反応を見て、次のアクションを考える。それを、求める結果に行き着くまで繰り返す。「計画」など信じず、自分たちの勘や実行力や「現場力」に頼る。これはこれで、一つの行き方ではある。地図のない森の中での獲物探し、に類した仕事には適しているといえよう。

(中略)

Structured Approachとは、課題解決の方法論である。とくに、対象・ゴールの全体像をつかむことに力点をおく。具体的に言うと、以下のような手順をとる:

(1) とりくむべき対象・ゴールの全体を、構成する部分部分に分解する
(2) 各部分と部分の関係(依存関係やレイヤー的関係)を理解する
(3) それぞれの部分の特性にあった道具・道筋を用意する
(4) (必要ならば)組織内で分担・分業して仕事を進める
(5) 作業全体の管制塔(コントロールセンター)をおく

記事の途中を省略しまくっちゃってごめんなさい。

このブログでは企業経営を例に挙げていてるけど、ある程度の人数で組織的に動くならこっちにアプローチを取るべきだろうなぁ。集団でトライ&エラーってかなり疲弊する。
Structured approach(系統的・構造的な進め方)ってのは、大ざっぱに言うと「全体像は見えている」ってこと。


スポンサーリンク

ソフトウェア開発にStructured Approachは不可欠

思ったんだけど、これってソフトウェア開発の考え方とも非常によく似ている。この考えが抜けていると、プログラムは書けるけどアプリケーションは作れない。
設計ができないと言い換えてもいい。小さい規模の、単純なアプリケーションなら、この考えなしでも出来たりするんだけど、少し規模を大きくしようとすると破綻してスパゲッティ化してしまう。

この感覚、非開発者の人には意外と伝わらないんだけど、ソフトウェア開発を仕事にしている人ならみんななんとなく解っている事だと思う。

プログラムは書けるけど、アプリケーションは作れない人って結構いる。これは特に、情報系の大学・大学院を卒業したばかりの新人に多い。コードの断片「スニペット」を書く訓練は積んでいるけど、アプリケーションとしてまとめる訓練が不十分だったり、書き捨てのプログラムばかり書いていて、1つのファイルに全部書くやり方を繰り返してきたような人だ。

それとは逆のパターンで、アプリケーションは作れるけど、プログラムは書けない人も会社員には結構いる。こっちは、全体の構成はできる(というかテンプレとして覚えている)けど、機能の高度化・肉付けができない人だ。コード量の割に、ほとんど空っぽのファイル数がやたら増えていたりする。枠組みは作れるけど、中身を書く訓練が少ない。

この2つの傾向はバランスの問題で、どちらかが完全に欠落するとアプリケーションにならないけど、作るもの・スケジュールによって割合は変動する。個人のスキルとしても、ちょっとした訓練で埋められるし、組織的に開発するならチーム内で上手くバランスを取れば良い。
先を急いで設計のステップを省略しちゃうプロジェクトもあるけどさ。

現実はハイブリッド

そして、ここでオイラの持論を展開すると、たぶんStructured Approachとトライ&エラーにもバランスがあるんだろうと思う。完全なStructured Approachは工場みたいなもので、似た仕事を大量にこなす、あるいはリターンの大きな仕事の際には大きな力を発揮するはずだ。だが、トライ&エラーの要素が皆無では、いずれ立ち行かなくなる。かといって、毎度トライ&エラーばかりやっていたのでは、あまりにも効率が悪い。持続しないし、なかなか規模を大きくできない。

Structured Approachとトライ&エラーは、農耕民族と狩猟民族みたいなものだろうなぁ。結局今の時代は両方必要になる。どちらかというと農耕寄りだけど。


スポンサーリンク

関連記事

Windows←切替→Mac
今夜の金曜ロードショーはヱヴァだね
偏愛マップ
共通の「思い出のコンテンツ」がない世代
無能の作り方
脳波で遊ぶゲーム 東京ゲームショウ2009
書籍『鈴木さんにも分かるネットの未来』読了
2018年の振り返り
2020年6月 振り返り
kotobankを使ってみた
皆声.jp
東日本大震災の記憶
Amazon Video Direct:自作の映像をAmazonで配信
2020年4月 振り返り
過程を晒す
Googleが求める『スマート・クリエイティブ』と言われる人材
歯を食いしばって見るべき動画
ファンの力
2020年9月 振り返り
スクラッチとマッシュアップ
自分の書いたコードは行数の3分の1ぐらいがコメントだったりする(さすがに極端かもしれない)
2019年5月 行動振り返り
選挙に「マイナス票」って無いのかな
アスペルガー症候群 WEB自己診断
Stanford Bunny
2020年11月 振り返り
2021年1月 振り返り
重いコンテンツとゆるいコンテンツ
界王拳って実は必須スキルなのかも
2019年1月~2月 振り返り
Windows Server 2008に触ってみた
自分を育てる技術
必見!就活リサーチ
東映特撮BBを不便に感じてしまう…
無料で学べる技術者向けeラーニングサービス「Webラーニングプラザ」
言葉が支配する世界
2017年 観に行った映画振り返り
書籍『自分の強みを見つけよう』読了
ゆるキャラ
機械から情報の時代へ
アメブロをしばらく放置してみた
2018年8月~9月 振り返り

コメント