技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
転職しました! 2024年2月1日より、Theoria technologies に転職しました! theoriatec.com Theoria technologiesは製薬会社のエーザイの100%子会社で、認知症エコシステムの構築を目指す会社です。 2023年の9月にできたばかりの会社で、同じ日に入社したCTOが正社員1人目、私が2人目。他の人はエーザイからの出向者で、合わせて5人という出来立てホヤホヤの会社です。 Theoria technologiesにはTechLeadという肩書で入社するのですが、人数が少ないこともあり、やらないといけないこともたくさんあるので、持ち前の高機能雑用っぷりを最大限発揮しながら走っていこうと思います。 もちろん、一緒に働く仲間を大募集中なので、気になる方はぜひ声をかけてください! 文化や仕組みはもちろん、本当に会社を作っていくところからというフェーズ
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
Help us understand the problem. What is going on with this article? 先日、とある記事が削除された。 数時間の寿命だったのでご存じない方もいると思うので、つかみだけ紹介しよう。 簡単に言うと、Unityの有志開発ライブラリ、UniRxについての記事だ。 企業プロジェクトでUniRxを気軽に採用すると地獄だぞ、という内容だった。 そしてこの記事が削除された理由は、コメント欄に 「それ全部あんたのチームの問題であって、UniRxの問題ではなくない?」 という趣旨の反論、批判が発生したからである。 彼らの言い分はこうだ。 技術力が低い人間が高等な武器を手にしても自爆スイッチ押すだけだ、と。 なので、技術力を身に着けてから着手すべきだし、追加人員も教育してから実戦投入しろと。 ■ さて、この発言そのものは真理である。 チームの全員が
フィボナッチ工数見積は「完成させます!(徹夜で)」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンの IT スタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑な IT プロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エ
最近の音声入力環境はこんな感じになっています。 Android Huawei M3 リモートマウス Simeji なぜそうなったかというと、もともと使っていたiOSの音声入力がなぜか、つい最近iOSがバージョンアップしてからリモートマウスを使うと二重に入力されるようになったため、非常に不便だったからです。 そして仕方がないのでGoogle音声入力に変えたのですが、iPadやiPhoneでGoogle音声入力を立ち上げると一瞬間があって、それがストレスになるからです。 そして私がこういうことを困っているということを説明したら、作者の方からこのようなソフトウェアを教えてもらいました。 スマホ(Android)をWindowsの音声入力デバイスにする/ボイスチェンジャーにする VoiceInput これはGoogleの音声入力を基本にして、句読点を入れられるようにしたものです。これを使うためにタ
参考 @kidach1 さんの投稿をPythonに書き換えてるだけです。 @kidach1 さん、いつもありがとうございます。 https://qiita.com/kidach1/items/4b63de9ad5a97726c50c 概要 改めて基本を学ぶ。 参考「Rubyによるデザインパターン第1章」→この投稿はPython デザインパターンとは プログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。 無駄無く設計されたオブジェクト指向プログラムの実現をサポート。 パターンとしてカタログ化されていることで 車輪の再発明を防ぐ デザインパターンの根底にある5つの考え 変わるものを変わらないものから分離する プログラムはインターフェイスに対して行う(実装に対して行わない) 継承より集約 委譲、委譲、委譲 必要になるまで作るな(YAGNI) 変わるものを変わらないものから分離する
「また新しいブラウザー? もういいよ。」いえいえ、Bliskはちょっと違います。Web開発者向けに便利な機能を搭載した、開発者専用のブラウザーなんです。 日々のWeb開発にどんなブラウザーを使っていますか? 私がTwitter上で先日実施した投票の結果によると、開発者の4分の3は一般的なWebブラウザーを使っています。おそらく以下のような理由が想像できます。 1番よく使うアプリケーションである すでに自分が使いやすいように調整できている 優れた開発ツールが入っている(どれもそうですよね!) それらのユーティリティが快適である そもそも、好みのブラウザーである しかし、そのブラウザーはWeb開発作業に向いているのでしょうか? 私もそうですが、いつもブラウザーにさまざまなアプリやツール、あとで読もうと思っている記事(……でもほとんど読みませんけどね!)のタブを57個くらい開いているのでは? こ
jQuery系ライブラリによるDOM操作が中心のプロジェクトにがっつり機能を追加する機会があった。 そのJavaScriptのコードは他の人から引き継いだコードで、一応引き継ぎ時にディレクトリ構成、設計、実装方針について共有を受けたが、それでもいざ手を入れようとすると自分自身のコードの理解が進んでおらず「えーっと...」となってしまった。 上記以外にも、長年、多くの人が触れてきたJavaScriptのコードに機能を追加する、修正するのはなかなか難しいのではないか、と思う。最初は、ちょっとしたユーザビリティの向上のために書かれたスクリプトが、気がつけば多数のDOM操作、至る所で宣言される変数、どこから実行されるか分からない関数群で無秩序に膨れ上がり、頭を抱えることになる(そうならないようにするのがウェブフロントエンジニアがいるひとつの理由ですが…)。 これらのケースでは、まずは修正、あるいは
Kickstarterで申し込んでいたThe Roost Laptop Stand(とRKM case)がようやく到着した。出資したのはいつだったか覚えていないくらい前のことだが、とにかく届いてよかったよかった。 前にも書いたが、基本的に自宅の自室と大学の研究室を行き来する生活を送っているので、およそノマドワーカーとは言い難い。ただ、ここ数年は国内、海外問わず出張へ行くことが増えてきたし、職場が自然豊かな地(婉曲表現)にあるということもあって、都心へ行く用事がある際には出先で数時間仕事をするということもある。そうなると、普段慣れ親しんだ環境以外であれやこれやと作業をするということが多くなるわけだ。去年は大学図書館の地下書庫に籠もって調べ物をすることが結構あったので、そういうときもいわば出先で作業ということになる。 スタバ等のこじゃれたカフェだと、どこへ行ってもノマドワーカーないしノマドワー
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!本当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
広告が邪魔なのでspeakderdeckにも上げました https://speakerdeck.com/brtriver/ying-ye-yun-yong-wozhi-eru-qi-fu-keru-guan-li-hua-mian 動画: https://youtu.be/CqMILKp3Ens?t=3h53m39s PHPカンファレンス2015での講演資料。 データを管理するだけが管理画面じゃない。サービスの質を向上させていくことができる最強の管理画面を開発運用していて意識していることを4つの工夫を軸にまとめています joind.in: https://joind.in/15322
伊藤直也氏が語る、モダンな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などのフロントエンドにまで共通する考え方とは何か、示唆に富むその内容をダイジェストで紹介します。 モダ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く