- ベストアンサー
属人的な仕事と効率化の問題
- 仕事の改善には専門的な知識が必要だと思いますが、それが属人的な仕事として扱われることがあります。
- プログラミングによる自動化は他の部署にも迷惑をかけないために行われました。
- 上司が属人的な仕事に頼らず効率化できる方法を求めているが、説得する方法はないのか悩んでいます。
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
外資系企業で管理職をしています。 エンジニアのグループをまとめています。 そのプログラム、あなたしか知らないというのは、 あなたの強みになります。 もちろん、あなたしか知らないというのは それは同時にリスクではありますが。 が、それはマネジメントから見たリスクで、 それを低減したいなら他の人に、あなたのやったことを 勉強してもらえばいいだけです。 なので、あなたの上司の、 他の方法を考えろという発言は、私には理解できません。 あなたとしては、他の人に勉強してもらうように 勉強会を開くなどして、周りの人と上司の賛同を 得るのが最初ですね（本来はそれは上司の仕事だと思いますが）。 あとは、これによって効率がどのくらい上ったかを 数字で見れるといいですね。 ちなみに私なら、正確な数字は要求しません。 だいたいで十分。正確な数字を集めるのに 時間を使うのがもったいないので。
その他の回答 (4)
- hue2011
- ベストアンサー率38% (2801/7249)
アナログ的やり方がどうだという話にすり替えないでください。 あなた、そのシステムの書類をきっちり書いていますか。 仕様書がしっかりしていて、それを周囲がきっちりレビューしていれば、別にあなたが死んだってだれかが読んで業務は継続できるんじゃありませんか。 属人的だなんていわれるなら、そういう資料をほとんど残さずやっているということです。 もしそうであれば、そんなシステムは廃止すべきです。 私は品質屋ですが、品質はどうやって確保するかというと、ドキュメントとテストです。 仕様書がきっちり書かれていて、その仕様を実現したかどうかを確かめるための試験仕様書が書かれていて、その試験をするためのサンプルデータがちゃんとライブラリ化されていることが最低条件です。 こういう環境でテストをされてでてきた結果は、品質を保証します。 それがきっちり行われていないなら私は承認印は押しません。 もしプログラマが、何も書かずに勝手にプログラムし「動くはずだ」「動く」などと抜かすなら、その人間のプログラマ職を解いたほうがいいと提案します。 そのときに自分はデジタルだ、アナログでいいのか、と言うなら、そのプログラマのやりかたがアナログであり、一切の記録がないものは数えられないからデジタルとはみなさないと私は言います。 あなたの仕事はきっちり書類化したデジタルなものなんでしょうか。 反省するとすればそこなんですが。
お礼
回答ありがとうございます。 ある程度の手順書は作ってあります。 本職プログラマでは無いので、仕様書なる物の存在は知りませんでしたが恐らく当社ではそのような物を作る風習がありません。 故に、他部門で専門で設備のプログラムを書いている人はかなり属人的になっています。 小さい会社では有るので結果的にそうなるのは致し方ない部分もあるとは思うのです。 ご指摘頂いた内容も分からなくは無いので参考にさせて頂きます。
- mochifuchi
- ベストアンサー率45% (67/147)
上司を説得する、というと評価を得る、という意味になると思うのですが、数値化するのはどうでしょう。 私も販管部門で儲けが出せないので、業務の効率化をみんな主に目標に立てますが、成果が見えにくい物もあるので、どのくらい時間短縮された、とか、どのくらい経費削減された、とか言うのが１番いいです。 上司もそのまた上にそのまま言えるし、管理者は数字好きですからね。 ミスがどのくらい減った、とか、今までリカバリにかかってた時間がこんなに削減される！とか言えば、導入の同意を得やすいと思います。 しかしやはり誰でもメンテナンスできることは必要なので、知識がないならない方に合わせたり、導入前に、事前に使用方法の展開を人を集めてちゃんとレクチャーするとかは重要と思います。 おととし、そういう緻密に組まれたツールを作った部員が突然死しまして、解読にほんとに時間を要しました。プログラミングは表の結果は同じでも、紐解くとやはり個性が出てしまうので。 解読出来たときは爽快でしたけどね(笑)！費やした時間は膨大でした。その間は人海戦術でアナログにこなしましたし(^_^;) いずれも会社のためなので、カタブツ上司を攻略出来るといいですね！
お礼
数字は、常に意識して作っているつもりで効果も報告しています。 リスクとして分かっているのならば、代わりの人を作るなどするのが管理職の仕事だと思うのですが、ある程度の使い方の手順書は用意してあって僕が居なくても使えるようにはなっているのですが、それでもリスクが頭をいっぱいにしているようです。 もう少し、しっかりしたデータを用意して説明をする必要がありそうです。 アドバイスありがとうございました。
- saltmax
- ベストアンサー率39% (2997/7599)
どうでもいいことなら やってみるというスタンスでもいいことですが 絶対に失敗できない環境での ヒューマンエラーの根絶方法は原始的なことで 物理的に失敗できなくすることであり、 失敗しても安全にすることです。 また、他の人が見ても間違って進行していないことを 確認できる視覚的要素が必要です。 ミスは必ず起こるもの、物は必ず壊れるものと思っていないと 危機管理はできません。 マンホールのふたが円なのも、照明のあるトンネルに入るときでも 車のライトをつけるのもそんな理由です。 そんな観点で貴方の仕事に対する姿勢を考えれば 既にある成果物に対しても改善すべきことがまだあると思います。 企業風土にもよることですが 導入事案に関しての根回しや承認承諾行為を疎かにすると 同じことでも採否に差が出るので指揮系統や社内の力関係に 無頓着ではいけません。
お礼
上司が替わったことも有り、考え方はそれぞれですでに運用している物に対しても平然と言ってきます。 もう少し、説明のスキルがあれば何とか乗り越えられるかも知れません。 アドバイスありがとうございました。
- kaitara1
- ベストアンサー率12% (1155/9149)
その上司による手作業とあなたの自動化を並行的に試してみたらどうでしょう。結果について話をするのがよいのでは。
お礼
立場が違いすぎて、恐らくやってくれません…。 リスクだ何だと言いつつも、その上司は僕が作った物を便利に使っています。 ごく稀に予期しないエラーを起こしたときに、自分じゃ対処出来ないが故だと思います。 他の回答者さんも数字の面でおっしゃって頂いてるので、並んででは無く性懲りも無く数字で攻めようと思います。 アドバイスありがとうございました。
お礼
かけた時間に対して効果が薄い物はなるべく作りたくないので、数字は意識して作っているつもりです。 なので、どれだけ早くなっているかやぽかミス防止になっているかは上司が知っているはずで、リスクと言いつつも具体的に動くことはしません。 課をまたいで使っている物なので、是非とも他に分かる人を作って貰いたい物です。 あなたのような、理解ある人の下で働けたらどれだけやり甲斐が有るか…アドバイスありがとうございました。