社内SEをしている方に質問です。

質問

現在３０歳で社内SEをしております。

前は開発PGとして、主にプログラムを担当していたのですが、
転職で上流工程を経験出来る環境にいます。

ですが、最近の悩みとして自分でなかなか仕様を決められません。
納期をどんどん遅らせてしまい、かなりへこんでいます。

こんなに自分に解決力が無いとは思いませんでした。
問題があった場合にそれを回避する方法がすぐに思いつきません。
あれこれ考えてしまい、長時間考察に使ってしまい、納期が遅れます。
いつも人に頼ってばかりいます。

３０にもなって情けないばかりです。

そこで、SEをしている方に質問なのですが
どうやったらスムーズに仕様を決める事ができますか？
仕様を決める際にどういった所を特に気をつけて仕事を進めていますか？

どういう努力をすれば良いのでしょうか？
今考えているのは業務をもっとしる事なのかなと考えていますが、
もしそれ以外にあれば教えて頂けないでしょうか？

どんなヒントでも結構ですので、ご教授お願い致します。

回答No.4

Brian12

回答No.１及び2のお礼を踏まえて、お応えします。

　トム・デマルコが提唱する構造化分析データフロー図（DFD）でのモデリングをお薦めします。
　いろいろなモデリング手法がありますが、私はこれが一番良いと思います。

　「構造化分析とシステム仕様」は１９８０年代の初版ですが、現在も版を重ねていると思います。
　私は、構造化分析DFDは人間の情報処理を図式化する手法だと捉えています。

　現状をDFDでモデリングした場合に、階層構造のあるレベルの処理の数が７以上であれば複雑であると評価します。
　また、それらの処理で受け渡しをするデータの流れが交差している場合は、処理の分割が不適切であることを示しています。
　従って、より良いモデルにするには、処理の数を７以下に減らし、データの流れが交差しないように処理を統廃合するのです。

　業務フローやUMLでは、この様にはできません。
　DFDの表記法を守ることで、改善箇所が見える様になることは素晴らしいと思います。
　但し、物事及びことばの構造的な解釈が必要です。
　これは、実務に携わっている方が理解していると思います。
　しかし、この解釈が誤っていた場合はモデル図に反映されるので心配はいりません。

　さらに良いことは、要件レベルで整合性の確保ができることです。
　スムーズに仕様を決めることができるのは、出力が明確に定義されていることです。
　しかし、出力が明確でもシステム全体としての整合が隠されていなければ、手戻りになります。
　これは構造的にモデル図を作成することで、実現しています。

　これらのことは実際にDFDでモデリングしないとわからないことと思います。
　しかし、何と言っても関係者が指をさしながら話ができることが良いことです。

　部門の責任者の方に提案しては如何でしょうか。
　尚、私はオリジナルの手法に少し手を加えています。
　大事なことは、自分なりの工夫をすることでよりよい物になるのだと思います。

　では、笑顔で朗らかに積極的楽天的にいきましょう。

お礼

DFDはちょっと挑戦してみる価値はありそうですね。
ありがとうございます。
返信が遅れました。m_ _m

回答No.3

Tasuke22

> 今まさに生産計画を支援するシステムの仕様決めを行っています。部署ごとにやり方が微妙に異なるのでまとめるのが難しいです。

計画問題は如何に割り切るかがポイントでしょう。
インタビューは計画担当者のこの人が出来る、と周りに認められる人から行います。
ルールといわれる、この場合はこうする、というものが50も出たらもう聞くことは無いでしょう。
このルールには大きく2つにわかれます。
１つは絶対条件
１つは良い計画にするための考え方
ゲームで言えばルールと勝つためのノウハウです。
支援システムではノウハウの部分をバッサリ捨てます。
そこは人間に任せるわけです。
将棋のプログラムで言えばプログラムで対戦しない。
人が差した時に、ルール上やってはいけないことは指摘する、です。
例えば、この部分にあるロットを入れたら別のこのロットの納期が間に合いません、とかいう指摘です。
ロット作りにもノウハウがあるでしょうが、それも人任せです。

これで部署によって微妙に違う、という部分が無くなりませんか。
絶対条件の数は意外と少いでしょう。
生産計画で営業に絡む部分に絶対というものがありません。
所謂、営業判断というものが出て来ます。
そのような部分はシステム上に取り込まない、です。

まあ、簡単に組み込めるものがあればいれてやってもいい、という軽い感じで。
つまり、ノウハウを組み込めば組込むほど、解を求めるプログラムに近づくわけで、泥沼に陥ります。
何が問題なのかさえ分からなくなってくるでしょう。
今、正にそういう状況でのこの質問ではないでしょうか。

システム側からしたら、計画の結果がデジタル化さえしていれば良い。
計画がどう作られても構わない、というスタンスです。
絶対条件さえプログラムが押さえてくれていたら、人も考え違えで奥深く考えることが無くなるので、楽になります。

上司や各部署で不満の声が上がっても言い逃れは簡単です。
まず、システム化して形を整えて、システム全体をつなぎ合わせましょう。
そこが最重要課題ではありませんか。
如何に計画支援システムを強化していくかは、その後に任せませんか。
というものです。
（勿論やる気は無いです。コストが掛かり過ぎの割に成果が出ないため）

計画問題が理解できない人は、計算したらポンと答えが出ると思い込む、私にしたらバカか宗教的な発言をしているかと思える、システムに邪魔な存在です。
尤も、計画問題をどう処理すべきか私のようにズバリと言う人には出会ったことはありませんけど。

私ははっきりしています。
解の探索空間が10の30乗を超えたら解を求めることをするな。
10の30乗以内なら数学的な技やシミュレーションを使う、です。
この場合でも、スーパーコンピュータの利用も含めたハードウェアからの検討が必要です。
ただ計画問題で解の探索空間が10の30乗に収まるものを見たことがありませんが。
つまり計画問題はスーパーコンピュータを使う問題以上の困難な問題ということです。

この見解一つで、何十万、何百万のシステム開発コスト削減になると思いますよ。

お礼

>まあ、簡単に組み込めるものがあればいれてやってもいい、という軽い感じで。
つまり、ノウハウを組み込めば組込むほど、解を求めるプログラムに近づくわけで、泥沼に陥ります。

そうですね、こういう感覚は絶対必要だと思いますね。
ユーザーに自由度を適度に与えないと、本当に嫌がられる事も多いと思いますので。

本当に色々とアドバイスありがとうございます。

お礼が遅れました。

回答No.2

Tasuke22

システムの枝葉のプログラム仕様から始める人がいましたが、あれは最低ですね。
企画と要件定義のフェーズはどのようになっていますか？
その内容いかんによって行うべきことが変わってくると思います。

私の経験では、ユーザが企画書を持ってきて、要件定義を行なって欲しいと依頼して来ましたが、企画書が企画になっていない。
仕方がないので、企画書を作ったこともあります。ユーザには喜んで貰えました。

企画書には、会社の存在意義が書かれていますか？
会社のコンセプトは何ですか？
会社の目的は何ですか？
会社の目標は何ですか？
目標を実現する手段は何ですか？
結果を評価し手段にフィードバックする仕組みはありますか？
それらを図にして矛盾は生じていませんか？
などなど、会社そのものを分析していなければ企画も有り得ないでしょう。

システム設計に入る前に要件定義が出来ていないなら、それを行う必要があるでしょう。
業務のヒアリングで振り回されるなど、有りえない話です。
基本、ヒアリングしても本当に知りたいことは出てきません。
それを言葉だけ鵜呑みにするから振り回されるのでしょう。
インタビュー技術を磨く必要もあります。
インタビュアー次第で本当に喋りたいことを言えるようになるものです。
しかし基本は分析です。
現行業務のフローは存在しますか？
新システムを想定した、新業務フローの作成はしていますか？
それらがあればインタビューのポイントも分かりやすいでしょう。
逆に言えば分かりやすくなるフローを作成しなければいけません。

新システムをA4一枚の図に出来ますか？
これによりシステムとサブシステムの関係をはっきりさせます。
サブサブシステムをサブシステムと思い込むようなミスを防ぎます。
声の大きい部署は自分のところをシステムの中心に置きたがるものですから。

これらは要件定義の一部の作業ですが、全体像を把握し自分の頭の中で具体像が浮かべば、システム設計もスムーズになるというものです。
ポイント中のポイントはデータベースでしょう。
現行の論理データベースの把握と、新システムの論理データベースの設計が新システムの基幹となります。
論理データベース図を見るとシステムの全容が見えて来なければいけないと思います。
このデータベースの管理・表示・更新・加工が必要なプログラムです。

なお、計画問題が入っている場合は逃げます。
計画問題とは、生産計画とか配送計画とか出荷計画とか勤務予定も入るでしょう、などなどの類で、順列組合せで場合の数が爆発する世界です。
逃げるとは、これをプログラムで解を求めるのを止める、ということです。
その代わり、人間が計画しやすいように、計画作成支援システムに切り替えてやります。
言ってみれば、計画専用ワープロといいますかCADといいますか、そんな類のプログラムにしてやります。

ざっと流したのでヒントになっているかどうか。
役に立てば幸いです。

お礼

>新システムを想定した、新業務フローの作成はしていますか？

↑これは確かにありませんね、恐らくどこかにあるはずですが
。図を見て流れが分かる様なものを作成してみようと思います。

＞人間が計画しやすいように、計画作成支援システムに切り替えてやります。

↑今まさに生産計画を支援するシステムの仕様決めを行っています。部署ごとにやり方が微妙に異なるのでまとめるのが難しいです。
やはり基本的な事が分かっていない様です、私は。それを踏まえた上で俯瞰的に行動しなければなりませんね。

全体を理解するだけでなく、それを第三者が図やフローにして表現出来る事が大事なんですね。非常に勉強になります。

ありがとうございます。

回答No.1

IDii24

外部のSEはヒアリングばかりするが、内部のSEはヒアリングなんかしているようでは本来はダメ。むしろ自分で組み立てられること。つまり業務を知っているのはもちろん、各部の関係も知り、しいては経営方針も知る事。
「今」を見るのではなく3年5年後を見る事。さらにシステムのライフサイクルを予想し、それまでの運用予算を組むこと。
ヒアリングはしてもよいけど疑いをもって臨むこと。大体のユーザーは自分の作業が正しいと思っているけど、実は殆どが無駄な処理をしているのです。システムを組むのは業務を整理し常に戦略を持たないとダメです。
つまり、今の部門でその対象業務をするのが良いのか、あるいは他の部門と連携した方がよいのか、あるいは外部に頼むのがよいのか。根本的にシステムを組むのは人事や業務戦略に関わる事なのです。便利になることは目的ではありません。また便利になり効率があがると何人の首を切れるか。どれくらい売上が上がるのか。そこまで考える必要があるわけです。

お礼

＞外部のSEはヒアリングばかりするが、内部のSEはヒアリングなんかしているようでは本来はダメ。むしろ自分で組み立てられること

↑確かにユーザーにヒアリングをすると部署によって意見が異なるため毎回振り回されています。自分なりの正しいビジョンを持つのは必要と思います。（それが難しいのですが。。。）

＞また便利になり効率があがると何人の首を切れるか。どれくらい売上が上がるのか。そこまで考える必要があるわけです。

システム構築の目的をしっかりと把握していない事が原因かもしれません。言われた事をただやってきた罰かもしれませんね。。。

道のりは長いそうです。
やはり私は勉強不足ですね。全てにおいて。

アドバイスありがとうございます。大変参考になります。