プログラマーの仕事について回る「文書作成」�@

ブログの更新もすっかり久しぶりになってしまいました。。。

私も１０年近くこの業界におり、ベテランといわれるような年になってきたわけです。
そこで、今回から、プログラマーの仕事ってどんなものなの？といったようなことについて、
後輩の方々に参考になるような記事を書いていこうかと思います。

今回は、プログラマーの経験に必ずついて回るような、「ドキュメント」について
少し書いてみようと思います。


＜プログラマーは、ただプログラムを書いているわけではない？＞

ＳＥやプログラマーの仕事というのはいつもプログラムを作成しているようなイメージがありますが、そうでもありません。
実は、「文書作成」のウエイトがかなり大きいものです。
（我々の間では「ドキュメント」という形で言うことが多いです。以下、「ドキュメント」という言葉を使っていきます）

ドキュメントといっても、いろいろ種類があります。
たとえば我々の仕事で言うと、このようなものがあります。
（職場によって、いろいろ言い方には差異があると思います）

・議事録
　→お客様との間での打合せや、社内での打合せでの決定事項をまとめたもの。
　　だいたい、駆け出しのころは必ず書く資料ですね。

・設計書、仕様書
→最終的にプログラムを作成して動くものを提供する、という過程で、各工程のインプット資料／アウトプット資料になるもの。
　プログラムを作成するときのインプットになる資料です。
　工程によって記述内容はかなり変わってきます。　

（※設計書・仕様書という言葉の使い方については、かなり人それぞれです。
　　たとえば自分では、
　　　・プログラムがどう動くのか、画面にはどう表示されるのか、という「使う人から見たふるまい」を定義したもの→仕様書
　　　・仕様書をもとに、内部的なつくりを記述したもの→設計書
　　という感じで使い分けていますね。

　例：「画面仕様書で、画面でどう動くのかを打合せで決定し、お客様の了解を得た」
　　　「画面設計書で、画面仕様書をもとに画面におけるプログラムのインプット・アウトプットを定義した」

・要求定義書
　→お客様のやりたいことを、文書レベルで記載したもの
　　「こうしたい、ああしたい」というような、お客様の頭の中で思っているような「絵に描いたもち」を、 文書にしたものと考えるとよいでしょうか。
　　よく絵や図を使用することが多くなる設計書だと思います。
　　（システムのことがわからないお客様にも直観的にわかるようなものにするため）

　　文章の性質的に、そのためある程度の経験がないと、作ることが難しい資料だったりします。
　　お客様と仕様を詰める力が必要になってきます。

・プロジェクト報告書
　→上で書いてきたものがお客様に対してのものであれば、これは社内の人への説明資料となります。
　　だいたい、今月（年だったり週だったりします）に、どんなプロジェクト運営がなされていたか、ということを
　　社内の上司や先輩に報告するための資料です

　　・このプロジェクトは今月何パーセントの黒字だった（赤字だった）
　　・このプロジェクトの状況は今月どんな感じだったか
　　・プロジェクトの人員の稼働はどれくらいか（残業が多すぎないか？士気は？）
　　・全体としてどれくらいの進捗率か。

　といったことが書かれてくると思います。
　（来年度から、工事進行基準による会計が我々の業界でも使われますが、その際月単位で見たときどうなのか
　ということののウエイトが非常に高くなってくると思います。また機会があれば調べて、説明したいと思います）

・・・などでしょうか。

実は「プログラム」も、ソースコードは人にわかりやすく記述する必要があるので、「ドキュメントの一種である」 ということをいう人も結構いらっしゃいます。
そういう意味では、常に「ドキュメントを作っている」という業種であるともいえるでしょうか。


＜ドキュメントってどんなものを書くの？＞

では上の中から、今回は「議事録」についてピックアップして、どんなことを書くのかを経験をもとに書いてみようと思います。
（経験のある方はいくつか意見があると思いますが、コメントなどで残していただければうれしいと思います）

・議事録

　　上でも書きましたが、「だいたいのプログラマーが最初に作成する資料」だと思います。

　　何が決まったかということを記録に残すというのは、われわれの業界でも一つの技術でもあります

　　例：
　　たとえばプログラムを作成するとき、お客様とやり取りをしていて、
　　「何がきまったの？これは言ったの？言わないの？こういう動作じゃなかったの？」
　　と突っ込まれたとき、
　　「いやいや、これはここでこう決まった（決めていただいた）じゃないですか」
　　というためのいわば「証拠」になるわけです

　　また、お互いに議論に夢中になり、結局何が決まったか、ということが落ちてしまうことも多々あります。
　　そういうときに、「ああ、こう決まったんだよな」ということが残る「資料」ともなるわけです。

　●記述するレベル
　　どこまで書くの？というと、打合せの性質しだいにもよりますが、だいたいが
　　上にあげたような性質から「決定事項だけ」、を簡潔に残すというのが多いのではないかと思います

　　また、少し砕けた会合の場合は、雑談レベルまで残すという場合もありますし、
　　誰が何を発言した？ということまで詳細に残す方もいらっしゃいます

　　いずれにしろ、
　　　・決まった事項は何か？
　　　・誰が、いつまでに、何をやるのか？（その後のアウトプットにも関連してきます）
　　　・後になって、出席者間で「言った、言わない」ということを防ぐ
　　　・出席していない人でもわかるようにする

というような位置づけがあるのではないかと思います。


今回は、
　・ドキュメントと言われるものの種類
　・ドキュメントのうち「議事録」にピックアップ
して説明してみました。

次回は、プログラムを作成するためにインプットとなってくる、「設計書／仕様書」について、書いていこうと考えています。
それでは。

柳下＠Mcube