• 締切済み

責任の範囲について

社内の業務をエクセルVBAで効率化をしています。 技術的には勉強と運用でカバーできていますが、問題点として 責任の範囲が曖昧といったことが出てきています。 一部だけの改良を聞いていたので対応し、 後から、これも必要だった、あれも…など、設計を変えないといけないような話になってきたりします。 打ち合わせをきちんとしていないのが悪いと言ってしまえばその通りなのですが、経験を得ている途中ですので… 外部に外注する場合であれば、取り決めされているのかなと思いますが、 ルールの引き方を知らないので、なにを参考にしたら良いか教えていただけると助かります。 「素人のプログラムは渡された人が迷惑」等は問題点として把握しております。今回の質問からは話がぶれますのでこのことについては意見してもらわなくて大丈夫です。 よろしくお願いします。

みんなの回答

noname#236874
noname#236874
回答No.3

アジャイルも良いですが、テスト駆動で乗り切りましょう! しっかりとテストをして、テストの範囲でなら動く。 それ以外は対象外としましょう。 テストに不備があればあなたの責任だし、テストに問題がなければ、あなたの責任ではありません。 この基準でいきましょう。 責任に関しては、さらに、上司と相談しましょう。 主に、バグや不具合が起きた時に、誰が責任を取るのか?という話です。 念のために、エクセルでの効率化は、ぜんぶ自分の範囲内なんですよね? 他人のプログラムをいじって、責任の所在が、とかいう話ではないですよね?

kaiketum
質問者

お礼

責任の範囲は間違ってないと思います。 ただ、わかっていても業務は進めていかないといけないので… うまく書けずすみません… 書いてくださりありがとうございます。

  • kon555
  • ベストアンサー率51% (1842/3559)
回答No.2

ふふ、大丈夫ですよ、外部に外注する場合でも大量に発生している事態ですとも・・・(瀕死) つまりSEじみた事をする以上、不可避な自体ということでもあります。まあSEに限りませんけどね。実際の物品の製造業でもよくある話です。 これを出来るだけ回避するには、やはり要求してくる側との打ち合わせしかありません。要求定義、というプロセスにあたり、実際の開発業務でも非常に重要なポントです。 「要求定義のチェックポイント427」など、検索すれば参考になる書籍は多々出てくると思います。 また、せっかく自社の業務なのですから、まずは貴方が「実際にその作業をやってみる」というのは非常に効果的です。 別に習熟する必要はありません。何回かやってみて、実際に使用者が困っているポイントが感覚で把握できれば十分です。 この辺りは、貴方が業務改善・効率化を専業としているのか、それとも何か別の仕事の兼務なのかにもよりますけどね。 責任の範囲、という話であれば、上記のようなやりとりで要求や仕様が固まった段階で書面などの形を残せばいいでしょう。 社内ならメール程度で十分です。「打ち合わせ通り、以下の用件で作りますよ。不備、訂正、追加は○日後までに連絡ください。・1.~~という動作を1ボタンで・・・」などですね。 あ、それとどこまでやっても後から「実はこんな機能も・・・」とか「こんなケースも・・・」は大量に出てきますよ。それは宿命です。 なので開発時はコメント等を大量に残しましょう。それが半年後の貴方を助けます。 頑張ってください。

kaiketum
質問者

お礼

大丈夫ではなさそうですが、大丈夫でしょうか?(笑) >貴方が「実際にその作業をやってみる」 最大の効果があるのですが、これをすると「この前勉強してくれたから、今忙しいから手伝いにきて」という謎の工程が発生したりします。 専業でもないのですが…仮に専業としたとして、 自分の能力アップが必要なのと、 今のままでは相手の甘えや丸投げに嫌な思いをするので…(社風です) 定義もフローも書面にしておきたいと思います。 要求定義のチェックポイント427、今から勉強します。 ありがとうございます。

  • togurin
  • ベストアンサー率45% (81/180)
回答No.1

お一人でやられているのかと思いますが、アジャイル開発を参考にルールを決めると良いと思いました。 調べればちゃんと解説されていますが、例えばです。 あなたに課せられる1つの要求をこの時期までやります、と言ったこと要求した人、それ以外の人と合意を取りつつ1つ1つ繰り返して効率化のVBAを改良していく感じです。 一度に並行して全部やろうとせず、短いスパンで柔軟に1つ1つ改良を重ねていき、よほど優先度が変わらない限り、そのスパンの間はそれ以外の要求は基本受け付けないと言ったスタンスを取り、それを要求する人にも理解してもらうことです。バージョンなどをつけ、何に対応したかなどを明記しておくと他の人にもわかりやすいでしょう。 そうでないと、随時各所から要求がありそれを全部満たそうとしていると整合性が取れなくなってきて、設計を変えないとならなくなる可能性もあります。 それでもどうしてもそうなる状況が発生したらのなら設計を変えるためにある程度の時間をもらい、それ以降の追加要求は受け付けないとか、ある程度確固たるスタンスなりルールを共有しないと、あなたに要求を言いたい放題になってしまうと思います。 それができると責任の範囲はあなたが要求として引き受けて改良したところまでとなるはずです。バージョンや対応状況はそのためにも明記しておくと良いと思います。それ以外はまだ未対応ですと言えるので、あなたの責任の範囲外になります。

kaiketum
質問者

お礼

アジャイル開発は言葉として知っていましたが、理解して実際に取り入れていきたいと思います。 言いたい放題は既に、遭遇してきました… お互いにプラスになるルールを作ってやり取りしたいと思います。 ありがとうございます。

関連するQ&A