セキュリティを「必要悪」にした犯人は業界自身ではないか？ (1/2)
セキュリティ対策と業務効率や生産性はトレードオフの関係にある。これはまぎれもない事実だ。「だからこそ、双方のバランスが取れるアプローチを模索しよう」――本来ならば、そう受け取られるべき提案だったが、そうはならなかった。 2016年10月20～21日、都内で開催されたセキュリティカンファレンス「CODE BLUE 2016」を締めくくる基調講演「How much security is too much?（セキュリティ対策はどこからが過剰なのか？）」で、カルステン・ノール氏は、セキュリティ業界の人間としてのジレンマを吐露した。 イノベーションを阻害しているのはセキュリティ業界かもしれない、と自問 業務効率や生産性とのバランスが取れたセキュリティ対策を実施すべきだ――。セキュリティ業界の人間はよく、そのように訴える。 だが、現実はそうはなっていない。高度なサイバー攻撃や内部犯行による大型のセキ
Amazon.co.jp：システム障害はなぜ二度起きたか みずほ、12年の教訓の TOSHI!!さんのレビュー
この1度目のシステム障害を、対応ベンダのうちの1社として見ていた者です。 確かに、ここまで掘り下げるのは大変だったでしょう。しかしながら、例えば、実務レベルの暗闘や困惑は 不十分というか、日経という立ち位置からか書かれていません。 私自身は別プロジェクトに居ましたが、ATM系の開発を社（当時）が請け負っており、そのマネージャーが 懇意の同僚でした。彼は、オブザーバとしてながら、実際の実務レベルミーティングに参加していたのです。 真の原因は、統合するシステムそのものの設計書・仕様書レベルで、負け組（＝新システム開発に乗れな かったカイシャ）が、意図的なイヤガラセで、「現状」の仕様や設計を開示しなかったことにあります。 システムというのは、使えば必ず手直し（所謂、バグだけでなく、法律改正に対応する修正もあります）が 多々発生します。都度、「その場しのぎのパッチ当て」から「キチンと予算を組んだ修
勘違い？小規模プロジェクトにドキュメントは不要か（前編）
この道20年選手になろうとしているプロジェクトマネジャー（プロマネ、PM）の宇佐木さん。ウェブシステムを作る小さいIT会社に勤めており、現在は○○植物園、××博物館、△△商店街の三つのプロジェクトを抱えています。 20代の頃にこの会社に転職して以来、多くのプロジェクトを担当してきました。ですが、このところトラブルが続いているようです。 システムエンジニア（SE）虎岡：ウサさん、この間頼まれた○○植物園のアクセスログの一覧できたけど、ものすごく時間がかかったよ。このシステムを実装したのって、外注先の荒川さん（プログラマー）だと思うけど、資料が何もないんだよ。アクセスログがどこにあるか分からないし、何というファイル名かも……。とにかく出しておいたから、あとはよろしく。 宇佐木：ごめんごめん。荒川さんにはいつも言ってるんだけど。なかなかドキュメント書いてくれないんだよ。 SE虎岡：ちゃんと伝わっ
なぜ、カルビーは「会議不要、資料不要」なのか
“ノーミーティング・ノーメモ”を合言葉に、カルビー社内の会議と文書のムダを一掃した松本会長。その厳しい会長が理想とする資料はどんなものか。 儲かる会社へと変貌させた立役者が「ノーメモ」を掲げる理由 2009年にカルビーの会長兼CEOになったとき、社内資料の多さにびっくりしました。売り上げデータ、在庫データ、エリア別データ、商品別データなど社内の帳票は実に1100以上あった。1100枚ではなく、1100種類ですよ。「すべての資料に目を通したら不眠不休で4日かかる」と笑えない“社内伝説”もあったほどでした。 各種データはグラフ化され、会議資料はパワーポイント一面に9つのグラフを載せた通称「9面グラフ」が基本でした。グラフが9つもあると、どこがポイントなのかひと目ではわからない。しかもそのことに疑問を持たない資料病、データ病が蔓延していました。 そのような状況を見て、就任早々に訴えたのが「ノーミ
エンジニアが採用できない会社 と 評価されないエンジニア - 情科若会2016公開用
2016年9月17日伊東山喜旅館での情報科学若手の会2016において発表に使用した資料です。発表中のつぶやきはこちら→ http://togetter.com/li/1026676
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
こんにちは、fluct SSP開発本部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です） ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明
long_time_work_cannot_finish_tasks
先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい？ 困ったことはない？」と尋ねられ、 僕は即座に「すごく楽しいですよ。日本で働いていた会社とは大違いです」と答えた。 「日本では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日本の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか？」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
20万人月の作業を1人でやる話 〜1万7千年生きたSE〜 - 特別天然記念物
昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。 SEはある日、上司に言われました。 「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」 そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。 途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。 約1万7千年前 |- 要件定義書を作成着手。 | 周りの人達は狩りをしながら生きている。 | 約1万6千年前 |- 要件定義書の作成が完了する。 | 基本設計に着手する。 | 土器を作り始める人が現れる | 徐々に日本列島が大陸から離れ列島になっていく。 | 約1万4100年前 |-
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
今まで学び実践してきたこと
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。
「Androidチームのこれまでとこれから」という話をした。 - パルカワ2
Androidチームに新しいメンバーが増えた事とテクニカルリードという役割を僕が担う事になったので、Androidチームのメンバーに僕が現状考えている「テクニカルリードの役割と責任」「Androidチームの方針」「Androidチームの文化」について簡単にまとめました。 方針に関しては、今年のはじめに決めて結構良い感じだったので、そのまま進めるという感じです。 追記: 来てくれ！！！！！１ minne Androidアプリエンジニア（正社員） | エンジニア | 職種詳細 | GMOペパボ株式会社 参考 「いるだけで成長できる環境」へ - ペパボテックブログ チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blog 業務遂行能力
システム障害で消耗してるあなたに：失敗から学ぶための取り組み「Failure teaches Success」 - クックパッド開発者ブログ
こんにちは！広告エンジニアのレオです。最近、システム障害を起こしていますか？クックパッドも例外ではないです。毎月、何かしらのシステムに何かしらの障害が起きてしまいます。その際、早く気づき、速やかに対応することによって被害を最小限に留めるように努めます。そして、システムやデータを正常な状態に復旧させます。 正常な状態に戻した段階では対応はまだ完了していません。問題の本当の原因は何なのか、またその再発をどうやって防止するかを考えて手を打つまでは、障害の対応が完了したといえません。予防しない限り、また同じ過ちを繰り返すことになってしまいます。 失敗は成功のもと 根本原因分析、そして再発防止は大事な作業ですが、とても難しい作業です。クックパッドでは、これらを少しでもやりやすくするために、ルールと仕組みをまとめています。この仕組みを「Failure teaches Success」（略してFtS）と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF] 客船事業評価委員会 報告
開発組織マネジメントのコツ - Speaker Deck
GE: 今後採用する全社員に対してプログラミング能力を義務付け・採用職種に関わりなく - BusinessNewsline
『日本でアジャイルが流行らない理由 - @ledsun blog』へのコメント
