タグ

仕事に関するjsoizoのブックマーク (55)

  • 「と思います」禁止令 | ウェブ電通報

    プロモーション・デザイン局 梅田悟司氏による朝日新聞WEBRONZAでの連載『「と思います」禁止令』を、ウェブ電通報特別バージョンでお送りします。 断定できる人は、強い 「人の心に響く言葉とは何ですか?」 そんな質問に対して、私は答えの一つとして「明確に未来を打ち出す言葉」と答えることがあります。学校の教科書では断定として登場する表現方法です。 断定は言い切ればいいので簡単なように思えます。しかし、実生活において言い切ることは非常に勇気がいることです。 通常の会話で考えれば、文末に何となく「と思います」や「のような気がします」といった言葉を入れることで、あえて断定を避け、内容をうやむやにしたり、言葉を濁すことがあります。人は無意識のうちに断定を避け、そうではない可能性を残しておくような言い方をしているのです。 これは一種のリスク分散と言えます。 「いやいや、断言はしていません」「その可能性

    「と思います」禁止令 | ウェブ電通報
  • 機械学習を使いこなすUXアーキテクト�エンジニアの必要性 | F's Garage

    例えば、今時の海外ゲームではAIゲームバランスを調整していると聞く。 自動的なゲームバランスの調整にAI的なロジックが使われていて、ゲームとしての適切なグルーブ感を自動調整しながら、ユーザーの楽しさを継続させるという部分らしい。 文章に書くと昔からアルゴリズムで行われているこのようにも思えるが、きっと、もっと高度なことが行われていると、一旦仮定する。 いずれにせよ一番重要なのが「ゲームとして楽しいバランス」。これを決めるのは、ゲームクリエイターの味付けでありセンスであるというところ。 昔、天才ゲームクリエイターと呼ばれる人と一緒に仕事をしていたので聞かされた話があって、それは現在の業界的に正しいのかはわからないが、ゲームが完成する直前になってからがゲームクリエイターとしての勝負だということ。 決して単純なロジックやフローチャートでは語りきれない「天才だけがもっているセンス」をどうにかパ

    機械学習を使いこなすUXアーキテクト�エンジニアの必要性 | F's Garage
  • 【資料公開】Effective Retrospective (効果的なふりかえり)

    みなさんこんにちは。@ryuzeeです。 2017年3月18日におこなわれたProductivity Engineering − Forkwell Meetup #4の登壇資料『Effective Retrospective』の資料を公開します。 登壇の時間が20分ですので基的な内容になっていますが、これからふりかえりを始める方やなんとなくいまのやり方がうまくいかないと思う方には役にたつと思います。 もっと詳細が知りたい場合は、アジャイルレトロスペクティブズを一読することをお勧めします。2007年のですがまったく陳腐化していないので参考になると思います。 なにかご質問があればTwitterなどでお知らせください。それでは。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレー

    【資料公開】Effective Retrospective (効果的なふりかえり)
  • growiz.us

    This domain may be for sale!

    growiz.us
  • エンジニアと健全なバトルをしてますか? Increments 及川卓也が語る優秀なPMの条件 | キャリアハック(CAREER HACK)

    及川さんがこれほどまでPMの重要性を語るのはなぜか。そして優秀なPMに求められる条件とは? [プロフィール] 及川卓也 (Takuya Oikawa) Increments株式会社 Product Manager 早稲田大学理工学部卒業後、外資系コンピューター企業での研究開発、マイクロソフトでの日語版・韓国語版Windowsの開発統括を経て、グーグルでプロダクトマネージャとエンジニアリングマネージャを務める。2015年11月より、プログラマのための技術情報共有サービス「Qiita」やドキュメントを軸としたコラボレーションサービス「Qiita:Team」を提供するIncrements株式会社にてプロダクトマネージャとして従事。エンジニアのキャリアプランニングやエンジニアリングマネージメントなどの領域で自社のQiitaやQiita:Teamの活用を軸としてスタートアップにアドバイスも行う。

    エンジニアと健全なバトルをしてますか? Increments 及川卓也が語る優秀なPMの条件 | キャリアハック(CAREER HACK)
  • 会社員の年収と「嫁ブロック」について|えとみほ

    採用面談をしていて思ったことなどを少し。 弊社のような極めて小さな会社の場合、言わずもがな一番苦労するのは人の採用である。最近の私の主な仕事はもっぱら採用絡みだ。ありがたいことに応募はたくさんあるのだけど、なかなかホイホイと人は採れない。 決して「いい人がいない」というわけではなく、いい人がいてもタイミングが合わなかったり、条件が折り合わなかったりで、こちらからお見送りすることもあれば、先方からお断りされることもある。 お見送り&お断りで一番多いのは、年収レンジが合わないケースだ。そして噂には聞いていたが「嫁ブロック」も存在する。最初は嫁を盾にとった年収交渉なのかなと思っていたのだが、当に嫁が条件を一歩も譲らなくて泣きそうになっている人もいるのだ。 会社員の年収はスキル・経験だけでは決まらない私自身も嫁の立場なので、夫に少しでもたくさん稼いできてもらいたいという気持ちは理解できる。まして

    会社員の年収と「嫁ブロック」について|えとみほ
  • ボトムアップ組織のマネジメントとは何なのか

    いま所属している会社は、ボトムアップな会社ということになっている。正確にはボトムアップとトップダウンが混在していてたまにミスリーディングなのだが、だいたいはボトムアップな会社といえるだろう。 それで、たまに、学生と会ってくれといわれて、うちの会社がボトムアップの会社なんですよ〜、と話すことがある。だがこのボトムアップというやつ、採用活動では『いかに若いうちから活躍できるか』をぐいぐいアピールするための文句ではあるのだが、実際、現場でどういうコミュニケーションになっているのか、あまり説明されない。どういう会社が「良い」ボトムアップの会社なのか、わりとみんな意識していない。 とりあえず適当に若いのに丸投げてみたら、いつの間にかイケてる提案を持ってきた、なんてことは、ありえない。それを実現するためには、上司側の見えない努力がたくさん必要なのだ。 こんなマニアックな話をしている人は多くないと思うの

  • 衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~ - メソッド屋のブログ

    今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って物を見てみたかったのだ。 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日で行っ

    衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~ - メソッド屋のブログ
  • マネジメントを経験してようやくわかってきた、半年で部下を1人前にするコツ - トイアンナのぐだぐだ

    試行錯誤しながら手に入れた部下や後輩を半年で1人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない? と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう1年いるんだからシニアだね!後輩指導よろしく」と宣告され、必死で3人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか

    マネジメントを経験してようやくわかってきた、半年で部下を1人前にするコツ - トイアンナのぐだぐだ
  • いい仕事をしよう // Speaker Deck

    UICrunch #9 に登壇させていただいたときの資料です。デザイナーに求められるデザインスキルとは、というテーマに対して、「仕事」という切り口でお話させていただきました。やっぱり人間は「いい仕事」をしたい生き物です。いい仕事ができれば、ビジネスを最大化できると信じています。それを紐解くスライドです。 弊社ブログでも事例を丁寧にまとめておりますので、ご覧ください。 http://memo.goodpatch.co/2016/07/ticketcamp/

    いい仕事をしよう // Speaker Deck
  • 主婦が技術書を書いてSIerに入社した話/jtf2016 - Docs.com

    Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find

    主婦が技術書を書いてSIerに入社した話/jtf2016 - Docs.com
  • 強い組織の「隠れキーマン」について - LiB-log

    経営者の中にはプロダクト思考の人や、ファイナンス思考の人など 色んなタイプがいるが、僕は圧倒的に「組織思考」の経営者だ。 美しいとさえ表現できるほどの組織/カルチャーを創る事が 何よりクリエイティブだと思っている。 そんな組織オタクの僕が、 今までリクルート、トレンダーズ、LiBと 自分でも3つの会社を渡り歩き、 一方で、自社内のみならず 営業としてクライアント組織を見たり 経営者としても勉強がてら沢山の組織をみてきた中で 強い組織には共通して「ある存在」が居る事に気がついた。 そんな話。 ーーーーーーーーー 乱暴に分けると、組織には 「①決めるコトに責任を持つ人」と 「②実行に責任を持つ人」がいる。 (小規模組織の場合、それを兼務しているケースが多い) ①の「決めるコトに責任を持つ人」というのは いわゆる役員や、事業責任者、マネージャーといった人たちだ。 具体的には ・会社や事業の方向性

    強い組織の「隠れキーマン」について - LiB-log
  • 1on1ミーティングのやり方 - @ledsun blog

    1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。 前提条件 弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。 インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。 面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。 やり方 人数 インタビュワーは6人います。ベテランエンジニア5人と営業1人です。 インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。 組み合わせ もっとも長い期間面談をしていない組み合わせで実施します。 組み合わせは、モンテカルロ法で抽出します。 そ

    1on1ミーティングのやり方 - @ledsun blog
  • 業務委託で開発をお手伝いいただく時に思うこと | F's Garage

    開発内製をしている組織が、業務委託で外部の方の力を借りて開発をお願いするというケースにおいて、発注者側が業務委託で仕事をお願いする時に思ってることを書いてみようと思う。 エンジニアで独立心が高い人であれば、技術顧問だけじゃなくても、部分的な工数を切り売りして複数のプロジェクトに関わりあいたい気持ちもあったりと思うので、そういう人に向けても一助になれば幸いです。 前提条件 ここ背景的な追記事項なんですが、基的な対象者は、「社員になってもらえたら超ラッキーみたいな人が、すでにフリーランスだったり、自分の会社を持っていて、別の仕事もやっている」という先方都合が上位なケースにおいて、業務委託でのみ契約に至る時に考えたりしたこと、という前提条件を追加しておきます。 ちょっと一般化して書いてみたら、もっと世界が広かったようで、そちらの世界の方で誤解を生んでいるケースもあるように思えました。それは純粋

    業務委託で開発をお手伝いいただく時に思うこと | F's Garage
  • レッドハット、「オープンな意思決定の仕組み」をGitHubで公開

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Red Hatは、同社がオープンプロジェクトの運営や、意思決定、コラボレーション、コミュニケーションなどを行う際に用いているベストプラクティスを一般公開した。 別の言い方をすれば、Red Hatは意思決定のコード(規範)をGitHubで公開したということになる。 同社の「Open Decision Framework(オープンな意思決定の仕組み)」は、企業やIT業界のリーダーが目を通すべき文書になりそうだ。このフレームワークは「意思決定者が透明性の高いコミュニケーションを取り、多様な意見を取り入れ、分散しているチーム間でより効果的にコラボレーションを進め、ビジネスプロジェクトや判断への想定外の影響を抑えるのを助ける」ものだという。 Re

    レッドハット、「オープンな意思決定の仕組み」をGitHubで公開
  • 目的思考がエンジニアと事業系お互い遠慮しなくていいチームを作る - Fringe81インタビュー [後編] - Qiita Blog

    fringe81さんでのQiita:Teamの利用状況について伺った前編。 職種やチームの境界を超えたコミュニケーションの場として機能しているのが特徴的でした。 後編では、そんなコミュニケーションが生まれる「fringe81チームの文化」がどう作られているかを聞きました。 Fringe81 が職種やチームの境界を超えてコミュニケーションできているのはなぜか?目的にフォーカスする思考―Qiita:Teamのご利用状況を伺うと、事業系と開発系など職種やチームの境界を超えてコミュニケーションが起きていますよね。Fringe81さんのように100人近い組織になると、その点をチームの課題としてあげることも多いのですが、 Fringe81チームが境界を超えていけているのは、なぜだと思いますか。 佐藤さん: まず基的なマインドとして「エンジニアをリスペクトする」ということがあります。営業主体の会社だと

    目的思考がエンジニアと事業系お互い遠慮しなくていいチームを作る - Fringe81インタビュー [後編] - Qiita Blog
    jsoizo
    jsoizo 2016/05/19
    発見大賞おすすめ。皆の発見を読んでいると幸せな気持ちになるし、発見されたら超嬉しい。
  • 辞める時に会社のほんとうの姿が見えるよね、という話

    私自身、独立するまで3回転職しているので、何度かは「会社辞めます」と上司や社長に伝えていることになるのですが、その際に思ったのは、辞める時に伝えた時の反応やコミュニケーションで会社の当の姿が見えるなーと思いました。 いままではぼんやりとそう思っていたのですが、先日友人との話の中で「会社が当に社員をどう思っているか」「辞めた社員がその会社のことを何と言うか」は辞める時の対応によってだいぶ変わるなーと感じる場面がありました。 辞めるときの対応として印象的だったのはその友人が話していたことを簡単に書くと、前職はIT系スタートアップを辞めることを代表の方に伝えたところ、「なるほど…。そういうことか、わかったよ。給与2倍にするから」と言われたそうです。 まじか…という感じですが、結構こういう社長というか会社あるんですかね!? どうやらこの会社は退職者が続いていて、当の理由はこの代表の価値観につ

    辞める時に会社のほんとうの姿が見えるよね、という話
  • 第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp

    「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニア仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「⁠常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス

    第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
  • グーグルが突きとめた!社員の「生産性」を高める唯一の方法はこうだ(小林 雅一) @gendai_biz

    社員の生産性を極限まで高めるには、どうすればいいのか――米グーグルが2012年に開始した労働改革プロジェクトの全貌が明らかになった。 社員同士のコミュニケーションを中心に、その仕事ぶりを徹底的に観察するワーク・モニタリングは、果たして功を奏したのだろうか? ●"What Google Learned From Its Quest to Build the Perfect Team" The New York Times, FEB. 25, 2016 プロジェクト・アリストテレスとは 上の記事によれば、米グーグル(持ち株会社に移行後の正式社名は「アルファベット」)は2012年に生産性向上計画に着手した。 この計画は「プロジェクト・アリストテレス(Project Aristotle)」と呼ばれ、同社の「人員分析部(People Analytics Operation)」によって実施された。 グ

    グーグルが突きとめた!社員の「生産性」を高める唯一の方法はこうだ(小林 雅一) @gendai_biz
  • 日経BP

    株式会社 日経BP 〒105-8308 東京都港区虎ノ門4丁目3番12号 →GoogleMapでみる <最寄り駅> 東京メトロ日比谷線「神谷町駅」4b出口より徒歩5分 東京メトロ南北線 「六木一丁目駅」泉ガーデン出口より徒歩7分

    日経BP