プログラマに負担をかけない仕様書の書き方や対応についての質問です。
今後、プログラマに事細かに指示を出す必要がある仕事に自分がつきそうです。いろいろなサイトを見ましたが、意思の疎通がうまくいかず、プログラマに負担がいってしまう事例が多くあり、気を引き締めて取りかかりたいと思います。
自分も若干の言語ならばわかりますが、ほとんど無知の状態に近いです。
自信の勉強ももちろんのこと、ミーティングなども綿密に行う事が必要ですが、その他に気をつけなければならない事や注意点、プログラマから見たやりやすさなどがありましたら教えて下さい。
また、どういう状況での作業がやりやすか、などの環境についてもよければご意見を聞きたいと思います。
みんなの回答
-
mouitchou
満足17pt
茫漠とした質問なのですが、簡単にひとつ。
プログラムのことをご存じないとのことですね。では、こういった言語についての細かいことは全部プログラマにお任せになることです。そして、あなたはユーザーから色んな情報を引き出してプログラマに渡す役目を果たしてください。（スケジュール管理などはもちろんやると前提しての話です。）
どんなとき、どこでどんなデータがどういうメカニズムで発生し、どう使われていくのか。その変化のしかた（仕事と情報の流れ）。異常な事態（例外）とはどんなときに発生し、なにが起こるのか。その場合の処理の方法。希望する画面やプリントのイメージ。
こういったことを図解を多く利用して整理なさることをお勧めします。プログラマから質問を受けたときにすぐに正確に答えを出せれば一種の尊敬を受けることができ、仕事もスムーズに進むことでしょう。
逆にプログラムのことを少々知っていても、肝心の仕事の内容やデータの流れなどを知らなければ尊敬を受けることはできず、いろんな場面でトラブルが発生していくことと思います。
ぜひ、その仕事を客観的な目で見直してみて、鳥瞰・俯瞰したり接近したりして、整理をなさることをご提案します。
---------------------------
たとえば、こんなツールも助けに使えるかも。
フリーマインドのサイト
-
zachouR
-
- その他の回答を読む
zachouR
この質問へのコメント
質問の情報
- 登録日時
- 2006-10-04 21:50:19
- 終了日時
- 2006-10-06 21:37:24
- 回答条件
- 回答にURL必須 1人2回まで
この質問のカテゴリ
この質問に含まれるキーワード
人気の質問
-
https://hikky-mura.org/t/topic/2523/7 でsma200さんという方に戸塚ヨットスクールを勧められましたが、僕…
hayakushinene
1
-
親族（実家）の犬が無駄吠えをしています。朝方に一時間くらい吠えているらしい。昼にも一時間くらい吠え続…
匿名質問者2
2
1
-
度々すみません。 私は以前から大学入試・成績など教育関連のネガティブな夢を見ていましたが、ここ最近そ…hayakushinene5
-
いつもお世話になっています。 自分、インセル予備軍かもしれません。 街中でカップルや夫婦等見ると羨まし…hayakushinene
-
学歴詐称ではなくて、貴族称号詐称について伺います。イボンヌの香りという映画で、ロシアの伯爵を詐称して…匿名質問者
自分は土木関係の出身ですが（プログラムは昔からやっておりました。）、同じ技術屋でも全く畑の違う技術を扱う人達は、どのような方々なのか？という事を知りたくて、はてなを利用して質問しました。
自分なりの結論ですが、自分が仕事をしていた時に考えていた事とほぼ同じだと感じました。
仕事に慣れるのには時間がかかりそうですが、卑屈にならず、一緒に山を越えていく感覚でがんばりたいと思います。
ありがとうございました。
心の声
「いやー、プログラマって宇宙人みたいな感じがあって、、、。きっと向こうから見たらこっちも宇宙人みたいに見えてるでしょう、、、。」
じゃあどうするかっていうと、結局のところプロジェクトマネジメントの問題になります。推薦書はすでにリンクで示しました。この意識を共有できれば、少なくとも大失敗はないでしょう。
開発中の仕様変更なんてよくあることなので、最初に出てきた仕様書の書き方なんて、些細なことです。
プライドを持たないっていうのは、違う気がします。プライドを持って、技術に対して誠実であることが重要だと思っています。最初は「あの人、全然分かってないよね」と陰口を言われることもあるかも知れませんが、「でも、一緒に仕事をして楽しいね」と言わせるようにしてみてください。プログラマもついてきます。
「プロジェクトマネジメントをより楽しむには、自分の得意な分野には手を出すな」と言う人もいます。
そういった仕事をしています。
プログラマに負担がかかる事はよくあることだと思います。
理由は、仕様がはっきりしないからです。
プログラマは、この仕様は、何をやりたいのかがはっきり解りたいだけなのです。あいまいに仕様を出されてもプログラマは、詳細に、ロジックを完成しなくてはいけないので曖昧なほど後々総合テストとかになるとあわてて直すはめになるのです。
プログラマに細かに指示を出す立場ですとやはりプログラマ同等の知識が必要不可欠だと思います。
プログラマの疑問や相談に答えられないまたは、質問を長期に棚上げしてしまうとプログラマは、適当に作ります。多分・・・
後々の工程で吸収しなくてはならないのでかなり厄介になります。残業も増えます。やる気もなくなります。
プログラマの要求に必死で答えてください。そうすれば、いいものができると思います。
質問が終了した後でも、ご返答ありがとうございます！
＞プライドを持たないっていうのは、違う気がします。プライドを持って、技術に対して誠実であることが重要だと思っています。
技術者で実際に作業する方にはその気持ちは非常に大事だと思います。しかし、今回の自分のポジションでは、プライドはただの見栄になってしまうと感じています。
自分は今回のプロジェクトが終了するまでバカ一直線でやるつもりです。仕事が完了すればそれでよいと感じています。
きっと、陰で言われてしまう事も多いでしょうが、覚悟はしています。
ありがとうございました。
実際にそのプログラマの方に聞いてみるのがいいと思います。
でも、プログラマの言いなりになる必要はないと思います。
わたしもプログラマです。
上でmouitchouさんが書いていらっしゃいますが、下手にプログラムのことなど知っているより、業務ルールを知悉している方がずっと重要です。この辺りを明快かつ詳細に伝え、また質問しやすく接して頂けると大変助かります。
それから仕様変更についてですが、もちろん仕様をガッチリ固めてスタートできればベストなのですが、現実には必ず作業途中で変更が発生するものと思われます（少なくともわたしの仕事はそんなのばかりです・・）。
質問者様はきっと、変更したい社内意見とプログラマとの間に挟まれて辛い思いをすることになるでしょう。
個人的に一番重要だと思うのは、変更可能性の有無を断言することではなく、「これで大丈夫なはずだけど、変わるとしたらこう変わる。こっちの方向に変わることは業務ルール上あり得ない」といった、「幅」を教えてあげることだと思います。業務アプリを作っているプログラマは、「ない」と言われた仕様変更が続々と発生してくることには慣れているはずなので、言われないでも自衛的に変更可能性を織り込んで書いているものです（わたしはそうです）。このとき「最大でどの程度の可能性があるのか」がわかるだけでも非常に楽です。
断言するのが責任だと思われるかもしれませんが、社内的に怪しいようなら本音を教えて欲しいです。変更を伝えるときの担当者様の心苦しさもわかっていますし、お互い任務ですから率直にお話したいです。
それから、プログラマ（これが実装者レベルのことなのか、向こうにかなりまとめてくれる人がいるのか今ひとつわかりませんが）側から「こんな感じ？」なドキュメントやら画面プロトやらといったフィードバックが色々返ってくると思いますが、これらは時間の許す限り細かくチェックしてやってください。
後で言われると厳しいだけでなく、ロクに見てもらってなかったりすると単純に凹みます（笑）。
仲良く頑張ってくださいね☆
専門分野にいると、とかくその分野だけで通じる言葉・図式を使いがちになり、実際そうすることで、情報伝達が効率化されますが、いざ、そういった専門用語を知らない人が入ってくると、とたんに情報伝達がストップしてしまいます。
「誰にでもわかる書類」を書くためには、用語を知らない人に対して、小ばかにせず、自分の知識を深めるチャンスと考え、丁寧に教えていくことが肝要かと思われます。