Page2RRS

• 06 Nov 2009 02:07

  2009年11月05日

  ・那須野トレードかあ

  ■_ 心をこめてセル操作

  いやまあなんというか。

  マクロを組んで作業するのは実力ではないですか？ -OKWave
  私の職業は一般事務（派遣）ですが少しVBAがわかるのでルーチン化できるものはマクロを組ん
  でいます。そうすることによってエクセルで1時間かかる作業が1分で終わることがあります。
  
  なので職場では「仕事が早い、仕事ができる」と評価されることがありますが
  先日先輩に怒られました。
  
  内容は
  ・VBAを使うのはずるい・それは実力ではない
  ・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  ・マクロを組むのはズルとしているのを同じ
  と。
  
  確かに手作業で行なえば周りの人と同じくらいの速さなので
  周りと同じ環境であれば（マクロを組まなければ）仕事が早いとは言えないかもしれません。
  
  しかし業務をどう効率よくして作業をするかを考え実践するのも仕事のうちだと思うのですが
  私の考えは間違ってますか？
  入力ミスもチェックするコードを書いたので、ミスはありません。
  
  「マクロを組んだ方が仕事が早くなるがそれが仕事ができる人には繋がらない」
  のでしょうか？
  
  職場にはマクロを組めるのは私しかいません。
  仕事が早く終わったからって遊んでるわけではないし
  時間が余ればさらに効率化できないかを考えたりしています。
  

  こんばんは。
  
  今回の話は、屁理屈でしかありませんが、老婆心なのかもしれませんが、マクロを使わない論理
  というのもないとは言えません。
  
  上の人に、こう聞かされることが多いのです。
  
  「この職場で、あなた一人しか使えないから困るのです。あなたがいないときに、この職場では、
  それを直すことも、止めることも出来ないのでは、困ってしまうのです。あなたが、完璧なマク
  ロを作るというなら、私は、何も言いません。ただ、そう言えないのなら、マクロはこの職場で
  は禁止します。他の社員が使えれば困らないのですが、特別に他の方にも学んでもらうというこ
  とも出来ません。」ということです。必ず、こういうときに、ゼロサムの論理を持ち出してくる
  ものです。
  
  実際、Office にマクロを使えないオプションを付けた人たちは、かなり手厳しい考え方を持っ
  ています。もともと、Office のセキュリティの設定の発想というのは、素人マクロの根絶から
  始まっていて、ウィルスの防除というのは建て前です。素人マクロによって、仕事をダメにされ
  たくない、ということです。だから、プロと認可された、CAデジタル証明付き以外は動かないと
  いう選択肢もあれば、Accessはできませんが、VBAそのものを使用できなくする選択もあるわけ
  です。
  
  マクロは使える人にとっては、何でもないことでも、使えない人には、迷惑だと感じる人がある
  し、いろんな屁理屈は聞かされます。会社によって、Office の開発の人が泣かされるようなリ
  クエストはいくつもあります。職場でマクロ禁止令が出ていないだけ救われています。
  
  質問者さんは経験がないようですが、会社内で、反感を持った人がいたり、社内で一人しか使え
  ない環境では、いろんな妨害や言いがかりがあります。Officeのトラブルがあると、すぐに、そ
  ちらに結び付けます。コンピュータに詳しいと自負している人から、Ver.4 マクロ関数を使った
  だけで、Office やPC自体を危険にさらすとか、言われたことがあります。
  
  それとは逆に、マクロやコンピュータに本当に詳しいということを会社に知られている場合は、
  相当に実力がないと、自分を滅ぼすことになりかねません。趣味でやっている範囲ならそれでも
  よいです。しかし、会社に開発するために入社したわけではないし、数万円の手当てをもらった
  ぐらいでは合わないことが多いのです。一人で、期限があるマクロの開発がどんなに大変か考え
  たほうがよいです。上司が理解があればよいのですが、無理難題を言ってくることがあります。
  社命として受けた以上は断れないし、かといって、特別手当が出るわけでもありません。
  
  私の同僚や先輩は、コンピュータの仕事で一人で必要以上の仕事を抱えて、それに反して、薄給
  で身体を壊して会社を辞めていきました。ともかく、私は、押せ押せの楽観論だけはお勧めしま
  せん。
  
  まず、周りにマクロというものは、どういうものか、大雑把なところぐらいは理解してもらって、
  便利で誰も使えるのだ、というところを宣伝していくことではないか、と思います。
  

  あなたは間違っていないと思います。仕事をするのに自分の持ってるすべてを利用すrのは当た
  り前の話でそれこそが実力です。単なる負け惜しみでしょう。
  
  ただ一つだけあなたが考えておかなければならないのは仕事はチームワークです。
  別にその先輩とやらに気を使えと言ってるわけではありません。他人より早く仕事ができたのな
  らそのマクロの完成度を高めて他人でも使えるようにして、全体の効率を上げるようにしましょ
  う。これはある意味マクロを最初に作るより時間もスキルも必要なことかもしれません。
  自分だけが使えるマクロというのはまだ「未完成」だというくらいに思ってください。
  今、少しづつ顕在化している問題に「Excelレガシー」という問題があります。
  そういうレベルの低い先輩とやらは無視して業務の効率化を目指しましょう。
  
  

  その先輩はクソ以下ですね。この話みて腹立ちました。
  
  (1)VBAを使うのはずるい
  →いうてるやつがせこい企みを持っているだけ。
  (2)それは実力ではない
  →言うてるやつが実力が無くて悔しいだけ。
  (3)仕事が早いというのは同じ環境でどれだけ間違いがなく
  効率よく作業ができるかだ。
  →間違いなくも効率よくもマクロの長所ですから。意味不明。
  (4)マクロを組むのはズルとしているのを同じ
  →殴っておあげなさい。
  

  これは、あまり笑えませんが、似たような笑い話があります。
  
  エクセルでデータを集計して、経理部門で請求書を発行してもらっているのですが、請求書の明
  細として一覧を印刷して添付しています。経理の女性は毎月、一覧表の金額を電卓で計算して合
  計金額を確認しています。他の部署のことなので口出しはしていません。その先輩もそのうちに
  気がつくと思います。
  
  >職場にはマクロを組めるのは私しかいません。
  
  これを機会にエクセルがわかる人を増やすのも試練かと思います。
  
  もうひとつVBAの知識よりも、仕事の流れを理解しOA化するルーチンを発想できる能力（経験も
  必要）が重要でそれをスムーズに業務に取り入れる能力(人間関係を含めて）の方がより難しい
  事であることも忘れないでください。せっかく作ってあげたシステムがあるのですが、意地で使
  ってくれなかったケースもあります。理由は、今まで長い間、この方法で仕事をしてきて問題起
  こしていない、導入することで仕事の流れが変わる、どこのものともわからない（新しい）もの
  は取り入れる必要がないと思っているようでした。
  
  何にでもつき物ですが、新しいことをなすには産みの苦しみが伴い、
  出る釘は打たれるものです。
  

  ご質問者の考え方は間違っていませんよ。
  安心して下さい。
  
  きっとねぇ、マクロやVBAの出来ない人間が
  出来る人間(つまりご質問者)にやっかんでるだけです。
  
  まるで、斧やノコギリだけで仕事してる木こりが
  チェーンソーや電動ノコを使う林業従事者を
  『機械を使うなんてずるい』
  と言ってるようなもの。
  
  確かに完成したマクロやVBAをつかう時点では時間はへりますが実はマクロやVBAを組むのに時間
  がかかります。(勿論、その道の勉強していればその時間は減らせますが)
  
  それと派遣の場合は、貴方の後の後任が、マクロやVBAが出来ないことで、派遣先からいい評価
  が得られなくなって迷惑するとでも言いたいのでしょうね。
  
  自信を持って、なおかつそれをひけらかさず淡々と自分の業務をこなしてください。
  

  他の方とまったく同意見ですが
  >・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  
  同じエクセル使ってますが・・・・
  VBA使えるってこと自体が仕事が出来てるわけです
  自分で覚える努力もしないでなにいってんでしょうかねその人は
  （ただのひがみにしか聞こえません）
  
  VBA知っててもコーディングが遅ければ（BUGとか含んで）
  手作業のほうが早いって可能性もないとはいえません
  
  あなたの考えは間違ってないと思いますよ
  

  先輩の発言は全く間違っています。
  
  おそらくマクロで仕事をしていることが問題なのではなく、先輩が質問者さんと肌が合わないた
  めいちゃもんを付けたのでしょう。マクロと仕事に関しての論理的な問題ではなく、お二人の感
  情的な問題と推測します。
  
  先輩への対応としては、マクロを使って有無を言わせぬ結果を出して圧倒するか、先輩の仕事を
  マクロでさっと片付けてあげて懐柔するか、その両方を使い分けるか、などが考えられます。
  
  別のカテゴリーでもっといい回答があるかもしれません。
  

  ＞・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  アホか。VBAで自動化するのはそのためだろうが。お前は永遠に手作業してろ。
  というのが正直な感想。
  言わせておけばいいんじゃないですか。
  

  ■_ 例外な話

  
  www.hans-eric.com » The Bad Practices of Exception Handling
  
  The Bad Practices of Exception Handling
  
  October 31st, 2009
  Hans-Eric
  
  Exception handling has truly been a blessing to us software developers. Without it, 
  dealing with special conditions and writing robust programs was a lot more painful. 
  But, like any powerful tool, badly used it could cause more harm than good. This 
  article name the top three on my Exception handling bad practices list, all of which I’
  ve been practicing in the past but now stay away from.
  
  例外処理はわたしたちソフトウェア開発者に対して本当に福音をもたらしました。例外処理がな
  ければ、特殊な条件を処理して robust なプログラムを書くことが格段に painful なものにな
  っていたでしょう。しかし他のどんな強力な道具もそうであるように、例外処理も使い方を間違
  えたときには利点よりも害をなすことのほうが大きくなってしまいます。
  このアーティクルでは、わたしが経験したことがあるけれども今はもう使っていないような例外
  処理のバッドプラクティスリストのトップスリーに名前をつけます。
  
  Swallowing Exceptions (例外を飲み込む)
  
  Have you ever come across code like this?
  あなたは次のようなコードを見たことはありませんか?
  
  try
  {
     DoSomeNonCriticalStuff();
  }
  catch (Exception e)
  {
     // エラーを無視 (Ignore errors)
  }
  
  DoStuffThatMustBeDoneDispiteAnyErrorsAbove();
  
  Of all the bad exception handling practices, this is the worst since 
  it's effect is the complete opposite of the programmer's intention. The 
  reasoning goes something like this: Catching exceptions where they don't 
  hurt makes my program more robust since it’ll continue working even when 
  conditions aren’t perfect.
  
  すべての例外処理のバッドプラクティスの中でも、プログラマーの意図を完全に捻じ曲げる効果
  があるのでこの例は最悪のものです。その理由は次のようなものに帰着します:
  例外が傷つけない場所での例外の捕捉はプログラムをより頑健 (robust) なものにします。
  それはコンディションが万全でないときであっても処理を継続するからです。
  
  The reasoning could have been valid if it wasn't for Fatal exceptions; 
  
  Here described by Eric Lippert.
  
  以下は Eric Lippert による説明です。
  
       Fatal exceptions are not your fault, you cannot prevent them, and you cannot
       sensibly clean up from them. They almost always happen because the process is
       deeply diseased and is about to be put out of its misery. Out of memory,
       thread aborted, and so on. There is absolutely no point in catching these
       because nothing your puny user code can do will fix the problem. Just let your
      “finally” blocks run and hope for the best.
  
  
       Fatal exceptions はあなたの間違いではありませんし、あなたはそれに逆らうことは
       できません。そして sensibly clean up することもできません、それが発生してしま
       ったときにはほぼ常にプロセスは deeply diseased であり、何かしら出力しようにも
       使える資源はほとんどありません。メモリーの枯渇、スレッドの中断、などなどとい
       ったものを捕捉するポイントは絶対にありません。なぜならあなたの puny user コー
       ドでその問題を解決できることなどないからです。
       Just let your “finally” blocks run and hope for the best.
  
  Catching and ignoring these fatal exceptions makes your program less robust since it 
  will try to carry on as if nothing happened in the worst of conditions, most likely 
  making things worse. Not very Fail fastish.
  
  こういった fatal exeptions を捕捉してから無視することで、最悪の事態が起きたのにも関わ
  らず何事もなかったかのように処理を続けてしまおうとするので、あなたのプログラムをやわな
  ものにしてしまいますがそれはさらに自体を悪くすることがほとんどです。
  Not very Fail fastish.
  
  So, am I saying that ignoring exceptions is bad and should always be avoided? No, the 
  bad practice is catching and ignoring general exceptions. Specific exceptions on the 
  other hand is quite OK.
  
  ではわたしは例外を無視することは悪いことで、いつでも avoid すべきといっているのでしょ
  うか? いいえそうではありません。bad practice なのは一般的な例外 (general exceptions) を
  捕捉しておいてそれを無視することです。特定の例外について行うのは問題なく OK です。
  
  try
  {
     DoSomeNonCriticalStuff();
  }
  catch (FileNotFoundException e)
  {
     // So we couldn't find the settings file, big deal!
  }
  
  Bad example, I know, but you get the point.
  悪い例ですが、ポイントをつかめたのではないでしょうか。
  
  Throwing Exception (例外の送出)
  
  Here's another bad practice I come across every now and then.
  
  throw new Exception("No connection!");
  
  The problem is that in order to handle Exception we have to catch Exception, and if we 
  catch Exception we have to be prepared to handle every other type of Exception, 
  including the Fatal exceptions that we discussed in the previous section.
  
  この問題は例外を処理するためには例外を捕捉しなければならないということで、仮にわたした
  ちが例外を捕捉したら先のセクションで述べたような Fatal Exception も含め、例外のすべて
  の型を処理するために例外を prepare しなければなりません。
  
  So, if you feel the need to throw an exception, make sure it's specific.
  
  ですから、あなたが例外を送出する必要性を感じたならそれを確実に specific なものにします。
  
  throw new NoConnectionException();
  
  If the idea of defining lots of specific exceptions puts you off, then the very least 
  thing you should do is to define your own application exception to use instead of the 
  basic Exception. This is nothing I recommend though, since general exceptions, like 
  ApplicationException, violate the Be specific rule of the Three rules for Effective 
  Exception Handling.  It’ll make you depend heavily on the message property to 
  separate different errors, so don’t go there.
  
  特定の例外を大量に定義するのを避けることを考えているのなら、あなたが行うべき the very 
  least thing はbasic Exception の代わりに使う自分独自のアプリケーション例外 
  (application exception)を定義することですが、わたしはこれをオススメしません。なぜなら 
  ApplicationException のような一般的な例外は効率的な例外処理のための三つのルールを破っ
  てしまうことになるからです。異なるエラーを分離するためにはメッセージプロパティにとても
  依存することになるので、
  so don't go there.
  
  Overusing exceptions (例外の使いすぎ)
  
  Exceptions is a language construct to handle exceptional circumstances, situations 
  where a piece of code discovers an error but don’t have the context necessary to 
  handle it. It should not be used to handle valid program states. The reasons are:
  
  例外とは exceptional circumstances やエラーを検出すべきコード片を置く situnations を 
  handle するための language construct ですが、エラーを処理するために必要なコンテキスト
  を持っていません。それは正当なプログラムの状態を取り扱うのに使うべきものではありませ
  ん。その理由には以下のものがあります:
  
      1. Performance. Throwing an exception with all that's involved, like building
         a stack trace, will cost you a second or so. Probably not a big deal, which
         is why I concider the second argument more serious:
  
         性能。例外を、スタックトレースの構築のようなそれを引き起こした原因すべてと
         一緒に送出するのは will cost you a second or so.
         大きな問題ではないかもしれませんが、わたしが第二引数がもっと重要であると
         考えている理由です:
  
  
      2. Annoyance. Debugging code where exceptions are a part of the normal execution
         flow can be frustrating. (Eric Lippert calls these types of exceptions Vexing
         exceptions, see the link at the beginning of this article)
  
         わずらわしさ。通常実行フローの一部として例外に置かれているデバッグ用コードは
         フラストレーションとなる可能性があります。
         (Eric Lippert はこの種の例外を Vexing exceptions と呼んでいます。
         see the link at the beginning of this article)
  
    …
  
  Those were the three misuses of exception handling I concider worst. 
  
  What's on your list?
  
  Cheers
  

  ■_ 本日の巡回から

  • プログラミングHaskell - あどけない話オーム社の方曰く「ソフトカバーなのに、ハードカバーのように平たく開ける特殊な製本」だそうです。
  • Plan 9 Gear : Plan 9 Gear based on artwork by Renee French
  • 社内の人間関係について -OKWave
  • お勧めのFPGAボード 2009年版 - ぱた☆へね
  • 技術者の価値 - CROSSFIRE DBとコンパイラの日記
  • ASCII.jp：レールガンのオープニングはアキバで壊滅！
  • Twitter / ユーリヤ・ティモシェンコ: @satomit このやろう、すごい勢いでフォローさ ...
  • Twitter / takeo: そろそろ単行本出版して RT @shelarcy: ...
  • Twitter / HiraSosuke: 祝一平の「試験に出るX1」が読みたい....誰か持っ ...
  • はてなブックマーク - そろそろPHPerにとどめを刺しておくか - 八発白中
  • そろそろPHPerにとどめを刺しておくか - 八発白中
  • Hexenkessel - pdl2h: starchart: ...
  • 小中学生でプログラミングスキルのある方に質問です。 - Yahoo!知恵袋
  • 南條愛乃が加入しテレビアニメ『とある科学の超電磁砲』のオープニングテーマ『only my railgun』を歌う新生『fripSide』を直撃インタビュー！！
  • To Moose Or Not To Moose の邦訳を本人っぽく書き直してみた - iYappoList::Writing
  • true tears ブルーレイ化 正式決定ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!:【2ch】ニュー速VIPブログ(`･ω･´)
  • Mooseの為か、そうでないのか - taro-nishino の日記
  • モジラ，「Firefox」プラグインの検査用Webページをオープン - 世界のセキュリティ・ラボから：ITpro
  • 日常の .NET 開発のための関数型プログラミング
  • 「Twitter」と「2ちゃんねる」、イザというとき役に立つのはどちら？ - japan.internet.com Webテクノロジー
  • 大至急解答お願いします！私は今大学でMATLABのSimulinkを用いた解析の研究に取り... - Yahoo!知恵袋
  • 場外乱闘×2 プログラマで、生きている: ワークVSライフ＝デスマーチ真の顧客満足を目指して: 就職活動中の皆さまへ
  • ウェブっ子「愛憎」 - 将来が不安

  Permalink  |  View Entire Page

Search the Site

Custom Search