1 | 2 | 3 | 4 | 5 |最初 次ページ >>
2010年12月05日(日)

質問の答えを書く

テーマ:ブログ

ビジネスによくあるシーン。


 1. ドキュメントを作る
 2. 誰かに見せる
 3. 質問される
 4. 質問に答える
 5. 納得してもらう


例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。また、ソースコードのレビューも同じである(以下、「ドキュメント」にはソースコードも含むものとする)。


さて、上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。


単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。しかも、少なくとも聞き手が質問せずにはおられない程度に「重要なこと」なのである。


そのため、今後、別の人(たとえば上司のそのまた上司)がこのドキュメントを読んだら、同じ質問をしてくる可能性が高い。質問の機会がなければ誤解されてしまうかもしれない。また、説明を受けた人ですら、後になってその内容が思い出せなくなって、違う解釈をしてしまうかもしれない。


「質問をする人に知識や読解力がないせいだ」と言いたい時もあるだろう。しかし、読ませる相手のレベルに合っていないドキュメントは悪いドキュメントである。幼児向けの絵本を漢字ばかりで書いているようなものだ。



ドキュメントの説明で質問があったなら、口頭で説明しておしまいにせず、説明した内容をドキュメントから読み取れるように、追記や修正をしておきたい。


ソースコードの場合なら、構造を見直す(リファクタリング)、変数名やクラス名・関数名を見直す、コメントを見直す、といった対応を検討すべきだろう。


特に、品質管理のために行うレビューの場合は、レビューアにドキュメントの内容を伝えることが目的ではなく、ドキュメントを良くすることが目的なのだから、なおさらである。





■関連記事
この文書は誰が読むのか
どこまで書くか設計書
書かずに伝える
ドキュメントへの「朱筆」について考える




ついてきなぁ!『設計書ワザ』で勝負する技術者となれ!
國井 良昌
日刊工業新聞社
売り上げランキング: 83877

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
マーチン ファウラー Martin Fowler 児玉 公信 平澤 章 友野 晶夫 梅沢 真史
ピアソンエデュケーション
売り上げランキング: 5343
AD
いいね!した人  |  コメント(13)  |  リブログ(0)
2008年08月18日(月)

Vモデル

テーマ:ブログ

受託開発プロジェクトの終盤、ユーザーテスト(受け入れテスト)などと呼ばれる検証が始まると、当初の要件を覆すような「仕様変更」が発生するものだ。


システムの要件定義(要求分析)は依頼者(顧客)と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。


開発会社もある程度は折り込み済で、「手戻り」の時間を確保しているものだ。しかし、なにしろリリースまでの時間が残り少ない時のことである。「手戻り」の規模によっては間に合わないケースも多く、顧客との関係が悪化することもある。


開発者が「しかし、当初のお話では・・・」などと反論しようものなら、「こっちは客だぞてめえ」ぐらいのことは平気で言う人も。ビジネスの世界では金を払う人が偉いのである。



いわゆる「Vモデル 」に従って進めているとされるプロジェクトでは、こうしたトラブルがよくある。Vモデルの図をよく見ていると分かるのだが、開発の終盤に「当初のお話」が間違っていることに気がつくというのは、自然なことである。


V字の後半の右上がりの部分は、テスト工程を表している。この部分は、意地の悪い言い方をすれば、「先にプログラムの細かい枝葉を確認し、システムの拠り所である要件が正しいかどうかは最後に確認しましょう」ということになっているのである。最後に要件上の問題が見つかるのは当然である。しかも、顧客が要件を出したのは遙か昔のことなので、今更「当初のお話」をしたところで、「そんなこと言いましたっけ?」となるのも当然である。



もちろん、ここでのテストとは、あくまでも動作確認(動的テスト)の話である。要件定義自体のチェック(静的テスト)は、V字の「書き出し」に定義した時点で行われているはずであり 100% 問題ない、という前提(というか建前)で進んできているわけである。基本設計(外部設計)以降も同様だ。


しかし、この静的テストは、主に要件定義書や設計書などを作って「机上」で行われる。開発の当初、まだ影も形もない新しいシステムを 100% イメージできる人がいるだろうか? もちろん、システムだけでなく、それを使った業務全体の運用イメージも必要なのだ。しかも、誰か1人が分かっていればよいというわけではない。そのイメージは、システムの素人である顧客と、業務の素人である開発者の間で、完全に共有しなければならない(出会って間がないにもかかわらず)。


実際のところ、そんなことはできないのである。結局、システム要件というものは、結局は開発期間の最初から最後までかけて、ああでもない、こうでもないと言いながら決めていくことになる。


いや、開発が終わってもそれは続く。完成した後で「ここはこうした方が良かった」と思わないようなシステムは、まずないだろう。ソフトウェアに限らず、実際に使ってみて初めて気がつくことがあるというのは、当然のことだ。


このように、仕様変更があるというのは自然なことであり、開発プロジェクトでは、変更があったときにどうするか、ということをあらかじめ決めておくということも重要である。



とはいえ、Vモデル(ウォーターフォール)での開発では、後半に発生する変更を少なくすることが最重要課題である。開発が終盤に近づくほど、残り期間が少なくなるし、同じ変更であっても手戻りの作業量も難易度も大きいからだ(既に作っている部分を直すため)。


このため、一番最初の要件定義の段階でいかにして精度の高い「完成図」をイメージするか、ということが非常に重要なのである。これは、開発側の視点でいえば、顧客に「どこまで本気で考えてもらえるか」ということにかかっている。


プロジェクトも始まったばかりのこの頃、顧客はのんきに構えているのが普通である。そして困ったことに、開発者にもそんな人は多い。会議を開いても、結論も出さずにあいまいな状態で終わったり、雑談ばかりしていたりする。「時間があるのだから、今考えなくてもいいでしょう?」などと思っているようだが、実はこの時が最も重要なのだ。Vモデルでは、最初はバリバリ、最後は淡々と仕事すべきなのである。







■関連記事
怖いこと
情報求む
捨てるべきときには潔く
簡単に見える時ほど注意せよ
ちょっとしたプログラム




はじめての上流工程をやり抜くための本 (エンジニア道場)
三輪 一郎
翔泳社
売り上げランキング: 6219
おすすめ度の平均: 5.0
5 上流経験者にもぜひ
5 濃い本です


成功する要求仕様 失敗する要求仕様
アラン・M・デービス
日経BP社
売り上げランキング: 16586
おすすめ度の平均: 5.0
5 要求マネジメントの良書
AD
いいね!した人  |  コメント(12)  |  リブログ(0)
2008年05月07日(水)

通のツール

テーマ:ブログ

私がパソコンを使う際には、マウスではなくポインティング・スティック(トラックポイント)を愛用している。会社のデスクトップ・パソコンにも、それが付属したキーボードを個人的に購入して繋いでいるくらいである。しかし、ポインティングスティックを搭載したノート・パソコンは種類が少なく、残念な限りである。


ポインティング・スティックがその機能性の割に普及しないのはなぜか。製造コストの問題もあるが、それよりも「とっつきにくい」ということのほうが重大なように思う。トラックポイントの開発担当者は「10分も使えばなれる」と言うが、店頭で10分も触る人がいるとは思えない。ThinkPad を購入した(あるいは支給された)としても、タッチパッドも付いているし、マウスも繋げる。それらに慣れたユーザーが10分間もトラックポイントを使い続ける機会はほとんどないだろう。



このように、便利な道具の中には、ある程度の慣れが必要なものも多いが、多くの人が触れる機会を持たないためにメジャーになりきれないというものがある。


もう十数年前の話だが、私の所属していた大学の研究室に「筋金入りのマック・ユーザー」というのがいて、いつも MS-DOS のコマンドラインによる操作方法を「呪文」と称して皮肉っていた(当時、GUI は Macintosh の十八番だった)。しかし、そんな彼が、ある研究の一環で UNIX 系の OS に触れるようになってからは、CUI の利点に気づかされたという話をしてくれた。GUI は「とっつきやすい」が、必ずしも CUI より便利というわけではない(詳細は「コマンドラインのすすめ」を参照)。



プログラミング言語についても同じことが言える。もう6年ほど前だろうか、常駐先で会った人に Ruby を薦められた。といっても、当時の Ruby は企業の開発プロジェクトで使うようなメジャーな言語ではなかった。自分で使う「ちょんプロ」を作るための言語としてである。しかし、当時の私は Perl を覚えたばかりだったし、それ以上の必要性も感じなかったので、結局使わなかった。近年の Ruby の評判を見るにつけ、あの時から使っておけばよかったな、と思うのである。



先に「道具」と書いたのだが、「書類の書き方」でも同じようなことがある。この仕事をしていると、顧客から見慣れない書式の図や表を見せられることがある。顧客側は「これが一番分かりやすい資料だ」というのだが、何が書いてあるのかさっぱり分からない。その資料はとりあえず無視して業務分析をしてみると、後になって「なるほど、確かに分かりやすい資料だ」と思えてくることがある。はじめからその資料を理解した方が早かっただろう。



「通」が使うような難しい道具に見えるものであっても、試してみれば意外と簡単に使えることもある。誰かが便利だというものは、積極的に試してみたいものである。






■関連記事
・「コマンドラインのすすめ
ファイラのすすめ
マクロのすすめ
ちょっとしたプログラム




ぷらっとホーム Mini Keyboard III 日本語版 HMB633PJP
ぷらっとホーム
売り上げランキング: 86676
おすすめ度の平均: 4.0
4 打鍵感のある省スペースキーボード


Rubyスクリプティングテクニック ―テスト駆動による日常業務処理術
Brian Marick
オライリー・ジャパン
売り上げランキング: 78287
おすすめ度の平均: 4.0
4 ツールを書くのにRubyを使うという本
AD
いいね!した人  |  コメント(4)  |  リブログ(0)
2007年10月14日(日)

マクロのすすめ

テーマ:ブログ

一般的なアプリケーションの機能として、いわゆる「マクロの記録」というものがある。Microsoft Office(Word や Excel)にも付いているので、ご存知の方も多いだろう。商用アプリだけでなく、フリーソフト(テキストエディタなど)でも、同等の機能が付いていることがある。これは、アプリケーションに対する一連の操作を「記録」し、後で同じ操作をしたい場合に「再生」するというものだ。一連の操作を何度も繰り返し行いたいときには便利な機能である。


ここで、「マクロの記録」機能で記録された一連の処理は、どのような形で「記録」されているのだろうか? 記録したマクロを編集機能(あるいはテキストエディタ等)で開いてみると、プログラムのソースコードが書いてあるはずだ。つまり、ユーザーの操作が、そのままソースコードとして「記録」されているのである。一般に、マクロとは、そのアプリケーションを操作するためのライブラリが付属したプログラミング言語である。例えば、Microsoft Office のマクロは、VBA(Visual Basic for Applications)という言語に、Word や Excel を操作するためのオブジェクト等が組み込まれたものである。


つまり、「マクロの記録」という機能とは、非常に簡単なプログラミング手段なのである。こうして記録されたマクロを更に自分で編集すれば、「一連の操作の繰り返し」以上の複雑な処理をさせることができる(もちろん、それなりの勉強は必要だが)。



マクロは、その性質上、アプリケーションによって書き方が違う。例えば、Excel マクロの知識だけでは Word のマクロは書けない。同じ VBA でも、アプリケーションを操作する機能の書き方(ライブラリの使い方)が全く違うからだ。プログラミング経験者でも、全く初めてのアプリケーションのマクロを書く場合には、そういった書き方を調べるのは面倒なものである。


そんな時にも、マクロの記録機能が役に立つ。書き方を知りたい機能を手動で操作すれば、自動的にマクロのコードが保存されるので、それを参考にすればよい。もちろん、自動で生成されたコードは理想的な書き方になっていないことも多いが、手直しするのはそれほど難しいことではないだろう。



プログラミングの入門に適した言語は何か、という質問を時々受けることがあるが、アプリケーションのマクロは、その選択肢のひとつだと思う。マクロの記録機能で作られたコードを参考にできるため、プログラミング初心者でも、アプリケーションがどう動くのか、ということをイメージがしやすいからだ。また、記録したマクロを編集して汎用性を高めていくという過程からは、学ぶべきことは多いだろう。


このブログでも何度か書いていることだが、プログラミングを学ぶには、とりあえず「自分にとって役に立つプログラム」を作ってみるのがよい。マクロを作るということは、いつも自分が利用しているアプリケーションを自動化するということであるから、実用的な題材を設定しやすいというメリットもある。


プログラミングを始めるにあたり、「つぶしのきく」言語を学ぼうとする人も多い。マクロなんて覚えても、大した仕事はできないと思うかもしれない。しかし、初めてプログラミングを学ぶ際に重要なのは、言語(文法やライブラリの使い方)を覚えることよりも、普遍的な知識(プログラミングのセンス)を身に付けることである。その第一歩として、身近なアプリケーションのマクロを選ぶというのも、そう悪くはないと思うのである。







■関連記事
面白いプログラムを作ろう
プログラミングを始めようとして何度も挫折した人へ
プログラミングの入門書は何が良いか?
コマンドラインのすすめ




VBA の絵本
VBA の絵本
posted with amazlet on 07.10.13
株式会社アンク
翔泳社 (2005/10/21)
売り上げランキング: 16468


すっきりわかった! エクセルVBA マクロ作成のツボ (ASCII dot PC BOOKS)
アスキー・ドットPC編集部
アスキー (2007/09/28)
売り上げランキング: 136526

いいね!した人  |  コメント(3)  |  リブログ(0)
2007年09月24日(月)

議事録係

テーマ:ブログ

自分が参加した会議の議事録を書いたり読んだりする機会は多い。最近は、誰かに書いてもらった議事録の内容をチェックすることがよくあるのだが、一度でOKが出せることはあまりない。


一般的にも、「議事録係」は若手に任されることが多いのではないかと思う。しかし、実は、議事録を書くのはそれほど簡単ではない。


よくある問題のひとつは、情報の抜け漏れである。といっても、メモを取っていなくて重要な内容が抜けてしまうようなのは論外である。問題は、会話を要約するときに、必要な内容を削ってしまうことだ。議事録といえども、全ての会話を全て残すわけにもいかない。しかし、重要な発言だけを適切にピックアップするには、十分な前提知識を持った上で、その会議の目的や位置づけをきちんと理解していなければ難しい。


もうひとつの困った問題は、議事録の大筋は違っていないものの、細かいニュアンスなどが違っていることだ。例えば、「個人的には○○ではないかと思う」といった軽い発言だったはずのものが、「○○である」と断定的な表現で記述されていたりする。言葉のニュアンスは聞き手によって受け止め方が違ってくることもあり、やっかいだ。


このように、議事録は会議の内容を機械的に記録するだけのものではない。議題に関する前提知識、メモ力、記憶力、理解力、文章力はもちろん、あちこちと飛躍する会話をまとめる能力、話し言葉をビジネス文書に適した言葉に変換するためのボキャブラリなど様々なスキルが必要だ。


そんなわけで、同じ会議であっても、書き手によって、全く違う議事録ができる。本来は客観的事実を記録するはずのものなのだが、現実はそんなものである。







■関連記事
書かずに伝える
この文書は誰が読むのか
メモをさせない方法




作成しなかったではすまない中小企業の議事録の重要性
松本 守
TKC出版 (2007/04)
売り上げランキング: 3605


デジタル法令&文例 新会社法対応 会議議事録 Vista/Office2007 対応版
インターチャネル・ホロン (2007/03/02)
売り上げランキング: 7015

いいね!した人  |  コメント(3)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。