2.共通化、部品化

◆作業の概要、目的、タイミング

作成画面やプログラム部分のうち、共通関数、テンプレート類を切り出し、早めに作成する。
  • 以降、共通関数を呼び出すだけである機能を実装できたり、テンプレートをコピーするだけで画面の枠組みが作成できたりする。
  • 同じような部分を何度も作成したりする必要がなくなるので、作業の効率化につながる。
  • 1つがきちんとできれば他も同じようにきちんとできるので、品質向上につながる。
  • どの部分を見ても同じような作り方をしていれば、メンテナンス性(保守性)向上につながる。
どんな共通関数やテンプレートなどがあるかをチーム内で情報共有し、その使い方を徹底する。
  • 一部の人しか使っていなかったり、使い方にばらつきがあると、共通化した意味がない。
各画面・各機能の製造が始まってから共通化・部品化の統一を図ったのでは、間に合わない。
その前に共通部分を切り出し、作成しておく。
  • 各箇所をそれぞれで作ってしまってから、あらためて関数呼び出しや部品の使用に置き換えるのは、かなり手間がかかる。
    また、修正漏れや修正ミスが入りやすくなり、かえって品質が落ちることもある。

◆事前に必要なもの、情報

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業 事前情報、他
・システムの内容詳細 ・技術知識(マシン、ソフト、プログラム言語)

◆具体的な作業項目、手順

  1. 部品化・共通化する箇所を洗い出し、特定する。
    • システム全体で、同じような処理が何度も出てくる箇所
    • どの画面でも同じような、共通した設定項目
    • その他
  2. それぞれの呼び出し方、使い方を決める。
    • 名前を呼び出して使う、ファイルごとコピーして使う、必要箇所だけテキストコピーして使う、など
    • 関数の場合:関数名、引数、戻り値など
  3. 実際に、作る。
    • 作っているうちに、(最初に決めた)使い方を変えたほうがいいと感じることもある。
      必要に応じて、使いやすいように変えながら作る。
  4. テストを入念に行う。
    • 自分が「使う」立場として、実際にコピーしたり呼び出したりして(仮に)使ってみる。
    • きちんと機能するどうか、確認する。
    • プログラムの場合、求められた機能が漏れなく満たされているかどうかをチェックする。
    • みんなが使い始めてから不都合が起きては、全員の作業や品質にかかわる。
  5. みんなが使える状態にする。
    • プロジェクトで決めた所定の場所に置き、メンバーに使い方を説明する。
    • 機能や使い方に不具合があれば随時報告してもらい、随時修正する。

◆成果物、最終イメージ、作業例

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他 この後の作業
・共通関数、ファイルテンプレートなど
・それらの使用ルール
・製造全般
・テスト

◆作業上のポイント、注意点

「どの部分をどう切り出すか」の判断が使いやすさのポイントとなる。
  • 切り出し方が良くなければ、逆に使いにくいものとなる。
  • ある程度の技術知識(プログラミング技術)が必要となる。
単に作るだけでなく、使い方や呼び出し方の明確化、入念なテスト、メンバーへの説明と徹底が大切となる。
  • そうしないと逆に、プロジェクト作業全体に手戻りが発生したり、混乱したりする。
  • また、作ったのに誰も使わないのでは、意味がない。
    というより、この作業自体が余計なこととなる。
プログラム言語によっては、ライブラリやフレームワークと呼ばれる基本機能のパッケージが市販やフリーなどであるので、どんなものが出回っているのかを知っておき、利用するのもよい。
  • 使い方さえ分かれば、開発効率の向上や品質の均一化につながる。

Copyright © Xincor miXell Co., Ltd. All rights reserved

results matching ""

    No results matching ""