タグ

managementに関するkarupaneruraのブックマーク (34)

  • ベネッセ事件はITマネジメントの課題として語るべき(追記あり) - arclamp

    思ってたより衝撃的だったのでブログを書きます。 顧客DB開発に関与=知識悪用し防止措置解除—派遣SE、逮捕状請求へ・警視庁 - WSJ 外部業者から派遣されているシステムエンジニア(SE)の男が、情報が流出したデータベース(DB)のシステム開発に関与していたことが17日、捜査関係者への取材で分かった。 警視庁は男が専門知識を悪用し、DBの流出防止プログラムを解除して顧客情報を記憶媒体に複製したことを確認。 これが当だとすると各所が大騒ぎにならないといけません。ただ、「すわ、セキュリティコンサルに依頼だ!」では、まったく解決になりません。むしろ、振り返って「自社のITマネジメントってどうなっている」を正しく理解した上で「で、これからどうしていく?」ということを考えないといけません。 この事件セキュリティの問題ではなく、ITマネジメントの問題なのです。 まず「流出防止プログラムがあった」こ

    ベネッセ事件はITマネジメントの課題として語るべき(追記あり) - arclamp
    karupanerura
    karupanerura 2014/07/17
    いいはなし
  • 職場で「自分から動ける人」と、「自分勝手に動く人」との微妙な差

    ある会社の社長から「社員に1人、問題児がいる」との相談があった。問題児自体はどの会社にもいるのでさほど珍しくない。そこで 「どんな問題を起こすのですか?」 と聞いたところ、「周りの意見を聞かず、勝手に仕事を進めてしまう」と仰っていた。 そのお話を聞き、私はひとつの疑問が浮かんだ。 社長は普段から、「社員がなかなか自分から動かない」と言っていた。「もっと指示を待たずに、自分から動いてくれるといいのに」とも言っていた。

    職場で「自分から動ける人」と、「自分勝手に動く人」との微妙な差
  • 開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;

    最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく

    開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
  • 「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog

    JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド

    「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
    karupanerura
    karupanerura 2014/03/16
    すごい。なるほど。
  • LINE、NAVERまとめはなぜ強いのか?――LINE株式会社 森川亮社長8000字インタビュー

    LINE、NAVERまとめはなぜ強いのか?――LINE株式会社 森川亮社長8000字インタビュー:これからの働き方、新時代のリーダー(1/7 ページ) リニューアル記念企画「これからの働き方、新時代のリーダー」 「アクションリーダーの『知りたい!』に応えるオンラインビジネスメディア」を統一コンセプトとして、9月2日にリニューアルしたBusiness Media 誠 & 誠 Biz.ID。これから数カ月間、リニューアルを記念して、スペシャルインタビュー企画を掲載していきます。 企画では、Business Media 誠編集部と誠 Biz.ID編集部がそれぞれテーマを決めてインタビューや対談を行います。Business Media 誠では「アクションリーダーに会いに行く」、そして誠 Biz.IDでは「時代の変化に合った働き方」をテーマに、さまざまな識者の方にお話を聞いていきます。 →リニュー

    LINE、NAVERまとめはなぜ強いのか?――LINE株式会社 森川亮社長8000字インタビュー
    karupanerura
    karupanerura 2014/03/02
    今更読んだけど、面白い。計画とクリエイティブの質の話は凄く共感するのだけれど、お金とどう折り合いを付けるのかは難しいと思うし、そこがキモなんだろうな。
  • あの日、Twitterのくじらが出なかったもう1つの理由

    社会を率いているリーダーは、いつの時代にも存在する。しかし、そのリーダーたちの顔ぶれは、毎年異なる。ここ数年、世界で注目されているリーダーの顔ぶれはどのように変化してきたのか。 社会を率いているリーダーは、いつの時代にも存在する。しかし、そのリーダーたちの顔ぶれは、毎年異なる。ここ数年、世界で注目されているリーダーの顔ぶれはどのように変化してきたのか。その移り変わりについて、漠然と想像することは可能だが、具体的に説明することは難しい。しかし、多くの活躍するリーダーの姿を間近で見てきた元日マイクロソフト会長、現慶應義塾大学大学院メディアデザイン研究科 古川享教授は、その変化を明確に示す。 今回は、2013年11月下旬から12月初旬にかけて古川氏が登壇した2つのイベントで語られた内容を合わせてレポートする。イベントは、慶應義塾大学大学院メディアデザイン研究科が主催した講演会「メディアイノベー

    あの日、Twitterのくじらが出なかったもう1つの理由
    karupanerura
    karupanerura 2014/01/09
    いい話
  • ToDoは書き出すだけでは意味がない理由:生産性の父、デビッド・アレン語る | ライフハッカー・ジャパン

    急に自由な時間ができたとき、その貴重な瞬間を「さあ、何をしよう」と考えることに費やしてしまっていませんか。 生産性向上のための仕事術「GTD」(Getting Thing Done)を提唱しているデビッド・アレン(David Allen)氏によると、「どたん場になってToDoの優先順位を考えているようでは手遅れ」なんだとか。GTDなどの生産性向上システムの最終目標は、頭の中にあるToDoやアイデアを引き出し、系統だてて整理することで、まだ取り掛かってもない作業が重荷になるのを防ぐことにあります。どんなシステムを採用していても、優先順位の検討はToDoを整理するときにしておくこと。「後で」では遅いのです。「何から着手しよう」と考えることに時間を費やすのはもったいないですよ。 これはある意味ジレンマでもあります。何を優先して実行するかを決めるには、すべてのことに優先順位をつけておく必要があるか

    ToDoは書き出すだけでは意味がない理由:生産性の父、デビッド・アレン語る | ライフハッカー・ジャパン
    karupanerura
    karupanerura 2013/12/16
    だいじだとおもう
  • Redmineで結婚管理はじめ(させられ)ました - razokulover publog

    聞くところによると、今日はいい夫婦の日らしいですね。 Twitterのタイムライン上では結婚を発表している方が結構おりました。 こんな話をすると、僕もあのGoogle Adwordsで出会った彼女と結婚か?と思われるかもしれませんが さすがにそれはまだ早い。 早すぎる。 と、思っていたんですが。 提案 けれども、ある日彼女にこんな提案をされました。 「結婚Redmineで管理しよう!」 先日github結婚式を管理している人のブログを読んだ気がするんですがRedmineは聞いたことがない。 そもそもRedmineとは、 Redmine.JP Redmineはオープンソースのプロジェクト管理ソフトウェアです。 思い返してみれば、Adwordsdで彼女募集の広告を出したとき、最速で「会いましょう!」と言ってきたのは彼女でした。 初デートのとき(このときまだ2回目の対面)に「同棲する?」と尋

    Redmineで結婚管理はじめ(させられ)ました - razokulover publog
  • 『反省させると犯罪者になります』を読んで愕然 - エキサイトニュース

    「悪いことをしたら反省するのが当然」「反省してもらわなきゃ困るよね」って考えてると、どんどん犯罪者が増えるよ。 ええええー!? さらに、自分の子供を犯罪者にしてしまうよ。 って、ええええー!? どゆこと? と驚きながら読み進めていった。 『反省させると犯罪者になります』 すごいタイトル。 でも、読んでいくうちに納得してしまう力がこのにはある。 第3章に、女優酒井法子の事例が登場する。 覚醒剤取締法違反で逮捕された彼女は、“自らが犯した事件を謝罪する目的で、「贖罪」というタイトルの著書を出版”する。 これが、まさに「模範的な反省文」になっているのだ。 “これでは自分自身をみつめたことにはなりません。酒井さんには失礼ですが、書名を「贖罪」とするには、内容としては表面的でしかありません”。 また、保釈された後の記者会見での言葉を引用し、“自分の弱さ故に負け”“自分の弱さを戒め”“二度と手を出さ

    『反省させると犯罪者になります』を読んで愕然 - エキサイトニュース
  • ボスとリーダーの違い : 2chコピペ保存道場

    karupanerura
    karupanerura 2013/05/24
    おもしろい
  • プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記

    プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、来であれば決裁権のある人間に

    プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
    karupanerura
    karupanerura 2013/05/24
    最後に。が一番だいじ
  • 「つまらない大人」になる方法 - デマこい!

    人は誰でも、若いころは「つまらない大人になりたくない」と考える。 くたびれたスーツを身にまとい、うつろな目で通勤電車に揺られ、安月給にため息を落とし、娯楽といえば野球のナイター中継とパチンコだけ。そんな灰色の人生を送るなんて、まっぴらごめんだ。 では、どうすれば「つまらない大人」にならずに済むのだろう。「おもしろい人生」の秘訣はなんだろう。それを知るためには、「つまらない大人」になる方法を考えてみればいい。 結論から言えば、つまらない大人とは減点方式でしか評価されない人の成れの果てだ。つまらない大人になりたくないのなら、なによりもまず加点方式で評価される人にならなければいけない。 先日、ジャーナリストのSさんと飲む機会があった。Sさんはセミナーや講演会でも人気を集める売れっ子だ。酔いが回ってきた勢いで、「大企業のおじさまはつまらない」という話になった。 たとえば若手の起業家を相手にセミナー

    「つまらない大人」になる方法 - デマこい!
    karupanerura
    karupanerura 2013/04/13
    ミスによるペナルティが大きい環境は良くないと思ってたけどその原因がわかりやすく示されていた。
  • デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい

    デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか?」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ

    デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
  • エンジニアを頑張ったで評価する会社は衰退する | rake enjoy

    この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。(最近のゲームなどは除く)またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を

    エンジニアを頑張ったで評価する会社は衰退する | rake enjoy