今日は珍しく仕事の話をします。
IT業界5年目、iOSエンジニア3年目ぐらいでしょうか、ようやく設計業務というのをやりました。
ちょっと手伝いをすることはありましたが、２ヶ月ほど設計業務に携わったのは初めてです。
業界としては不可欠な業務ですので、現場に入る時の面談や、転職時の面接にてこの経験のことは絶対聞かれます。覚えているうちに記録してみます。
・設計業務とは？
実装についての細かい部分を決める、設計書を作る業務です。
ウォーターフォールモデルで説明します。ウォーターフォールモデルとは「ゆっくり確実にやる方式」と思ってください。
このモデルでは大きく４つの要素があります。
・要件定義
・設計
・実装
・テスト
「要件定義」にてやりたい機能を整理し、「設計」にて具体的な作り方を決め、「実装」にて作り、「テスト」にて実装したものが正しく動くか確認しています。
・実際の設計者の動きは？
自分の職場の話をします。方法は状況に応じて様々ですので、一つの例にすぎません。
設計の前工程である要件定義では、依頼者と製造者が協議をしながら仕様を決めていきます。この決まった仕様を元に、まずデザインを依頼します。
出来上がったデザインを元に、設計者が具体的な実装を設計書に落とし込みます。
デザインにはボタンや画像、テキストなどの要素があります。この要素一つ一つに吹き出しで名前を命名します。「戻るボタン」とか「場所説明テキスト」なんて具合です。
そして「戻るボタン」がどんな機能を持っているのか、表を使って表現します。
例えば「ボタン」であるので押下が出来ること、戻るボタンの画像はサーバーから受信したものを使うこと、テキストであればどんな文言が表示されるか、編集が可能か、などを書き出します。
デザイナーさんは実装方法を感知しないため、その実装方法を決める必要があります。これが設計者の仕事です。
要件定義で決まったことを資料化したものとデザインされた画像を比較しながら
「ここにはユーザーの名前を表示するから、アプリ内に保存されているユーザー情報のUsernameを使えば良いな」
「ここには最新の運転状況が必要だから、サーバーから取得した運転ステータスを表示させればいいな」
といって決めていきます。判断がつかない場合やデザインの実現が難しい場合は、要件定義をした人に質問したり、デザイナーに修正依頼をしたりします。
ちゃんと資料が整っていれば難しいことはありません。実装でありがちな想定外の不具合なども少ないので、スケジュールも組みやすいかと思います。
キャリアの観点で言うと、実装時に何が必要かを考えなければならないので少しは実装経験があったほうが良いでしょう。ベテランである必要はないと思います。
・気を付けるべきことは？
この資料で実装者が実装できるか？という視点で考えることです。
情報が不足していたら、実装者はいちいち質問しなければならず時間がかかってしまいます。
情報が過剰であったら、読みにくくて効率が落ちたり、見落としのミスを生んだりします。足りないよりは多いほうがいいですけどね。
この方法だとデザイナーが色や文字を作成してくれているので、色や文字の情報は省略しても良いかもしれません。そのあたりは工夫しながらやりましょう。
・感想
面白くないが苦ではなく、業務もスピーディーに進められたと思うので、向いているかもしれないと思いました。
