同僚が potatotips という Android/iOS の Tips を共有する勉強会、というのやってて楽しそうだったのがあり、そういやPHP懇親会、という最初から飲んで全員が発表するスタイルの勉強会大昔にやったな、というのを思い出してもう一度なにかやってみよう、と思いました。 phpblt.connpass.com ちょっとテッキーなかんじの雰囲気にできると面白いかなーと思います。 ネタには制限はとくにないけど、宣伝っぽいやつじゃないほうがいいな。 もはや PHP にネタは限定しないので、Web周辺、インターネット全般でも良いかと思います。 BLT ポテトチップスに対抗するならなにがいい、と同僚のQAの子に聞いたら「ベーコン！」といってたので、BLT を思いついて、ちょうど LT って入ってるから良さそうだと思って決めちゃいました トップのカチョイイ絵は同僚のスーパーデザイナーが作

エンジニアの視点を学ぶデザイナーとエンジニアは仕事の仕方も考え方も異なります。しかし、良い製品をつくるためにはお互いの協力が欠かせません。考え方が違うからといってそのままにしておくと、品質の低下に繋がることがあります。 「デザイナーはユーザー（人）の声や行動に耳を傾けるべき」「彼らのニーズに合わせた提案や設計をすべき」といった論調を見かけることがありますが、これはユーザーだけでなく、一緒に仕事するエンジニアにも適応できます。すぐ側にいるエンジニアを考慮した提案ができないのであれば、ユーザー相手はもっと難しいと思います。 今でも仕事でビジュアルデザインを担当することがありますが、エンジニアと仕事をする際に以下の 6 点に気をつけています。 1. どういうタイプのエンジニアか知るすべてのエンジニアがデザインに興味があるとは限りません。中には仕様を指示してもらえればそれで良いといった方もいます。

最初に正直に書きますが、この問題については、ぼくも日々悩み続けています。優秀な人が絶対辞めない素敵な方法があるのならぜひ教えていただきたいところですが、ぼくなりの思うところを書いてみたいと思います。（というか段々回答を書くのがしんどいご質問が増えてきたような…。もっと軽めなご相談でも大歓迎です！） まず、エンジニアが転職する理由は本当に様々です。報酬が理由なこともあれば、その企業で使っている技術が不満、ということもあります。他社に一緒に働きたい人がいる場合もあれば、会社の規模、場所、昇進しやすさなどが合わないこともあるでしょう。このほか、マネジャー職に就いたものの、メンバーとしてやり直したいと思ったり、プロジェクトが一段落し、なんとなく長く勤めたので変化が欲しいと考えたりする人もいるかもしれません。非常に多くの要素が絡みますし、常に隣の芝生は青く見えますので、上司としてはエンジニアのリテン

非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー

先日、同僚のスペイン人インターンにちょっと難しいかなぁってレベルのタスクを振ったんですね。そしたら 「もちろんできるけど、やり方はわからない！」という返事が返ってきて、これはめちゃくちゃいい返事だなぁと思ったので色々考えたことをまとめておきます。 できないと言わない重要さ 自分の経験上、できないと言うよりできると言ってしまって後から考える方がいいことが多いです。 できないという言葉は不思議なもので、口に出すと本当にできなくなってしまいます。 SHIROBAKO22話 『ノアは下着です。』の中で、ベテランアニメーターの杉江さんが以下のような言葉を新人アニメーターに伝えています。 僕は才能っていうのは何よりまずチャンスを掴む握力と失敗から学べる冷静さだと思う。絵の上手い下手はその次だ。僕は僕より上手い人間がわずかな自意識過剰やつまらない遠慮のせいでチャンスを取りこぼしてきたのを何度も見た・・・

Web上で請求書の作成・処理が行える無料サービス「Misoca（ミソカ）」。2011年の11月にサービスを公開してから3年半で、ユーザー数は既に4万人を上回っている。 サービスを運営しているのはスタンドファーム株式会社。現在、6人のコアメンバーと4人の外部サポートメンバーからなる同社の代表・豊吉隆一郎氏曰く、「創業当初からリモートワークを推奨し、現在もチームメンバーに出勤義務は与えていない」と話す。社員10人中9人がエンジニアという組織をリモートでどのようにマネージしているのか、プログラマ集団をどのように1つのチームとして成り立たせているのか、お話を伺った。 豊吉隆一郎氏。スタンドファーム株式会社代表取締役。1981年岐阜県生まれ。岐阜工業高等専門学校 電気工学科を2004年に卒業後、TOYOSYSTEMとして個人事業でWeb受託開発業を開業。2011年、スタンドファーム株式会社を創立し、

Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。

日の出とともに起きるエンジニア この春で意図的に自分のライフスタイルをそれまでの「渋谷で月曜から飲んじゃうぜ！」パターンから完全に変えてから2年半が経ちます。現在自分は朝8時半に出勤、午後3時半〜4時くらいに退勤、あとは午後7時〜8時頃にまたオンラインになり家から必要な事を行う…という基本スケジュールをとっています。ステレオタイプなエンジニア象では夜中遅く暗い部屋でハックしているイメージがありますが、現在の自分は日の出とともに起き午後11時すぎには寝てしまう生活をしているエンジニアなのです。 幸いな事にプログラマー・エンジニアという仕事は周りの理解さえあれば伝統的なサラリーマンのステレオタイプから見たら明らかに異常なスケジュールでも特に生産性を落とさずに仕事を続けることができると仕事ですので、これを最大限利用させてもらっています。 自分は子育てのために意図的にこのような形を取っており、転職

CodeIQ感謝祭のパネルの前段の10分程度のプレゼン資料です

インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間

最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意

2015-03-19 エンジニアスタートアップは１人でいいから通訳を雇ってくれ 「エンジニアの言葉を通訳する人間が必要」 前の会社でよく言われていた言葉であり、「通訳」が必要なくらいエンジニアとビジネス側には隔たりがあるのだ。 私はマーケティングやファイナンスの人間だ。何をやっていくら儲けるかを考えるのが仕事。なので、無駄なコストをカットして、注力すべきところに投資したり上手にヘッジすることがミッションだ。 だが、その仕事の中でやっかいな存在にあたるがエンジニアだ。 彼らは何をしているのかよくわからない。外注のデザイナーやコーダーは何を作っているのかがよくわかるけど、正社員メンバーの、システム基盤？だのアルゴリズム？だのやっている人たちについてはまったくパフォーマンスがわからない。 部署横断のミーティングなんかやると温度差に驚く。 営業「営業の仕組みを変え、売上をキープしつつコストをダウン

※発言は個人の感想です。 わたしがCEOなのは本当です。いわゆる創業社長ってやつで、なし崩し的にCEOになってます。技術が分からないのも本当。また弊社は大企業でもなければIT企業でもないので、大企業だのIT企業だののCTOの場合はまた話が違うのかもしれません。まぁそんなの、究極的には各社それぞれケースバイケースですよね。 ただイマドキ、どこの会社も業務システムを使っているし外部向けのWEBサイトくらいあるでしょう？オンラインマーケティングだって少なからずやっているはずです。だからITと無関係な企業ってのもないんじゃないかなぁ。 そんなわたしがCTOに求める役割は 「経営課題のうち技術によって解決できるものを見つけ出し、解決してほしい」 です。 あ、念のために言っておくと、こういう文脈で「～してほしい」というのはモヤッとした個人的要望ではなくて、社として負ってほしい職責を指します。だから職務

最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。 技術的負債とは… 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。 wikipedia – 技術的負債 この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。 「負債」という言葉はなかなか面白い比喩である。 では少し、負債という言葉について調べてみると、こういうのが見つかる。 負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。 すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。 http://financial.mook.to/accounti

nobkz.hatenadiary.jp 昨日だが、このエントリーがバズっていて僕自身もtwitterでいくつか言及した。twitterってその場の思いを素早く伝えるのは非常に便利なんだけど、コンテキストが重要なものが説明しづらいとか、フロー的な情報という問題もあるため改めてブログに書いてみる。 率直な感想 まず、彼自身がCTOじゃなく１人のエンジニアとしてこの会社にジョインしていたのであればまぁわかるよという内容だ。エンジニアとしての美学を追求し続けたけど、それじゃビジネスが立ち行かなくなった。俺のことをわかってくれるVCが日本にはいない！ まぁここまではよくある話だと思う。誰もが失敗はするし、最初からうまくいく人なんてごく少数だと思う。問題は、この事自体を環境のせいにしているということだと思う。 技術的負債を早く返しすぎたのが失敗と書いてあるが彼がそう感じているのであればそうなんだ。た

＜前編のあらすじと後編のお話＞ 本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya：チーム名の