業務運営が出来ていない場合の対処

質問

毎度お世話になっております。

私は組込み系の開発を行っている企業に勤めているのですが、
弊社の業務フローで悩んでおりご質問させて頂きました。

以前(約1年前)に開発案件受注から設計書作成・コーディング・テスト→納品との流れが判る業務フローを作成し、運用しているのですが・・・
(作成までその様なフローはなくその場仕事でした)
フローの流れが守られておりません。

フロー自体は複雑ではなく、受注→基本設計→詳細設計→テスト→納品との流れを図で記述した程度のものです。

現状、受注を受け基本設計が作成終わるか終わらないかでコーディングをし、仕様も明確になってないままテストを行っており客先納品の間際になって詳細設計を作成し納品している状況です。
このままでは、不具合の乱立・仕様検討不足による漏れが出てもおかしくないと思います。
ルールを細分化し厳守させようとしましたが効果薄でした。
口頭による仕様変更追加等も多々あります。

フロー通りに運営するにはどこから手をつけていくかすら不明になっています・・・
アドバイス・経験談などありましたご教授お願いしたいと思います。

回答No.4

sabidnsk · ベストアンサー

文章を書く・記録を残す・資料をメンテナンスすることは面倒くさいですし、その意味・有用性がわからないとなかなか着手できないですよね。

これは小さなツールを導入して有用性を感じてもらったり（その場合は熱意があって信頼できる推進者が必要ですが）、プロジェクトマネジメントの考え方などを少しづつ社内で共有したり、ひたすら上司の方が定期的に書かせる、チェックする、議論するといったことを率先してやるしかありません。（部長さんのやり方では上手くいかないでしょう・・・。）

本当に組織化されたソフトウェア開発会社（たとえばIBMなど）はこれらのルールを守っているか各プロジェクトに監査が入り、遵守しているかをチェックされ、従っていないと厳しい処置がとられます。このような管理を行うことで現場の負荷はずいぶんあがりますが、プロジェクトが炎上火しなので最終的には楽になり、またコスト的にも大きく安上がりになることがわかっているようです。

難しい本が多いですが、何かプロジェクト管理の本を読んでみるとよいと思います。たとえばこんな本はプロジェクトマネジメント素人の私でも理解できました。
http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E7%8F%BE%E5%A0%B4%E3%83%9E%E3%83%8B%E3%83%A5%E3%82%A2%E3%83%AB-%E8%83%BD%E7%99%BB%E5%8E%9F-%E4%BC%B8%E4%BA%8C/dp/4822229793

あと、無料で使える簡単なツールもありますので、負荷の増えないものから順次導入していってはどうでしょうか。
特に工程表ツール『開発マイルストーン』は無料にもかかわらずすばらしいです。既存の工程表の変わりに使うだけで、計画と実績の対比が簡単にでき、遅れや工数超過が可視化でき、どうしたら挽回できるのかを考えることができます。（今のやり方は計画と実績を対比せず、計画が役に立っていないと見受けられます。計画はそう簡単に変更してはいけません。）課題管理表もそれなりに使えるかもしれません。

http://tools.rightclicksright.net/data/frame_99102.aspx

さらに、仕様の項目は各プロジェクトで共通の項目が多いと思いますので、今回のプロジェクトで一覧化した仕様の項目を整理し、今後のプロジェクトの仕様管理の標準テンプレートとして活用してはどうでしょうか。このツールは特に工数の負荷は増えず、効果も実感しやすいので、きっと使ってくれると思います。

お礼

回答有難う御座います。

確かに有効性を感じれば考えも変わるかもしれません。

日毎に集計を取るとか、定期的に○○がかなり苦手っぽいです。
(余談：朝の朝礼だけは毎日欠かさず行います(部長による30分の無駄な週の予定の確認と言う名の演説))

開発マイルストーンの紹介有難う御座います。
以前弊社でも個人的に入れている人がいましたが、運営できずに断念した模様です。
今回私も、DLして工数を入れてみましたが・・・見れる状態ではありませんでした。
原因(1)：予定と実績の掛け離れ　→予定1/1～1/31　実績3/1～3/5　　予定4/1～4/4　実績2/1～2/27　等々
原因(2)：実績の記入なし　遅れ50日とかが普通に羅列されていました。

ただ、今現状できていない部分(記入する・予定を守る)が可視化できるので
最初の小さな一歩でもいいのでツールの導入運営に着手して行こうと考えています。
すぐには良くならない　最初から完璧はない　との精神でやっていこうと思います。

回答No.3

sabidnsk

当方が察するに、利用されているフロー図はソフトウェア開発の際に当たり前に行っているプロセスに過ぎません。これがあるからといって、品質、スケジュール、コストを役に立てるためにはまったく役に立たないと思います。

必要なのはプロジェクトマネジメントです。簡単でも良いので工程表による進捗管理や、問題管理、予算管理、リスク管理などをきっちりと行うべきです。

特に一番問題になっているのは変更管理の手順が不明確なところにあると思われます。これには二つの取組みが有効だと思います。

(1)仕様項目の一覧化と事前の仕様の明確化
まず仕様で決めるべきポイントを一覧化し、決まっていないところと決まっているところを明確にして決まっていないところを徹底的につぶしていってはどうでしょうか。顧客自身、何を決めなければいけないことが何か認識していないケースも多々あると思いますので、一覧化して議論するのはきわめて有効です。

(2)仕様変更管理手順の明確化
現在は現場の方が勝手に仕様変更を受け、その内容がチーム内に共有されていない結果、スケジュールの遅れ、予算の超過、品質トラブルの発生といった問題が起きていると思われます。
このため、仕様変更のやり取りはリーダーに一元化して他のメンバーは仕様変更を受けないことにすべきです。さらに、変更依頼の履歴は必ず文書に記録し、これらをチーム内で共有・ディスカッションして他の箇所やスケジュール・コストに大きな影響を与えないか検証した上で受けるかどうかを判断します。また、変更内容は必ず記録し、顧客と共有し、さらに変更分の費用は請求すべきです。これにより仕様変更自体の減少と、言った言わないのトラブルを回避することができるとおもいます。

お礼

回答有難う御座います。
>簡単でも良いので工程表による管理
行っているのですが、最初の工数見積り時点まで記入しそれ以降はメンテナンスを行っていません。
行ったとしても初期状態から遅れが出てそれに合わせた予定の引き直しと言うその場限りの予定表にしかなっていないのが現状です。
ここ数週間で多少記入が見られますが、それでもその場限り感があります。(納期に余裕のある時期は記入され、納期間際になると放置状態です。)

>(1)仕様項目の一覧化と事前の仕様の明確化
一度一覧化を図ってみたいと思います。
ただ後述している通りの問題があるので、徹底させるのが一番の問題となってくると思います

>(2)仕様変更管理手順の明確化
以前から行っておりますが・・・リーダが不在で開発の最前線に部長が出て全打合せ・仕様変更による修正の打合せを行っており、
部長の考えが「俺がいないとダメだろ」との事で履歴を文書に記載は困難な状況です・・・(メールが大嫌いな部長なのです)
これは、一回言った言わないのトラブルになってから対処したほうがいいのでは？とも思っておりました。

お礼を記述して思ったのですが、文章を書く・記録を残す・資料をメンテナンスする部分が非常に弱いと痛感しております。
どんなに良いシステムを導入しても、良いマネージメントを行っても運用出来なければ効果が上がらないので
まず”書く”という所からのアプローチを行って行きたいと思います。(基本的すぎて恥かしい限りですが・・・)

質問内容が変わっていますが、書かない人間に書けと言ってもダメだろうし書かないと次ステップに進めないような
業務体制を取っても後で書くで終了してしまいそうです。

回答No.2

aokisika

＃１の方がおっしゃるように。フローが守られないのは、守られない原因があるからです。

ところで、↓の本が参考になるかもしれません。
http://www.yononaka.net/toshokan/penguin.html

お礼

回答有難う御座いました。
お礼が遅くなり申し訳ありません。

本　参考にさせていただきます。

回答No.1

nori_007

フローは作っただけではダメだと思います。
現状なぜ、フローが守られないかを調査し、原因を突き止め、改善する事で結果フローが守られるのではないでしょうか。

有りそうな原因として、営業が仕様も確認せず仕事を受注し、納期も短く、とにかく作り納品して、修正が発生しの繰り返しなる等は、愚の骨頂だと思います。だいたいが口頭による仕様変更なんてあり得ません。

お礼

回答有難う御座います。
お礼が遅くなり大変申し訳ありません。

フローがなぜ守られていないかを調査して行きたいと思います。
【中間現状】
フローが守られていない理由として現状は下記があげられる事がわかりましたのでそこからアプローチして行きたいと思います。
(1)フローの存在すら知らなかった。
(2)優先順位がコーディング　>>　設計書　になっていた
とりあえず動いてからだよ　と言われました。

意識改善を含め問題の改善に努めて行きたいと思います。