【Webinar資料公開】AWSで作るデータ分析基盤サービスの選定と設計のポイント - NRIネットコム Design and Tech Blog
こんにちは佐々木です。 もの凄く遅くなりましたが、2021年3月18日に実施したデータ活用に関するウェビナーの資料と動画の一部の公開です。 講演資料＆講演動画 当日は、AWSの大場さんより『AWS Analytics サービスのご紹介』と、NRIネットコムの分析・マーケティングチームの柿崎さんより『顧客理解を深め、キャンペーン成果の最大化を目指すデータ活用』、そして佐々木の方から『AWSで作るデータ分析基盤 サービスの選定と設計のポイント』の3本立てでお送りさせて頂きました。佐々木の資料と動画、またAWS大場さんの動画を公開させて頂きます。 speakerdeck.com www.youtube.com www.youtube.com お伝えしたかった事 佐々木パートのお伝えしたかった事としては、次の2点に集約できます。 DWHとデータレイクは分離する データレイクも用途に応じて3層構造に
「本日増員20名が来る。マシンはまだない」信じられないPMの言動10選 - paiza開発日誌
Photo by thejbird こんにちは。倉内です。 先日PM経験を振り返って反省する記事を書いたばかりですが（さまざまな反応ありがとうございました！）今度は前職でプロジェクトメンバーだった頃に遭遇した、いろいろなプロジェクトでの「信じられないPMの言動」をまとめてみました。 このようなPMを反面教師にしきれなかった部分ももちろんありますが、「自分はこうならないぞ」と戒めにしていた部分もありました。 今回は私の経験談だけでなく、SEの友人にヒアリングした内容も含めています。もちろん表に出せるものだけを厳選しているのでご安心ください！ 信じられないPMの言動10選 1.「年末年始休む人は理由含めて報告して」 出る前提かい！というツッコミはもはや入れる元気もありませんでしたが、デスマってると休むのが異端みたいな空気ありますよね。怖い。 みんな頑張って出るならまだ納得できるのですが、実作業
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
ITトレンドに見る日本のエンタープライズITについて
ITトレンドに見る日本のエンタープライズITについて1. ITトレンドに見る 日本のエンタープライズITについて 2017/9 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1 3. アジェンダ • ITトレンドの流れ »Agile »Cloud »DevOps »Microservices • 日本のエンタープライズITの状況 • 今後にむけて 2 4. ITトレンドの流れ 3 5.
チーム開発の進め方 - クックパッド開発者ブログ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 今回はウチのチームの開発の進め方や見積もりの仕方を説明しようと思います。 実はコレ系の話は 5 年前にもデブサミで発表 したのですがこの時はリリースまで 1 年とかのレベルのプロジェクトの進め方の話でした。今回は 1,2 ヶ月でリリースまで持っていく開発の進め方を説明します。 動画サービス部分を microservices 化するときに実際に行った事を元に説明します。開発者は 3 人で 1.5 ヶ月位の開発です。 何故このようなことを行うのか 誰だって楽しく仕事がしたいし、なるべく不安などは無い方が良いはずです。 例えば自分がやっている作業がどうなったら終わりなのかわかっていなければ不安でしょうし、いつまでに作ればいいのかわかっていなければ不安でしょう。 そういった不安をなるべく無くすためにうちのチームでは
マイクロサービス運用の所感 #m3dev
[AC06] クラウド・ネイティブなスケーラブル・アプリ開発のために～12 Factor App on Kubernetes on Azurede:code 2017
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015
伊藤直也氏が語る、モダンなWebテクノロジーに共通する傾向とは？（前編） Chef、Docker、MicroservicesからReact、FRPまで。QCon TOkyo 2015 最新のITと関連技術をエンジニアの視点で掘り下げるイベント「QCon Tokyo 2015 Conference」が4月21日に都内で開催されました。 そのセッションの1つとしてKAIZEN platform Inc.の伊藤直也氏が行ったのが、「モダンWebシステム開発」と題して、最近のWebアプリケーションに関する技術に共通する傾向を探った講演です。 ChefやPuppetなどによるInfrastructre as CodeからImmutable Infrastructureなどのインフラ周りからReactなどのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
【前編】CTO不在で、開発組織改善に着手！ 一休のエンジニアが語る苦悩の1年
Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏（@naoya_ito）。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第四回のゲストは、伊藤氏が現在、技術顧問として就任し、開発部門の組織改善を行っている『株式会社一休』のエンジニア、宿泊事業本部のシステム開発部の部長である笹島祐介氏（写真中央）と開発組織改善の発起人である田中健介氏（写真右）の2名が登場！CTOが不在の開発現場で10年以上前からサービス提供している、そんなよくある状況の中、どのように現状の改革に挑んでいるのか――苦労話も炸裂し、現役エンジニアには興味深い話が展開されることに！お楽しみに！ — 伊藤直也（以下「naoya」）：とりあえず乾杯しましょうか。 — 笹島祐介（以下「笹島」）＆
「作らないことも選択肢に」「なぜやるのかを自分の言葉で」未経験エンジニアが社会人1年目で学んだ6つの教訓｜(株)リブセンス
JJUG CCC 2015 Spring の発表資料。 --------------------------------------------------------------------------------- 私は2014年にITベンチャーにエンジニアとして入社しました。 理系の大学院出身でしたが、学生時代はとにかくプログラミングから逃げるように過ごしてきました。 入社後の研修ではJavaでif文やfor文の書き方を学んでいたという見事な初心者っぷり。 そんなJava初心者の私が、2ヶ月でwebサービスを開発し、公開するというプロジェクトにチャレンジしました。 数々の困難を乗り越え、何とか「ニクリーチ2016」というwebサービスを公開。 当セッションでは 入社後どのような研修を受けたのか ニクリーチ2016ではどのような技術を使ったのか 一人開発プロジェクトを通して感じたこと
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
APIドキュメントを実装と乖離させないために - Qiita
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Should your Engineering Lead be fired?
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創
モダンな現場にするために実践したこと
