skillup

技術ブログ

ドキュメント作成 プロジェクト管理

ファジープロジェクト対策 その1

投稿日:2018年10月7日 更新日:

5月ぐらいから着手していたプロジェクト(顧客管理ソフト)が終焉を迎え、検証段階に入ったので、記して置きたいことなど。

数ヶ月程度ですが、自分が携わったプロジェクトの中では過去最大クラスのものでした。

ポイントとしては、WEB系にはありがちだと思いますが、下記のように作りたいものがファジーだったりすることが多いです。

  • 仕様が不明な点が多い、固まっておらず、質問しても顧客のレスも遅い
  • 仕様書がない。あってもあまり機能していない、テーブル定義書やデザインデータがない
  • ドキュメント自体残す習慣があまりない

ようは仕様が曖昧なまま「こんなのが作りたい」と言われるケースです。自分の場合は某WEBサービスをベースに作って・・などと言われたので、まだよかった方だったのかもしれませんが・・・

便宜上ファジープロジェクトと定義します。

以下のような点がポイントでした。

常にメモを残す

ドキュメントとかがないので、数ヶ月単位のプロジェクトになると作った意図とかを忘れてしまいがちになるんですね。

最悪なのが間違って作り直してしまうことです。そのためにも自分への備忘録として、常にメモを残すこと。

単純ですが、これがあると上記のようなミスが防げ、地道に効率アップをすることができます。

テーブル設計

何と言ってもデータベースの設計がもっとも影響度が大きいです。しかもテーブル定義書がないので、手探りでこんな感じかな?で作るしかありません。

これなんですが、やはり一般的な業務管理プロジェクトのテーブルをたくさん見ておくことがポイントになります。

いわゆるアンチパターンやグレーパターンなど言語化できる部分もありますが、ステータスはどのように管理するか、正規化をどの程度行うかなどはどうしても経験に寄るところが多いです。

以下のような本で勉強すると言う方法もあります。
グラス片手にデータベース設計~販売管理システム編

実践的データモデリング入門 

コーディングスキル+ユニットテスト

次に大事だと思ったのは常識的なコーディングスキルとユニットテストです。

テストはTDDとかそういった原理主義的なものではなく、粒度を細かくすることで該当箇所の挙動をすぐに確認できることが目的です。コーディング時に気をつけるべき点としては以下のような点。

  • メソッドが適切な役割で設計されているか
  • メソッドの行数は30行程度か
  • メソッドの引数を変数でおくことと、ハッシュやオブジェクトなどでおくことのメリット、デメリットを理解しているか
  • クラスが役割に応じて分割されているか
  • クラスの行数は多くても300行程度か
  • テスト可能なコードか
  • (一つ上のものとだいたい同じですが)画面からデータを入れる場合であってもテスト(コマンドライン)により挙動が確認可能か

長くなるので後編へ。

-ドキュメント作成, プロジェクト管理
-

執筆者:


  1. […] 前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 […]

comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

業務フローの分解について

上流工程を担当するようになり、プロジェクトマネジメントや、要件定義、業務フロー分解などについて勉強しておいたほうがいいなーと思い、最近では読書をしております。 本日読んでわかりやすかった本は「はじめよ …

no image

テーブル設計に関するメリデメ

昨日も書いた記事なんですが、基本的に実装にしても設計にしてもこれが最強っていう手法はなくて(あったとしたら全員がそれを使うのでそもそも選択肢という概念がなくなる・・)メリットデメリットをしっかりと考慮 …

no image

仕様の把握で見るポイント

新しい現場に入って技術的な部分はもとより仕様の把握などでポイントになる点などを。 Contents1 ER図2 ステータス変更3 プレイヤー(イベント)整理4 タイムテーブル5 マトリックス表6 ダミ …

no image

コードレビュー時のポイント

コードレビュー(仕様的な点ではなくて規約的なところのチェック)などで気をつけることなど。 ポイントとしては検知ツールで確認するコストを減らすことが一番大事(カスタマイズの方法について調べておく)、ある …

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

アーカイブ