WEINの前谷優太と申します。 今回下記の記事が出た影響で、多くの方から僕に、連絡や問い合わせが来ております。 最初から最後まで渦中の1人として巻き込まれた僕としては、この件を言及するかどうかについて最後の最後まで悩みました。 それこそ元上場企業の社長や本田圭佑さんや高岡浩三さん含めて、海千山千の人たちに対して、たとえ本当のことであったとしても22歳の自分が何か言及をすることは、本当に恐怖でしかありません。 ですが事実無根のことや、切り取られて印象操作された記事で、WEINが掲げたビジョンを達成できなくなってしまうのは、どうしても嫌だったのでこのnoteを投稿いたします。 (こういった文章は表に出すのは今回が初めてですが、可能な限り客観的な事実を記載していき、解釈を入れないように注意してまいります……。) はじめに今回、DIAMOND SIGNALで取り上げられているWEIN Group(
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
こんにちは、らくからちゃです。 システム業界に身を置いておりますと、色んなお客様とお仕事をさせて貰う機会があります。システム構築はお客様との二人三脚。お客様の作業効率が弊社の作業効率に直結することも多いものの、横から『こうしたほうがええんとちゃうの？』とも言い出せず、悶々としてしまうときがあります。 そこで直接は言いづらい『ここらへん考えてみてほしいなー』という点について、だらだら適当に書いてみます。ありきたりのことしか書きませんが、どこかのプロジェクトの燃焼速度が多少なりとも遅くなれば幸いです。 例題 例えば、上司からこんな風に指示されたものとします マーケの部長が、修理案内の通知を封筒に詰めて送る作業をやってくれるひと探してるんだけど、お願いしてもいい？ 宛先と対象商品と諸々が書かれたA4用紙が1000人分くらい来るからさ、宛先が東日本なら茶色、西日本なら白色の窓付き封筒に入れて糊付け
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
こちら読ませてもらった。 blog.asimino.com おそらくこれを書いたあしみのさんは「失敗を恐れずに己の責任感を育てるためにもあえて『できます』と断言して自分を追い込め」みたいな意味で言っているのだろうと理解した。 予断を持つようなことばかりしているとやがて自分に甘い人間になってしまう。だからできるかできないかに関わらず「できる」と断言できるような社員に育って欲しいというイメージなんだろうと思う。 私も十数年前の若い頃に、あしみのさんのような上司のもとで働いていたことがある。 「これとこれ。○○日までにできるか？」 だいたいこうやって聞かれる。 この時の職場はとにかく不確定要素が多くて、とてもじゃないが数日単位にまたがるような業務だと仕上がり日の約束なんてできなかった。なので「全力でがんばります！」といつも答えていた。 それは冒頭の記事の上司のように「できると思います」と答えたら
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
第二次世界大戦時のCIAの秘密資料。題してSimple Sabotage Field Manual。要は、敵国内のスパイが、組織の生産性を落とすためにどのような「サボり」ができるか、という「サボり方ガイド」である。2008年に公開された。（なお、正確に言うと、CIAの前身組織、Office of Strategic Servicesの作成文書である。） 以下、一部を抜粋した意訳です。本文は意訳の後に。 「注意深さ」を促す。スピーディーに物事を進めると先々問題が発生するので賢明な判断をすべき、と「道理をわきまえた人」の振りをする 可能な限り案件は委員会で検討。委員会はなるべく大きくすることとする。最低でも5人以上 何事も指揮命令系統を厳格に守る。意思決定を早めるための「抜け道」を決して許さない 会社内での組織的位置付けにこだわる。これからしようとすることが、本当にその組織の権限内なのか、より
こんにちは。 ここしばらく、システムトラブルの対応で午前帰りが続き、疲れてきてしまいました・・・。直接、トラブルの原因になった訳では有りませんが、エンジニアさんも巻き込んでしまい、もう少し上手く回す方法はなかったのかと、自分の未熟さを反省中です。 さて残業といえば、先生は大変そうですね。ただでさえ、ひとりで何十人もの生徒をみないといけない上、ほぼ無償ボランティアの部活顧問まで行い、その上で親に押しかけられたら溜まったもんじゃ有りませんよね。横浜市で、先制の『ノー残業デー』を設定するそうですが、多少なりとも状況が改善することを期待してやみません。 ただ、個人的にはこの『ノー残業デー』という制度がしっくり来ません。だって、『ノー残業デー』って、その日以外は残業することが前提なワケですよね？更に、こんなニュースも有ります。 正社員と同じ等級制度や人事制度を用いるため、基本給も同じ水準だ。賞与は正
採用がほんとうに難しいです、という嘆きを経営者や人事の方から聞く。 「いい人を採るために何をしていますか？」 と伺うと「広告を増やしました」「イベントに参加しました」「SNSを活用しました」などと回答がある。単なるアピール不足で人が採れていないケースでは、これらの手段は有効である。 だが、ある経営者の話を聞き、私は大事なことを忘れていたと認識した。 私は、その経営者に世間話をしようと採用の話を何気なくもちかけた。 「いま、多くの会社で人が採れない、という悩みを抱えていますよね」 「そうなんですか？うちは人が採用できない、という悩みを持ったことはないですよ。」 「…本当ですか？」 「本当です。」 「…秘訣を教えて欲しいのですが…」 「真理は一つです。いい人が採れないのは、ダメな会社だからです。逆に言えば、良い会社であれば良い人が採れます。それだけの話です。」 「…もう少し具体的に教えていただ
エンジニアからみた良いプロダクトマネージャ（以下PM）とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト（製品）マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか？と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
同じTシャツを着ているのは決断の回数を減らすため Facebook社員・チャールズ氏（以下、チャールズ）：それでは会場のみなさんが質問を考えている間に、ひとつ質問を読み上げましょう。イタリアのソレントから、アントニオさんの質問です。 「どうしてあなたは毎日同じTシャツを着ているのですか？ ひょっとして1枚しか持っていないのですか？」 （会場笑） マーク・ザッカーバーグ氏（以下、マーク）：実は同じものを何枚も持っています（笑）。この話はシェリルにしてもらいましょうか。 シェリル・サンドバーグ氏（以下、シェリル）：7年間マークと一緒に働いていますが、私は聞かれるたびに「マークはあのTシャツをたくさん持っているのよ」と何度も答えました（笑）。 マーク：ありがとう、シェリル（笑）。これは単純なようでいて、奥が深い質問です。コミュニティにおいて、どのように責務を果たすべきだと考えているか、ということ
私は今の会社に中途で就職したのですが、入社して一年後に部長になりました。38歳でした。中小企業でしたがそこそこ社員数もいましたし、老舗の会社ですので当時私より「年上の部下」は必然的にかなりの人数存在していました。 私は部長になった日から今日まで様々なやっかみや嫌がらせをぶつけてくる中々手強い「年上の部下」に対峙してきました。最近はその人数も減りほとんどいなくなりましたし、私も少しは認めてもらえてきたので、今思えばいい思い出ですが当時は相当泣かされたというか苦しめられました。 その時現実にいた「年上の部下」のタイプと、その人たちに当時「改めて欲しいこと」を指摘した時などによく返ってきていた面倒臭いセリフをいくつか紹介します。その後で私がその人たちに少しでもモチベーションを上げて業務にあたってもらうためにどう接したか、私を認めてもらうためにどう接したかも紹介します。 最近人事異動があってまさに
少し前、生産管理に関して人前でお話しさせていただいたときのことだ。“納期遅れを防ぐために、もっと積極的に在庫を活用しよう”という趣旨の説明をしたあとで、ふと心配になって、セミナーの受講者の方にこう質問した。——皆さん、在庫は悪だと思いますか？ すると、40名近い受講者がほぼ全員、「悪だと思う」という答えの方に手を上げた。わたしはちょっと驚いて、前に座っていた方にたずねた。 ——どうして、悪だと思うのですか？ 「だって、置いておけば、コストがかかるでしょう。場所代とか。在庫がなければかかりません。」というのがその人の答えだった。 ——たしかに、どこか倉庫を借りておいておけば、保管費用がかかりますよね。でも、失礼ですが、御社の工場は借地ですか？ もし自社の敷地だとしたら、工場の隅っこに置いておいておけば、1円もコストはかかりませんよ？ 「それは、そうかもしれませんけれど・・金利がかかります。」
Kaizenの経営をはじめて、20ヶ月が経ちました。 正直、笑っちゃうくらい大変なことだらけ。 ただ、多くの事を学んだのでサンフランシスコに向かう機上で少しまとめてみました。 何かの参考になれば幸いです。 1:スタートアップの経営者は、想像以上に会社をコントロールできない 経営者は会社をコントロール出来ると一般的には思ってる人が多いと思います。 人数小さいチームであれば、尚更コントロール出来ると思いますよね？ 僕もそう思ってました。 スタートアップの現実は、そんな事全くない。 全くです。 小さな船が荒波に揉まれながら、予想外の事が毎日、なんなら1日数回にわたり起きるんです。 常に問題と格闘してます。 なので、その船に一緒に乗ってる仲間も、自ずと問題と格闘してくことになります。 多分、どうしてこんなに問題が起きるんだ！ 経営者は何やってるんだ！ バカヤロー！！ って従業員は毎日思ってると思う
転職・求人情報サイトのtype エンジニアtype スキル SEが知っておくべき、新規プロジェクト「失敗の本質」～成功率8割以上のPMOが語る、炎上させない方法論とは （写真左から）マネジメントソリューションズCOOの田口正剛氏と、マネージャーの佐藤直樹氏 企業景気の復活やサービス競争の激化により、国内・海外ともにシステムの新規導入・刷新プロジェクトの需要が高まっている。そこで、SIer・ユーザー側それぞれが人的リソースの確保と並んで取り組んでいるのが、プロジェクトの成功率アップだ。 2014年の『日経コンピュータ』によると、昨今のシステム関連プロジェクト成功率は約7割とのこと。プロジェクトの平均成功率は短期のものほど高く、「3カ月未満」が81％、以下、「3～6カ月未満」が78％、「6カ月～1年未満」が74％、「1年以上」が67％だった（※データの出典元は同誌2014年10月16日号）。
会社はヒト・モノ・カネで動いている。カネ・ヒト・モノでもなくモノ・ヒト・カネでもなくヒト・モノ・カネの順番で必ず表現される。ただ単にこれは偶然の並びで慣れてしまっただけではなく、間違いなく組織においてもっとも重要な経営資源はヒトなのだと考えている。 その中でも会社が成長するうえで最も重要なヒト（ポジション）と言えるのがマネージャー（中間管理職）であることには異論はないと思う。マネージャーにはほぼすべての会社において共通したミッションがある。それは「目標を達成すること」と「会社を成長させること」である。この２つのミッションを遂行できないマネージャーしかいない会社はもしかしたら近い将来潰れてしまうかもしれない。 そこでこの２つのミッションを遂行できない、会社を潰すタイプのマネージャーの意識と行動について考えてみたいと思う。チョイスしたものは偉そうに書いている私自身も耳の痛いものばかりである。こ
指揮者というのは、自分の才能だけあっても上手くいきません。奏者の実力を十分に引き出せた指揮者だけが、最高の音楽をつくり出すことができます。それは、ビジネスにおけるリーダーにも同じことが言えるのではないでしょうか。 ここでは、イスラエル出身の世界的な指揮者イタイ・タルガム氏がTED Talksで行ったスピーチをご紹介していきます。 タイプの異なる指揮者5人の例をユーモラスに取り上げ、「リーダーシップの在り方」について語ってくれます。人を率いる立場であるすべての人に、素晴らしい教訓を教えてくれています。 彼のスピーチを簡単にまとめると、 1．人がついて来ない「命令型」 リーダー自身に才能があっても、一人一人を駒のように扱っていては誰もついてこなくなる。 2．やる気が感じられない「放置型」 全く干渉せず、自分からは何も発信しないのでは、ビジョンも共有されず素晴らしい結果は生み出せない。 3．不安
それなりに人数の多い会社の中では、誰に話を通すだの何だのといったことがある。この前、入社3年目の若い同僚に 「それは話の持っていき先が違うよ」 「でも○○さんからそうしろって聞いて」 「それは○○さんがわかってないよ」 「そんなこと言われたってわかんないですよ」 と不愉快そうに言われて、それはそうだと思った。 どこにどう筋が通っているかというのは、背後に理屈がある。その理屈を見せずに結論だけ言っても混乱させるだけだ。それでもう少しきちんと説明したい。 その前に自分で整理しておこうと思った。 建前と実態 まず最初に考え方の枠組みについて。考える方向には建前と実態がある、とみなす。 建前 ： 条件から出発して、順番に考えたら「こうなる」という理屈 実態 ： 現実にこう運用されている、という観察結果 建前＝演繹的=セオレティカル、実態＝帰納的＝プラクティカルという感じで、逆方向のアプローチだ。こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
