Structured Approach

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

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

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

どんなイベントでも、
(1)計画を立てる
(2)事前の準備をする
(3)本番を実行する
(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とトライ＆エラーは、農耕民族と狩猟民族みたいなものだろうなぁ。結局今の時代は両方必要になる。どちらかというと農耕寄りだけど。