「のどが渇いた」というユーザーに何を出す？ ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
2022年9月13日 株式会社メンバーズ ポップインサイトカンパニーでのウェビナーのスライドです。「ユーザーが欲しいと言った機能をつけたのに使われない！」という経験はありませんか。プロダクトをつくるとき「ユーザーの心理を理解しよう」とよく言われます。しかし、ユーザーに言われたままやることと、ユーザーが本当に望んでいることは異なります。「UXデザイン・UXリサーチ」は、ユーザーを理解するための専門技術です。ユーザーインタビューやユーザビリティテストを用いてファクトを集めることで、ユーザーの表面的な言葉に惑わされない、本当のインサイトにたどりつくことができます。かんたんなワークも交えながら、体系的に解説いたします。Read less
お題箱124 671.以前ツイートされていた雑な格言シリーズの「面接では嘘を吐いてもよい」や「結果が全て」等の意味を詳しく教えて欲しいです。現在進行形で振り回されてます このツイートですね。 仕事に関する言説って「面接では嘘を吐いてもよい」とか「結果が全て」みたいな、まあ正しいっちゃ正しいけどその言い方だと学生は誤解するだろみたいな「精緻な言語化を怠った雑な格言」が無限にあってだいぶ振り回されたのけっこうムカついてる — LW (@lw_ru) 2023年9月22日 いま無職なのでやや気が引けますが書きます（無職が語ることじゃねえだろと思ったので、念のため信頼できる社会人の友達に下読みしてもらって内容に問題ないことを確認しました）。 最初に書いておくと、僕は数百人規模の中小ITでしか働いたことがないので、価値観がその規模感に寄っています。仕事の感性は職や規模によってかなり違って、例えば同じ
2022年8月9日 ある企業さまでの研修「45分間で『ユーザー中心のものづくり』ができるまで詰め込む」のスライドです。登壇枠が45分という限られた時間のなかで、UXデザイン・UXリサーチのもっとも大切なエッセンスを凝縮してお伝えするようにしました。Read less
プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
第0部 まずは「分かりづらい説明」を知ろう（p.14～） 第1部 口頭説明編（p.25～） 第2部 資料作成編（p.63～） 第3部 スライド作成編（p.81～） スライドのまとめ（p.115～）
心理的安全性という概念がある。ここ十年ほどチームづくりの最重要ファクターであるともてはやされ、他方では粗雑な理解によって批判されてきた。急に人気の出たアイドルの宿命みたいなものを背負っている。 世間的なイメージがどのようなものか、少し羅列してみよう。 なんでも言える。否定されない。安心して働ける。不安がない。感情を大切にしてもらえる。あなたはあなたのままでいいと肯定される。 こうしたイメージを抱いている人もいるかもしれないが、残念ながらこれらは、心理的安全性の正しい姿からは遠くかけ離れている。ただ安心してほしいのは、こうした誤解をしている人は決して少なくないということだ。 手持ちのグーグルで「心理的安全性 誤解」と検索してみると、何ページにもわたって理解を正す記事が並んでいる。NewsPicksも、プレジデントも、朝日新聞も、Qiitaも、東洋経済も、あらゆるメディアが心理的安全性の誤解に
私事ですが、11月15日をもってアイティメディアを退職し、約10年関わってきたねとらぼの編集・運営業務から離れました。 いやー10年もいたのかと我ながら驚いていますが、いたらしいです（ちなみになんかモメたりしたわけではなくただの転職）。 そんなわけで、この記事はいわゆる退職エントリというやつになります。 ねとらぼという得体の知れないサイトのわりと初期から関わらせていただき、10年かけてそれなりの規模にまで育ててこれたというのは、なんだかんだで自分にとってはかなり貴重な経験でした。せっかくなので、ねとらぼがどのようにしてあの形になったのか、中の人は日々どんなことを考えて更新していたのかなど、怒られない程度に書き残しておきたいなと思います。 （といいつつ結構いろいろ書き散らかしたので、怒られたら五体投地してすぐにごめんなさいする所存です） 自分がねとらぼでやったこと自分がアイティメディアに入社
目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件
中田:‖ @paddy_joy 今日のマネジメント研修はめちゃくちゃ良かった。Twitterではボロクソに言われてる人が講師だったのでむしろネタにしてやろうくらいの気持ちで受けたんだけれども説得力がTwitterとは段違いだった。発信する場によってこれくらい印象が変わること自体が一つのケーススタディーになりそう。 2023-03-08 17:09:03 中田:‖ @paddy_joy 「"心理的安全性"は部下の立場でしか語られないのが大きな問題。「指摘したら部下が落ち込むんじゃないか」「指導をしたらパワハラ扱いじゃないか」などと心配するのは上司の側の心理的安全性が脅かされている。ダメなものはダメだと上司が躊躇なく言えなければその組織も強くならない」 2023-03-08 17:14:14 中田:‖ @paddy_joy ↑この前段に、「部下が上司に指摘できない組織は死ぬ」というデータがいく
コラム53：迷惑はかけてもいい 日本人ならたいてい子どものころから、親や学校の先生などから、「他人に迷惑をかけてはいけません」と言われて育ってきたのではないだろうか。そのため、「他人に迷惑をかけてはいけない」というのは、普遍的な道徳律だと思っている人も多いのではないかと思う。私も数年前までそう思っていた一人だった。しかし、どうやらこの教えはそれほど普遍的な規範とは言えないようだ。日本語教師をしている私の知人によれば、中国ではこのような規範を子どもに教える親はほとんどいない代わりに、「困っている人を助けなさい」と教える親が多いという。私の友人の韓国人によれば、韓国でも「他人に迷惑をかけるな」という人はいるものの、日本ほど多くはないという。むろん、日本でも「困っている人を助けなさい」と教える親もいるだろうが、「他人様に迷惑をかけてはいけない」と教える親に比べると、圧倒的に少数派だろう。 新約聖
「もし私が顧客に何がほしいかを聞いていたら、彼らは『もっと速い馬がほしい』と答えただろう」という自動車王フォードの名言があります。またユーザー中心のはずのUXデザインで「顧客の声を聞かない」「ユーザーは本当に欲しいものを言葉にできない」という言葉を聞くことがあります。どうすればよいのでしょうか。欲しいものを訊くのではなく、行動の目的を訊くことで、ユーザーの本当のニーズにたどりつくことができます。Read less
コロナ禍のアメリカで奮闘する日本人牧師がいる。関野和寛さん（40）。ミネアポリスの病院で「チャプレン（病院聖職者）」として勤務し、新型コロナウイルス感染者の心をケアしながら、ときに命が消えていく瞬間を看取り、家族に寄り添う。新型コロナウイルスとの闘いの最前線に立つ、関野さんの日々とは。（ジャーナリスト・室橋裕和／Yahoo!ニュース 特集編集部）
本エントリはカケハシ Advent Calendar 2023 の 11日目の記事です。 今年はPart2もあるのでぜひそちらもご覧ください！ カケハシのVP of Engineeringの湯前（@yunon_phys）です。皆さん、目標設定と評価は順調ですか？私はこれまで何年にも渡って、様々なメンバーの目標設定や評価をしてきました。残念ながら、こうすれば良い目標設定や評価が出来る！という銀の弾丸は無さそうです。でも、こう考えたら目標設定はやりやすいかも、こうすると評価はより納得感のあるものになるかも、というのはあります。 そこで今回は制度を施行・運用していく立場の人間として、目標管理と評価制度の考え方について、私の意見を述べていきます。 目標管理 目標はそもそも変わるものである みなさんこんなことありませんか？ やる気満々であんなことやこんなことを色々考えて、壮大な目標を期初にがんばって
子どものころは絵を描くのが好きだった。 学校の休み時間は、クラスメートはみな外にサッカーをしにいっていたが一人教室にのこってノートに漫画を描いている、そんな小学生だった。 自宅に戻っても、自室にこもってよく漫画を描いていた。 漫画と書くいっても、別に人を楽しませるために描いているわけではなかった。もちろん褒められると嬉しかったが、それが目的だったわけではなく、いま思えば、それは自分で自分を癒すかのような行為だった。自分を救うために絵を描いていた。 絵を描いているときは、それに夢中で没頭していて、ほかの何にも代えがたい時間を過ごすことが出来た。この時間が、どこか自分の救いになっていた。 中学二年生ぐらいになって思春期にさしかかった頃だろうか。教室で絵を描いていると浮いてしまうことに気づいて、恥ずかしくなって、描かなくなった。 それでもやっぱり絵を描いたりなにか作品を作ったりするのは好きだった
今回の記事では、ちょっと感覚的でふわっとした話をしようと思います。それは「『仮説ドリブン』という考え方には往々にして落とし穴があるのではないか？」という問題提起です。 そもそも、「仮説ドリブン」（仮説駆動型：hypothesis-driven）というアプローチは実験科学分野出身の我が身にとっては、個人的には馴染み深いものです。まだ僕がポスドクだった頃、国際会議に際して日本人研究者同士で集まる会が毎回あったのですが、その席上でお話を聞く機会があった当時のトップ研究者の先生から「この世の森羅万象は網羅しようとするにはあまりにも広大過ぎる、故に森羅万象を区切って『仮説で白黒つけられる範囲』に絞り、これを検証するということを繰り返して前に進むべき」ということを聞かされ、感銘を受けたのを覚えています。 実際、仮説ドリブンの考え方は非常に有用なものであり、今現在僕自身が主戦場とする広告・マーケティング
プログラマーの教養としての原則
参考 プリンシプル オブ プログラミング - 3年目までに身につけたい一生役立つ101の原理原則 発行: 2016/3/23 著者: 上田 勲 まえがき プログラマーの世界で語り継がれる原則や格言を知ることは、その共通の言語や道徳を理解する手助けとなります。 『プリンシプル オブ プログラミング』（以下、プリプロ）は、統一された語句と形式により、先人のプログラマーたちが重要視していた思考法やアプローチを、微妙な概念の違いに気を使うことなく理解できるよう構築されています。この記事では、この本を読む上で役立つ101の原則マップと原則から抽出した価値観をまとめます。プリプロを読む際のガイドになればと思います。 一方で、プリプロに収録されていないウィットに富んだ原則や格言も多く存在します。この記事では、主に私の現場で重要視しているプリプロの101の原則以外の原則・格言も追加で紹介します。 プログラ
2023年1月11日より開催された「Regional Scrum Gathering Tokyo 2023」の登壇資料です。 https://2023.scrumgatheringtokyo.org/index.html ----- Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています！📣 ▼Visional Engineering Blog https://engineering.visional.inc/blog/ ▼VISIONAL ENGINEERING Twitter https://twitter.com/VISIONAL_ENG
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
疫病が流行しているのでよぶんな外出を控えるようにという通達が出された。弊社ではそのために些末な打ち合わせもオンラインでおこなわれ、皆が慣れてきた今となってはリアルタイムの共同作業も気楽に実施されている。本日は上司からの資料レビューであった。 上司：急ぎでイレギュラーな仕事やってもらっちゃってごめんね わたし：いえいえだいじょうぶです 上司：こういう差し込みの仕事、ガッてやってバッて出してくれるのほんと助かる わたし：いやあ、この程度でよろしければ 上司：あのね、できればこの程度じゃなくしてほしい 上司：あなたの仕事はいつもスピーディで対応も柔軟で素晴らしい。でも雑 わたし：あっそれが本題ですね 上司：うん。赤字のところ見ておいて。とくに数字の誤字は致命的だからね。あと図の作りとレイアウト。せめて余白を左右対称にしてほしい。総じて雑 わたし：承知しました。赤線ありがとうございます。すごく直し
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
Negative Capabilityという概念を最近知った。詩人ジョン・キーツが提唱したとされている用語で「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」を意味する。対義語はPositive Capabilityで、所謂課題解決能力の事。 我が身に翻ってみると思い当たる事が多く、特にマネージャーをやっているとこの能力の有用性を感じずにはいられない。例えばよく目にするのは以下の様な事象だ。 新しく入ってきたマネージャーが成果を出そうと張り切って色々提案するが、芯を外していたり合意を得られてなかったりで現場でハレーションが起きる ある問題を解決する為に新しいツールを導入するが、新しいツールが更なる問題を引き起こし以前より状況が悪化する 組織内で色々改善活動を試みるが、すぐには効果が出ず反応も芳しくないので心が折れてしまう これらはpositive capability
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2022年度リクルート エンジニアコース新人研修の講義資料です
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide
Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
マネージャーの評価基準（シート・動画付き）｜長村禎庸@EVeM
はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか
本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。 ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。 無駄なく、効率的にと思っても、ついつい発生しちゃう。 こういうの、オーバーエンジニアリングって言うらしいよ！？ でも、どこからオーバーで、どこまではオーバーじゃないんだ！！ ということで、勝手にオーバーエンジニアリングを定義してみようと思います。 作り過ぎて、時間や金を無駄にすること？？？？ とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。 wikipedia（英語版） Overengineering - Wikipedia 一部抜粋。 Overengineering (or over-engineering,[1]
評価者を孤独にしない
EMゆるミートアップ vol.6 〜LT会〜 登壇資料
【資料公開】スプリントレビュー Deep Dive
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろ スクラムチームの外側のステーク
Google 広告はそう多くの難しい知識や技術を必要とせず、誰にでも扱えるものですが、設定できることが数え切れないほどあるために、やるべきことはなんであるのか、力のかけどころがどこなのかわかりにくいものにもなっています。
この記事の概要 昨年、デザインに関する社内研修を実施し、その内容をQiitaでも共有してみたところ多くの反響をいただきました。 最近内容をアップデートして研修を実施する機会があったので、こちらも投稿してみます。 具体的な制作テクニックよりは抽象的な考え方がメインですが、デザイナーと一緒に働いている方や、デザインにも興味がある方のお役に立てるのではないか、と思っています。 自己紹介 私はQiitaでデザイナーをしている綿貫佳祐といいます。 2017年に新卒でエイチームに入社して、今年で6年目です。 普段の業務では、企画を考えたりUIを作ったりコードを書いたり。 割と幅広めにデザインに携わっています。 普段の業務以外だと、会社としての発信のデザイン監修する機会が多いです。 例えば、ロゴとかコーポレートカラーのような、会社として大事なグラフィック要素1。 これらが広報物内でどう使われているかのチ
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
こんにちは、CX事業本部デザインチームの小峰です。 先日、Agendというメディアさんからインタビューいただきました。 仕事のすれ違いを「ただ、話す」で解決していく、スクラムから学んだチームコミュニケーション―――――クラスメソッド小峰さんインタビュー この中で「ただ話す」を紹介しています。 今回は、これについて少し深掘ってみます。 これを知ったのはインタビューでもお話した通りLeSS Frameworkがきっかけでした。複数チームによるアジャイル開発体制を検討している中で出会いました。いわゆる「大規模アジャイル」の一種です。 「ただ話す」は、大規模アジャイルの学習のために「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」という本を購入し、そこで紹介されていたものになります。 調整と統合 スクラムガイドでは主に1チームでのスクラム
仕事における後進教育のススメ
専門学校の常勤講師（学科長）を経験したWebディレクターが、現場に戻って効果があった教育手法、の話です。 詳細はコチラ↓ https://toksato.hatenablog.com/entry/koshinkyoiku-slide/
BtoBサイト改善ガイド | 才流
自社に合ったキーワードを入れるだけでテキストリンクCTAが作成できるテンプレート集です。あらゆるパターンを想定した内容となっているので、複数パターンを組み合わせて作成いただくこともできます。
仕事において、やる目的や内容が見えないとすごく憤りを感じることが人がいる。自分もたまにある。これは当然の感情だと思っている。 ROIの高い仕事をするには目的が何より大事だ。また、「わからない」「自分は知らない」という情報の非対称性に対する不安や嫌悪感は、誰しも持ち合わせている。これは物事を知り学ぶことによって生き延びてきた人類の本能と言ってもいい。いや、チョット言いすぎたかもしれない。 それを前提として、説明する側はしっかりと説明責任を果たそうと気を配る。いわゆる情報の透明性や風通しの良さというやつである。組織についてしっかりと考えているところはどこもすごく頑張っていて、それ自体もとてもよいことである。 一方で、説明をする側、受ける側という構図がなんだかよくないというか、フェアじゃないような気持ちになることもある。説明をする側を経験してきた方はわかると思うが、本人も正解かどうか自信がない状
bao @baobabustroll 消耗品使い終わったのに次の箱すら開けてない場面に遭遇したら、ラボの人全員に「この放置されてた空の箱を片づけてわざわざ補充したのはわたしなので、わたしを讃えよ」って褒めてもらいに回ってたらそのうち放置する人がおらんようになった。 2023-10-15 07:43:42
コードレビューの基準
コードレビューの基準 コードレビューの主な目的は、Google のコードベースにあるコードの全体的な健康状態を時間をかけて改善することです。 コードレビューのすべてのツールとプロセスは、その目的のために設計されています。 これを実現するには、さまざまなトレードオフのバランスを取る必要があります。 まず第一に、開発者は自分のタスクを進めることができなければなりません。 コードベースに改善を提出できなければ、コードベースは改善しません。 また、どんな変更に対してもレビュアーがいちいち難色を示して変更を取り入れずにいると、早晩、開発者は改善を行う意欲を失います。 一方、CL の品質を確認するのはレビュアーの義務です。CL を取り入れてコードベースのコードの全体的な健康状態 (code health) がだんだんと悪化するのは問題ですから、きちんと確認しなければなりません。 これは骨の折れるやっか
Recruit (@recruitengineers) on Speaker Deck
プロデザ！ BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
プロジェクトの成功率を高める検証手法として、心理学者であるゲイリー・クラインが提唱した事前検死(pre-mortem)についてまとめる。 事前検死(pre-mortem)とは事前検死(pre-mortem)とは、プロジェクトの開始前に「プロジェクトは失敗した」という想定で、チーム内でその原因を検証することをいう。 「pre-mortem」は、医療の改善などのために遺体の検死や解剖を行うことを意味する「post-mortem」に由来しており、絶対に失敗が許されない場面において絶大な威力を発揮するとされている。 事前検死を行う4ステップ当然だが、前提として事前検死の目的はプロジェクトを中断ではなく、強化することにある。 ここでいう強化とは、主に目的/目標達成の達成確率を高めることを指す。 0. 失敗を許容する文化形成これは事前検死を行うためのステップというよりは、検証を適切に行うために必要不可
自社ビジネスがどうありたいかは選んだKPIに表れる、というのは一側面としてそうだと感じます。SaaSなどのスタートアップやユーザー向けサービスの提供企業、ECもそうですしオウンドメディアなどもそうでしょう。どのような指標をキーとして把握しているかによって、そのビジネスが向かう方向が決められます。 逆に言えば、月並みなKPIを適当にそろえているだけでは、月並みな存在に終わるかもしれない、ということです。 全体の売上を追うのか、あるいは注力する特定カテゴリーの売上を重視するのか ユニークユーザー数を追うのか、あるいは特定アクションを行ったユーザー数を重視するのか（あるいはMAUを追うのか、常連層を把握するのか） 全体PV数を追うのか、特定カテゴリーの状況だったりスポンサードコンテンツの効果を追うのか 顧客獲得コストや獲得件数を追うのか、LTVと並べて収益性（ユニットエコノミクス）を把握するのか
サービスやアプリケーションを作り出すためには二通りの道があります。ひとりで作る道と、みんなで作る道です。いずれの道もメリットやデメリットがありますが、ここではそれらに触れません。 今回は、わたしのようにずっとひとりで作ってきた人間が、どのようにしてチーム開発というものに関わっていくべきなのかに焦点を当ててみたいと思います。 はじめに 少しわたしの話をします。 わたしがWeb制作というものを仕事にすることになったのは、前職へ入社してからです。その会社は中規模の紙媒体をメインで扱う制作会社で、自分が配属されたのはWeb事業を担う小さな部署でした。当時はまだWeb黎明期から足が抜けきれていない時分で、いまはなきFlashがまだ目新しく、そのFlashもまだMacromedia製品でしたし、jQueryなどはまだ生まれてもいませんでした。 そこで携わったのは主に中小コーポレートサイトの制作で、今の
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
23/10/21 就活に苦しむインテリの学生に社会の真実を教える - LWのサイゼリヤ
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
プロダクトマネジメントクライテリア
わかりやすい説明のための 10 の鉄則
「心理的安全性」はなぜ混乱を招き続けるのか | Q by Livesense
【報告】ねとらぼを退職しました（＆この10年でやってきたこと振り返り）｜てっけん
目標設定とは何か - Konifar's ZATSU
「説得力がTwitterとは段違いだった」Twitterでボロクソ言われてる人のマネジメント研修の内容が非常にタメになる
コラム53：迷惑はかけてもいい｜運営委員・相談員のコラム｜学習相談室｜東京大学大学院法学政治学研究科・法学部
「顧客の声を聞かない」とはどういうことか
「わかるよ、クソだよねこの世界は」――米コロナ病棟で命に寄り添う、日本人牧師の奮闘（Yahoo!ニュース 特集）
目標管理と評価制度の考え方 - KAKEHASHI Tech Blog
自分を救うプログラミング｜naoya
「仮説ドリブン」という名の甘い罠 - 渋谷駅前で働くデータサイエンティストのブログ
「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論- / #RSGT2023
長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと
雑で速いやつに対する説諭 - 傘をひらいて、空を
マネージャーとNegative Capability - scrapbox - hotchemi
大事ではないことを大事だと錯覚した結果、オーバーエンジニアリングになる - @i2key のBlog
リスティング広告のやり方 - Google 広告 でやるべきことまとめ - 株式会社JADE
デザインの役割や価値（社内研修資料） - Qiita
技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita
チーム間の調整テクニックのひとつ「ただ話す」 | DevelopersIO
説明責任と信頼 - Konifar's ZATSU
消耗品を使い終わったのに補充されない問題を解決した方法が賢くて優しい「片付けと補充、なにげに大事な業務」
プロジェクトの成功率を高める事前検死(pre-mortem)｜Yusaku Akasaka
自社ビジネスがどうありたいかは選んだKPIに表れる - 株式会社真摯
チームを知らないわたし達へ - MATSUKAZE.DESIGN
news.yahoo.co.jp
tv.dmm.co.jp
x.com
tv.dmm.co.jp
www.watch.impress.co.jp
live-style.jp