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

http://dennou-kurage.hatenablog.com/entry/2013/07/12/200730 たぶん、俺なんかよりずっと頭が良いであろう脱社畜の人も、なんか妙だ妙だと言いつつも違和感しか言えてないのって、正しいけど踏み込めてない気がする。 報連相ってさ、ビジネスマナーなんだよな マナー。 でさ、マナーで仕事って回さないだろ。 契約や職分で仕事ってのは回るだろ。 マナーってのは、もちろん出来た方が良い事だろうよ。 Yシャツは洗濯したヤツをきるとか、爪は伸ばさないとか、髭は剃ってくるとか。 でもよ、一人の人間が髭を剃ってこなかったら会社が損害を受けるなら、髭剃りチェックをルーティンに組み込むのが会社であり、仕事だろ。 そう言う意味で、相手のマナーに頼って仕事をするのは、相当に脆弱なんだよ。 どうやって意見を吸い上げたらいいかなｰ、どうやったら円滑にまわるかなーってので

マッキンゼー・アンド・カンパニーにて、食品、通信、医薬、金融、インフラなどの各企業への戦略・組織コンサルティングに従事。その後グロービスに参画し、現在はグロービス経営大学院研究科長として企画運営を統括。教員としては、思考領域・ヒト領域の科目を担当する。 キャリアデザイン学会・日本労務学会会員。 株式会社ラポールヘア・グループ社外取締役。 共著書に『ビジネススクールで教えている武器としてのAI×TECHスキル』東洋経済新報社、共訳書に『一流ビジネススクールで教えるデジタル・シフト戦略』ダイヤモンド社。 GLOBIS知見録 GLOBIS GROUP 女性活躍推進を阻む企業の誤解 日本企業において今ほど女性リーダー、マネジャーの活躍推進が望まれている時代は無い。しかし、現実に多くの企業で女性リーダーの台頭が広く進みそうな気配は依然としてうかがえない。女性リーダーが生まれない日本企業の現状を変える

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

概要 esa.io 導入の過程について 経緯 世の中のシステム改善の情報はよく見かけるが、 自分も改善しようとした時に、どのようにしたらいいか分からない 。 実際の改善をするまでの 細かな過程などを参考にしたい 、という相談を受けました。 同じような情報が欲しい、という方が他にも居るかもしれないので 私の業務の改善実績を公開することにします。 需要がありそうなら、シリーズ物として地道にアウトプットして行こうかと思います。 ポイントとして、私自身は優秀なハッカーや優れたマネージャーなどではなく、 ありふれた開発者の一人 に過ぎません。 私の性格については、引っ込み思案で内向的。 どちらかという消極的で、お世辞にもコミュニケーションが上手なほうではありません。 勉強会に行って、 懇親会でほとんど発言せずにしょんぼり して帰ったり、 RubyKaigi のオープンスペースの昼食が怖くて、 豪華な

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

ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ

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

概要 お願いした作業の進捗を聞くときには「進捗どうですか？」より「困ってますか？」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか？」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか？」はtwitter上で使うと「最近どうよ、忙しいの？」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか？」は質問攻めになりやすいと思うからです。「進捗どうですか？」の先に待っているやりとりはだいたいこんな感じです。 「進捗どうですか？」 「進捗ダメです。」 「どこがダメなの？」 「単体テストが遅れています」 「どれくらい遅れてるの？」 「えーと・・・、0.5日分くらいです」 「項目数でい

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分程度のプレゼン資料です

安藤日記 安藤日記：デジタルガジェット好き「安藤幸央」の日々のメモ ( yukio.andoh@gmail.com ) [ http://twitter.com/yukio_andoh ] Design Sprint Newsletter https://designsprint.substack.com/ Googleベンチャーズが教える、デザインへのダメ出し指南 （原文：GV Guide to Design Critique / Braden Kowitz http://www.gv.com/lib/critique ) 批評は素晴らしいデザインに到達するための最も重要な要素のひとつです。しかし、あまりにも指摘が多過ぎると、デザイナーたちは、散り散りになったような、挫折してしてしまったような、無力になってしまったような感覚を持ってしまい、批評そのものを置き去りにしてしまうのです。たとえ

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

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

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