NECで何が起きているのか
かつて日本を代表するPCメーカー、そしてシステムインテグレーターの大手6社に数えられるNEC。それを退職した今、機密に触れない程度に、特に研究所の裏事情を説明していこう。おそらく製品部門は違う苦しみを抱えているだろうが、高額なボーナスもらってるんだから耐えてくれ。 IT音痴の研究所トップ私が入社したのは、研究発表でのいわゆる一本釣りだった。釣りあげた部門も、当時の研究に比較的近かったため、給料をもらいつつ研究ができる、という不純な動機があったのは確かだ。大手特有の研修体制も魅力に感じた。 雲行きが怪しくなったのは1年目の夏である。当時研究所のトップであるE氏による、研究発表の総評の場で「まだそんな研究していたのか」という発言だった。NECのシステムインテグレーションといえば、重要な事業の柱であり、事業部からの引き合いも非常に強かった。折しも、AWSが日本国内での事業が躍進し、オンプレミスと
アジャイル開発手法 (スクラム、XP) の導入事例 - GMOインターネットグループ グループ研究開発本部
はじめまして、次世代システム研究室の A.F. です。 今回のエントリーでは私たちが日々の業務で取り組んでいる『アジャイル開発手法 (スクラム、XP)』の導入事例について紹介させて頂きます。次世代システム研究室の重要なミッションは『GMO インターネットグループの重要なプロジェクトの成功を技術面でサポートする』ことですが、そのため自ずと携わるプロジェクトは多岐にわたります。例えば EC やソーシャルゲーム、広告技術と各プロジェクトで目的も規模もユーザーも異なりますが、Web サービスとして共通しているのはいずれも『変化が激しい』『不確実な要素が多い』という点です。 開発側のスケジュールやリソースといったものから技術的な実現可能性、対象となるユーザーやマーケット、はたまたそれを取り巻く環境など様々な不確実要素を抱えながら開発を行うわけですが、その中で最初から全ての要件を定義することは難しいで
アジャイルな見積りと計画づくり：第2部：規模を見積もる「４章 ストーリーポイントによる規模の見積もり」まとめ - 基本へ帰ろう
個人的感想 「期間を導出する」と「自分で期間を見積もる」 この差は大きいと感じた。暗黙的に過去の経験をもとにして期間を見積もっているかもしれないが、数字に落とし、計測していくと、その数字が定規となり、顧客に見せられ、何もないよりも、説得力がでると感じた。顧客とのコミュニケーションの信頼が増すことで、よりいっそう仕事がしやすくなり、価値の高いものを生む仕組みが作れると感じた。 目次 規模を見積もる ストーリーポイントは相対的 ベロシティ ベロシティが見積もりミスを補正する 規模を見積もる アジャイルチームは、規模の見積もりと期間の見積もりとを分けて考える 規模の見積と期間の見積の違い。この違いを理解するために、これから私の庭の端にある一山の土を、庭の反対側の端まで運ぶことになったとしよう 期間のみを見積もる場合 私は土の山を眺めて、手持ちの道具を思い浮かべる（シャベルと手押し車だ）。そして、
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
スプリントの期間を長くしたいと思ったら...
みなさんこんにちは。@ryuzeeです。 元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。 本文に入る前に若干前提事項を補足しておきます。 以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです（例：2週間スプリント→4週間スプリント）タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されませんそしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です コーチとしてよく、「スプリント期間が短すぎるので、XからYに
修羅場を経験してから しっかり内省すれば一皮むける | 人材・組織開発の最新記事（コラム・調査など） | リクルートマネジメントソリューションズ
近年、私たちが行ったマネジメント（に関する）研究を6つのテーマでまとめ直した『マネジメント人材育成ブック』より、第2章「経験から学ぶ」として、経験学習論や経験デザイン研究についての研究成果をお届けします。 はじめに、架空の会社・X食品の新任営業マネジャー（加藤洋介）と、社内の誰かが対話する「ストーリー」がついています。 それぞれの章の研究成果を受けた内容となっておりますので、本文の導入として気軽にお読みください。 また、メルマガ会員の方は『マネジメント人材育成ブック』全体のPDFをダウンロードいただけます。ご興味のある方は、ぜひそちらもご覧ください。 第2話 新任マネジャー、修羅場経験を聞く 水曜の朝、加藤はいつものようにコーヒーを飲みながら、田中部長を前にしている。課長になってから1年、毎週続けてきた「1on1ミーティング」の一幕だ。国内第一営業部は、最近、業績が落ちてきている。今日の議
freeeの新しく公開されたAPIを使って、非エンジニアが音声で勤怠打刻をしてみました！ - freee Developers Hub
こんにちは、freee株式会社のgokiです。 私は2017年の新卒としてビジネス職で入社し、現在はProduct Value Boosterという、営業チームや導入支援チームに自社プロダクトの価値を咀嚼してお伝えするお仕事をしています。 非エンジニアではあるのですが、いろんな業務改善ツールを作ることが好きで、趣味でいろいろ作ったりしています。 IFTTTを使って音声で勤怠打刻をしたかった理由 皆さんは、勤められている会社で勤怠って付けていますか？ ほとんどの人が”YES”だと思うのですが、あれってなかなか面倒だったりしますよね。 freeeでは、会計や人事労務管理はすべて自社のサービスを使用しているのですが、クラウドとはいえ、勤怠のためにPCをつけて、ログインして打刻、という作業時間がもったいないなぁ、と感じていました。 人事労務freeeがタイムレコーダー（打刻）のAPIを公開！ そん
「15人のスタートアップ」が、メルカリやDeNAに習ってメンバー200人になっても困らない行動指針を熱心に創った話
「15人のスタートアップ」が、メルカリやDeNAに習ってメンバー200人になっても困らない行動指針を熱心に創った話 自分が代表を務めているミラティブは、「エモモ」のように、まだ誰もやっていないが「こうすれば世の中がもっとよくなる」という自分たちの信じる価値・仮説を、自分たちの力で正解にしていく野心的なプロジェクトをたくさん進めています。今はまだフルタイム15人の会社ですが、そのためにはスーパーな仲間がたくさん必要です。もっと多くの仲間を作るべく、採用にフルスロットルで踏み込みはじめました。 そこで、10人のタイミングで300人を見据えていたという初期メルカリに倣って、あるいは自分自身も策定プロセスに関わってきたDeNA Qualityに倣って、たとえ社員数が200人300人になっても通用するような「会社の文化を明文化したもの」＝行動指針（バリュー）を創ることにしました。 結論を先に書くと、
OAuth 2.0 / OIDC 実装の新アーキテクチャー - Qiita
1.『On-Premises』パターンは、自分でマシンを用意し、そこに認可サーバーのソフトウェアをインストールして運用する方法です。 2.『Hosted Server』パターンは、マシンの物理的な運用はクラウドサービスにまかせ、そのマシン上に認可サーバーのソフトウェアをインストールして運用する方法です。 例えば AWS の EC2 インスタンスに OpenAM をインストールして運用する場合、このパターンに該当します。 3.『Hosted Service』パターンは、認可サーバー自体がクラウドサービスとして提供されるパターンです。 Okta や Auth0 がこのパターンに該当します。 4.『Semi-Hosted Service』パターンは、認可サーバーの主要機能を提供するサーバーが存在するものの、一部をローカルで実装するというパターンです。 Richer 氏が明示的に言及しているように
Apache Shiro を使ってみました - n-agetsumaの日記
この記事は Java EE Advent Calendar 2014の12/17分の記事です。昨日は @glory_ofさんのJAX-RSのレスポンスでした。明日は@nagaseyasuhitoさんです。 Java EE8では、『使い方が複雑・各APサーバ固有のレルム設定がよくわからん』とあまり評判のよくないセキュリティ周りの機能の再整理*1が行われようとしています。 しかし、Java EE8の仕様がリリースされるのはだいぶ先の2016年。 そんなに待てないので、Apache Shiroを試してみました。 Apache Shiroの既存の他の記事は部分的なコードの抜粋が多く、動かせるコードがあまり見当たらなかったので、GitHubにサンプルコードとしてまとめてみました。 Apache Shiro とは Easy To Useを一番の目的にしたJavaのセキュリティフレームワークです。 歴史
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018