タグ

ブックマーク / el.jibun.atmarkit.co.jp (7)

  • 引き継ぎされていないからしませんって本気?:Just an ordinary day:エンジニアライフ

    みなさま、おはようございます。Kyonです。 前回の"引き継ぎって大事なんやで"コラムを公開する前日に、「引き継ぎされていないからしませんでした」と言われたという話を知人から聞き、「社会人としてどうよ?」とという話になりました。 いろいろ聞いてみると、闇深そうな感じがしたので(?)、めでたくコラムネタ入りと相成りまして候。 お互いの言い分があることはわかる 登場人物を整理しておきます。 知人:私の知人です。 Aさん:Bさんにある仕事を引き継いだ人。知人や周りの人から、対応の良さを評価されている人。 Aさんグループ:Aさんを筆頭に、あと他に数名いるグループ。Aさんの対応方針がよく伝わっていて、他の人に対応してもらっても、Aさんと同じぐらいの満足度が得られる。 Bさん:コラムで中心となる人。冒頭の「引き継ぎされていないから・・・」と発言した人。 Bさんグループ:Bさんを筆頭に、あと他に数名い

    引き継ぎされていないからしませんって本気?:Just an ordinary day:エンジニアライフ
    moritata
    moritata 2019/09/27
    社会人として、ってのは気になった。これだけ読むとそんな単純な話には思えなかった。顧客には良くても利益に悪影響が出ることとかあるかもしれないし。本来改善行為ってのは組織の側が考えるべき話かと思うけど
  • エンジニアにコスト感覚を問いたいのでしょうか?排泄行為の後に睡眠をとられてはいかがでしょう。:101回死んだエンジニア:エンジニアライフ

    いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ▪コスト感覚を語らせる前に エンジニアとして仕事をしていて「コスト感覚を高めろ」という話をされた事はないだろうか。私のいた現場では、たまに朝礼の話題に上がったりした。だが、内容を要約すると、「お前らの給料高いから、安い値段でいっぱい仕事しろ」ということだ。思えば失礼な内容だ。 コスト感覚については、あくまで常識の範囲内で十分だと考えている。どうやって儲けるかは別セクションの人が考える問題だ。情報提供をして話し合うなら分かる。だが、なぜ技術プラス損益の責任まで負う必要があるのだ。営業に強引に技術をやらせるのと同じだ。部署を分けてる意味が無くなる。 もう一つ、キャパシティー的な問題がある。人一人のキャパシティーは限られたものだ。得手不得手もある。コスト計算の技術IT

    エンジニアにコスト感覚を問いたいのでしょうか?排泄行為の後に睡眠をとられてはいかがでしょう。:101回死んだエンジニア:エンジニアライフ
  • 業務時間外で勉強をしなければいけない理由:101回死んだエンジニア:エンジニアライフ

    いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ▪️業務時間外の勉強を新人にどう説明しているか IT業界技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ!」としか言わない。 IT系に勤めているからそれが当然だと思うかもしれない。だが、「仕事で必要だから」では理由が弱い。しんどい仕事をした後に、更に勉強というのはなかなかしんどい。相応の理由でも無い限り、モチベーションは保てない。

    業務時間外で勉強をしなければいけない理由:101回死んだエンジニア:エンジニアライフ
    moritata
    moritata 2015/08/18
    こまかな理由はともかく、一線で頑張りたけりゃ普通に努力するよね、って話なだけかと。同時に学習コストを個人に転嫁する企業を見るけど、それはそれでアホだよなぁと。
  • 言語擬人化妄想:プログラマで、生きている:エンジニアライフ

    わたしは、いまの会社に入ってからはVisual Basic(以下、VBと略)とTransact-SQLをメインに仕事をしているんですけど、最近、久しぶりにC++を使うことになりまして。「ようやくさんのとこに戻れるぞ~」と思って喜んだんですが、いざ向き合ってみるとC++がすっかりツン化していました(爆)。 以前はツンデレ程度だったのに、ちょっとよそ見している間に、ツンツンツンデレくらいな感じです。どうやらVBと付き合いすぎて、VB脳なままでコードを書いたらご機嫌を損ねてしまったようです。「ごめん。君と向き合ってるときは、君のことだけ考えるから」とか妙な言い訳をしつつ、3日ほど頑張ったらなんとか以前の感じに戻りました。関係が修復できてうれしかったです(笑)。 世の中、擬人化が流行しているらしいです。国とかならまだイメージがわくのですが、鉄道擬人化とかなると、もう何がなんだかさっぱり分かりま

    言語擬人化妄想:プログラマで、生きている:エンジニアライフ
  • オブジェクト指向。教科書と現実のはざまで:Innovation “D”:エンジニアライフ

    新人教育のため、久しぶりにオブジェクト指向の教科書をつらつら眺めていると、ふと何点かの疑問がわいてきました。 ■「集約」の章にて 「集約」の説明用に、『ハンドル』『タイヤ』『エンジン』などが集約されて『自動車』になっている図が掲載されていました。 ○(ささやかな)疑問その1 そういえば昔、日やヨーロッパの自動車メーカーから部品を調達して組み立てた中国製の自動車が、別の国では安全性の問題から自動車として認められなかった、というニュースがあったような……(うろ覚え)。 各部品はちゃんとしていたから、自動車は走ることができたのでしょう。でも、各部品が「集約」されても『自動車』として認められない場合がある。そういうのって、どう表現するのだろう? ○(ささやかな)疑問その2 唐突ですが、『歌』を「集約」で表現したら、どうなるのだろう? 『歌詞』と『曲』、『歌手』の「集約」??? そういえば昔(昔の

    オブジェクト指向。教科書と現実のはざまで:Innovation “D”:エンジニアライフ
  • 「ビジネスの言葉を話せるエンジニア」の可能性:わたしの愛するエンジニアライフ:エンジニアライフ

    音が語れるエンジニア参加型メディア「@IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「ITエンジニアとビジネス」だ。 ITエンジニア技術力さえあれば、ビジネスのことは考えなくてもよいのか。それとも、技術力に加えて、ビジネス視点も必要なのか。ITエンジニアとビジネスの関係について書かれたコラムを集めてみた。 システム語とビジネス語、両方を使いこなせ ITエンジニアでもあり、同時にITコンサルタントでもある林浩一氏は、「バイリンガルを目指せ」と提言している。ここでいうバイリンガルとは、「システムの言葉」と「ビジネスの言葉」の両方が話せる、という意味だ。 システム開発や、それに従事するITエンジニア技術を軽視する経営者/コンサルタントはいまだに存在する。例えば

    「ビジネスの言葉を話せるエンジニア」の可能性:わたしの愛するエンジニアライフ:エンジニアライフ
  • 実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ

    わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

    実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ
  • 1