仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。
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
コメント