年金機構の情報流出を見てちょっと思ったこと [ほほほのほ]
いつもならFaceBookに先に書いているんだけど、今日はこっちに。あとでFBにも貼る。 いつものごとく時間がないので、雑感を駄文で。 年金機構が所謂職員の失敗で、年金情報を流出するという事件が発生した。 詳しいまとめは、いつものごとく、高速に素晴らしいまとめをしてくれる日本年金機構の情報漏えいについてまとめてみたを参照。Kangoさん、いつも本当に素晴らしい。 さて。この事件とか事件について色々喋っている人とか、大臣と呼ばれる人とかを見ていて感じた雑感を。 非常に大量に情報を流出してしまった事件としては、ベネッセ事件があった。詳しくはベネッセの情報漏えいをまとめてみた。を参照。 この事件において、ベネッセは様々な方面から散々ぶん殴られた。マスコミもJIPDECも利用者も、好きなようにベネッセをサンドバッグにした。まぁ、自分も殴った側にいるのだから偉そうなことは言えない。この件について、株
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
現場ロックインが技術力さげてるのかもしれない - Javaプログラマのはしくれダイアリー
はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して
「イオン不振の原因は、コスト削減の常態化」：日経ビジネスオンライン
イオンが岐路に立っている。規模では国内最大級になった同社のPB（プライベートブランド）「トップバリュ」は「質より安さ」の印象が染み付き、ブランドイメージがここ数年で急速に悪化。トップバリュの4割弱を削減する決断を下した（詳細は「イオン、『トップバリュ』を4割弱削減へ」）。不振の背景には、限界に達した中央集権の拡大路線があった。日経ビジネス本誌4月27日号の特集「イオン 挫折の核心～セブンも怯えるスーパーの終焉」では、イオン不振の真相と次に目指す成長の姿に迫った。 なぜ今、大改革に乗り出したのか。グループの中核となる総合スーパー事業を展開するイオンリテールの岡崎双一社長が語った。 イオングループの中核事業である総合スーパーの不振が続いています。 岡崎社長（以下、岡崎）：色んな理由を言う人がいますが、本当のところは…うーん…。 現象を分析すると、人が足らなくなりすぎたのでしょう。 長いデフレの
人事がそっとつぶやく「こんなマネージャーが会社を潰す」８つのタイプ - ひかる人財プロジェクト
会社はヒト・モノ・カネで動いている。カネ・ヒト・モノでもなくモノ・ヒト・カネでもなくヒト・モノ・カネの順番で必ず表現される。ただ単にこれは偶然の並びで慣れてしまっただけではなく、間違いなく組織においてもっとも重要な経営資源はヒトなのだと考えている。 その中でも会社が成長するうえで最も重要なヒト（ポジション）と言えるのがマネージャー（中間管理職）であることには異論はないと思う。マネージャーにはほぼすべての会社において共通したミッションがある。それは「目標を達成すること」と「会社を成長させること」である。この２つのミッションを遂行できないマネージャーしかいない会社はもしかしたら近い将来潰れてしまうかもしれない。 そこでこの２つのミッションを遂行できない、会社を潰すタイプのマネージャーの意識と行動について考えてみたいと思う。チョイスしたものは偉そうに書いている私自身も耳の痛いものばかりである。こ
若い同僚を疲弊させたくない - やしお
隣の席に入社2年になる若手社員がいる。私が半年前に今の部署に異動してから様子を見ていて、大変そうな状況になっている。まだ経験の浅いうちに、仕事のマネジメントをしてくれる人がいないというのはつらいことだなと思った。 自分が入社して配属された部署には、課の下に3、4人程度の「チーム」があってリーダーがいた。そのリーダーが部署間の調整や仕事の割り振り、メンバーの進捗を確認したり、あるいは物事の判断をしていた。メンバーにはきちんと仕事がフィルタリングされた状態で入ってきたし、業務の負荷量も把握してくれていた。だからメンバーは自分の作業に集中すればよかった。またメンバーが「いったいどういう背景や経緯でこの作業があるのか」と聞けばリーダーはきちんと教えてくれたし、あるいは「これはこうした方がいいのでは」といった提案も受け付けてくれていたから、「ひたすら作業ばかりをしてむなしさが募る」といったこともなか
「Office 365運用管理入門」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
Tech Basics／Keyword： Azure Active Directory（Azure AD） Azure ADはクラウドベースの認証／SSO基盤である。ID管理や認証、さまざまなクラウドサービスに対するSSO、オンプレミスのActive Directoryとの連携などが行える。（2016/1/21） Office 365運用管理入門（12）： Office 365のセキュリティとコンプライアンスをさらに強化する Office 2016のリリースに伴い、Office 365のセキュリティやコンプライアンス機能も強化された。2016年2月に予定されている「Office 365 ProPlus」の2016バージョンの自動更新までに変更点を確認しておこう。（2015/12/7） Office 365運用管理入門（11）： Office 2016を社内で展開する二つの方法 Micros
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;
僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明
多種多様な基準から見るプログラマの市場価値 | POSTD
私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ
在庫をどの形で持つか — 在庫管理論を再考する(2) | タイム・コンサルタントの日誌から
前回、このサイトでわたしは「在庫というものの意義をちゃんと積極的に評価して、そのコストやリスクに見合う適切な活用方法を考えるべき」だ、と書いた。「そのコストやリスク」のうち、『在庫のコスト』とは、前回も説明したとおり、保管費用と在庫金利に代表されるコストである。 それでは『在庫のリスク』とは何か。代表的なものは二つある。保管期限切れリスクと、不動在庫化のリスクである。在庫品目の中には、保管期限のあるものが存在する。電子材料系や化学品などに多いが、一定の有効期限がある。飲料・食品などでは賞味期限というかたちをとる。いずれにせよ、ある一定の期限を過ぎたら、在庫として無価値になってしまうのだ。したがって、基本的には保管期限が来る前に、使い切ってしまわなければならない。ちなみに生産スケジューリングの分野では、とくに中間在庫品に有効期限のある問題は、解くのが最も難しい部類に属する。これに保管スペース
パフォーマンス３倍を実現した仕事術
当方都内ヴェンチャーSE。 俺がリーダーになってから試しに導入してみたルールのおかげでチームの生産性が３倍になった。 誇らしいことだが、果たして一般的に有効な方法なのかどうか気になるので広く反応を集めたいと思って書く。 そのルールというのは単純、「一日に５時間以上コードを書かない」というものだ。 勤務時間の８時間のうち、本当に仕事をするのは５時間だけに制限する。 そして残りの３時間は会議と称する息抜きタイムにした。 これで生産性は３倍になった。 社長も機嫌も俺の評価もうなぎ登り。 社長はモーレツに仕事をする人で、社員にも同じようにモーレツに働くことを求めていたが、俺は同調しなかった。 普通の人間は集中できる時間に限りがある。 凡人にはよくて一日５時間が限界だ。 それ以上の時間を使っても、単位時間あたりの生産性は下がるばかりだ。 ならいっそ、残りの時間は最高のパフォーマンスを発揮できる５時間
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
Windowsインフラ管理者入門という本を書きました
本の紹介 概要 この本はWindowsインフラの管理をする中で知っておくべきことや、多くの人がつまづく所、混乱するところ、落とし穴にはまりやすいところ等について書きました。特に初めの3～5年程度をかけて苦労しながら理解していくであろう事が沢山詰め込まれています。 この本に書かれていないこと 存在している山ほどある機能を中途半端に抜粋してスクリーンショットを沢山張りつつ、操作方法を紹介する…という本ではありません。 インターネットで検索すれば簡単にヒットするような基本的なWindowsの操作などはほぼ書かれていません。 想定読者 組織のシステム管理者として配属された人 組織のシステム設計、構築、運用を請け負うシステムインテグレーターの新人～数年経験がある技術者 既存の本の目次を見て「違うんだよ、機能や設定方法なんてやればわかるんだから、もっと基礎力がついたり、現場で役立つノウハウが得られるよ
在庫は本当に悪なのか — 在庫管理論を再考する | タイム・コンサルタントの日誌から
少し前、生産管理に関して人前でお話しさせていただいたときのことだ。“納期遅れを防ぐために、もっと積極的に在庫を活用しよう”という趣旨の説明をしたあとで、ふと心配になって、セミナーの受講者の方にこう質問した。——皆さん、在庫は悪だと思いますか？ すると、40名近い受講者がほぼ全員、「悪だと思う」という答えの方に手を上げた。わたしはちょっと驚いて、前に座っていた方にたずねた。 ——どうして、悪だと思うのですか？ 「だって、置いておけば、コストがかかるでしょう。場所代とか。在庫がなければかかりません。」というのがその人の答えだった。 ——たしかに、どこか倉庫を借りておいておけば、保管費用がかかりますよね。でも、失礼ですが、御社の工場は借地ですか？ もし自社の敷地だとしたら、工場の隅っこに置いておいておけば、1円もコストはかかりませんよ？ 「それは、そうかもしれませんけれど・・金利がかかります。」
io.jsについて知っていること - from scratch
今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Alfresco - Open Source Enterprise Content Management (CMS) including Web Content Management