サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
装丁を味わう
i2key.hateblo.jp
Recruit Engineers Advent Calendar 2022 - Adventar 23日の記事になります。 1. 方法論は限定スコープ内における合理性の話である 書籍などで得られる概念や方法論(技術含む)は、その書籍がスコープとしている中での限定合理性の話をしており、 書籍がスコープとした範囲における論理的正しさである場合がある。 特定のスコープの中においての最適なので、実は全体からみると個別最適だったりする。 つまり、実は引いてみると非効率なことを近距離でみると効率的だと主張している場合もある。 この包含関係による概念的強さみたいなものは存在しており、例えば、制約条件理論みたいなものは、様々な概念の上位に存在しており包含していたりする(そう勝手に思っている)。スコープを決めそのスコープ内におけるボトルネックを活用しスループットを最大化させるという概念的な強さはあり、その
これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。(書いているのは21日です。) 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■:実作業日(問題なければできそうな工数) □:バッファ日(例えば50%の確率で問題おきたときに使う予
サマリ 体重が100kg から 79kgに減量成功。目標BMI値の人と同じ食事を取り続けるとそこにBMIは収束するらしい。 youtubeはじめた。チャンネル登録よろしくね!! バイクを趣味にした。バイク免許を小型自動二輪(8月卒業)、普通自動二輪(10月卒業)、大型自動二輪(12月入校) 納車を1年で3回経験し、納車中毒に。納車のUX最高。好きな単語は納車。今年の1年を表す単語は納車。 仕事 1月にRegional Scrum Gathering Tokyo 2021にてカネとAgileという登壇をしました。 カネとAgile(大企業新規事業編) #rsgt2021 from Itsuki Kuroda 5月に新入社員向けの研修資料公開。新人のとき聞きたかったといわれた話を新人向けにしました。 事業価値とエンジニアリング。 会社のアドベントカレンダーに以下を投稿しました。 大事ではないこ
本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。 ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。 無駄なく、効率的にと思っても、ついつい発生しちゃう。 こういうの、オーバーエンジニアリングって言うらしいよ!? でも、どこからオーバーで、どこまではオーバーじゃないんだ!! ということで、勝手にオーバーエンジニアリングを定義してみようと思います。 作り過ぎて、時間や金を無駄にすること???? とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。 wikipedia(英語版) Overengineering - Wikipedia 一部抜粋。 Overengineering (or over-engineering,[1]
2018年みなさま大変お世話になりました。2018年は、マネジメントする組織のメンバ数が20人から100人へと拡大したことがあり、はじめてずくしの1年でした。そのため、基本的にはインプットの年で、社外登壇やアウトプット活動はほとんどしておりません。そんなのする暇がなかった・・・・。でも、ゲームはかなりしました。ゲームの話と、数少ないアウトプットをまとめておきます。 Regional Scrum Gathering Tokyo 2018 Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。 川口さんから恐怖のパネルセッションのオファーを頂き、前回のPO祭りの当日丸投げ対策として事前に仕込んだ資料になります。 カネとAgile #RSGT2018 from Itsuki Kuroda confengine.com DevLove関西 ”効率が
Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。 フォースを感じる 自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。 ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ
「再発防止策はチェックリストによる目視確認」 開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。 そこでよくある議論として、 とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します!今後はリリース前確認でかならず目視でチェックリスト確認を実施します」 ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」 みたいな光景です。 ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてで
今年の振り返りがてら、オフィシャルな社外発表ベースの今年のアウトプットの雑なまとめ。大体0.5回/月の社外登壇らしい。 2017/02/16 Developers summit 2017 新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi from Itsuki Kuroda www.slideshare.net i2key.hateblo.jp 2017/03/18 DevLove関西リンスタ関ヶ原(新大阪の変) リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan from Itsuki Kuroda www.slideshare.net 2017/06/18 DevLOVE200 Bridge 上記デブサミの以下の焼き直し 事業が対峙する現実からエンジニアリングを俯瞰する #devlove from
THE STARTUP WAY THE STARTUP WAYはLEAN STARTUP著者のERIC RIESの最新刊になります。ERIC RIESがLEAN STARTUPの考え方を大企業に適用させる場合の考えかたについて記載されています。前作のLEAN STARTUPを読まれて実践されている方をベースに読んでみたまとめを書いてみます。英語は苦手オブ苦手なので、誤訳というか誤理解もあるかもしれませんが、全体の雰囲気が伝わればよいかなくらいの期待値でおねがいします。大企業でリーンスタートアップを実践している人には伝わるとは思うので。 なお、フランクにではありますが、エリックからは本中の図の引用の許可は頂いております。 Yes please do— Eric Ries (@ericries) 2017年11月26日 概要 大企業も従来のマネジメント方法だけでは不確実性に対峙する際に立ち行か
先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。 フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda www.slideshare.net また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について(QCDのトレードオフなんて本当は無かったんだ) - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。(と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。) フロー効率性とリソース効率性についてかんたんな説明 リソース効率性について リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空き
最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得
完全に出遅れ感ありますが、モダンアジャイルが気になってきたのでちょこっと自分の中で理解のために整理をしてみました。モダンアジャイル自体にプラクティス厨やめろというメッセージが含まれているかとは思いますが、とは言え、本家 Modern Agile - Industrial Logic でもある程度はプラクティス風な記載はされているので同様にやるべきこと、やるとよいことをプロットして思考を整理しました。箇条書きで見にくいかとは思いますが、あくまで自分用なので。今後追記編集していくかもです。テキトーに自分用メモとして書いただけなので間違ってたら指摘ください。また、入門というタイトルは自分が入門しただけなので、入門者のために書いてるわけではないのであしからずw 各プラクティスや方法論は理解してる前提で箇条書きしてます。 Modern Agileの位置づけの理解 ここにプロットされている諸々の方法論
Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d
このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN
本ポストは特に私が所属する組織の見解ではなく、私が今までの経験&自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス
DevOpsはエンタープライズのスタートアップへの憧れ と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ?そもそもあってるっけと思いFacebookストーキングしたら違ってた。 "DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。 自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下(Dev部門、Ops部門、ビジネス部門、...and so on)においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近
チームをスクラムにしたいのですが とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。 PO、SM、エンジニアの相互の信頼が一番大事。 信頼がポイント。それがない状態で始まると意味のない何かになりやすい。 最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。 そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕(PO)はそんな天才でもない
ローレムに提供した下記ネタの原文を自分の活動ログとしてこっちにも残しておきます。(マルチポスト的でごめんなさい) 余裕があればもっといっぱい色々書きたいことあるので追記していきます。多分。やっぱしないかも。 l-orem.com リーンスタートアップで大事なことは、リスクを最小化するという価値観や考え方だ。一方Webや書籍ではどうしても教科書的な内容が多い。その様な環境において、初学者はどうしてもそこに書いてあるやり方ばかりにフォーカスしてしまう。結果「これはリーン」「これはリーンでない」というどうでもいい議論になりがちだ。本記事ではそこに一石を投じたいと思う。 リーンスタートアップを方法論として捉えてる人へ・・・うまくいきゃどうやったっていいじゃん! 本記事は4/16に開催されたリンスタ関ヶ原での発表「LEAN STARTUP アンチパターン」から抜粋した物です。 1. キャンバス依存パ
社内でマインドフルネスの30分ワークショップをやったのでメモとして残しておきます。 本当は長期にわたる研修なので、こんな簡単な話ではありません。 以下の様な禅語があります。 調身 調息 調心 正しい姿勢を保ち、正しい呼吸法で坐禅を組めるようになれば、心身ともに整うという意味です。 このように、本来は、正しい姿勢のとりかたに始まり、さらには、正しい睡眠のとりかたについて、食生活について、などなど、様々なことを学んで実践した上で、やっと調心(マインドフルネス)のフェーズになります。が、今回はそういうの全部すっ飛ばして要素のみを。興味を持った方へのググラビリティを提供するという意味で。 マインドフルネスって何よ。 日本でいうところの「瞑想」になります。ただし、瞑想というとどうしても伝統的な、宗教的な意味あいが入ってしまうのですが、マインドフルネスはそういうのを一旦全部除外して、サイエンスなアプロ
エンジニアとしてサービスを作ってる時にどうしても行き詰まるのが、デザイン。 仮に、それがデザイナーと組んでチームとしてやっているときは良いのだけど、エンジニアの自分だけでやっているような場合特に困る。 Webサービスを作るのであれば、最近はTwitterBootstrap等を使えば、それっぽく見えるようになってきたし、また、iOSに関しては標準のUIKitのデザインでまあまあ綺麗。プロダクトとしてもMVPは達成できると思う。Androidに至ってもかつてはデフォルトだとなにこれ感がつよいUIだったけど、最近はよくなってきているし、**Bootstrap系なデザインライブラリを使えばそこそこ綺麗につくれる。その上で、残る課題がアイコン。ロゴ。 OSSをGithubで公開しているような方の場合は、ソースコード自身がプロダクトのため、デザインは不要かもしれないけど、やはりロゴ。ロゴが欲しくなると
もう数ヶ月前のことですが・・・、Developers Summit 2015で発表してきました。 そして、先日のDevelopers Summit 2015 Summerにて発表&表彰をして頂きました。 デベロッパーズサミットというと数年前の自分からしたら神々がそれぞれのマサカリでもって斬り合いする天下一武道会みたいなもので、まさか自分が登壇することになるとは(しかも2回も連続で)夢にも思っていませんでした。 今でも想像するだけで脇に変な汗かくくらい鮮明に覚えていますが、この壇上から300人くらいの方々に話すというUXはとてつもなかったです。高校時代はバンドをやっていましたが、人の前で演奏しているときの感覚とすごく近い体験でした。色々なコミュニティの勉強会で登壇させていただくことはありましたが、それらとは全くの別物でした。程よい緊張感と楽しさが同居する感じ。もうそんな機会はないと思いますが
先日開催されましたDevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜 - DevLOVE | Doorkeeperで発表させて頂きました。 会場でのMVP投票にて1位と2票差で2位でした。投票して下さった方々、本当にありがとうございました! 発表資料をはっつけておきます。 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove from Itsuki Kuroda あと、補足で社内でリーンスタートアップについて説明する機会が最近多いのでそのために作った資料ものっけときます。 リーンスタートアップ概論 from Itsuki Kuroda リーンスタートアップ概論
本ポストは下記のアドベントカレンダー13日の記事になります。 Web API Advent Calendar 2014 - Adventar ところでみなさん、Zapierってご存知でしょうか? The best apps. Better together. - Zapier 一部界隈では便利ツールとして凄く有名ですが、ご存知ではないかたのために簡単に説明いたします。 APIとAPIをコーディング無しで連携させることが出来るハブサービスになります。 Yahoo PipesとかIFTTTのようなイメージです。 ただ、連携可能なサービスがものすごく多く、300以上あります。SlackやTwitter、Instagram、Facebook、JIRA、Trello等有名どころは大抵連携できます。 Twitterでファボッたツイートを自動的にインスタペーパーに登録したりとか、そういう連携です。 あと
Androidの実装をOSのバージョンが2.xの頃からしておらず最近のコーディングの仕方をキャッチアップしているので、メモを残して行きます。 画像キャッシュ メモリキャッシュ ディスクキャッシュ 大きなBitmapをメモリに読み込むときに気をつけること inPreferredConfigで画像の質を下げメモリ使用量を減らす inPurgeableでGC時に解放されるようにする inJustDecodeBoundsとinSampleSizeでメモリ読み込み時にメタ情報のみを先に読み込み、1/nサイズにしたものをロードする Bitmapオブジェクトのリサイクル 画像キャッシュ メモリキャッシュ Twitterのタイムラインを実装するような時に、APIレベル12以前は下記のように画像キャッシュをしていたと思います。WeakHashMapのがいいかもですが。 public class ImageC
Social.frameworkとAcount.framework使ってTwitter投稿とTableViewへのタイムライン取得&表示でSwiftをハローワールドしました。 xcodeでコード補完が殆ど効かなくて苦行でした。 コードをおいときます。(実行環境はxcode6-betaなので、いつ動かなくなってもしらんです) https://github.com/i2key/HelloSwift こんな感じね。
Play2.1.3 Javaで発生したけど、こうするとなおるよ。Play2.1.3 Scalaはしらぬ。 @kara_d さんに教えてもらたのでメモ。 Build.scalaのmainに以下を追加 testOptions in Test ~= { args => for { arg <- args val ta: Tests.Argument = arg.asInstanceOf[Tests.Argument] val newArg = if(ta.framework == Some(TestFrameworks.JUnit)) ta.copy(args = List.empty[String]) else ta } yield newArg } こんな感じ val main = play.Project(appName, appVersion, appDependencies).sett
ふと思い立ってかいた。 スマホアプリを開発する際、mixiさんが公開しているようなスマホ向けガイドラインと同様にAPIサーバでも、ある程度の確認用のガイドラインを個人的に設けていますので、メモとして公開してみます。クラウド環境の登場により誰でも簡単にサービス公開できるようになりましたが、結局のところインフラ構築コストが無くなるだけであり、サーバ品質は自身で担保しないとなりません。 前提 本ガイドラインの目的 リリースしてから、問題が発見されるようなことが無いように、サービスを運用する上で確認すべきことをリスト化しています。機能要件の試験は済んでいることを前提とし、運用レベル確認のためのリストになっています。当然、品質目標はミッションクリティカルなレベルの品質ではなく、toC向けの無料スマホアプリレベル品質になります。 対象 スマホアプリ向けAPIサーバ 環境 AWS等のスケーラブルなクラウ
アウトプット デベロッパーズサミット2022にyoutuberとして登壇 「オーバーエンジニアリングって何!?ぶくぶく膨れ上がる仕様、使われない機能、過剰品質、、、突き詰めたら、その先に真のチームの姿があった。」というタイトルで登壇させていただきました。勝手にyoutubeで再演しているのでおいておきます。 ブログ版 i2key.hateblo.jp また、公募賞(平均満足度1位)を頂きました。ありがとうございました。 codezine.jp 毎年やっている新人向け研修資料公開 毎年新人向けにやっている研修資料の2022年度版です。つぎたしつぎたしで毎年アップデートしております。 ブログ2本 アドベントカレンダーシーズンにしかブログを書かなくなってしまった・・・・・。のですが、結構ブクマやPV数がありまして、ありがとうございます。 「納期コミットのオーダーは結果的に納期を遅らせること」を逆
hatena blogデフォルトだと横幅が狭く、ソースコード等が見難いのでカスタマイズしたのでメモ。 /* <system section="theme" selected="report"> */ @import "/css/theme/report/report.css"; /* </system> */ /* <system section="background" selected="fff"> */ body{background:#fff;} /* </system> */ pre.code{ font-size: 70%; background:#EEEEEE; max-height: 500px; white-space: pre; overflow: auto; } #container { width: 1200px; } #content { padding-left
次のページ
このページを最初にブックマークしてみませんか?
『@i2key のBlog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く