なぜUI/UXデザイナーの仕事は批判の的になるのか？その謎を解明すべく我々は（以下略）
この記事に関連する話題: プロダクト開発者に求められる、これからの「倫理」の話をしよう。 他人の仕事の難しさ・勘どころを正しく想像できる者に、私はなりたい。 もちろん専門外の話であればそれを100パーセント理解するのは難しいし、知った気になって軽々しく口を出すのも違う。でもその仕事に向き合う人の“気持ち“を知る努力はできるはずだ。その努力なくして「あのチームは仕事が遅い」「なんでこの程度のモノしか作れないのか」などと批判をするのは大変格好が悪い、と僕は思う。 社内外の様々な会話のハブとなるプロダクトマネージャーという仕事において、この点は特に重要だと思う。 ・・・という話は既に "Don't "Guess" How People in Other Roles Work" で書いた通りで、書籍 "Inspired: How to Create Tech Products Customers
自走するエンジニアが育つ組織の作り方
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお
専門家の予測をうのみにする人が知らない真実
テトロックは予測者のタイプごとにニックネームをつけた（哲学者のアザイア・バーリンの著作からアイデアを借りた）。 「1つの分野について詳しく知っている」視野の狭いハリネズミと、「たくさんの分野のことを少しずつ知っている」統合的なキツネだ。 そのニックネームは、心理学と機密情報収集の世界で有名になった。ハリネズミ型の専門家の視野は深いが狭い。中には、1つの問題だけにキャリアのすべてを費やしてきた人もいた。ハリネズミは、世界の動きについての理論を、自分の専門分野という1つのレンズだけを通して作り上げ、どんな出来事もその理論に合うように曲げてしまう。 「ハリネズミ型」の予測精度は得意分野でも悲惨 テトロックによると、ハリネズミは自らが専門とする1つの流派の中で「一心に働き、曖昧な問題に対して、型にはまった解決策を導き出す」。結果はどうでも構わない。成功しても失敗しても常に自分は正しく、自分の考えを
体験学習サイクル・経験学習モデル | Poso’ｓログ
チームビルディングやプロジェクトアドベンチャーなど体験学習と呼ばれる教育手法では、ディビット・コルブの体験学習サイクルの考え方がとても重視されています。 簡単に言えば、体験と対話のセットで学びになるという考え方です。 体験学習サイクルの考え方を知る 体験型のチームビルディング研修、リーダーシップ研修、組織づくりでは、体験からの学びを体験学習サイクル（経験学習モデル）に当てはめて説明がされます。体験学習（経験学習）のルーツは20世紀アメリカの哲学者・教育思想家のジョン・デューイに遡るとされ、デューイの学習理論を実務家に分かりやすくモデル化したのがディビット・コルブの体験学習サイクルです。 そもそも学習とは何か？ 旧来型の座学研修での学習とは、講師から受講生に対する知識の移転のプロセスです。具体的には「先生が授業で話をしたり黒板に板書したりして生徒に知識を伝え、生徒がノートに書き写し暗記して覚
人はなぜ休日にも仕事のメールをチェックしてしまうのか？
待ちに待った休日は仕事から離れてのんびり過ごそうと決意したものの、ついスマートフォンやPCで仕事のメールをチェックしてしまい、リラックスできないという経験がある人も多いはず。なぜ休みの日に仕事のメールを確認してしまうのか、どうすればメールを確認しないですむのかについて、シドニー大学ビジネススクールのダン・ケプラー准教授が解説しています。 Here's why you're checking work emails on holidays (and how to stop) https://theconversation.com/heres-why-youre-checking-work-emails-on-holidays-and-how-to-stop-148720 休日なのに仕事のメールが気になってしまったり、仕事の用件を思い出してメールを送ってしまったりと、どうしても仕事が頭から離れ
リモートワークでは自己主張スキルが大事な気がしてきた - $shibayu36->blog;
リモートワークをしていると特定のスキルを保有しているか否かで自分の成果や成長が大きく変わってくると感じてきている。その中の一つとして最近感じているのが自己主張スキル。 なぜそう感じるか。それは最近ローカルでの開発からリモートの開発になったことで、自分がメンタリング・ファシリテーション・スクラム開発などをしている時に、非言語情報である表情や相槌、目線などの情報を使って良い感じに対処することが非常に難しくなったからだ。リモート会議だとミュートを多用したり人によってはビデオを切っていたりするので*1、言語情報以外の情報が全く入ってこなくなり、「良い感じ対処」のための情報量が圧倒的に不足するようになってしまった。例えば メンターとして困りごと相談を受けている時間に沈黙が生まれると、理解していて沈黙しているのか、今考え中で沈黙しているのか、全く理解不能で沈黙しているか分からず、どう対処したら良いか分
技術者には試行錯誤は圧倒的に悪であると腹落ちした話｜牛尾 剛
私はシアトルのクラウドの中の人として、ソフトウェアの開発を行っているが、先日ある問題がきっかけで、技術者には試行錯誤がとても良くないということが腹落ちしたので、忘れないように書いておきたい。 先日起こった事先日起こった事は、私がシアトルから一時帰国して、普段使わないラップトップを使って日本から仕事をしている。 Application Insights というログを管理するプラットフォームがあるのだが、とても不思議なことに、Application Insights のログファイルを見ると完全に正常に動いているようにしか見えないのだが、クラウドのポータルに行くと、テレメトリが来ていない。 Application Insights のチームのメンバーが助けてくれることになったので、彼女に、Teamsで画面共有をして、「ほら、出ないでしょ？」と見せると、なんとテレメトリがポータルに来ている。その後
マルチタスクからシングルタスクへ 生産性倍増のからくり
あなたは複数の案件を抱えているだろうか。それともひとつのプロジェクト専任だろうか。 今も昔もマルチタスクがもてはやされている。 同時に複数のプロジェクトをこなす。 うまくバランスをとりながら、最終的に結果を出す。 イメージはヒーローそのものだ。 だが、マルチタスクは極めて効率の悪い働き方だ。 ジェラルドワインバーグ氏をご存じだろうか。 マルチタスクによる弊害を実際に調査してまとめている。 複数の作業を同時並行で進めると、作業間を行き来するロスが発生する。 一瞬思考が停止してしまうのだ。 今の作業を中断し、次の作業に移るまで、コンテキスト交換のロスが発生する。 前の作業の終了地点を思い出すためにかかる時間のロス。 他のタスク（プロジェクト）と間違えて作業してしまい、やり直すロス。 専任タスクに比べて多くの損失が発生する。 下のワインバーグ氏のチャートを見ていただきたい。 5つのプロジェクトを
どもども "VP of Engineering" です。｜hidek
どもども。 昔はブログで文章を書く機会があったのですが、閉じてしまってから仕事以外で文章を書く機会がめっきり減ってしまい、文章構成力の著しい低下を感じたので note でも始めてみようかなぁ、と思って書き始めます。 と言いつつ、ぶっちゃけ会社の広報から 「リモートワークでコミュニケーションが疎になる中で、hidek さんはもっと社外発信しないんですか？どうなんですか？やるんですか？やらないんですか？」 という圧をかけられたのがきっかけなのですが… まぁ冒頭の課題も感じていたので、ゆるゆると徒然なるままに書いていきたいと思います。 お決まりなのですが、個人としての発信なので所属する会社や団体とは関係ないということで、よろしくです。 で、初回は僕が担っている VP of Engineering という役割について書いてみたいと思います。すでにあちこちで語られていることなのですが、初稿ということ
「PDCA」を回しまくっている人が時代遅れなワケ。世界は “まずはやる” 方式にシフトしている。 - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
「PDCA」という言葉。知らない人はいないと言えるほど、日本のビジネスにおいて広く浸透している言葉ですよね。 でも、このPDCAはもう時代遅れかもしれません。なぜならば、世界では今、それに代わる「デザイン思考」が主流になりつつあるからです。いつもPDCAを回しているつもりの人は、自分自身の仕事を知らず知らずのうちに “遅くしている” ことを、今すぐ自覚するべきです。 “変化し続ける世界” にPDCAはそぐわない 「Plan（計画）」→「Do（実行）」→「Check（評価）」→「Act（改善）」→「Plan（計画）」→……というサイクルを回してビジネスを進めていく「PDCA」が、なぜ時代遅れになりつつあるのか。それを理解するには、PDCAが考案された当時の時代背景を知る必要があります。 実は、PDCAという言葉は日本人が作ったのです。戦後、来日した統計学者デミングによる統計的品質統制 （SQ
仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話 - Qiita
はじめに プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。 10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。 レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。 そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。 つまり、各自の仕事の進め方の良し悪しを見える化が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結
自身を破壊し続けること――さくらインターネットの田中社長が語る「変化に強い開発組織」の条件
自身を破壊し続けること――さくらインターネットの田中社長が語る「変化に強い開発組織」の条件：ソフトウェア・ファーストな組織へ（1/3 ページ） AI活用やDX（デジタル・トランスフォーメーション）、アズ・ア・サービス化によるサブスクリプション・モデルの導入など、テクノロジーを駆使した新たなビジネスがさまざまな業界を席巻している。今まで非IT企業だった企業群もソフトウェア開発をコア・コンピタンスにしていく必要に迫られる中、組織全体でITシフトを進めるためのステップを書き記したのが及川卓也氏の著書「ソフトウェア・ファースト」（日経BP）だ。 及川氏は執筆に際して、ソフトウェア・ファーストを実践することで各業界に新風を吹き込んできた日本企業に取材を実施。デジタル変革のあるべき論だけではない、リアルな実情を踏まえたソフトウェア開発力向上のヒントを探った。 今回紹介するのは、さくらインターネット社長
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
ビジネス、テクノロジー、クリエイティヴの バランスをとるには？｜深津 貴之 (fladdict)
Line Developer Day 2019にて、「ビジネス、テクノロジー、クリエイティヴの バランスをとるには？」という発表をしました。そのスライドや補足など。 この登壇では、下記のようなことについて話させていただきました。 ・ビジネス、テクノロジー、クリエイティブ視点で、経営レイヤーからどうバランスをとり連携していくか？ ・定性的な判断、定量的な判断、その両者のバランスをどうとるか？ 端的にいえば、この問題に銀の弾丸はありません。開発手法というよりも、地道な意識共有、価値観共有があるのみかなぁと思います。 あと現場からボトムアップするというよりは、経営者がしっかりやるべきことかなぁと。決算書の数字しか見れない経営チームというのは、あんまりよろしくないし、それを直すのは経営レイヤーの責務かなと。 売り上げだけとか、DL数だけを見ると、サービスはどんどん歪んでいきます。数年ぐらいは大丈夫
1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
エンジニアリングマネージャーはエンジニアリングがわからなくてもよいのか
エンジニアリングマネージャー界隈でよく聞く話マネージャーは役割であって上下関係ではないマネージャー＝エラいという不文律が存在している組織がまだまだ多い。そうではないと言ったところで給与体系が違ったり、組織上ツリー構造の上位に位置していたりする。マネージャーになることを「昇格」と呼んでたりするのは、こういう風習の表れだったりする。 それにしても「部活のマネージャー」と聞いて上下関係を思い浮かぶ人はいないのになんで「組織のマネージャー」になると話が変わるのだろうか。部活のマネージャーは仲間だけど、組織のマネージャーは仲間だと思えないのかもしれない。 ところが少し前からWorks Rulesの影響などもあって、徐々にマネージャーというものが見直され始めてきているように感じる。役職としてのマネージャーから役割としてのマネージャーへと目線が移ってきた。 自分もそういう考え方のほうが好きで、メンバーと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームで品質を考えるレビュー #JaSST
Stop Trying to Multitask. You’re Terrible at It.
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
フロー効率性とリソース効率性について #xpjug
