ＳＥをされている方の提案方法

質問

私は、簡単なプログラムを組める程度で（VBA ＡＣＣＥＳＳ ＶＢ）
便利屋さんという中途半端な立ち位置です

本格的にシステム作成の流れを見てきたわけではないので
この作り方で大丈夫なんだろうか？後々、他の人が変更する場合はどうするのか？など、
ぼんやり不安をかかえていますが、後任の育成や対応策のことも相談を進めています。

さて、質問内容なのですが
最初のころは
「エクセルの再計算ボタンをセル内に大きく置けないだろうか？」と聞かれ
できるんかなぁ？？といった感覚で、調べて動かしてみて
使ってもらってＯＫが出ればヨシといった形でした

でも、長く同じポジションにいるうちに
「100個ほどあるファイルの必要なシートの必要な行を1つのシートに貼り付けたい、できる？」といった
実際ファイルをみせてもらわないことには何にも言えないような、、
流れはそんなに難しいものではないからと、作りかけてみたものの、
予想外なデータの作り方だったり、シート名がばらばらだったり等で
あらら、と思うことがよくあります。別の方法で対応できてはいますが、、、

依頼されている方は、ぼんやりとした要望で出来るかできないか聞いていて、
出来るかできないかの判断をするための私の聞きたい詳細を、
依頼者から聞き出せていない状態だなぁと思っています。

もらったファイルを見てプログラムしながら、
作りながら考えながら作りながらの対応が多いです、、

そこで
作る前に打ち合わせをしておくと、お互いに少しはよくなるかなと思い始めたのですが

かといって、どんな画面が良いですか？とぽんっと投げるわけにもいかず
サンプル的な画面を何種類か作り印刷して説明をすると、話が広がる？のかなとか思ったり、、

どういうボタンが必要ですか？というより、
この場合だと　期間の指定と、番号の指定で検索出来たほうがよいですね？とか？

自分だったらこうあってもらうと助かるといった視点で提案？

すみません　話が広がってしまいましたが、、
どんな風に身につけられたのか、勉強されたのか幅広く教えていただけると助かります

回答No.4

boruto1126

システムエンジニアを２５年やっているものです。
今までの経験で述べさせていただきます。
参考にしていただければと思います。

今回のパターンで絶対やってはいけないのは、プログラマーさんの考えだけで作ってしまって、
最後に、依頼者にできましたという開発方式はやめたほうがよいと思います。
へたをすると、もう一度１から作り直すはめになるからです。

今回、私だったら下記のように進めます。

（１）まずは依頼者の要望を細かく聞いてください。
　　　わかる部分は、書面でまとめてください。
　　　漠然としている部分は、あなたが幾つか案を作ってこれも書面でまとめてください。
　　　画面が必要であれば、画面も作ってください。
　　　このとき、一番いけないのは案もなくユーザーにどうしましょうかと聞く事です。
　　　これは、SEとして一番いけないと思います。必ず、いくつか案を考え依頼者に聞きましょう。
　　　そうしないと、「このSEはあまりできる人ではないな」、と思われるかもしれません。
（２）（１）の内容をとりあえず、依頼者とレビュー（打ち合わせ）をしてください。
　　　これで第一段階の仕様書を作り（簡単でいいと思います）、プログラムを作ってみましょう。
　　　たぶんそんな完璧な物は作れないでしょうが。
（３）最初のプログラムができたら、とりあえず依頼者にすべてを見せて指摘（修正内容等）をうけましょう。
　　　このとき、必ず書面で議事録をとってすぐに依頼者に見せて今後の修正内容を確認しましょう。
（４）開発期間にもよりますが、（１）～（３）を数回繰り返し、だんだん完璧なものに作り上げていきましょう。
　　　今回の場合は、スパイラル方式（何回もユーザに見せながら完璧な物にする）がいいと思います。

この作業方法で気をつけなくては行けないのは、下記２点です。
（１）必ずすべてのレビューに関して議事録をとっておき、あなたと依頼者で言った言わないという事はなくしましょう。
（２）依頼者が毎回全然違った事を言ってなかなかプログラムが収束しない場合で、開発工程がオーバーするようであれば、その旨をきちんと依頼者に伝えて、対応方法を考えてください。ある程度で妥協してもらうとか。

何回も言いますが、依頼内容、議事録は必ず書面で残しておいてください。あとで困りますので。

プログラムがんばってください。

お礼

boruto1126さん　ありがとうございます

>書面でまとめる、画面作り、提案
ですね。

ファイルの構図や流れが頭にあって
”こんな作業が必要だ”と自分が気がついて
プログラムを組んでいるだけの状態と

人が”こんなのできる？”と言うのの対応は
まったくもって別物ですね、、

便利屋という中途半端な立ち位置のせいもありますが
「画面はこうで、ボタンはこう」と指示がもらえずに、
なんでー後から言うんだろうなーと悩む日でした

相手にどんなふうに使うかのイメージをつくってもらうところからなんだなぁと、、

勉強になります

回答No.3

noname#214300

社内でSEをしている身から言うと、ご質問の手合いには「出来ません」「知りません」「上司に言ってください」といって、確実に逃げる作業ですねぇ……。（簡単に言うと、会社の利益の貢献にならない、無駄な工数ですから）

というのはあまりにあんまりなので。

ユーザ要求があやふやで中々最終形態まで持って行けない場合、始めに画面イメージでも作って「見た目で」説明した方が速いです。
相手はロジックの中身とかは一切考えてくれず、見た目だけで判断しますから。
そして、機能を少しずつ実装していき、ある程度のところでユーザに動きを見て貰う方が良いでしょう。
システムの構築の仕方にはいくつか方法がありますが、ご質問の状況では「プロトタイピング」というのがお勧めです。その辺の情報を集めてみて、ご自分の仕事にフィードバックしてみてください。

＞自分だったらこうあってもらうと助かるといった視点で提案？
そういうのは独りよがりといいますので、あくまで「ユーザだったら助かるだろうな」と考えてください。

お礼

lbn0915さん　ありがとうございます

>簡単に言うと、会社の利益の貢献にならない、無駄な工数ですから
おっしゃるとおりと思っています^^;

そんな中回答いただきありがとうございます

>「見た目で」説明した方が速いです。
そして、機能を少しずつ実装していき、ある程度のところでユーザに動きを見て貰う方が良いでしょう。
はい

プロトタイピングについて調べてみました
ペーパープロトタイピングというページが面白く
本を読んでみようと思います

「こういう画面で、ここに検索ボタンを置きますね」
と画面を指さして確認するだけでは
「うんうん」と言われるけど、
作ると後から、
「やっぱりこの方が、、」となることが予想されるので
紙に出力して、一度席まで持って帰って上司に確認してもらうくらいにお願いしてみようと思います、、

>>自分だったらこうあってもらうと助かるといった視点で提案？
間違えました。
自分がユーザーだったらこうであってもらうと助かるといった視点でした、、すみません

回答No.2

Tasuke22

昔、PCが無い時代、またはあってもビジネスでは使えないような時代、
前もって机上で検討するしか無かったのですが、出来てみてユーザが
思ったものと違う、ということはよくあったことです。

その時代の後半にAI技術をビジネス界に持ち込みだし、AIの技術がどうの
と言っていましたが、実際は作って使って修正し、の繰り返しがそれ以前
の作りより容易なことが重要であることに気が付きました。

今の時代、PCで一人ひとりが直ぐにプログラミングできます、
私なら、打ち合わせしながらプログラムを作って、これでどうですか？
という感じで、打ち合わせイコールプログラム作りにしたいところです。
まあ、最初の一発は時間を貰ったとしても、一回目のレビューで何度も
手直ししながら完成したいところでしょう。

その為には、各種関数やクラスなどを仕事に使うことを想定しながら、
何度も繰り返し勉強したり、修正を何度も行ってもエラーが出にくい
作りを勉強したり、開発が少しでも楽になるツールを開発したり、
本読みとツール作りには余念がありませんでした。

後、社内規程というか、社内のシステム化において、どういった基準や
思想が使われていたのか、資料は揃っていないでしょうが、そういったこと
を少しでも知ることにより、多くのことが予測できたりします。

車の運転に例えると、時間を作ってはコースを歩いて、隅々まで目で確認
しておき、何時どのコースを走れと言われてもいいように準備しておく、
といった感じでしょうか。

最後に目先の仕事の知識だけではなく、ITの国家試験のように広く浅い
知識の勉強も常に必要でしょう。

お礼

Tasuke22さん　ありがとうございます

>作って修正しの繰り返しがそれ以前
の作りより容易なことが重要であることに気が付きました。
なるほど。
大企業の大きなソフトを複数人で作るとなると
仕様が大切になってくるといった形なのかなと思いました
現時点では、作って使ってもらって修正してで充分なのかもしれませんね

>何時どのコースを走れと言われてもいいように準備しておく、
といった感じでしょうか。
あらためて常々意識を高めておくことが大切だなぁと
思いました

ありがとうございます

回答No.1

IDii24

SEは通常は入社の時からSEコースの研修を1年ぐらい受けてます。プログラマは殆ど下請けです。でもSEもプログラミングできないとね程度にプログラミングします。ですのでSEという肩書を書いている人はちゃんと理論から研修されていると思った方が良いです。個人でやってもおそらく見当違いになるし、企業では会社のルールというのもありますから。
で、もし個人で身につけたい場合は本をあさるしかないですが、ご質問の内容からすれば、これはユーザー側の事務処理の手助け程度の案件だと思います。であれば特に方式など気にする必要もなく、メモ程度のやり取りでも十分だと思います。
もしその程度と考えていても時間がかかり、結局人件費を大量に費やしているならまずそれを報告すべきです。一か月かかり切りになれば少なくとも10万以上のシステムであり、さらにメンテが続けば年間運用費と言うことで掛った時間だけ会社が出資していることになります。
さらに100万以上時間がかかるなら、資産として計上し税金が課せられるのでその辺も企業であれば考慮するべきなのですよ。
このようにアプリを作ると言うことはそれができると、それだけ時間と人を短縮できるか、それと作成する金額の差を見て制作を決定すべきで、そのために設計書と要件定義が必要なのです。つまりはお金の流れを上手く管理し、時間を管理し報告する。それがSEの仕事だと思ってください。

お礼

IDii24さんありがとうございます

>メモ程度のやり取りでも十分だと思います。
わたしもそんな風に思います
ただ、メモの内容すらどんなふうにしたらよいのか？
とかいう頭でした、、

パッケージソフトがあって、そこから手を加えるなら
説明もしやすいのかな、、

そんな話を通り越して、お金の流れもお教えくださりありがとうございます

勉強になりました