効率化の意味は

連載第8回目となる今回は，「⁠コーディング」をテーマにお話していきたいと思います。特に今回は，フルフラッシュサイトの制作におけるコーディングの効率化に焦点を当ててお話ししていきます。

当然のことながらクライアントワークには納期がありますから，企画，デザイン，コーディングといったWebサイト制作上のどの工程にも時間的な制約が存在します。ただ，そのなかでもフルフラッシュサイト制作におけるコーディングの時間的制約については特に注意を払う必要があると，著者は考えています。

フルフラッシュサイトの制作ではFlashの機能向上に伴い，ときに汎用アプリケーションに迫るほどの複雑かつ大規模なプログラミングが必要になる場合が出てきました。しかし汎用アプリケーションの開発には数ヶ月，場合によっては一年以上の期間が設けられるのに対し，Webサイト制作では早ければ1週間でコーディングを要求されるような状況も珍しくありません。機能は高度になる一方でも納期は変わらないのですから，コーディングはさらに厳しいスケジュールで作業しなければならない局面が増えてきたのではないでしょうか。そのような限られた状況でも企画の意図やクライアントの要望を確実に捉えたWebサイトを実現するために，コーディングの効率化は欠かせない要素になると考えています。

本格的プログラムには設計がつきもの

フルフラッシュサイトとhtmlベースのWebサイトでは，ひと口にコーディングと言っても作業を進めるうえで基本となる考え方に大きな違いがあると，著者は考えています。htmlのようなマークアップ言語を用いたコーディングでは，基本的にはサイトマップに従ってコードを記述していくことで，概ね目に見える形でページが姿を現していきます。

しかし「Action Script（以下，AS⁠）⁠」を用いたFlashのコーディングでは，より"プログラミング然"としたコードの記述が行われます。サイトによってはページの概念が希薄ということもあり，記述自体が複雑というだけでなく，画面上で見えるページに対して裏で動く記述がまったく別の場所に格納されていることも珍しくありません。このため，特にフルフラッシュサイトのコーディングではそれぞれの記述を機能ごとに分け，Webサイトとして成立させるために各機能の関係を把握し，整理する「設計」が非常に大切になります。

フルフラッシュサイトのコーディングを行うにあたっては，走り書き程度であっても機能ごとにWebサイト全体を俯瞰できる構成図を書き起こすことが必要だと思います。具体的にはプログラムを機能ごとに「クラス」（⁠注1）に分け，「⁠メインクラス」を起点に，「⁠ローディングクラス⁠」⁠，「⁠ナビゲーションクラス⁠」⁠，「⁠サウンドクラス」など，役割を明確化して整理する作業のことです。プログラム開発の世界では「UML（Unified Modeling Language⁠）⁠」と呼ばれるプログラム設計の統一表記法がありますが，それに近いものと言えるでしょう。

この作業は頭の中を整理するために行うものであって，必ずしも詳細な書面に残す必要はありません。ただ，現在ではJAVAをはじめとする高度なプログラミング言語に近い機能を持ってきたASです。複雑なコーディングであればあるほど，今後ますますプログラムを行うにあたって設計という考え方が，後述する効率化のためにも大切になってくるのではないかと考えています。

※1　クラス

オブジェクト指向プログラミングでデータとその手続きをまとめて定義したもの。クラスに対して具体的データを持つオブジェクトは「インスタンス」と呼ぶ。

コーディングに「ルール」や「スタイル」を

フルフラッシュサイトのコーディングを行うとき，前述のようなクラスごとに整理した設計図は結果的にどのWebサイトをコーディングしても似たような構成になるときがあります。これは特定のコーディング・ルール，またはスタイルが存在していることの裏返しでもあります。今回のテーマに繋がってきますが，それが個人のものであれチームのものであれ，コーディングに一定のルールを設けることは効率化に欠かせない要素ではないでしょうか。

たとえば，自分があるWebサイトのコーディングを行っている期間は，当該Webサイト向けに記述されたプログラムのどこに何のロジックが存在するかということは比較的容易に分かります。自身が担当しているのですから当然ですね。しかし，ひとたび納品を終えて公開したWebサイトについてはいかがでしょうか。公開して数ヶ月経過したあと，クライアントの要望で何らかの修正または変更点が発生するといったケースはしばしば存在します。そんなとき，記述者本人ですら統一した記述ルールやスタイルが存在していなければ，ちょっとした変更ひとつにも仕様を思い出すのに無駄な時間を費やしてまったり，さらにはあらぬ不具合の原因になってしまう可能性があります。

そのような状態に陥らないためにも，クラス分けのルールをはじめ，変数や関数を宣言するときの命名規則など，コーディングに関して自分なり，あるいはチームなりのルールやスタイルを明確にしておくことが効率化に向けた第一歩になると考えています。