オランダの金融機関INGが取り組んできたアジャイル型組織への変革が興味深いので、マッキンゼーによる彼等へのインタビューについて冒頭の部分を訳してみました。ぜひ読んでみてください。 マッキンゼー: 「アジリティ」をどう定義しますか？ ING: アジリティとはまず「柔軟性」、そして新しい方向に向かってすばやく適応できる組織の力がポイントです。前例踏襲や官僚的な部分を避けて、みんなの力を引き出そうとするわけです。 また、能力が高くバランスの取れたプロフェッショナルを「育成する」という側面も重要です。「アジャイル」であること、は単にIT部門やその他いろいろな部門を「変える」というのに留まりません。大切なのは、End to Endで一貫した原理を持つ、マーケティング、プロダクト、そして営業の専門家、UXのデザイナー、データアナリスト、そしてITエンジニアといった多様な分野の人たちからなるチーム -

日本の電子決済と異なり、中国のQRコードスマートフォン決済「アリペイ」「WeChatペイ」は、加盟店手数料などが原則不要だ。それでなぜ利益を上げられるのか。今日頭条が報じた。。 踏んだり蹴ったりの電子決済 日本で電子決済が広まらない理由。それは手数料だ。加盟店は一般的に3％から5％程度の手数料を支払わなければならない。お客さんが1000円のランチを食べても、電子決済で支払われたら、実質の実入りは950円で、50円は決済運営企業に支払わなければならない。 これは、ギリギリのコスト、ギリギリの利幅で経営している小規模飲食店にとって、かなりきつい。電子決済をする客が増えてきたら、値上げをせざるを得なくなり、値上げをすれば客数が減り、客数が減れば売り上げが下がるという悪い循環に入ってしまうのではないかという恐怖がある。 そのため、飲食店では、電子決済に対応していることを積極的にアピールしないことも

SREチームの那須です。 3/7に開催されたピクスタさんの 大規模プラットフォームを支えるエンジニアの技術と工夫〜Web現場Meetup #3〜 で登壇させていただきました。そのときにお話ししたgrpc-gatewayを使った管理画面の構築について改めてまとめてみます CrowdWorksのマイクロサービス化の試み CrowdWorksでは現在マイクロサービス化を進めています。 CrowdWorksはモノリシックなアプリケーションです。様々な機能が一つのアプリケーションに同居し、サービスを提供しています。 モノリシックなアプリケーションの問題点としては一つの問題が全体に波及してしまうということがあります。メッセージの機能を改修したところ問題が発生しアプリケーション全体が不安定になるということもありえます。 そこでCrowdWorksでは最初の試みとして、新しく作るサービスをCrowdWor

Terraform職人の @minamijoyo です。 クラウドワークスではAWSのインフラ構成管理にHashiCorpの Terraform を利用しており、 日々Terraformの設定ファイルを書いてるわけですが、 コード書いてると、リソースタイプの名前がうろ覚えとか、属性値の名前のスペルに自信がないとか、この属性値って必須項目だっけ？ とか、なんだかんだで公式ドキュメントを見ながらコードを書いてることが多いです。 Vimのプラグインで補完してくれるやつがあるのは知ってるんだけど、 あらかじめリストファイルを持っているアプローチだと、バージョンに合わせてリストファイルの更新しないといけなくて、仕組み上の限界があるし、サポートされてない自作プロバイダとかだとそもそも使えない。 なんかもっといいかんじにできないかなぁと思って、趣味でTerraformのソースコードを読んでたら、最近入っ

六年前、いたいけな田舎娘（私）が京大に入って驚いたのは「どうして今までそれで生きてこれたんだ……」という人間の多さであった。 どうして今までそれで生きてこれたのか。 京大というのは日本で一番自信家の多い大学である（という話を昔書いたことがある）。*1 ちなみにこれはライフハックなのだけど、職場や知り合いで元・京大生を見たら「ハッこいつ自信家だ！」と思ったほうがいい。基本的に謙虚なふりをしてても自信なさげに振舞ってても、そいつは心の奥底では自分が世界で一番エライと思っている人間である。本当に！ しかし話を戻すと、自信家という生き物は、基本的に出る杭は打たれるこの国で、「自信なさそうに振舞う」という処世術を習得する。それが普通である。 とくに中高なんて、みんな一緒の制服を着て同じ試験を受けて同じよーな場所に帰るわけで、いくら能力があったとて「俺/私、自信ありまーす！」なんて叫んでたら殺されるだ

採用の話がだいすきなみなさんこんにちは。@ryuzeeです。 アジャイル開発をはじめた当初はだいたいパイロットチームを作って、そこでうまくいくと組織内に横展開していくパターンが多いと思いますが、そのときに困るのがスクラムマスターです。 スクラムマスターは特に成熟度の低いチームにおいてその存在が欠かせませんが、いきなりスクラムの経験のない人にやってもらうのも大変なので外部から採用して解決しようとすることがあります。 このとき単に認定スクラムマスター研修に参加して認定資格持ってるから大丈夫か、というと全くそういうわけでもなくスクラムの本質を理解していていることが重要です。じゃあそれをどう確認するのか？という点について以下のサイトで採用のときに聞いてみると良い質問が38個紹介されていたので、ご紹介します。 Hiring: 38 Scrum Master Interview Questions T

What's PWA ? Progressive Web Apps （プログレッシブ　ウェブ　アップス）の略 Googleが推進している、モバイルユーザーの体験（UX）向上を目的とするプロジェクト・技術のこと PWAは、わざわざApple StoreやGoogle Play Storeからインストールする必要はありません 不安定なネットワークでも迅速に起動し、関連性の高いプッシュ通知を送信することができます。 ホーム画面にアイコンを表示することができ、トップレベルの全画面表示で読み込むことができます。 ▼このように、Webサイトを直接ホームに追加することでアプリケーション化されます 導入事例 大手WEBサイトからで導入がはじまりつつあります コンバージョンアップにも効果的です Trivago https://www.trivago.com Twitter Lite https://mobi

開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず

2016年8月時点の結果報告を追記します！ ということで、概ね１ヶ月継続が65%から70%という状況をキープしています。 フェーズ的に中長期施策をアプリで打てなかったので、半年継続はもう少し改善できると思いますが、３月継続でも半数を維持していますので概ね間違った選択はしていないことが証明されたかと思います。 エンジニアがディレクションをして１ヶ月継続率を半年で15%改善した方法 最近は技術職でもサービス改善の前線を担う一員として、「KPIの数値目標を個人目標に設定された！」というのは珍しい話ではないと思います。 私も、前々職では所属部署の目標としてそういった数値目標はありました。 個人目標としてはエンジニアとしての目標の設定でしたが、前職では旧来であれば企画職がもつ数値の目標を設定していただいたり、以前務めた会社では少数チームでエンジニアとはいえ、運営的なKPIを個人目標に設定いただいたり

dev.to を見ていたら、 #impostorsyndrome というタグがあり、 #shecoded でもけっこうみんな Impostor Syndrome に苦しんでいたという記述がありました。 調べてみたら、 Impostor Syndrome （詐欺師症候群） に陥っている方は多いんじゃないかと思い、というか自分がまさに当てはまった気がしたので、エンジニアの視点でまとめてみます。 Impostor Syndrome とは wikipedia によると インポスター症候群またはインポスター・シンドローム(英: Impostor syndrome) は、自分の達成を内面的に肯定できず、自分は詐欺師であると感じる傾向であり、一般的には、社会的に成功した人たちの中に多く見られる。 能力の高い人々は、自分が偽物であると人から思われたくないがために、熱心に働く傾向がある。その勤勉さの結果、人

アダルト業界でデザイナーとして働いていた頃、 あるデザイナーの「ゆるやかな死」を見たことがある。 ここでいう「ゆるやかな死」というのは、 「アウトプットの決定的な低下」のこと。 ▼ 音声で聞きたい方はこちらからお聴きくださいｂ ▼ エースデザイナーの「異変」その人（以後、Nさんとします）は僕が新卒入社する前から、DVDジャケットのデザインを1ヶ月で10点前後作り続けている現役バリバリのグラフィックデザイナーだった。 月で10点は、ジャケット以外の業務も含めれば余裕で週3くらいは残業が必要な量。それをNさんは月に1回くらいの残業で平気にこなす。 言うなればエース、シニアとも言えるデザイナーさんだった。 そんなNさんがある時から変化が生じ始める。 アウトプットのテンプレ化AVは「シリーズもの」が多い。 かの有名な「マジックミラー号」も、様々なシリーズ、企画内容が出ているが、それらをまとめて「マ

昨日 2月末に株式会社groovesを退職します を発表したエンジニアのマネージャーを務めている（2018年1月時点）赤川です。 本記事の前半では、なぜ彼が望む「フレックスでの深夜勤務」を用意できなかったかを紹介し、後半では彼と共にプロダクト開発に携わってきた立場から、彼の推薦文を書きます。 なぜこの記事を書くのか？ フレックス制度の導入を検討している会社の参考にしてほしい エンジニアの成長・キャリアアップを応援する Forkwell を運営している会社が、自社のエンジニアのキャリアアップや転職を応援しないのは嘘になるので、感謝をこめて送り出したい 今回の経緯 まず、今回の件について、彼とどのように会話を進めてきたかを紹介します。 2017年8月　1on1 MTG で、自身の生産性をあげるためにフレックスを導入したいと伝えられる。フレックスについて調査開始。 10月　エンジニアチームに、深

最近、自分のキャリアを考えていて、35歳定年説について考えてしまった。プログラマーに限らず、35歳というのは結構過渡期ではないかと感じている。最近もまつもとゆきひろさんのこんな記事があった。 http://hrnabi.com/2017/12/06/15766/hrnabi.com プログラマー35歳限界説というのは、おそらくマネージャーかプログラマーかのキャリアの分岐点であり、未だにキャリアを上げていくためにはマネジメントしかない環境でのことだと思う。ただ、私がいた環境も含め、これは徐々に変わってきていて、エンジニア自体が足りないという時代背景もあり、ある程度自己研鑽さえやっておけば、35歳以降もプログラマーとしてやっていくことは十分可能になってきたのではないかと思う。できない環境の方は、是非転職してみたらいかがだろうか。 そこでプログラマーだけでなく、ちょっと話を拡大して、もう少し仕事

こまたつです。 この記事は 退職者アドベントカレンダー の20日目です。 adventar.org 退職、流行ってますね！！*1 お前誰という人が多いかもしれないので、簡単に経歴を書いておきます。 新卒で小さいSI -> DMM.com Lab -> Cookpad と今回で退職は3回目です。 2012年くらいからAndroidエンジニアで、その前はstrutsとかCOBOLとかPL/SQLとかエクセル・ホーガン氏やってました。 クッ社ではJenkinsおじさんをやったり、やめる前はサービス開発をもりもり頑張っていました。 なんでやめたの クッ社はフレックス三食シャワー昼寝付きリモート可で強いエンジニアと研鑽できる、過去最高にいい環境だったのですが、次の理由があってやめることにしました。 東京のスラムと呼ばれる恵比寿での生活で消耗した*2 入社時に比べてだいぶ成長したので、独力でどのくらい

いわゆる人工知能技術が巷をにぎわす昨今、人工知能を研究する部署/団体を設立するのがトレンドになっています。もちろん、部署の設立にはそれをマネジメントする人間が必要です。「その時」は突然やってきます。 「わが社でも人工知能技術を研究しビジネスに役立てるべく、新しい部門を設立することになった」 「はい」 「ひいては、君にその部門のマネジメントを任せたい」 「！？」 「将来的には100人規模にし3億円規模のビジネスにしたいと思っている(※)。まずは中期計画を作成してくれ」 「そ、それは・・・」 「部門設立のプレスリリースは来月発行される。よろしく頼むよ(肩ﾎﾟﾝｯ」 (※: 好きな数字を入れてください) (from 疾風伝説 特攻の拓) 本文書は、実際こうした事態が起こった時に役立つチェックリストとして機能するようにしてあります。具体的には、以下の構成をとっています。 設立編: 何を「目指す」の

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

はじめに クラウドワークスの初期バージョンを作ってから早6年。後任のエンジニアたちには様々なdisりを受けてきました。 システムアーキテクチャや設計（命名は除く）に関するdisりについては、何よりもビジネスを軌道に乗せることが優先されるタイミングでどこまで「ちゃんと」やるべきか、という議論の余地が常にあります（自分のスキル不足については、いったん棚に上げます）。 一方、「命名」については、サービス立ち上げ期であっても「ちゃんと」やるべきと断言できます。 なぜならば、 システム外（例えば、非エンジニアとのコミュニケーション）にも関係してくる、ある意味ではシステムの最も基礎的な部分と言えるため、ここでしくじると影響範囲がでかい ネーミングをがんばったからといって、それ自体にかかる時間はたかが知れているし、その後の開発速度に悪影響を与えることもほとんどない すなわち、命名を「ちゃんと」考えるとい

Web技術の標準化団体であるW3Cは、HTML 5のマイナーバージョンアップである「HTML 5.2」の策定を完了し、勧告としました。 HTML 5.2ではいくつかの機能追加、削除、バグフィクスなどが行われています。 機能追加の例では、ダイアログボックスを表示する＜dialog＞要素が追加されました。下記は＜dialog＞要素を用いたサンプルです。 ... <body> <div> <!-- body content --> </div> <dialog> <h1>Add to Wallet</h1> <label for="num">How many gold coins do you want to add to your wallet?</label> <div><input name=amt id="num" type=number min=0 step=0.01 value=10