こんにちは。ユーザーファースト推進室 ディレクターの林田です。 ユーザーファースト推進室では「企画やディレクション、実装・デザインなど、一気通貫して役割を担えることで、より良いサービス開発が可能になる」という考えの下、ディレクターでも企画・進行管理だけでなく、コードを書いたり、場合によってはデザインを行うことがあります。 今回は、一気通貫してプロジェクトを進めるスキルの習得を目的として、あるアイコンの部分公開をディレクションから実装まで一通り行いました。 その中で私が感じた「ディレクターがエンジニアと仕事を進める上で気をつけたいポイント（主に技術面）」についてご紹介したいと思います。 ※ 尚、ここでは経験から得た学びの共有にフォーカスしたいと考えていますので、ABテストの手法や結果等については敢えて触れません。ご了承ください。 実装始める前後で考えたこと 実装開始前 これまでクックパッド上

1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ

本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった

JJUG CCC 2015 Fall 2015-11-28T15:00-15:50 の発表資料です。 話せなかった分は切りましたが、言いたいことは言い切っています。

数カ月前のことですが、次のような依頼をいただいたことがありました。「新野さんのモデレータとしてパネリストから発言を引き出す能力を生かして、SEや営業がお客様の要望をうまくヒアリングできる技術が身につくような講座をお願いできないだろうか」と。 SEの仕事としてお客様の要望を聞き出す、いわゆる要求開発の重要さが増してきている一方で、SEやエンジニアの研修は技術中心でヒアリングを上達させるようなものはなく、なんとかそういった研修ができそうな人を探しているとのことでした。 超大手SIerからヒアリング講座の依頼が 僕は仕事としてほとんど毎月のようにパネルディスカッションのモデレータをしています。今年に入っても、インフォテリアの「ASTERIA Cloud Conference 2015」、F5の「F5 Agility Tokyo 2015」でモデレータを行い、今週金曜日にはCloud Days T

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

ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。 1. ネーミングの大切さ 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソースコードを見る人に「僕は○○する変数だよー！

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

後編はこちら：Web業界・EC業界・ソシャゲ業界の違い（後編）「商品特性とコントロールできるレバー」 年明けで様々な記事を読んでいたところ、以下の記事を発見しました。 Web業界からEC業界に行ってブチ当たった、皆が教えてくれない「EC業界の見えない壁」の正体を、もやっと掴めました！ ECサイトの運営に携わっている方にはぜひ読んでいただきたい内容です。 記事を書かれている永上さんは、以前の会社が一緒だったこと、そして過去にブログで取り上げていただいたこと（参考：「えがちゃん」に取材をしていただきました！）などのご縁がありました。そんなこともあり、2013年から永上さんが運営している「メンズファッションプラス（株式会社ホットココア）」のコンサルティングを担当しております。 メンズファッション＋ 2013年の春からコンサルティングを開始したので、間もなく2年間になります。最初はアクセス解析に関

この記事は↓に移転しました。 laysakura.github.io

新卒エンジニア向けにコードレビューを「する」話をしました。 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721

2014-11-22 コミットメッセージのルール 開発でGit(Github)を利用している時、コミットメッセージは後からログを見返すときにとても大切なものだけど、 普段適当に記述しているのもあって、改めてルールを書くことにした。 コミットの粒度 コミットの粒度では、何かしら一つの作業を終えたら・・・という粒度でコミットすることにする。 具体的には ある範囲のUIを実装した時 何かしらのコードを削除した時 バグを潰した時 など、比較的作業単位で細かくコミットするようにする・ コミットメッセージの内容 1行目 / 内容の要約 例 modify serarch button for product menu 2行目 / 空行 空行にする理由としては、可読性や要約と内容を分離するためにある。 3行目 / 本文 実際に何をやったのかを書く。長すぎるのもダメなのでだいたい60字ぐらいでまとめるよ

いわゆる基盤系のエンジニアリング技術について、私の場合は、今の会社に入社して２年間で徹底的に叩き込まれました*1。C言語なんかは独習の範囲内であって、コンピュータに関する基礎的な知識が不足していると痛感しています。一方、Computer Scienceに関する基本的なトピックはシンプルなものが多いので、数学の素養と、大学で詰め込まれた技術があれば何とかなる感じがしています。 飽くまでも、ですが、OSとかRDBMSとか、全ては手段です。ビル建設でいえば生コンのようなもの。砂利とか。肝心なのは、自分が欲しいビルの理想をきちんと描き、実現までの手段・手順を整理する。理想としているビルができているかを確かめる。難しいのは、「そんなビルが技術的な観点から本当に建設できるのか？」を確かめながら進むこと。 あるいは、それらの技術を全て、日本語にしてきちんと表現すること、設計を周囲に伝えて合意をとること、

人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。 1. 根本的な帰属の誤り 根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照） これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを

SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング＆品質 Hironori Washizaki

世の中にはわたしのようなライトC++書き向けの資料が不足しているので, 普段使い*1用途で収集したものをまとめてみました. ドキュメントを読む C++プログラミングガイド モダン C++ プログラミング - 日本語公開記事 - サイボウズエンジニアのWIKI STLのドキュメント cplusplus.com - The C++ Resources Network C++ reference - cppreference.com clangを使う Clang - Wikipedia gccよりもclangの方がC++ 規格に準拠しているとうたわれています. また, コンパイルもちょっと速い. *2 標準ライブラリを使う ∧∧∧∧∧∧∧∧∧ ＜ STL!STL!STL!STL! ＞ ∨∨∨∨∨∨∨∨∨ ＿　　　　 ＿ `/っ)　　　 /っ) / /　∧_∧ / /　∧_∧ ＼＼(　　 )＼＼(

「マイクロサービス」という新しいアーキテクチャスタイルが話題になっています。ごく簡単に言えば、1つのシステムを複数の小さなサービスを組み合わせて実現することです。マーチン・ファウラー氏とJames Lewis氏が今年の5月に公開した記事「Microservices」で注目が集まりはじめました。 参考："Microservices"を読んだ | SOTA 参考：クックパッドとマイクロサービス - クックパッド開発者ブログ 参考：マイクロサービスとSOA - InfoQ このマイクロサービスを実現する上で、組織が備えていなければならない能力について、マーチン・ファウラー氏が先月、「MicroservicePrerequisites（マイクロサービスの前提条件）」という記事を公開しています。同氏のWebサイトの記事は翻訳が許可されているので、ここで翻訳を紹介したいと思います。 マイクロサービスの

「プロジェクト＆プログラム・アナリシス研究部会」の2014年第5回会合を、以下の要領にて開催いたします。 今回は、製品開発プロジェクトのスケジューリングについて、この分野の専門家である（株）iTiDコンサルティングの蟹江淳様にご講演をお願いすることにしました。 新製品開発では、納期短縮と変更管理を両立させることが、プロジェクト・マネジメント全体の急所になります。納期を短くするためには複数の作業を平行に進める必要がある。 しかしそうすると変更が生じた時のインパクトが大きくなる－－この矛盾を、どのように克服するか。自動車業界をはじめ、多くの企業に対し、製品開発の専門的コンサルティングの実績をお持ちの蟹江様から、その勘所を教えていただきますので、ぜひご期待ください。 ＜記＞ 日時： 2014年9月26日（金）　18：30～20：30 場所： 慶応大学　三田キャンパス・北館・会議室3（地下1階）