機能の共通化 初心者PHPエンジニアの備忘録#4

  • このエントリーをはてなブックマークに追加

現在の現場でシステムの要件定義段階から参加させていただき、設計して、実装して、完成して、改修入って、失敗に気づいたときの話です。

前提を箇条書きでご紹介

●現場にアサインされた際、要件定義はほぼ終了していた
●DB設計は任せることができたが、詳細設計・実装は自分1人
●設計~実装までは4人月程確保されていた
●システムの概要としては、作業内容の記録と見積書のエクセル発行

(※上記から分かるように、大層なシステムではありません)

それではどのような失敗をしたのかご紹介させていただきます。

結論から言うと、共通化していなかった

見出しの通りなのですが、どういった機能を共通化していなかったのかを(なるべく)簡潔にご紹介いたします。

機能① : 管理者マスタへの追加の際に、スタッフを選択する機能

このシステムでは、全機能を使用できるユーザを管理者マスタで管理しており、
管理者マスタへ追加するスタッフは、該当部署の全スタッフから選択できるようにするという仕様です。

機能② : 作業内容書の作成の際に、作業者を選択する機能

作業内容を記録する際には、必須項目である「作業者」を選択しなければなりません。
「作業者」は、該当部署の全スタッフから選択できるようにするという仕様です。

上記2つの機能に共通するのは、どちらも「該当部署の全スタッフから選択できるようにする」という部分です。

どう書いていたのかというと、

どちらの機能も、別々の画面で利用されていた機能であったため、該当画面を担当する各controllerに同じ内容のソースを書いておりました。

どのような弊害が生じたのか

実装が完了して、ユーザの方々に受入テストをしていただいた後に出た要望の中に、
スタッフ選択機能のロジックを変更する必要のある要望がありました。

要望自体はそれほど苦労することのない内容だったのですが、
その際に私は同じ機能が2つあることを失念しており、機能②の改修のみ完了させて本番に反映しました。

(もはや、共通化がどうこうではなく、検証能力が問われるところかもしれませんが…)

機能①について言及されたのは、それから少し経過してからでした。

すぐに対応は完了しましたが、
もし、これが大規模なシステムで、同じような機能を何十個も持っていたら…と、冷や汗をかいたため、今回の失敗から感じたことを備忘録として残しておこうと思います。

共通化は詳細設計の段階から!!

今回の失敗の原因は、詳細設計(担当⇒私)にあったと考えています。

詳細設計を作成するのが初めてで、テンプレートなどもなく、自分用だからという考えのもと、

・画面名
・機能名
・機能内容

上記3項目のシンプルな設計書を作成しました。

実装をしていく中で、考慮漏れが多数あり幾度も手直しがあったのは目をつむるにしても、
この段階で、
画面に関係なく同様の機能があったら分かるようにマーキングしておき、
実装の初期段階で、
「function.php」のような全画面共通で使える機能を記述するファイルを作成しておけば、
いざ該当機能の実装に入った際に、「この機能は別画面でも使われるからfunction.phpに書いて呼び出そう」という開発ができたはずです。

まとめ

今回の備忘録として扱った「共通化」ですが、ブログ書くために色々と調べてみると、
「共通化は悪」、「共通化で効率が落ちた」等の情報が散見されました。
なんでもかんでも共通化!という意識でいるのは危険なようです。

その中でも、これは正しいかな…と思ったトピックを最後に紹介します。

共通化する機能は粒度が小さいものほどリスクが小さく、メリットもモノによっては大きい。

粒度が小さい機能の極端な例として、大文字を小文字に変換する機能が挙げられておりました。
粒度が大きい(業務色が強い)機能ほど共通化する際のリスクが高まるようです。

どの粒度までが共通化に適しているのか…
自分なりの答えが見つかったらブログに致します。

  • このエントリーをはてなブックマークに追加

フリーランスで高収入と安心を実現するなら

テックブレインは、高単価・保障に強いIT/Webフリーランスエンジニアのための独立支援サービスです。

常時5,000件以上の高単価案件が豊富にあるため収入を最大化できます。また、あなたの立場になって案件の紹介から企業との交渉をシステム開発経験があるコーディネーターがフルサポート。正社員並みの福利厚生も利用できます。


高単価・正社員並み保障のフリーエンジニア求人案件へ