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


スポンサーリンク

関連記事

過程を晒す
Web配信時代のコンテンツ構成
2020年10月 振り返り
犬が電柱におしっこするように、僕はセカイカメラでエアタグを貼る(初日の感想)
書籍『ピクサー流 創造するちから』読了
皆声.jp
映像ビジネスの未来
リア充っぽくなりたいです。
2020年7月 振り返り
中学3年生が制作した短編映像作品『2045』
Texturing & Modeling A Procedural ApproachをGoo...
書籍『自分の強みを見つけよう』読了
書籍『天才を殺す凡人』読了
1週間のサイクル
TOHOシネマズ新宿
ヘッドマウントディスプレイとビジュアリゼーションの未来
重いコンテンツとゆるいコンテンツ
2018年4月〜5月 振り返り
ガメラ生誕50周年
あの頃で止まった時間
2018年6月~7月 振り返り
遺伝子検査で自己分析
東映特撮BBを不便に感じてしまう…
書籍『医師のつくった「頭のよさ」テスト 認知特性から見た6つのパターン』読了
他人に水面下の苦労は見えない
猫背の巨人・ウルトラマンベリアル
to do listって結構大事だよね
キャリアの振り返り
2020年1月 振り返り
すてる英語学習本『ずるいえいご』
書籍『鈴木さんにも分かるネットの未来』読了
副業の基本と常識
分業とコミュニケーション 情報伝達網の設計
最近思ったこと
「自分が何を学んでいるか」を人に説明できない
THIS IS IT ⇔ IT IS NOT THIS!
感じたことを言語化する
トランスフォーマー/リベンジ Blue-Ray 予約開始
Google ブック検索
PowerPointによるプレゼン
書籍『具体と抽象』読了
インフラがアウトプットの質を左右する

コメント