2月
2010
IT CIRCUS 2010 IN OSAKA に参加してきた
2月17日に大阪で行われた「IT CIRCUS 2010 IN OSAKA」に参加してきた。
講演の詳細は上記リンク先から参照いただくとして、お話を伺って考えたことや感じたことを、少々長くなるが書き留める。
今回のセミナーを通じて何より一番強く感じたのは「なんか、ウェブ制作現場の潮流って、ソフトウェア開発の歴史を辿っているような気がする」ということ。せっかくなので、ソフトウェア開発現場が歩んできた道をウェブ制作現場へ照らし合わせてみたうえで、「今後ウェブデザイナーとして求められるもの」を考えてみたい。
ウェブ制作の歴史は、いわゆる「ウェブ制作会社」が会社として成り立つようになってから、まーせーぜー10年程度だ。
少し前までは、制作担当は、なんでも「ウェブデザイナー」と呼ばれる職種にひとくくりにされ、分業のスタイルも整ってはいなかったが、最近ようやく、コーダーやディレクターなどと呼ばれる、いわゆるシステム開発における、プログラマーやプロジェクトマネージャーに相当する職種が浸透してきている。
実際の制作スタイルを見てみると、森川さんの発表内容にもあったとおりウェブの「標準化」と呼ばれる統一された仕様が求められるようになって、5年ほどたとうか。つまり、以前までは「一人のスーパープレイヤー」さえ居れば金になる時代（「一発芸」と表現されていたもの）だった。そういったスタイルが、徐々に苦しくなってくるのは、制作に必要な要素が徐々に体系化されてきたことでもある。
つまり、仕様が標準化されれば、分業ができる。分業ができれば、個々が専門化する。個々が専門化してくると、それぞれ職種に名前が付く（私達はおそらくイマココ）。という流れの中にあることを押さえておきたい。
んで、この流れにのり、専門家の技量水準評価のために、品質評価リストや公的資格が生まれたりする。そうなれば、顧客の要求も「○○を満たせる人材」「○○の条件をクリアするサイト」といったスキルレベルを明確に要求してくるようになる（スキル・品質の数値化、定量化）。
さらに、分業化が進むと、プロセス（いわゆる仕事の進め方）を標準化しよう、統一しようという話題が持ち上がる。一人のスーパープレイヤーの仕事では発生しえなかった、コミュニケーション・ロスが、分業では当然ボトルネックとなってくる。プロセスが標準化されてくると、それぞれ個々のタスクでの「成果物」もおのずと決まってくる。そうして、ひとまずは、案件の計画から制作完了・リリースまでの一連のタスクリストが、制作者間で共通認識として出来上がる。このあたりのプロセス体系は、PMBOKあたりが標準になっていてウェブディレクションに取り入れているところも多い。
ただし、従来のシステム開発で使われるウォーターフォール・モデルではない。既に「市場の変化のスピードの早さ」をまさにフロントエンドで感じざるをえないウェブ制作においては、PDCAサイクルを工程に組み込んだ、スパイラル・モデルとして制作工程ができつつある。（ISO13407のHCDプロセスもそう。）
別に取り立てて特別に言うことではないし、知っている人からすれば「当たり前」のことなのだろうが、近年のソフトウェア開発の歴史は「市場の変化のスピードの早さ」との闘いである、と言っても過言じゃない。ウェブ制作現場においても、きっと同じ道を歩むことになる。
「市場の変化のスピードの早さ」とは、即ち「仕様変更」の回数が増え頻繁になることである。顧客自身が市場変化を捉えきれず、工程途中で仕様が変わることがどうしても増えてくる。「前工程において、合意を得たものだ」と強く断れば良い？
ふふふ、そうも言えないケースだってあるんだから。もう、何なら「あらゆるものは、フィックスなんてしない」という考えでも良いくらいである。だってそのためのサイクルプロセスなのだから。
では、具体的にウェブ制作として、この静かに忍び寄る避けられない脅威に対してどう身を守るべきか。
他にもあるかも知れないが、私が思うのは「制作物の構造化」である。テンプレート、コンポーネント、ライブラリ、フレームワーク．．．要は、呼び方はナンだって構わない。つまり、再利用できるものとそうでないものを可能な限り切り分けて、「変更が発生した場合の作業量を最小にする」ことに留意し、またその努力をすべきである、ということである。
実は、プログラム言語において、過去の偉人達が作り上げてきた、関数、構造体、オブジェクト指向などの概念は全て、作ったものを「再利用」しやすく「変更発生時の影響を最小限に食い止める（変更作業量を最小にする）」ためのものである。
同じ話で、スクリプト言語にOOPが必要なのはもちろん、グラフィックソフトでレイヤーが分かれているのも思想は同じ、てかそもそも、HTMLとCSSが分離して策定されたのも、想定される変更頻度が異なる「テキスト」と「スタイル」を可能な限り分離することで、修正時のソースレベルにおけるインパクトを小さくするためのものである。
積極的にフレームワークやライブラリなどを利用するとともに、何らかの設計の際に、少しこんなことを意識することをお勧めしたい。
「今、私が作っているモノは、絶対に後になって変わる。もしくは（私でない）誰かが変える。その時のために何をすべきか。」という意識がカギである。
Related posts: