検索
カレンダー
2020年4月
« 4月    
 1234
567891011
12131415161718
19202122232425
2627282930  
ブログメニュー
Amazon検索
キーワード:

ドキュメントは必要?

2007年3月19日

傲慢SE日記さんの「ドキュメントは必要? 」という記事を見て、私も思うところを書いてみたいと思います。
本当はコメントに書こうと思ったのですが、長くなりそうなので記事にしてみました。

私が以前いた職場ではウォーターフォールで仕事をしていたのですが、たしかに設計者に書かれたドキュメントには抜けや間違いが多く、結局はドキュメンとソースが乖離したものになってしまいます。
ですので私も、傲慢SEさんのように「どうせドキュメントには不備があってソースが正しいのだから、ドキュメントはいらないのではないか」と考えていました。

ですが、初めてプロマネと設計を担当(人数が少ないのでプロマネと設計を兼務しました)し、私のこうした考えを一変させる経験をしました。

そのプロジェクトのメンバは6人で、殆どのメンバがスキルに自信を持ち、殆どのメンバがドキュメントの作成を苦手としていました。
そこで私はメンバと話し合い、アジャイル手法の一つであるXP でプロジェクトを進めることにしました。
これでドキュメントを書く工数や製作工数が削減できると考えたのです。

結果から言うと、これは大失敗でした。
XPの各プラクティスに対して、次のような問題が発生したのです。(ここに挙げている問題点は私たちの未熟さから発生したもので、XPの問題ではありません)

  • ストーリーの不備による要求変更の増加
    プロジェクトの終盤にさしかかっても要求変更が相次ぎました。
    これは私が基本設計しているにもかかわらず、私が所属する会社が孫受けだったことが原因だと思います。このような立場では、顧客の常駐どころか対面も叶いません。
    プロジェクトの終わりのほうで知ることになるのですが、私たちが作成したドキュメントやプロトタイプは、プロジェクトの終盤になるまでエンドユーザに見せられていませんでした。定期的に元請のSIerに提出していたにもかかわらずです。
    この結果、プロジェクトの終盤になっても要求が変更され、その結果仕様変更が相次ぎました。
    また、ストーリーが明確でないため、メンバは最後まで仕様を理解しませんでした(理解しようともしませんでした)。
  • 反復形開発による仕様変更の増大
    XPではドキュメントで顧客にコミットメントを取らないため、必ずといっていいほどプロトタイプを公開したときに仕様変更を要求されます。これは間違ったことではなく、本来、XPは「仕様変更を受け入れよう」という考えのもとに作られているのだと思います。
    ですが、このプロジェクトでは仕様変更するたびに、「なぜ俺が作ってから仕様変更が発生するんだ」とメンバから不満が続出しました。
  • テスト駆動開発の形骸化
    最初はユニットテストをきっちり行っていたのですが、仕様変更がある度に徐々にテストケースと仕様が食い違うようになり、最終的には誰もテストケースを更新しなくなってしまいました。
    結局、メンバは(目先の)工数削減のためにテストを省略してしまったのです。
    その結果、品質は目に見えて低下していきました。
  • YAGNIを取り違えたやっつけ仕事の増加
    YAGNIとは、「You Aren’t Going to Need It.(今必要なことだけ行う)」ことです。
    これは私は、「将来必要になるかどうか分からない機能を今作りこむのはやめよう」ということだと思っています。
    これをメンバは、「エラー処理も今は必要じゃないから作るのはやめよう」と考えたようです。このため、ソースコードには大量にTODOとかかれたままでエラー処理を考えられることなく作られていきました。
  • ドキュメント工数の削減の失敗
    ドキュメント工数を削減できると考えていたのですが、結局納品物として、基本設計書、画面設計書、テスト成績書等、普段作っているものと同じだけのドキュメントが必要でした。
    それも検収の関係上から、プロジェクトの中盤で完成したドキュメントの提出を求められました。
    結局、「ドキュメントを書かなくてもよい」ということにはなりませんでした。

これらの問題点は、単純にプロジェクトがアジャイルプロセスに即していないだけだったかもしれませんし、私やメンバの力不足があったのは確かです。ですが、私はこれを機に仕事の進め方を考え直すこととなりました。
その後に読んだある本(題名は失念してしまいましたが、確かスティーブ・マコネルの本だったと思います)(Joel Spolsky の「ジョエル・オン・ソフトウエア」でした)に、ドキュメントについての重要性が書かれていました。
内容も詳しくは忘れてしまいましたが、その本に学ぶところがあり、私はウォーターフォールを適用すべきガイドラインと、ウォーターフォールを適用する場合 の注意点を次のように考えています。(これらのポイントは私の中でまだ未完成ですので、これからも変えて行きたいと思っています。)

ウォーターフォールを適用すべきガイドライン

  • お客様にアジャイル手法を受け入れてもらえない場合
  • 製作者が働いている会社が元請ではない場合(製作者が元請のオフィスに常駐している場合はOK)
  • 製作者の技量が低く、また教育するだけの余裕がない場合
  • アジャイル手法が理解できていないメンバが半数以上いる場合

ウォーターフォールを適用した場合の注意点

  • フェーズごとにお客様に確実にコミットメントを取ること
  • 期限だからといって、完成していないのに次のフェーズに移行しないこと
  • ドキュメントを書く人はドキュメントを書くスキルを持っていること
  • ドキュメントの保守に専任の担当者をつけること

リストの中でも太字にしましたが、ウォーターフォールの中での問題点の一つは、「ドキュメントを書くスキル」の必要性が見過ごされていることだと思いま す。ドキュメントを書いた人はドキュメントの読者が理解できない場合、往々にして「読む人の頭が悪い」のが原因だと考えてしまいがちです。ですが本当にそ うでしょうか?私は、ドキュメントの書き手が悪い場合のほうが多いと思っています。
ちなみに、ウォーターフォールを適用した場合の注意点は、先述の本と「アジャイルソフトウェア開発の奥義」に学ぶところが大きいです。

最後に、私が傲慢SEさんと同じような状況に置かれたときにとった行動は、「ドキュメントを読んで理解できない点や矛盾点をリストアップして送りつける」というものでした。
設計者のプライドを傷つけないよう、文句をつけるというより、単純に分からないとか論理的に矛盾しているというスタンスをとるように気をつけました。
そのリストで相手が非を認めた項目については、早急にドキュメントを修正してもらうようにしました。
この方法が正しいかどうかは分かりませんが、ウォーターフォールの下流工程を担当する上での一つの対策だと思っています。

私が勉強をする理由

2007年2月28日

傲慢SE日記さんの「何故SEは勉強をしないのか? 」というエントリーに影響を受けて、私の考えも書いてみることにします。

仕事に対する姿勢として、社会人は大きく2つに分かれると思います。
一つが、「生活は仕事中心。お金をもらって仕事をするからには責任を果たすべき。」派で、もう一つが、「仕事はあくまでお金をもらう手段。仕事以外で人生を充実させるべき。」派です。

私の少ない経験の上での話ですが、ソフトウェア業界は後者の方のほうが多いようです。
以前私がいた職場で働いている方の過半数は、仕事は会社にいる間だけで十分で、家に帰ってから勉強するなど考えられないようでした。
人生は仕事が全てではないので家にいる間は家庭や趣味を大切にしたいのでしょうし、私はその人の考え方を否定するつもりはありません。

ですが、やっつけ仕事で建てられた家には住みたくありませんし、二日酔いの医者に掛かかりたくないのは私だけではないはずです。
同じように世の中の大半の人は、責任を持って仕事をしていない人が作ったソフトウェアにお金を払いたくないはずです。

世の中には、努力なしで仕事を完璧に遂行する天才がいるのかもしれません。
残念ながら私はこのような天才ではありませんが、凡人なりに責任を持って仕事をしているので、業務時間以外でも勉強を続けるしかないのです。

読みやすいコードの重要性

2007年2月2日

読みやすいコードの重要性いつも巡回しているブログの中に、「整理されたコードが読みにくい理由 」という記事がありました。私はこの記事は素晴らしいと思います。プログラム初心者・初級者の方は、元記事と併せて読まれることをお勧めします。

この記事を読んで私もコードの書き方について少し書いてみることにします。仕事柄、私も色々なコードを読む事がありますが、私が気になってしょうがないのは次のようなコードです。

public void hoge(ModelList modelList) {
	String name = ...
	if (modelList.find(name == null ? DEFAULT_NAME : name).update()) {
		...
	}
	...
}

上のサンプル関数「hoge」は、モデルオブジェクトのリストからname(設定されていない場合はDEFAULT_NAME)をキーにして一つを取り出 し、それを更新するイメージをJavaで書いたものです。このコードの3行目は、4つの処理(findメソッド、name変数の判定、updateメソッ ド、if文)が書かれています。
このように処理を詰め込んだコードは一見エレガントに見えるかもしれませんが、直感的に何をしようとしているか分かりにくくなると思っています。

私は同じ処理を書くとき、コードが少し長くなっても下のような書き方をします。

public void hoge(ModelList modelList) {
	String name = ...
	if (name == null) {
		name = DEFAULT_NAME;
	}

	Model model = modelList.find(name);
	boolean result = model.update();
	if (result == true) {
		...
	}
	...
}

確かに、私のようなコードを書いていると変数を大量に定義する必要があったり、タイプ量が増えたりするといった問題があります。(コードが幼稚に見えると いうこともあるかもしれません。)ですが、変数が増えるということは変数名でコードを理解しやすくなるということですし、なんといっても保守コストが増え るリスクに比べれば上記の問題など些細なことです。

どのようなコードを書くべきかは状況によって違いますので一概には言えませんが、全てのプログラマはコードを書くとき、ソフトウェアのライフサイクル全体にかかるコストを考えるべきではないでしょうか。

中国の人工衛星破壊実験と囚人のジレンマ

2007年1月24日

最近、『中国、衛星破壊のミサイル実験に成功 』というニュースがありました。この結果、スペースデブリ が大量に発生したようです。

このスペースデブリに関して、最近『使用中の人工衛星や有人衛星などに衝突する危険性が問題となっている』そうで、今回の中国の行動は、他国にかなり迷惑をかけていると言わざるを得ません。

このニュースを聞いて、私は「囚人のジレンマ 」を思い出しました。私は数学やゲーム理論に疎いので完全には理解できていませんが、国際情勢をこのゲームに当てはめてみると、今回の中国は「裏切り」を 行ったということになります。無限回の囚人のジレンマゲームで、全体的に有益になるのは「しっぺ返し戦略」だと言われています。この「しっぺ返し戦略」を 他の国が採るなら、次回は他の国が「裏切り」を行うのが有益ということになってしまいます。

中国は、他国が「しっぺ返し戦略」を採らないと思っているのでしょうかね。

言い伝えについての考察

2007年1月5日

明けましておめでとうございます。
皆様は正月休みをどのように過ごされたでしょうか。
私は実家に帰って両親と雑談してきました。
私の母は風水や占いといったものが大好きで、「占星術の本によると、今年の運勢は…」だとか、「風水の先生の話では、この家は風水的に…」だとか色々聞かされました。

私はいつも、こういった話に違和感を感じます。それは、占いや風水は「結果」だけを強制して、論理的な「理由」を教えてくれないからです。
例えば、風水的では鬼門にトイレを配置してはいけないようで、これは風水では有名な話のようです。(私は風水には詳しくないので本当かどうか知りませんが…。)では、なぜ鬼門にトイレを配置してはいけないのでしょうか。
私の想像ですが、この言い伝えには以下のような理由があるように思います。
昔のトイレはかなり不衛生でしたので、これが居住空間の風上にあると、細菌が繁殖しやすい環境になったのだと思います。この「風上」が鬼門や裏鬼門の位置にあたり、結果的に「鬼門にトイレを置いてはいけない」となったのではないでしょうか。
このような理由がわかって初めて、守るべき言い伝えかどうかがわかると思います。

プログラムの世界も同じようなもので、よく「GOTO文は書いてはいけない」だとか、「コードは1行80文字に収まるように書くこと」などといった、言い伝えと化しているものがあります。
これらの言い伝えを守るも守らないも自由だとは思いますが、どちらにしても理由をしっかり考えてから決めたいものです。

資格取得のための勉強法

2006年12月22日

当ブログにコメントしてくださった方の記事 を見て、私も資格試験を受けていた頃を思い出しました。
# 逆に言うと、ここ2年くらいは資格とは無縁だったりします

この際ですので、(役に立つかどうかわからないですが)私の勉強法をご紹介したいと思います。

私は資格試験を受けようと思ったとき、その分野に関する雑誌を定期購読するようにしています。
例えば「テクニカルエンジニア(ネットワーク)」なら「日経ネットワーク」、「テクニカルエンジニア(データベース)」なら「DBマガジン」といった感じ です。情報セキュリティアドミニストレータを取ったときだけ、どの雑誌がよいかわからなくて結局購読せずじまいでしたが…あせる

この方法のキモなのは、雑誌の講読を必ず半年以上続けることです。
もちろん、雑誌だけでは資格取得に必要な知識を全て得ることはできませんし、試験に必要でない知識が身につくこともあります。ですが、雑誌だと「受験勉強」という意識でないので気楽ですし、読み続けると業務に近い知識を得ることができます。
これに加え、雑誌を読んでわからないことなどの基礎知識を、資格試験対策用の本から得ます。

私は半年間この方法で基礎知識と業務知識をつけ、試験対策は直前の半月~1ヶ月だけで済ませました。

この方法は私のような記憶力のない方にお勧めだと思います。皆さんはどのような勉強法をお持ちでしょうか。

続・私が資格を取った理由

2006年12月19日

前回は資格の利点について考えたので、今回は問題点について考えてみました。

「私が資格を取った理由」 に『早く一人前になりたいから資格を取った』と書きましたが、これは知識を吸収したいという意味だけでなく、私が当時在籍していた会社の体質に因るところも大きいです。
私が当時在籍していた会社では、社内制度として資格の取得を奨励していました。具体的には、資格が取得できれば褒賞を、取得できなければ出世できないなどの罰則が与えられます。
私はこれを逆手にとり、資格さえ取得できれば一人前と見なされるだろうと考えたのです。

今思えば、これはかなり危険な考え方です。
たとえ資格を持っていなくても有能な方もいれば、資格をたくさん持っているからといって仕事が出来るとは限らないからです。
資格が不必要だと思われる方の多くは、自分より仕事が出来ないと思う人が資格を持っていて、その人が自分よりも重用されているのではないでしょうか。

私は、これは資格制度自体に問題があるのではなく、資格を重視する上長や会社の体質に問題があるように思います。
個人的な意見なのですが、資格は有能であるかどうかを証明するものではなく、その分野の仕事をするに最低限の知識があるかどうかを保障するためのものだと思います。
資格を持っているどうかを仕事が出来るかどうかに置き換えるのは、部下や社員の仕事の出来を見ることができない上長や会社の怠慢ではないでしょうか。

私が資格を取った理由

2006年12月18日

いつも読んでいるブログで資格についての記事を読みました。
私が資格を取ろうとしない理由
これに触発されて、私も資格について色々思うことを書いてみることにします。

私は社会人になりたての頃、早く一人前になりたくて色々な資格試験に挑戦しました。
幸い、5つほど取ることができましたが全て情報処理推進機構(IPA)のものです。

今思うと、資格を取って一番役に立っているのは、意外かもしれませんが試験勉強でした。
私自身は学生の頃からコンピュータ関係に興味があり、趣味レベルですがプログラムも一通りできました。
たぶん、最低限の仕事をこなすのなら資格は必要ではなく、業務の勉強のみでよかったはずです。
ですが、この時点で持っている知識というのは「私が興味を持つ」ものであり、自分が満足できる「最低限の」ものです。
試験勉強をするということは、「私が興味を持っていない」ものも含まれており、どの程度の知識が必要かというのも試験で客観的に判断できます。

この強制された知識の範囲と深さが役に立つと思うのです。
勘違いされると困るの敢えて書きますが、私は「資格さえ持っていればいい」と言いたいのではありません。
また、資格に合格できる知識が全て仕事に必要な知識でもなく、また仕事に必要な知識でも試験に出ないものもあります。
ですが、知識の幅や深さを広げるための動機付けに資格制度が利用できると思うのです。

資格反対論者と話す機会があったので色々話を聞いてみたのですが、彼らの言い分が私には納得できませんでした。
彼らは、「試験で問われる内容は実際の業務で要らないものが多いから意味がない」とよく言います。
本当にそうでしょうか。
試験勉強に本気で取り組んで、資格を取って、その後で本当に要らないと思うのなら納得できます。
ですが、今まで出会った資格反対論者で資格を持っている方はいませんでした。
自分で試していないものを批判するって、おかしいと思うのですが…。

ちなみに私は、いわゆるベンダ資格というものは持っていません。
ベンダの製品を使えるかどうかを証明する資格を用意するくらいなら、ベンダは製品を誰でも使えるようにすべきだからだと思うからです。
逆に言うと、資格が必要なくらい難しい製品を使いたくないからです。
…この部分は、ベンダ資格を持っていない私の負け惜しみとも言えますがあせる

アジャイル、AJAX、Web2.0…言葉だけが一人歩きしていませんか?

2006年12月2日

最近、目を引くキーワードがでてきて、それが一人歩きしているような気がしてなりません。
タイトルにも書きましたが、アジャイルやAJAX、Web2.0などが代表的なものです。
Web2.0に至っては、私には意味不明です。マーケティング的な意味と技術的な意味が混在していて、本当は何を指す言葉なのかサッパリです。

最近はXPに代表されるアジャイルな手法がもてはやされていますが、その前のRUPやMDAやUMLの騒ぎはどうなったかも気になるところです。
SIer等の上流工程(と言われる部分)にかかわっている方々はバリバリ使っていると思いますが、私がかかわるような小さな案件では、MDAなど影も形もなくなってしまいました。

・・・SOAという言葉もそろそろ飽きられてきていますし、次の流行はSaaSですかね。