サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

ソフトウェア開発 旧館より 考え方

変更履歴を論理的に見ておかしいと思わないのは…

投稿日:2008年9月13日 更新日:


仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。

SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があります。
変更日や変更者、変更箇所等を書いていくものです。

ある日、こういう変更履歴の記述を見つけました。

—————————————–
変更日:変更者:対象テーブル名:変更内容
2008/2/10:佐藤:発注テーブル:「備考カラム」を100桁から150桁に変更。
2008/2/15:鈴木:出荷テーブル:「出荷日時」カラムを追加。
2008/3/4:鈴木:発注テーブル:「最終更新日時」カラムを追加。
2008/3/11:前田:Order:「商品コード」カラムを追加。
—————————————–

#本当はExcelなのでちゃんと表組みになっています。

この前田さん(※もちろん仮名です)の対象テーブル名の記述に「?」と思ったわけです。
(善し悪しは別として)「対象テーブル名」には論理テーブル名を書くのがそのプロジェクトのルールでした。
明示されていなくても(明示されているのがベストですが)、それまでの記述を見ればそれはある程度、判断できるものです。

(それを理解していたかどうかは分かりませんが)前田さんの物理テーブル名であるOrderと書きました。
変更履歴の意図(いつ、誰が、どれを、どのように、どうした)が分かれば「そんな細かい点にこだわらなくてもいいやん」と言われるかもしれません。

ただ、私はそのルールを変えた明確な理由がなく、なんとなく(厳しい言い方をすると何も考えずに)記述したことが気になりました。

SEの大事な能力の1つに論理的思考が求められるます。
またその能力から導き出される矛盾点や配慮も求められるものだと考えています。
そして、それはアクション以外にもドキュメントにも当然のように求められます。

それをふまえて考えると、こういう細かい点やその一貫性に気を回さない/回せないと、いつかこういうことに起因したトラブルが発生するのでは?と不安に思うわけです(心配性なのかもしれませんが…)。

リーダーの立場として、そういう特性のメンバー作成のドキュメントは要チェックしてしまうわけです。
誰しも、自分のタスクにいちいち細かく指示されるのはイヤだと思います。

「卵が先か鶏が先か」の議論はありますが、リーダーに「このメンバーは大丈夫だ」と思わせる実績を残せば細かい指示もなくなってくるのでは?と思います。
#同時にリーダーが我慢して任せることも大事です。

似たような話ですが、時間にルーズな人が「プライベートな待ち合わせとかではルーズだろうけど、仕事ではちゃんとしているよ」と言っているのを聞いたことがあります。

本質的にルーズで、そして改善しようと思っていないのであれば、仕事面でもどこか出てしまうものだろうなぁと思うわけです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Jemimus via Visualhunt / CC BY

-ソフトウェア開発, 旧館より, 考え方

執筆者:


comment

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

関連記事

ドキュメント修正の大事さ

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。 言いたいこと 仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコード …

生産性の低さを嘆くよりも…

プロジェクトにおいてメンバーにタスクを割り当て、その品質や進捗管理をすることがあります。それについての自戒を書いておきます。 プロジェクトにはQCDなど色々な問題がつきものです。 その1つに【(自分も …

ペアプログラミング―エンジニアとしての指南書[読書感想]

ペアプログラミング―エンジニアとしての指南書 著者:Laurie Williams, Robert Kessler 翻訳:長瀬 嘉秀, 今野 睦, テクノロジックアート 今の小規模プロジェクトで、ペア …

問題対私達の構図

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。 #ここで …

新しいチームリーダーのことを社内SNSで知った

12月頭に全社横断的に(主に開発工程の)生産性向上をミッションとする部門に異動になりました。 で、「まずは顔合わせを…」ということになりました。 新しいチームで一緒になるチームリーダー(上司)は分かっ …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。