はてなブックマーク

Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。 フォースを感じる 自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。 ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ

最新版 本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。 i2key.hateblo.jp 本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。 共通の価値観としての「リードタイム」 SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得

社内でマインドフルネスの30分ワークショップをやったのでメモとして残しておきます。 本当は長期にわたる研修なので、こんな簡単な話ではありません。 以下の様な禅語があります。 調身 調息 調心 正しい姿勢を保ち、正しい呼吸法で坐禅を組めるようになれば、心身ともに整うという意味です。 このように、本来は、正しい姿勢のとりかたに始まり、さらには、正しい睡眠のとりかたについて、食生活について、などなど、様々なことを学んで実践した上で、やっと調心（マインドフルネス）のフェーズになります。が、今回はそういうの全部すっ飛ばして要素のみを。興味を持った方へのググラビリティを提供するという意味で。 マインドフルネスって何よ。 日本でいうところの「瞑想」になります。ただし、瞑想というとどうしても伝統的な、宗教的な意味あいが入ってしまうのですが、マインドフルネスはそういうのを一旦全部除外して、サイエンスなアプロ

Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d

本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。 ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。 無駄なく、効率的にと思っても、ついつい発生しちゃう。 こういうの、オーバーエンジニアリングって言うらしいよ！？ でも、どこからオーバーで、どこまではオーバーじゃないんだ！！ ということで、勝手にオーバーエンジニアリングを定義してみようと思います。 作り過ぎて、時間や金を無駄にすること？？？？ とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。 wikipedia（英語版） Overengineering - Wikipedia 一部抜粋。 Overengineering (or over-engineering,[1]

Recruit Engineers Advent Calendar 2022 - Adventar 23日の記事になります。 1. 方法論は限定スコープ内における合理性の話である 書籍などで得られる概念や方法論（技術含む）は、その書籍がスコープとしている中での限定合理性の話をしており、 書籍がスコープとした範囲における論理的正しさである場合がある。 特定のスコープの中においての最適なので、実は全体からみると個別最適だったりする。 つまり、実は引いてみると非効率なことを近距離でみると効率的だと主張している場合もある。 この包含関係による概念的強さみたいなものは存在しており、例えば、制約条件理論みたいなものは、様々な概念の上位に存在しており包含していたりする(そう勝手に思っている)。スコープを決めそのスコープ内におけるボトルネックを活用しスループットを最大化させるという概念的な強さはあり、その

本ポストは下記のアドベントカレンダー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でファボッたツイートを自動的にインスタペーパーに登録したりとか、そういう連携です。 あと

チームをスクラムにしたいのですが とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。 PO、SM、エンジニアの相互の信頼が一番大事。 信頼がポイント。それがない状態で始まると意味のない何かになりやすい。 最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。 そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕（PO）はそんな天才でもない

LINEで使われているような電話番号による認証を試しに作ってみたので、ブログにまとめておきます。 電話番号認証とはこんなのです。 まず、電話番号を用いた認証ですが、方式が2通りありますので、それらの概要を説明します。 SMS利用パターン 電話番号をアプリ側で入力すると、サーバから4桁の暗証番号入りのSMSが届き、その4桁の暗証番号をアプリ側で入力することで電話番号が正しいことを証明するやりかたです。 SMSを送信するには送信元の番号が必要になります。また、例えばアメリカ、カナダのようにショートコード(SMSで利用される事業者コード)を取得する必要のある国もあります。ショートコードは審査が入るため、数ヶ月取得に要することがあります。今回は送信者番号は通常の電話番号にします。 IVR利用パターン IVRとはInteractive Voice Responseの略で、自動音声応答による認証です。

このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN

「再発防止策はチェックリストによる目視確認」 開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。 そこでよくある議論として、 とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します！今後はリリース前確認でかならず目視でチェックリスト確認を実施します」 ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」 みたいな光景です。 ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてで

完全に出遅れ感ありますが、モダンアジャイルが気になってきたのでちょこっと自分の中で理解のために整理をしてみました。モダンアジャイル自体にプラクティス厨やめろというメッセージが含まれているかとは思いますが、とは言え、本家 Modern Agile - Industrial Logic でもある程度はプラクティス風な記載はされているので同様にやるべきこと、やるとよいことをプロットして思考を整理しました。箇条書きで見にくいかとは思いますが、あくまで自分用なので。今後追記編集していくかもです。テキトーに自分用メモとして書いただけなので間違ってたら指摘ください。また、入門というタイトルは自分が入門しただけなので、入門者のために書いてるわけではないのであしからずw 各プラクティスや方法論は理解してる前提で箇条書きしてます。 Modern Agileの位置づけの理解 ここにプロットされている諸々の方法論

先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。 フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda www.slideshare.net また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。） フロー効率性とリソース効率性についてかんたんな説明 リソース効率性について リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空き

DevOpsはエンタープライズのスタートアップへの憧れ と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ？そもそもあってるっけと思いFacebookストーキングしたら違ってた。 "DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。 自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下（Dev部門、Ops部門、ビジネス部門、...and so on）においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近

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日 概要 大企業も従来のマネジメント方法だけでは不確実性に対峙する際に立ち行か

本ポストは特に私が所属する組織の見解ではなく、私が今までの経験＆自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス

Account.frameworkで既にTwitter認証済みのACAccountを使い回してiOS側からSLRequestやTWRequestでAPIコールをしているだけであれば、必要ないのですが、どうしてもサーバにもAccsessTokenやAccessTokenSecretを渡したい場合があります。 しかしながら、ServiceTypeがTwitterの場合、ACAccountにはACCredentialがあるもののその中のoauthTokenは空っぽです。Facebookの場合は、入っています。 つまり、ACAccountStoreでのTwitter認証の場合、tokenの生データに触れることができません。 そこで必要になるのがReverseAuthになります。 詳細はこちらにかいてあります。 https://dev.twitter.com/docs/ios/using-rever

ブログはじめました。インプット期間が長過ぎたため、そろそろアウトプットしていかないとという焦りもあり、ブログ始めます。久々のブログなので、記事ひとつに対するパワーの入れ方がわかっていないので、長い文章になってしまいました。すみません。 最初のブログですが、社内勉強会について書いてみます。キッカケは先日、DevLove主催の社内勉強会x勉強会に参加してみて色々な方々とお話をして、自分の経験も共有することで、これから社内で勉強会を始めようとしている誰かの役に少しでもたてるかなぁと思ったためです。内容は勉強会の進め方とかテクニック的な話ではなく、自分を何が後押ししてくれたかのようなマインド要素が強くなっております。また、メリハリをつけた文章にするため、ややコントラストを強めに思い出を美化しております。 私は8月に転職をしていて、現在も転職後の社内で勉強会をしていますが、今回、ここで書きたい内容は

Web2.0で火がついたマッシュアップブームにより、WebAPIが脚光を浴びました。 当時は、GoogleMap上に何かを表示して、すげーーーってなっていただけですが、 最近は、スマホアプリのバックエンドとしてのより実用的な需要が高まっております。 スマホアプリを開発する場合は、サーバサイドはJSONをレスポンスするREST形式のAPIにすることが一般的だと思いますが、それらのAPI提供社側はJavaDocのような統一したAPIリファレンスがあるわけではなく、各社独自にリファンスドキュメントを公開しております。もっとフォーマットが統一されていると見やすいですよね。（個人的にはGoogleAppsのAPI Consoleが好きです。APIリファレンスであり、実行も出来るという。） 以下に、いくつかAPI公開されているもののリファレンスをあげてみます。 ATND API http://api.

ローレムに提供した下記ネタの原文を自分の活動ログとしてこっちにも残しておきます。（マルチポスト的でごめんなさい） 余裕があればもっといっぱい色々書きたいことあるので追記していきます。多分。やっぱしないかも。 l-orem.com リーンスタートアップで大事なことは、リスクを最小化するという価値観や考え方だ。一方Webや書籍ではどうしても教科書的な内容が多い。その様な環境において、初学者はどうしてもそこに書いてあるやり方ばかりにフォーカスしてしまう。結果「これはリーン」「これはリーンでない」というどうでもいい議論になりがちだ。本記事ではそこに一石を投じたいと思う。 リーンスタートアップを方法論として捉えてる人へ・・・うまくいきゃどうやったっていいじゃん！ 本記事は4/16に開催されたリンスタ関ヶ原での発表「LEAN STARTUP アンチパターン」から抜粋した物です。 1. キャンバス依存パ

Androidの実装をOSのバージョンが2.xの頃からしておらず最近のコーディングの仕方をキャッチアップしているので、メモを残して行きます。 画像キャッシュ メモリキャッシュ ディスクキャッシュ 大きなBitmapをメモリに読み込むときに気をつけること inPreferredConfigで画像の質を下げメモリ使用量を減らす inPurgeableでGC時に解放されるようにする inJustDecodeBoundsとinSampleSizeでメモリ読み込み時にメタ情報のみを先に読み込み、1/nサイズにしたものをロードする Bitmapオブジェクトのリサイクル 画像キャッシュ メモリキャッシュ Twitterのタイムラインを実装するような時に、APIレベル12以前は下記のように画像キャッシュをしていたと思います。WeakHashMapのがいいかもですが。 public class ImageC

ふと思い立ってかいた。 スマホアプリを開発する際、mixiさんが公開しているようなスマホ向けガイドラインと同様にAPIサーバでも、ある程度の確認用のガイドラインを個人的に設けていますので、メモとして公開してみます。クラウド環境の登場により誰でも簡単にサービス公開できるようになりましたが、結局のところインフラ構築コストが無くなるだけであり、サーバ品質は自身で担保しないとなりません。 前提 本ガイドラインの目的 リリースしてから、問題が発見されるようなことが無いように、サービスを運用する上で確認すべきことをリスト化しています。機能要件の試験は済んでいることを前提とし、運用レベル確認のためのリストになっています。当然、品質目標はミッションクリティカルなレベルの品質ではなく、toC向けの無料スマホアプリレベル品質になります。 対象 スマホアプリ向けAPIサーバ 環境 AWS等のスケーラブルなクラウ

Java1.5からEnum型が追加され、定数の定義等に利用されていますが、EffectiveJava久々に読み直していたら、EnumでSingletonをやるのがおしゃれさんだよと書いてあったので、ブログにメモしときます。 周知の事実すぎるので、今更かよ感ありますが、知らなかった人は明日からやってみてください。 Java1.5より昔は以下の様にSingletonにしていたと思います。ここでは遅延初期化とか、スレッドセーフかどうかとか、シリアライズで複製されちゃうじゃんとかそういうことは分かり難くなるので、省きます。そうすると、こんな感じですね。 package singleton; public class TraditionalSingleton { private static final TraditionalSingleton INSTANCE = new TraditionalS

第三回Playframework勉強会で発表してきました。 当日のtoggetterはこちら。 内容は、今回私が開発したソーシャル音楽アプリAttaccaでPlay2.0+Javaを選択した経緯がメインになります。 こんなアプリです。 発表資料はRECRUITの黒田として発表した部分は省いております。i2key個人として発表した部分のみにしております。ご了承ください。 Play2.0+Javaでサービスを本番稼働させた話 #play_ja View more presentations from Itsuki Kuroda UST録画はこちら。 Video streaming by Ustream 17:14 〜 43:00が私の発表になります。 最後のAction Invoker Actorsの値についてですが、やはり512はやりすぎwwwと@Masahitoさんにご指摘をうけました。ま

今年の振り返りがてら、オフィシャルな社外発表ベースの今年のアウトプットの雑なまとめ。大体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

こんばんは。Play! framework Advent Calendar 2011 jp #play_jaの12月23日の記事になります。よろしくお願いします。 さて、Spring Module知ってますか？ Play!にはSpring Moduleなるものがあります。これによってPlay!でもSpringFrameworkを使うことが可能になります。 Springを使うことのメリットとしては、それなりに大規模な開発において、インタフェースクラスを確実にきって、責務の所在を明らかにした実装を行うケースかと思います。 そして、Springを使うことでフィールドに依存ロジックをhaveする実装になり、外部から依存ロジックを注入可能になることで結果的にテスタビリティが上がるので個人的に好きだったりします。 そもそもPlay!が「そういう面倒なことしなくていいから、ささっと作って動かして確認して

アウトプット デベロッパーズサミット2022にyoutuberとして登壇 「オーバーエンジニアリングって何！？ぶくぶく膨れ上がる仕様、使われない機能、過剰品質、、、突き詰めたら、その先に真のチームの姿があった。」というタイトルで登壇させていただきました。勝手にyoutubeで再演しているのでおいておきます。 ブログ版 i2key.hateblo.jp また、公募賞（平均満足度1位）を頂きました。ありがとうございました。 codezine.jp 毎年やっている新人向け研修資料公開 毎年新人向けにやっている研修資料の2022年度版です。つぎたしつぎたしで毎年アップデートしております。 ブログ2本 アドベントカレンダーシーズンにしかブログを書かなくなってしまった・・・・・。のですが、結構ブクマやPV数がありまして、ありがとうございます。 「納期コミットのオーダーは結果的に納期を遅らせること」を逆