月別アーカイブ: 2007年12月

仕事に対する心構え

(プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。
#フレックスの人は悠々~って感じですが。

始業時間になればすぐに仕事をするか?と言えばパソコンも起動中だったりします。
パソコンが起動してからも、Yahoo!やニュースサイトのチェックをする人もいます。中にはゴソゴソとパンやおにぎりを食べている人もいます。
#チェックする気持ちも分かりますが、それが仕事に関係あるのか?と思います。

ひどいと、サイトチェックが一通り終わった後、「一服~」とばかりにタバコを吸いに行く人もいます(で、仕事を始めるのは10時過ぎてからとか…)。
学校(か社会人1年目…会社でこれを言われている時点でどうかと思いますが…)で教えられなかったのでしょうか?

始業時間 <> 出社時間 ではなく、 始業時間 = 仕事開始時間

こういう話をするとえてして「そんな細かいルールなんて守らなくても成果を出せば良いんでしょ」と声があがります。

確かにSEやプログラマーのタスクで、時間さえかければそれに応じた成果が出るものはそれ程多くありません(単純なテスト実施やホントにコーダだとそうかもしれませんが)。
むしろその人の能力や(同じ人でもその日の)集中力によって生産性に10倍以上もの差が出る職種です。

どうしても朝に弱い人もいますし、それぞれの集中力を高める方法で成果を出せば良いとは思います。
ただ(ビジネス面での)時間にルーズな人は、他のシーンでもルーズになっていると思います(もしくはそう思われることが多いです)。

ぶっちぎって優秀…イチローやビル・ゲイツ…まぁそこまで行かなくても所属する組織レベルなりで「あいつなら(多少時間にルーズでも)しゃあないわ」と言われる程…で、代替できない価値を持っていれば別ですが。

ついでにいうと「仕事のできる人」(大括りにしていますが)は、やはり時間の使い方がうまく、段取り上手な人です。
少なくともそれで給料をもらっているんだからもう少し仕事に対するプロ意識(心構え)…たかが出社時間のことですが…を持って欲しいなぁと思ったわけです。

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

Photo via Visualhunt.com

日常の意思決定にも使えるかも…狩野分析法

http://d.hatena.ne.jp/masayang/20071213/1197534511にて狩野分析法というものが紹介されていました。
「Agile開発で~」と書かれていますが、Agileで無い場合でも使えそうです。

実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断が出来そうなツール(考え方)の1つかなと思います。

>「必要なものに○をつけてください」などとアンケートをとっても、全部に○がつくのがオチであろう。

そうなんですよね。判断基準が明確でない優先順位付けの結果「全て最優先」なんていう状態になるわけで。

本体の話に戻すと…これを使って、お客様にも機能毎の優先度を可視化して、費用対効果の面で共通認識を作りやすくなると思います(この辺、実際に適用していないので、あくまで予想ですが)。

#まぁ優先度が分かったからと言って、それを望む費用で望む質で提供できるかはSE(とその会社)の腕の見せ所ではあるのですが…。

少なくとも導入後の「俺はこんなモンよりもっと欲しいモンがあったんじゃ!!」という叫びを聞く可能性は少しでも減らせそうです。

システム開発だけで無く、日常のそれなりの意思決定…携帯や家電を買う時の機能の優先付けなんか…にも使えそうです。

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

Photo credit: hahn.elizabeth34 via Visualhunt.com / CC BY

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

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。

言いたいこと

仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないようにしましょう。

その為の改善策は?

新規、保守開発問わないシステム開発で、(仕様変更や実装結果を反映する)「ドキュメント修正」をWBSのタスクとして明確にします(ちなみにこれを「バッファやん」なんて甘い考えを持っているようではダメです)。

変更管理、不具合管理のフローにおいても「プログラムが正しく修正されていることを確認する」が終了条件では無く(たいがいはこれで終わっていると思います)、「該当の仕様書、テストケース(つまりドキュメント)が修正されていること」を終了条件とすることで、プロセス面でアプローチをします。

もう1つは自分がドキュメントがグダグダなシステムを保守/修正して、大変な痛い目をあって実感すること(できれば裏返しの成功体験も掴んで欲しいですが)です(「喉元過ぎれば熱さを忘れる」はありますが…)。

そもそもの問題提起

ソースコードとドキュメントの乖離で、何が困るかと言うと、保守や機能追加/修正時に役立たず、工数の増加を招きます。さらに悪いことにそのドキュメントを信じて進んだ場合、システム障害を引き起こしお客様に迷惑がかかります。

問題の発生原因

よく聞くのは「時間が無い」「面倒くさい」というものです。

[1]「時間が無い」
余裕のあるプロジェクトなんてなく、バッファなんぞは予期せぬ出来事でアッという間に食いつぶされていきます(バッファがあるだけマシです)。「そんな紙よりも実際に動くものを作る方が良い」という感覚も開発者にはあります。

[2]「面倒くさい」
新規開発中やそこそこの機能追加であれば、仕様書の作成中、実装中に「やっぱり…」と仕様変更/追加になることはままあることです。
その都度、仕様書に反映させるのは非効率で、ある程度Fixしてから反映すれば良いというわけです。

「ドキュメントは大切ですよ~」と話になると「意味の無いドキュメントなんかより、ソースコードが全てだ。ソースコードがドキュメントだ。」とXP(エクストリーム・プログラミング)かぶれ?な発言をする人がいます。

確かにXPにはそういう思想もあるとは思いますが、あくまで「不必要なドキュメントは作らない」というもので「ドキュメント全てを不要」なわけではありません。

それに「ソースコードがドキュメントだ」なんて言うからには、そのソースコードは適切なコメントから始まり、変数、メソッドの命名規約、分かりやすいアルゴリズム(なぜこういう処理なのかが手に取るように分かる)…つまりCodeCompleteを実践しているような…であることが前提です。

で、上記のような発言をする人に限って、大したソースコードじゃない…むしろ非常に読みづらく理解に苦しむソースコードな気がします。
良いソースコードを書ける人はドキュメントの重要性も理解している方が多い気がします(少なくとも私が出会った人の中にはこれを理解していない人はほとんどいません)。

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

Photo credit: JD Hancock via Visualhunt / CC BY