まつもとゆきひろ氏がソフトウェア開発に役立つ2冊の書籍を紹介 『失敗の科学』と『APIデザインケーススタディ』から学べること
まつもとゆきひろ氏がソフトウェア開発に役立つ2冊の書籍を紹介 『失敗の科学』と『APIデザインケーススタディ』から学べること #11 「失敗の科学」 オープニングトーク まつもとゆきひろ氏：まつもとゆきひろです。月曜日に放送して以来、ちょっと間が空いてしまいました。今日これを録音しているのは、（2022年）6月25日の土曜日なので、月曜日から土曜日まで録音できなかったということになります（笑）。 「Voicy」は、一発録りで流す仕組みで、編集をほとんどかけていないので、そういう意味で言うと、習慣化して毎日10分とか録れば、すぐに毎日できるようになると思うんですけれども、まだ習慣になっていないので、忙しいとこうやってつい後回しになって、じゃあ、次の日、とかなってしまいがちなのが現状です。 例えば、毎日「Wordle」をするとかですね（笑）、日記を書くとかですね、それから、「mruby」に1日
仕事をがんばる“戦闘モード”が一定以上続くとどうなる？ 自分をケアするために知っておきたい「観察」の方法
本イベントは、『部下との対話が上手なマネジャーは観察から始める ポリヴェーガル理論で知る心の距離の縮め方』の出版を記念して開催されました。同書籍の著者で株式会社ロッカン代表の白井剛司氏が登壇。本記事では、観察に役立つポリヴェーガル理論と、自分の状態を自覚するための3色のモードについて解説しました。 前回の記事はこちら 観察には3つの段階がある 白井剛司氏：では、（職場に安心感やつながりを作るための）「観察」とは何だろうということですね。3つの段階があるんですけど、1番目は自分の言動パターンに気づくことです。「自分は、人から何か言われた時に『いや、そうじゃないのに』と思ったり、『こう返さなきゃいけない』と思ったりする」と気づく感じですね。 あと萎縮したり、腹が立って感情的になったり、それを我慢しようとしたりしていることに、自分なりに気づく。まずは自分に注意を向けます。2番目は、自分（の状態）
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore／After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの
膨大な業務知識・業界知識・ドメイン知識は“小さく調べる” BtoB・BtoC経験者のPMが語る、ミニリサーチの良さ
株式会社エス・エム・エスのプロダクトマネージャー、キムダソム氏が、顧客が抱える問題の解像度を上げて事実を明らかにするプロセスである「プロダクトディスカバリー」において、ミニリサーチを実施して得られることを紹介します。 本セッションのテーマは「プロダクトディスカバリー」 キムダソム氏：本日、私から話をするのは「BtoBの顧客理解が捗るミニリサーチ」についてです。 プロダクトマネジメントのカバー範囲は、プロダクトの戦略だったり、ビジネス戦略から実際動くものを作るまでのステークホルダーとのコミュニケーションだったり、データの分析だったりと、多岐にわたって広がっています。（スライドを示して）その中でも本日のテーマに特に関わっているのが、右上のプロダクトディスカバリー領域です。 プロダクトディスカバリーとは、顧客が抱える問題の解像度を上げて事実を明らかにするプロセスで、優れたプロダクトディスカバリー
中間管理職の「過剰負担」は、なぜいつまでも解消しないのか？ 見逃しがちな“落とし穴”とマネジメント再構築の4ステップ
多くの企業がこれまで以上に注力している管理職育成。一方で管理職に求められる機能は減ることがなく、むしろ時代の流れとともに求められる役割は増え、負担そのものは増加し続けているという現状も。そこで今回は、組織強化のコンサルタントサービスなどを提供する株式会社タバネルの奥田和広氏が、マネジメントを仕組み化するための4つのステップを解説します。 組織課題の1位は“ミドルマネジメント層の過剰負担” 奥田和広氏：まずは今日の主題の「中間管理職の実態」からお話をさせていただきたいと思います。どんな企業でも、中間管理職の方はいらっしゃいます。「中間管理職は組織の要」なんて言われることが多いですね。 経営者からの要求と、現場からの要求、「経営と現場をつなぐ要」ということで、中間管理職は組織の中で非常に重要な役割を果たしていることになるかと思います。 こういう重要な役割を果たしていますので、当然、業務的にも責
「それは、本当に安全なんですか？」 セキュリティ専門家が「GitHub Copilot」の全社一斉導入時に考えたあれこれ
「GitHub Copilot 導入時に考えたセキュリティのあれこれ」というタイトルで登壇したのは、freee株式会社のただただし氏。タイミー社主催の「GitHub Copilotで拓く開発生産性」で、「GitHub Copilot 」を全社一斉導入する際に考えるべきセキュリティリスクについて発表しました。 freee株式会社 PSIRT マネージャーのただただし氏 ただただし氏：freee株式会社のただただしと申します。 今日は、「GitHub Copilot 導入時に考えたセキュリティのあれこれ」ということで、Copilotのセキュリティリスクについて語るわけですが、考えてみたら、GitHubの中の人を前にこんなことをしゃべるのは相当大胆な話だと思います。最後にいいことで締めるのでちょっと我慢してください。 自己紹介をいたします。ただただしと申します。PSIRTという組織でマネージャー
ユーザーはドキュメントを「読みにくるけれど読んでいない」 “流し読み”しやすいドキュメント作成のポイント
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。さらに、ドキュメントの具体的な書き方と、フィードバックの収集について話します。前回はこちらから。 ドキュメントは「書き始める」ことが大事 岩瀬義昌氏：3章にいきます。時間的にあと15分ぐらいしゃべっても大丈夫かな？ 10分ちょっとしゃべれると思うので。（スライドが）あと70枚あるので、すごく速くいきますね（笑）。 ドラフトの執筆です。みなさんもドキュメントを書くじゃないですか。ちょっと胸に手を当てて（考えて）みると、ドキュメントを書く上で、一番難しいことは何だと思いますか？ （スライドを示して）書ける人は良いんですが、最初の人が1文字目を書き
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト
関数・変数・機能に対する名付け方は“理解の試金石” まつもとゆきひろ氏が、プログラミングで名前が大事だと思う理由
技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。「技育祭2023【春】」に登壇したのは、Ruby開発者のまつもとゆきひろ氏。プログラミングの体験の中で実感した、ことわざや格言について話しました。全4回。1回目は、「名前重要」について。 日本人プログラマーで最も有名なRubyの生みの親 まつもとゆきひろ氏：ご紹介に与りました、まつもとゆきひろです。裏番組もおもしろそうなんですけれども（笑）、こちらに来ていただいてありがとうございます。何人ぐらい来てくれているのかな？ まぁいいや。 今日はですね、「プログラミングのことわざ〜Rubyの父が語る教訓と知恵〜」というタイトルでお話しします。 まつもとゆきひろです。こんな感じのアイコンで活動していますけれども、Rubyを作った人として知られています。インターネットではひらがなです。ちょっ
管理や報酬と結びついた目標は“チート”を誘発する モラルを崩壊させない「目的ベースの目標設定」のやり方
NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話 吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があ
“やります”ドリブンで生まれた負の連鎖を断ち切るために PMの「やるべき業務」「やらなくていい業務」を整理する
PMのはみ出し領域の事例、どこまで対応すべきかについて語る「それってPM業務？みんなの組織のPM担当範囲を聞いてみよう【開発PM勉強会 vol.19】」。ここでアルプ株式会社の前川氏が登壇。PM業務の中で「やらなくていいこと」を決める方法について話します。 前川氏の自己紹介 前川裕一氏：では「業務範囲はどこまで？」という勉強会のところで、「やらないことを決める」みたいな、ふざけたタイトルでやります。アルプ株式会社の前川が発表を始めます。 アルプでPM（プロダクトマネージャー）をやっていて、サブスクリプションビジネスの契約・請求管理の仕組みの「Scalebase」を開発しております。もともとはエンジニアからPMになった枠ということで参加しています。 新卒からモバイルアプリエンジニアをやりつつ、アルプに来てからもバックエンドエンジニアをやって、アルプで2022年からPMにジョブチェンジをして、
副業PMが正社員PMと同じ認識を持てるように Notionを活用して自社制作したプロジェクト管理ツール
中島氏、イヌ氏の自己紹介 椿原ばっきー氏（以下、椿原）：まず1人ずつ紹介します。まず中島さんです。よろしくお願いします。中島さん、自己紹介をお願いしてもよろしいでしょうか？ 中島悠輔氏（以下、中島）：はい。はじめまして。中島悠輔と申します。株式会社SEVENRICH Accountingというところで、今はクリニック向けのシステムのプロダクトマネージャーを本業（として）やっています。ご縁があってLboseさんの副業PMの求人を拝見した時に「ぜひお話をうかがってみたいです」というところから、このようにしてお仕事を頂戴するところに今はなっています。 椿原：ありがとうございます。具体的な案件の話はあとであらためてちょっとしようかなと思うので。 中島：よろしくお願いします。 椿原：続きまして、（お名前が）斬新ですね（笑）。イヌさん。 イヌ氏（以下、イヌ）：はじめまして。イヌと申します。すみません、
「成果を出せば評価される」という考えが不幸の始まり 人事評価制度に不満の声が出る、必然の理由
人気シリーズ『図解 人材マネジメント入門』や『図解 組織開発入門』の著者であり、企業の人材マネジメントを支援する株式会社壺中天の坪谷邦生氏が、MBO（目標管理）をテーマとした新刊の発行にあたり、各界のエキスパートと対談を行います。第3回の後編は『最高の結果を出すKPIマネジメント』の著者である中尾隆一郎氏と、人事評価制度に不満が出やすい理由や、ハイパフォーマーを育てるマネジメント手法について語りました。 「成果を出せば評価される」という考えが不幸の始まり 坪谷邦生氏（以下、坪谷）：私はもともと人事制度のコンサルタントなので、KPIマネジメントと評価・報酬との紐づけが気になるんです。メールで「密結合ではなく、疎結合にしたほうがうまくいく」と教えていただいたのですが、もう少し詳しく聞かせていただけますか？ 中尾隆一郎氏（以下、中尾）：普通の人は、成果を出したら評価をされて、給料が上がって、昇進
1つでも該当すると、「会議の成功率」は5分の1以下 AIが導き出した、会議の成功を阻む5要素
働き方が多様化した時代にも柔軟に対応し、最短距離で成果を最大化する「チームマネジメント」について、3回にわけて特集した株式会社SmartMeetingと株式会社SmartHRのセミナー。 本記事では、「成果を上げるための会議」をテーマに、『超・会議術～テレワーク時代の新しい働き方』の著者・越川慎司氏が登壇した、3回目のセミナーの模様をお届けします。日本企業における労働時間に占める社内会議の時間割合や、「会議の成功」の定義、そして会議でアウトプットが出ない理由など、さまざまなトピックが語られました。 延べ17万人超の労働時間を減らし、売上を上げる支援 越川慎司氏（以下、越川）：クロスリバーの越川でございます。はじめの40分で「815社に対応してきた会議データの実情」と「質と量を改善するためにどうしたらいいのか」といった資料を共有させていただきます。「こうやったらうまくいくよ」ではなくて、実例
悪しきコードの痛みを知り、設計スキルを高める方法を学ぶ 全17章からなる『良いコード/悪いコードで学ぶ設計入門』
4/30発売の『良いコード/悪いコードで学ぶ設計入門』を紹介する「『良いコード/悪いコードで学ぶ設計入門』著者トーク」。ここで著者の仙塲大也氏が登壇。続いて、各章の概要について話します。前回はこちらから。 第1章：悪しきコードの弊害から痛みを知る 仙塲大也氏（以下、仙塲）：ここからは各章の紹介です。本書は1章から17章までの全400ページあります。第1章「悪しき構造の弊害を知覚する」。1章と2は、新卒さん向けの章です。「設計なんかぜんぜん知らないですよ」という方向けの章です。 そもそも設計って、「設計しなきゃ」という危機意識が必要なわけですね。その危機意識の醸成には、悪しきコードによる弊害を知覚する必要がありますよ。悪しきコードの弊害を数例用いてダイジェスト的に紹介して、痛みを知ってもらおうという章です。 第2章：「設計とは？」を学ぶ 第2章「設計の初歩」。本格的な設計は3章の「クラス設計
「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない コンテナのスペシャリストが語る、運用性を損なう8つの実装例
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it 原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOで
「エンジニア環境にいて良かった」と思ったスキルとマインド ユーザーとの距離を測る・エンジニアに任せる・他責からの卒業
「DeNA TechCon 2021 Winter」は、学生に向けて、DeNAを軸に「エンジニアとして企業で働くこと」について、先輩たちが紹介するイベントです。そこで、DeNA SOMPO Mobility 代表取締役社長の馬場光氏が、「事業責任者がエンジニアとしてやって良かったこと」について話しました。 「エンジニア」と「事業責任者」の間で 馬場光氏（以下、馬場）：それでは「プロダクトマネージャー／事業責任者が考えるエンジニアとしてやっていたこと3選」をお伝えいたします。 本日、学生のみなさんが聞いているということなので、お話ししたいこととしては、まずは簡単に私の自己紹介とDeNAでのキャリアを紹介します。 キャリア紹介については、n＝1の紹介ではあるんですけれども、もしみなさんがDeNAにJOINしたらどんなキャリアを描くんだろう、というところをイメージしながら聞いてもらえるとうれしい
コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。植山氏は、制作中のリンカである「mold」について発表しました。全2回。前半は、リンカの概要について話しました。 LLVMのリンカ「lld」オリジナルの作者 植山類氏：植山類です。今僕が作っているmoldというリンカについて発表します。 今回の発表の概要です。リンカが何かを知っている人はそんなにたくさんいないと思うので、まず説明します。次に、「mold」のポイントは速いことなのですが、速いと何がうれしいのかを説明します。そのあと、どれくらい速いのかを説明した上で、どう実現されているのか、概要を紹介します。詳細になると何時間あっても終わらないので、かなりハイレベルな話をします。 自己紹介のスライドを入れていませんが、僕はリンカを何度か作ったことがあって、LLVMのlld
“難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件
ビジネス・ブレークスルー大学（BBT大学）は、オンラインのみで経営の学士資格を取得できる、日本唯一の大学です。今回はBBT大学主催で行われた、経営学部教授・斉藤徹氏の 『だから僕たちは、組織を変えていける やる気に満ちた「やさしい組織」のつくりかた』刊行記念講演の模様をお届けします。社員のエンゲージメントが高い「やさしい組織」をつくるために一人ひとりにできることは何か、今まで斉藤氏の30年近い起業家経験から得られたエッセンスが1冊にまとめられています。本記事では、建設的な議論を行うための「推論のはしご」の考え方について、組織に「安心感の醸成」をもたらすためのポイントについて語られました。 建設的な議論を妨げる最大の要因は、感情的になってしまうこと 斉藤徹氏：続いて、（チームメンバーの意識が）外に向いたらどうすればいいのか。これはみんなが意見を出し合うことが大切です。でもこの建設的に第3案を
「私たちは慣れに支配され、使いにくさに気づいていない」 UI研究者・増井俊之氏が語る“使いやすさ”の本質
機能とUIの進化はなぜ比例しない？ UI研究者に聞く、使いやすさの本質とUIのこれから 「私たちは慣れに支配され、使いにくさに気づいていない」 UI研究者・増井俊之氏が語る“使いやすさ”の本質 誰もが気軽に電子機器を持つようになった今、私たちの生活はデジタルの恩恵で確実に便利になっています。しかし、UIは“よりよさ”を求めた結果、期待した評価とは正反対の声が集まること少なくありません。 そこで今回は、慶應義塾大学環境情報学部の教授で、予測型テキスト入力システム「POBox」やiPhoneのフリック日本語入力システムの開発者であるUI研究者の増井俊之氏に、UIの本質についてお話をうかがいました。まずは増井氏がUIに関わることになったきっかけと、使いやすさの本質について。 UI研究に関わるようになった流れ ーー学生時代には電子工作やソフトウェアに興味をお持ちで、現在のUIにつながる研究は社会人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
