Redis の障害を想定した避難訓練を行いました - Pepabo Tech Portal
こんにちは、EC 事業部のフロントエンド・エンジニアのおいちゃん（@inouetakuya）です。先日、社内で Redis の障害を想定した避難訓練を行ったので紹介します。 背景 カラーミーショップ では、以前は Redis を利用していていましたが、ここ一年の間に用途が変わってきました。つまり、以前はコンテンツのキャッシュやセッションの保存先だったものが、いまでは非同期処理のためのキューとして使われるようになり、かつその処理には決済に関わるものも含まれています。 つまり Redis にダウンタイムが発生すれば、それがそのままビジネス面でのダメージに直結します。そこで Redis の自動フェイルオーバーを実現するため、インフラチームとともに Redis Sentinel の導入を進めてきました。 解決したい課題 Redis Sentinel を扱うのははじめてだったので、当初は「本当に自動
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 ソフトウェア開発では、手法やフェーズに応じて適切にツールを使い分けることが重要です。株式会社エウレカが、主力サービスのPairs開発チームで実践しているTrelloを活用したタスク管理のノウハウや考え方を紹介します。 初めまして。株式会社エウレカのCTO Office責任者、梶原成親（@kajinari）です。 エウレカが目指すのは自立・自律した組織。全社でスクラム（Scrum）開発を推進し、強いチーム作りをするのが私のミッションです。 管理ツールもさまざまに使い分けていますが、スクラムに合っていると感じるのは、タスク管理ツールのTrelloです。私はもともとアトラシアンのユーザーグループで、東京代表のオーガナイザーを務めていました。Trelloは、アトラシアンが買収したのを機に使いは
Alignment and Autonomyな組織づくり - クックパッド開発者ブログ
はじめに サービス開発部部長の勝間(@ryo_katsuma)です。 普段は、エンジニア、デザイナ、ディレクターを含む様々な職種のメンバーのマネジメントを行っています。 今日は、私の部署における組織づくりの取り組みについてお話いたします。 背景 現在、私が所属しているサービス開発部は、年初の組織改編時に発足しました。レシピをさがす、のせるなどを含むレシピサービス、いわゆる「クックパッド」において、広告事業、会員事業など事業にまつわる開発以外のユーザーに触れる部分の開発を行っています。 クックパッドはPCウェブ、モバイルウェブ、モバイルアプリといくつかのプラットフォームをサポートしていますが、ここ最近の部署での開発はモバイルアプリを中心に行っています。 メンバーの数も他の部署と比較しても多く、学生アルバイトも含めて約45人が所属し、役割ごとに分割されたグループにも10人前後のメンバーが配置さ
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
2003年に IEEE から出された Michael Cusumano らによる国際的 Survey - A Memorandum
前回のプロジェクトの成功率についての Survey に続き、国際的な Survey の結果紹介です。 2003年に IEEE から出された Michael Cusumano らによる国際的 Survey プラクティス パフォーマンス まとめ blog1.mammb.com 2003年に IEEE から出された Michael Cusumano らによる国際的 Survey 2001年から2002年の間に以下の組織を対象に調査。 インド Motorola India Electronics、Infosys、Tata Consulting、Patni Computing 日本 日立、NEC、IBM日本、NTTデータ、SRA、松下電器、オムロン、富士ゼロックス、オリンパス アメリカ IBM、HewlettPackard、Sun Microsystems、Microsoft、Siebel Syst
リーダーであるための視野・視座・視点 - Tech Inside Drecom
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
貸与PCがいつでも交換可能になりました - 本質を考え、大胆にルール改変 | mercan (メルカン)
こんにちは。CTOのid:sotarok です。 メルカンに記事を書くのは初めてとなります。 エンジニアたちは エンジニアブログ も頑張っておりますのでよろしくお願いします! さて、今日はメルカリのエンジニア・デザイナーの「貸与PCのルール」を変更したという話をしたいと思います。 貸与PCを「いつでも交換可能」にした メルカリでは、ほとんどのエンジニアやデザイナーが、Mac (主に MacBook Pro) を利用しています。 みなさんご存知の通り、最近待望の新モデルが出ましたね!! まあ、ESCキーがとか、USB-C がとか、Skylakeか … とか色々ありますが、間違いなく、待望の新モデルだったかと思います!笑 かくいう私も個人としては既に購入しました。TouchBar 意外と良いし、キーボードの感触も悪くないですよ。なにより軽くて最高ですね。 で、この度メルカリでは、エンジニア・デ
全力で効率の良くないチームをつくる - Mitsuyuki.Shiiba
というのが、最近の僕の好み。 効率の良いチーム 効率の良いチームは、みんなすごく効率良く仕事を頑張ってて。システムも効率良く既存のリソースを使ったりしてて、開発もすごいスピードで進んでいる。 なんだけど、最短の道を選び続けていて、どんどん選択肢がなくなっていって、動きが鈍くなってく。 そうすると、どうするか？「このままじゃダメだ！もっと効率良くやらなきゃ！」ってなって、最後には、頑張り続けて疲れた人が離れていく。そんな感じがする。 効率の良くないチーム きょろきょろしたり、うろうろしてみたりして、選択肢を広げておく。ペアワークとか。暗黙知の共有とか。形式知化とか。新しい技術へのトライとか。そういう、一見、遠回りに見える道の方が、実は近い。という感じがする。リファクタリングとかもそうかな。 遠回りに見える道を選ぶのには、勇気が要るのだけどね。だって、最短に見える道を選んだのにうまくいかなかっ
4ヶ月の間に一休.comで起きた変化 - zimathon blog
概要 最近いろいろな方（社内、社外含め）に、エンジニアチームどうですか？良くなってますか？という質問を頂きます naoya さんってどうなんですか？やっぱりすごいですか？とも その度に「良くなってますよー」と返事をするのですが、肌感としてはあるもののしっかり言語化できていない そこで、naoya さんがCTOとして今年の春に一休に来てからをちょっと振り返ってみた 振り返ってみるとたった4ヶ月ということに驚いています :eyes: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める
モバイル開発組織変遷モデル - hotchemi-ja-blog
今月から2年半いた組織を離れて新しい環境で、相も変わらずモバイルエンジニアとして働いている。 これまでモバイル開発専門の組織から1チームでAPIからアプリまで面倒を見るようなチームで働いてきたが、今の現場はまだモバイルチームがそんなに成熟しているわけはなく、これから色々と整備していこうという段階である。 これまでの経験の中で、どうやらモバイルアプリの開発組織には成長の過程に一定のパターンがあるらしい事に気付いた。 その変遷は、あたかもタックマンモデルの如く4つの段階から成っているように思える。 創生期 人数: 約1-3人 業務内容: Webviewベースのアプリのメンテ、スクラッチ開発等 組織がこれからモバイル開発にトライしていこうという状態、もしくはあまり力を入れていないがとりあえず既存アプリはメンテしたいという状態。 組織自体のモバイルへのコミットメント意識が薄いため、立場が弱くなりが
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない
タスク管理してますか？(あいさつ) みなさんは日頃どんなタスク・プロジェクト管理ツールを使っているでしょうか？ Backlog？Trello？Wunderlist？それともgithubのIssueで十分？カンバンほしいからZenhub？Waffle？変化球でProducteev? 僕も前職含めて上記含むすべてのツールを試してみました。 各タスク管理ツール所感 Trelloのガントない問題 ポンポンタスク登録できて便利。人のアサインも簡単だし。あ、でもこのタスクの粒度細かすぎない？依頼するときもされるときも細かすぎない？一つのリスト長すぎない？ あと標準でガントがないよね？全体見渡す側からすると不安（らしく）になっちゃうからやっぱりガントほしい。アサインできるの便利だけど、あぁでもこれボード6個くらいできちゃった。横断めんどい。どのボードもカードで溢れている。ガント追加してくれるサードパーテ
失敗を歓迎する組織へ - けんちゃんくんさんのWeb日記
今朝起きてMacBookをあけると、ディスプレイにはなにか触られたような跡がたくさんあって、スリープさせていたはずのマシンは電源が切れていた。 十中八九息子の仕業なわけだけど、本人は何も言ってこないのでしばらく待っていた。が、nasneで天才テレビくんの録画を見るのに夢中のようだ。 意を決して「パパのこれなんか変だなー」と言ってみると表情が変わる。 失敗することとそれを報告すること、あるいは叱るということ 基本的には、なにか失敗したときよりも、その失敗を言わないことを叱るようにはしている。(もちろん両親も人間なのでそうならないことも多々あるが…) 仕事だと、当然ながら失敗そのものよりその報告と対策をどうするかが大事なわけである。失敗をしてしまった人はたまたまババを引いてしまった、あるいは地雷を踏んでしまっただけで、ババがあるということ、地雷が埋まっていることを身を持って示してくれた勇者なの
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
リモートワーク
転職してリモートワーク始めて 5 ヶ月たった。 Basecamp （旧 37 Signals ）の本で読んで夢にまで見てたリモートワークだけど、始めてみると理想と現実は違った。 良かったところは？ リモートワークだと通勤時間がないとかがよくあげられる。しかし自分の場合は福岡に拠点がある東京の会社に雇われていてそこで一人で仕事してるので通勤時間ゼロにはなってない。家で仕事する日もあるけど大体毎日片道40分くらいかけて通勤してる。必要なミーティングさえ外さなければ病院行ったりとか子どもの面倒見たりとかできるのはよい。あと午前中家で仕事して、昼間の空いてる電車に乗って座って仕事しながら出社できるのも良い。ただ仕事に時間の区切りがなかったり家で仕事できるということは、気になる仕事を夜や休みの日に家でやってしまって、フルタイムの社畜に成り下がってしまうリスクを伴うので注意が必要。 さみしいのか？ さ
良いエンジニアの定義
今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル（以下プロマネ力と省略）も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも
残業しない会社のつくりかた - ゆとりずむ
こんにちは。 以前、とりあげた記事が、気がついたら1000ブックマークをこえていてびっくりしました( ﾟдﾟ) 色んな人に共有されて良かったなあ(∩´∀｀)∩とのんきに考えていたところ、ある方から連絡を頂きました。 おいこら、勝手に何しとんねん(^^) 昔ネトゲで仲良くなった、この会社の役員様からでした((((；ﾟДﾟ))) あ、すんません消しときます(´・ω・｀) まさかここまでシェアされるとは思わず・・・。企業秘密だったりしました？と言ったところ いやー、別にかまへんよ。親父がみんなに愛されてて面白かったわ。 と、あっさりOKを頂きました。わたしと同い年でも、二十歳で役員に任じられた男は懐の深さが違いますね。（ちなみに、社長さんの息子ではありません） ただうちは、『世の中の人がまだ見つけていない、技術の新しい活用法を発見する』ことに軸足をおいてきた会社。いい仕事をするために、働きやすい
あるシステム屋さんが平均残業時間一桁を実現した方法 - ゆとりずむ
こんにちは。 ここしばらく、システムトラブルの対応で午前帰りが続き、疲れてきてしまいました・・・。直接、トラブルの原因になった訳では有りませんが、エンジニアさんも巻き込んでしまい、もう少し上手く回す方法はなかったのかと、自分の未熟さを反省中です。 さて残業といえば、先生は大変そうですね。ただでさえ、ひとりで何十人もの生徒をみないといけない上、ほぼ無償ボランティアの部活顧問まで行い、その上で親に押しかけられたら溜まったもんじゃ有りませんよね。横浜市で、先制の『ノー残業デー』を設定するそうですが、多少なりとも状況が改善することを期待してやみません。 ただ、個人的にはこの『ノー残業デー』という制度がしっくり来ません。だって、『ノー残業デー』って、その日以外は残業することが前提なワケですよね？更に、こんなニュースも有ります。 正社員と同じ等級制度や人事制度を用いるため、基本給も同じ水準だ。賞与は正
ソフトウェアプロジェクトにまつわる神話 - A Memorandum
管理にまつわる神話 開発に必要な手順書も標準集も揃っている。必要なことをすべて部下に教えられないだろうか スケジュールに遅れたなら、さらにプログラマを追加すれば取り戻せる ソフトウェアプロジェクトを第三者機関に委託すれば、リラックスでき、その機関にソフトウェア開発を任せられる 顧客にまつわる神話 プログラムを書き始めるには、大まかな目的があれば十分である。詳細は後で決めればよい。 プロジェクトに対する要求は常に変化するものだ。ソフトウェアは融通がきくため、容易に変更できるだろう 技術者にまつわる神話 プログラムを書いて動くようにすれば、それで仕事は終わりだ プログラムを走らせるまでは、その品質を評価できない プロジェクトの成果物は、動いているプログラムだけで良い ソフトウェアエンジニアリングを現場に適用すると、大量かつ不要なドキュメントを作成しなければならず、間違いなく作業が遅れてしまう
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
