こんにちは、Max Huber展が気になるkijimaです。

FlasherにとってActionScript以外で重要だと思った(というか伸ばしておきたい)スキルについて、感じたことを主観で徒然と書きます。


それはずばり、資料を作成するスキル。

「資料」と一言でいっても、その種類と作る目的は様々。
たとえば一番身近なところでは、Flashの開発中に紙とペンで書く自分のためのメモ。処理の流れを図に表したシーケンスやクラス図を書きながら、ああでもないこうでもないと想像しながら何度も書き直します。自分だけに分かればいい資料といったところでしょうか。

他人と共有する資料となると、いわゆる企画書や仕様書、もっと基本的なところでいうとスケジュール予定図などと種類は増えてきます。サーバー側プログラムとFlashの連携が必要な場合、プログラマーとAPI仕様書を共有しながら作業を進めたりします。

…と、ここで気づくのは、作業を進めていく中でFlasherである自分が必要に迫られて資料を作る機会というのはそんなにないんじゃないかということ。API仕様書も、プログラマー側で用意してくれるケースが多いですし。いやいや、それじゃいけない。もっとFlasherからも資料にコミットしないと。

プロジェクトのチーム内でディレクション・デザイン・プログラム・Flash実装と明確に作業分担がされている場合、ディレクターが作った画面仕様書(といってもクライアント確認用の非常にざっくりした感じ)をそのまま参考にして作業を開始してしまいがちですが、そこはFlasherからもきっちりと「ここはこうしたほうがおもしろい」「これは無理なのでこの方法で」と提示していきたいですね。


自分から資料を作るクセがないままでいると、アプリケーション的なFlashを組もうとするときに痛い目に見ます。ユーザーが操作できる箇所の多いFlashを組むときなんかの話です。

どんな操作ができて、その操作によってどんな結果が返ってくるか(そしてエラー時の例外処理も)という機能をまとめた仕様書がないと、開発がスムーズに進まないどころか後々になって何がバグで何が仕様なのかもわからない状況になってしまいます。

リリース前になって第三者に確認作業をお願いするときも、何が正しい動きで何がバグなのかを示す資料がなければ、テスター本人が判断するしかありません。


クライアント含めプロジェクトメンバー全体でこの部分を共有するための資料というのが本当に大事だなと最近改めて強く思いました。

と同時に、機能を一番把握しつつ仕様上の危ない箇所に対しての判断や懸念点の洗い出しが細かくできるのは、やはり実装する本人であるFlasherではないかとも感じたわけです。そのへんを把握しているプロジェクトマネージャーがいる場合にしても。


…などといろいろ考えていくと、やっぱりFlasherもガシガシ資料作るべき。
案件引き継ぎのときや複数人開発にシフトする場合もスムーズに移行できますしね。


総じて、デキる人は資料を作るのがうまい。そして速い。
AS書くのが早くても意外とこの部分に時間がかかってしまったら元も子もないので、資料はさくっと作れるようになりたいですね。

資料といえばエクセル。
最後に、弊社プログラマーチームの運営している「tech.kayac.com」でエクセルの使い方について書かれていたのでリンクしておきます。

エクセルの条件付き書式を使ってみよう


HTML5飯