設計力のお話 応用編１「要件に合わせ考えて行動しよう」
設計力を身につけるナレッジ：応用
本ナレッジはプロを目指す方向けにしっかりと理解して頂きたい内容をまとめたナレッジです。
現役で活躍しているプログラマーであって設計力の不足が問題になることがあります。
しっかりとした設計力とプログラミング力を持ち合わせていればとても強力な武器・アピールポイントとなります。
応用編では実務業務に対して臨機応変に動けるようになれる情報を記載していきます。
プロジェクト規模・予算・スケジュール・要望に合わせる
設計力につながる基本のお話としてナレッジを作成しました。
設計力につながる基本のお話（設計１：データの流れ）
設計力につながる基本のお話（設計２：考えをまとめよう）
設計力につながる基本のお話（設計３：仕様と処理の流れを考えよう）
設計力につながる基本のお話（設計４：構成図・クラス図で構想をまとめよう）
これらのナレッジは理想のお話です。
超大規模プロジェクトではほぼすべて行われる・作成される資料について説明しました。
ですが、資料作成のために割く時間というのはかなり大きい負担となります。
設計に便利な資料をすべて作る必要はありません！
と書きますのは、受注した案件の内容次第で求められるものが異なるからです。
案件対応の中で依頼内容に応じて必要な資料は用意するべきではあります。
ですが、求められていないものや案件の規模から必要ないと判断されるものは時間をかけて作る必要はないということです。
引継ぎ資料の設計図として仕様書やフロー図などどういった資料が必要であるかは案件ごとにしっかり確認しましょう。
資料の作成時間としてプログラミング作業以外にも時間がかかりますので、そういった人件費もしっかり見積として考えられるようになると設計力がある人として判断を頂けるのではと思います。
設計時の想像力はとても重要
案件規模によりますが・・・
後から機能拡張したいとか方針を変えたいなんてのはほぼ１００％あります。
原因として良くあるのは依頼者と利用者の意見の相違があるからです。
そんな要望が来た時に「開発していたプログラムでは何ともできず、作り直し・・・」なんてことになったら大変ですしモチベーションも下がります。
開発を進める際にはどういった人が使うものであるかが重要です。
業務改善系の案件であれば特に現場のスタッフの意見が含まれているか確認しましょう。
UIの基本として・・・
- 直観的である
- 操作の回数を少なく、得られる結果は大きく
- 操作ミスが発生しにくい（削除前の最終確認など）
- 待たされていると感じにくい（処理効率の良さ、待ち時間に他の同時作業が行える）
- 動作していることを明確に（処理待ちでも画面は更新する、フリーズさせない）
- 操作エラーや警告は具体的に表記
といった要素はしっかりと実装して使いにくいと思われないようにしましょう。
言語・エンジン・フレームワークは案件内容に応じて考える
案件の依頼を受ける時点でプログラミング言語やエンジンやフレームワーク指定されていることが多いです。
人気・流行な言語・エンジン・フレームワークには使われる理由がありますが受ける案件に合致しているかは別のお話です。
もし新規開発の案件であれば今一度、指定されている環境が目的・用途に見合っているかを見極め提案できるようなりましょう。
特に主流なプログラミング言語は時代によって変わります。
変わらず続くものあれば廃れていくものもあります。
採用する理由（メリット・デメリット）を述べられ引継ぎがしやすい環境を選ぶようにしましょう。
特に小規模で少人数で素早く開発したいという案件はフレームワークがメインになります。
自分が使えても他者がフレームワークを使いこなせるようになるのも学習が必要で簡単なことではありません。
チームワーク重視な案件では引継ぎ時のフレームワーク学習コストを抑えるために使わないという選択も実際にあります。
半永久的に一人・少人数（知っている人だけ）で開発・保守し続けられるできる案件は存在しません。
案件によっては規模を大きくなることでメンバーが後から増えたり、自身の体調や家族事情などで案件から離れたりすることで引継ぎが必要になる場面があります。
その場合に引継ぎにトラブルや戸惑うようなことがないようにしておく必要があります。
特に引継ぎした後継者が開発・保守が出来ないプログラムを納品したとすれば次の依頼へつながる可能性は減るでしょう。
現在はIT技術者の人材不足で案件はたくさんありますので仕事の受注に困ることはないかもしれません。
培った信頼は次へつながりますが、品質の悪さが後から判明したときの信頼の失い具合は計り知れないのでしっかりと考えましょう。
設計しながらプログラミングはとても危険
とくに経験が浅いと・・・設計しながらプログラミングをすると自分では手に負えないほどに複雑なソースコード（スパゲッティーコード）を生み出してしまう危険性があります。
大体の原因は全体を把握していない状態で小さな機能をどんどんつなぎ合わせて作ってしまうことが多いためです。
ソースコードの行数やファイルサイズが膨大になっていたり、１つの関数の行数がパソコンのディスプレイの上下のエリアをはみ出たら危険信号です。
学習や課題などで多機能・小規模プログラムを作ることになりましたらまずはプログラミングをすぐに始めず一呼吸おいて必要なこと・作業として行うことを洗い出しから始めましょう。
次に、私のナレッジにて紹介しております設計資料を参考に分類ごとに整理してからプログラミングを進めましょう。
プログラミングを進める際の書き方に関しても設計を意識した便利な書き方がありますがこちらでは割愛致します。
ナレッジで紹介しております各資料の作り方は大まかな概要のみまでとしています。
しっかりと学びたい方はご相談、プラン契約を頂けましたらより詳しく説明させて頂きます。
