プログラマに質問。初めて出向く現場が

そういう現場では、とりあえず私の場合、念頭に置くのは

　急がば回れ

です。

・「これはどういうものですか」と聞かず、自分で調べた結果を「これはこういうものということでいいですか」と聞きます。前者の質問だといいかげんな回答が来ることが多いですが、後者だと誤りの場合、誤りに至った経緯まで推測するネタが拾えることが多いです。

・質問するときに、本題からちょっとずれた質問をもう一つするようにします。隠れていた仕様がそこから見つかることが多いです。

・チームの場合、デイリーに短いミーティングをして、適量の情報共有を図ります。情報は多すぎても漏れるだけで、適切な量と質が重要だと思います。

・ドキュメントの記述の曖昧さや、複数のドキュメント間に矛盾は仕様を誤解するポイントなので注意します。

・情報の信頼度を管理します。複数ドキュメントに同一記述があり、複数のお客さまから同一情報を入手できればまず信頼できる・ある機能について担当外のお客さまが「あれはこんなものだと思う」と言ったのを聞いた、等、前者と後者を明確に分けます。

いいかげんな仕様理解で開発しても、できたものが要求に沿ってなければ無意味だ、とわかっていても、早く開発に着手しないといけない…、というのは悲しい現実だと思います。

業務と仕様を理解していれば、最悪、フルリリースできなくても最適な部分リリースが可能となると思えば、やはり仕様を「深く」理解している必要があり、そこには労力をかける価値があると思っています。

私感ですが、参考になれば幸いです。

http://d.hatena.ne.jp/ksh/

理解するスピードには個人的差異があるので、どんな人でも有効な手法として、「とにかく時間を費やす」方向でいかがでしょう。

時間は作れるものです。

寝ても覚めてもご飯を食べても用をたしても電車に乗っている間も思考を繰り返し続けて力技でなんとかするうちに理解するスピードも上がっていくと思います。

自分はそうしてきたような気がします。

URLはダミーです

http://q.hatena.ne.jp/answer

まず、仕様に関する問い合わせ先を確認する。客先仕様などはできるだけ一度最初に顔合わせをしてから確認する。

可能であればできるだけ直接聞いたほうが良い。又聞きの場合は意味が変わっていることが多い。

エビデンスを残す。会議の場合は議事録に署名。メールの場合は保存しておく。

仕様に関する質疑応答の記録を残しておく。

不具合管理システム(BTS)に「仕様確認」の項目を設け不具合処理と同じ用に処理する。仕様確認が採番されデーターベース化されるため良い。

Ｗ字型開発(ダブル・Ｖモデル)を使用し、ＴＤＤで開発を行うことで、仕様の不明点を早く洗い出す。

http://www.jasmin.jp/activity/kenkyu_bukai/ise/070217_1.pdf

http://www.mozilla-japan.org/products/firefox/

URLはダミーです。

最悪な状況を考えると

あまり理解しないまま、作業を進め

最後にミスがあり、最初から(大きな範囲を)やり直しになることです。

しっかりと、仕様を理解してから作業に入る。が大前提かと思いました。

仕様理解を効率的に行うための知識の整理方法は

・仕様書、過去のデータがある場合はあらかじめ入手しておく

・全体的な構造を理解する。連動？している箇所を把握しないと、ミスが連鎖してしまう。

・全て、何もかも、細かいことまで、期日を決めて行動する。

・不明な点があれば、しっかり質問してまとめる

自分としては、こんな感じです。

ぜひとも、色んな回答をみてみたいものです

これは、私のあくまで個人的な方法ですが……。

時間的に余裕がない場合には、徹底的に関係者にインタビューします。

・顧客

・開発者

・企画担当者

・ユーザー

・その他、とにかく関係者には誰でも。

さらに、インタビューした内容をテキストファイルにして、インタビューをした相手に見てもらい確認してもらう。

（相手は、初回のインタビューで思考が整理でき、この時点で忘れていた情報や、さらに追加になる情報を教えてくれる場合が多い。）

インタビューした相手が開示することを許可してくれる場合には、社内にWikiなどのウェブを作成し、聞いたことを他の人からも見られるようにしておくのも有効です。

（間違いや、誤解を他の人が指摘してくれることも多いです。）

Wikiはいろいろとありますが、日本語であればPukiWikiが一番運用しやすいですね。

http://pukiwiki.sourceforge.jp/

時間がある場合には要求管理ツールやマインドマップなどのシステマティックな方法もよいかと思いますが、時間がないときにはとにかく人に聞きまくるのが一番というのは、私の経験上学んだことでした。

機能を列挙して、必要ならばそのウォークスルーも明確にします。

それを元に、テスト環境とテストデータを作成し、整合性をとります。先に目標が明確になるので、途中から突っ走ってもゴールで大きな間違いが起こることは避けられます。

開発言語がCやC++なんかだと、状況に応じて試作をPerlやRubyなんかで一気に組んでしまいます。それを上位階層に組み込んで結合試験を通しつつ、ターゲットプログラムのコードを書いていきます。

だいたい、こんな感じでやってます。他の方々の回答も参考にしたいですね。

ダミーURLです。

http://www.yahoo.co.jp

そのシステムが使われる業務の入門書を読んでから、

システムの仕様書を読む。

たとえば、経理システムを作ると業務に従事する際に、

経理についての知識がほとんど無い場合は、

システムの仕様書だけを読んでも、理解しづらいと思います。

（※良くできた仕様書なら問題ないとは思うのですが、

時間的に厳しい現場だと、仕様書も厳しい内容のこともありますので・・・）

簡単な入門書なら、２～３時間あれば読めると思います。

あとは、書店に行く時間もあるかどうかですが・・・

http://www.mayonaka-navi.info/mapsearch/tokyo.html

どの工程かにもよりますが、求めたい理解度に応じて、

以下のことを行うと良いかと思います。

（機能仕様の理解方法という意味で書きました）

0. サービス仕様、要求仕様をざっと読む

1. 用語定義を確認する。

通常の IT 用語辞典に載っていないものや、意味が違うものを 把握する。ちゃんとした仕様書であれば、書いてあるはずです。

2. データ構造を確認する。

データベースでは E-R 図、ソースに対してはクラス図を作成し、どのようなデータがどのような単位に束ねられているか把握します。ここを見ればおおよそ、きれいな設計かきたない設計かが分かります。

3. データ構造に対する操作一覧を確認する。

2.に対して、どのプログラムがどのような操作を行っているかを書き並べます。データベースの場合、CRUD 図や、クラス図の場合、単にメソッドの引数・戻り値を確認します。

4. 各操作の内容を確認する。

各操作の内容が仕様書のどこに書かれているかのインデクス作成を行い、内容を理解していきます。

ダミーURLです。

http://www.yahoo.co.jp