顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore／After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの
秩序があると混沌よりも良いんじゃ(プロジェクト遂行における創発段階においても段取りや問題探索空間の縮小が必要という話) - Lambdaカクテル
同僚と1on1していて面白い話をしたのでメモ。 プロジェクトの不確実性 前提として、自分はソフトウェアエンジニアとして働いているのだが、0→1的な仕事の場合、プロジェクトは最初は不確実で混沌とした状態にあり、しばらくの創発的な状況を通過していくことでいずれ不確実性が減っていき、最終的にはプロダクトとして結実する、という流れを辿る。 最初のうちは不確実だし、様々な可能性に目を向けることが必要な段階なので、ブレインストーミング的な感じでランダム性やクリエイティビティを誘導したりすることが多い。一方、これはビジネスなので、最終的にはプロダクトとして結実させなければならない。したがって道筋を描くための段取りはしなければならない。 よくある不確実性コーンみたいなのを思い描いてほしい。 不確実性へのアプローチ 自分は理数系の正式な教育を受けておらず、どちらかといえばいわゆる人文系な発想をしがちである。
進捗確認をやめると上手くいく｜きゅーい / koyo
プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり
チュートリアル：React の導入 – React
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 新しくなったチュートリアルでは最新の React の使い方がライブサンプル付きで学べます。 このチュートリアルは React の事前知識ゼロでも読み進められます。 チュートリアルを始める前に このチュートリアルでは小さなゲームを作成します。自分はゲームを作りたいのではないから、と飛ばしたくなるかもしれませんが、是非目を通してみてください。このチュートリアルで学ぶ技法はどのような React のアプリにおいても基本的なものであり、マスターすることで React への深い理解が得られます。 ヒント このチュートリアルは実際に手を動かして学びたい人向けに構成されています。コンセプトを順番に学んでいきたい人は一段階ずつ学べるガイドを参照してください。このチュート
決済サービスを閉じるときのやることリスト | メルカリエンジニアリング
Merpay Advent Calendar 2020の20日目は、メルペイProduct EngineeringチームのVP of Engineeringを担当しているnozaqがお送りします。 2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。 取り組んだこと 決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご
一人前のプロマネってどんな人？ プロジェクトマネジメントのスキルセットとは - 誰も教えてくれないプロマネのコツ
今やあらゆる場面で必要とされるプロジェクトのノウハウを、300件以上成功させてきたプロフェッショナルがこっそりお伝えします。 先日、仕事で関わっている方から、「結局、プロマネって何ができないといけないんですかね？」という質問をされたので、その場でざっくり洗い出してみました。 世の中には PMBOK や ITSS, PRINCE2 などのスキル標準を定めたものはありますが、これらは大規模システム開発を志向しており、概念として抽象度が高いためベースの知識として利用できる環境は残念ながら非常に少ないという現実があります（もしこれらを利用できる環境にいるならとても幸せなことです）。 少なくとも日本で実施される一般的なプロジェクトは PMBOK や ITSS を元に共通認識を整備するどころか、「限られた予算で1年でクライアントのシステムを刷新する必要がある」とか、「社長の思いつきで何も決まっていない
Early Work
初期の作品 --- Early Work Paul Graham, October 2020 これは、Paul Graham： Early Work を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2020 by Paul Graham 原文: http://www.paulgraham.com/early.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。 出版社の案内ページ Amazon.co.jp サポートページ 2020/10/20 翻訳公開
グーグル元社員が考案「新型やることリスト」が超便利 | Forbes JAPAN 公式サイト（フォーブス ジャパン）
グーグルで最速仕事術「スプリント（デザインスプリント）」を生み出し、世界の企業の働き方に革命を起こしてきた著者が、今度は、時間を最大限に有効に使うメソッドを生み出した。それをまとめたのが『時間術大全──人生が本当に変わる「87の時間ワザ」』（ジェイク・ナップ、ジョン・ゼラツキー著、櫻井祐子訳、ダイヤモンド社）だ。同書はたちまちのうちに話題となり、世界16カ国で刊行が決まっている。 著者のジェイク・ナップはグーグルで、ジョン・ゼラツキーはユーチューブで、長年、人の目を「1分、1秒」でも多く引きつける仕組みを研究し続けてきた「依存のプロ」だ。 そんな人間心理のメカニズムを知り尽くした2人だからこそ、同書の時間術はユニークかつ、きわめて本質を突いている。「人間の『意志力』などほとんど役に立たない」という、徹底して冷めた現実的な視点からすべてが組み立てられているのだ。 さらに、「いくら生産性を上げ
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
伝わるプロジェクト課題の書き方（Backlog） - Qiita
はっきり言うと表題の書き方独自ルールなんて覚えたくありません。 よく「パッと見でわかりやすくしたい」と言われます。 そのパッと見はすべてのシチュエーションに対応できているのでしょうか？ その強調は本当に必要ですか？ もっと重要な他の課題の主張を潰してませんか？ BACKLOG-1 ○○画面で■■のボタンが押せなくなる 種別： 社内FB これでも十分見やすいし伝わります。 重要なことは詳細に追記する（詳細を編集する） BACKLOG-1 ○○画面で■■のボタンが押せなくなる 種別： 社内FB 詳細： 再現できません。 状況を確認してください。 修正が必要なら修正をお願いします。 ... コメント： ○○の画面で◇◇を行うと発生する不具合です。 コメントで調査結果が報告されたとします。とても重要なコメントです。 このまま放置すれば別のコメントによってログが流れてしまいます。 調査した人と修正す
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか | タイム・コンサルタントの日誌から
旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実
若手は居場所をなくさないために積極的に主導権を取れ――今のSIerの現実：明日から使えるシステム開発プロジェクトの進め方 再入門（1） 本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。 連載目次 今のSIerの現実――プロジェクトの進め方を見直そう 本連載では、システム開発プロジェクトの進め方をあらためて解説する。いまさら「プロジェクトマネジメント？」と思われる読者もいるかもしれない。実は、システム開発を取り巻く環境がここ数年で大きく様変わりしている。その結果、プロジェクト推進の在り方を再確認する必要性が増しているのだ。 まず、SIerが得意としてきたワンストップの受託開発が減ってきている。従来、SIerは事業会社からの相談を受けて、シ
【2016年最新版】プロジェクト管理ツール（無料）が便利すぎる - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
フリーで使えるガントチャートテンプレート一覧｜IT情報局
この記事では、エクセルで作成されたガントチャートテンプレートを無料でダウンロードできるサイトを厳選して紹介します。 ガントチャートは、会社でプロジェクトをスケジュールどおりに遂行する場合に作成するスケジュール管理表です。 しかし、ガントチャートを使ってプロジェクトのスケジュール管理をする場合、会社に決まったフォーマットがない場合は自分で０から作らなくてはなりません。 ガントチャートを０から作るのも大変ですよね。素早く楽に作成するには、使い勝手のよいテンプレートを自分で改良するのが一番です。 以下では多くのサイトを紹介しているので、ぜひ自分のプロジェクトに合いそうなガントチャートテンプレートを見つけてください。 <関連する記事> 要求仕様書の書き方やテンプレートが見れるサイトまとめ タイムスケジュール表 無料エクセルテンプレート エクセルで作成したガントチャートを無料配布しているサイト一覧で
引っ張るだけがリーダーじゃない。支援型リーダー「サーバントリーダーシップ」という考え方 - U-NOTE[ユーノート] - 仕事を楽しく、毎日をかっこ良く。 -
皆さんはリーダーシップという言葉を聞いてどんなイメージを思い浮かべるでしょうか？ "周囲の人々を巻き込みながら引っ張っていく"といったイメージを持たれる方も多いかもしれません。 しかし、上記のようないわゆるリーダー的性格ではなく、陰で他人を支える方が性に合っているという方も多いはず。また、リーダーシップなんて自分には関係ないと思っている方もいるかと思います。そんな方におすすめしたいのが、「サーバントリーダーシップ」という考え方。
![引っ張るだけがリーダーじゃない。支援型リーダー「サーバントリーダーシップ」という考え方 - U-NOTE[ユーノート] - 仕事を楽しく、毎日をかっこ良く。 -](https://cdn-ak-scissors.b.st-hatena.com/image/square/de2d8be3c015d90a82bd23006470a8ce003f22c3/height=288;version=1;width=512/https%3A%2F%2Fimgs.u-note.me%2Fnote%2Fcaption%2F47500356.jpg)
大きな話ができる人 - レジデント初期研修用資料
少ないリソースをやりくりできる能力と、たくさんの人数や、大きな予算をその大きさなりに使ってみせる能力とでは、求められるものがずいぶん違う。 小さなタスクを正確にこなせる人が増えた一方で、世の中からはたぶん、大きな話を大きく論じられる人が減った。 大きさが変わると道具も変わる 同じ「切る」道具であっても、手術用のメス刃とチェーンソーとでは異なって、「丸太を切る」という問題があった時に、「大きなメス刃」は解答としてふさわしくない。大きな問題を論じるためには「大きな言葉」が必要で、大きな言葉はたぶん、小さな言葉の延長線上には存在しないのだろうと思う。 新人だったころの田中角栄は、選挙の第一声として、「みなさん、あの山を削っちゃいましょう。余った土は海に入れて佐渡ヶ島とつなぎましょう。山がなくなれば雪は全部関東の方にいく。新潟の耕作可能免責は飛躍的にひろがる」とマイクでがなった。 「大きな言葉」で
【無料配布】Web制作設計手順書 | 毒舌プランナーの異論持論
皆さん、長らくお待たせ致しました。 先日からお話に上がっていた 【Web制作設計手順書】 を配布致します。 下記よりダウンロードして下さい。 PowerPoint用とKeynote用とがありますが PowerPointに関してはアニメーションなど上手く動作しなかったりしますので その点についてはご了承下さい。 ※追記：単純に閲覧用、印刷してお使いになる方用にPDF版も用意しました。 ※追記2：PowerPoint版の5Pと14Pがおかしかったのを修正しました。 ※追記3：「色彩」の部分で黄色と白が見辛かったので全体的に修正しました。 基本的にはMacやiPadをお持ちの方はKeynoteでの閲覧を推奨いたします。 また注意事項としましては 無料配布ではありますが、著作権は放棄しておりません。 編集する、再配布、商用利用などご自由にして下さって構いませんが 「自分が作った」 等と豪語するのは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
#6@『永久パピルス』 on Twitter: "実際両方経験してる身としては、IT業界の人は土木建設業界に勉強しに行っても良いのではないかと強く感じるしなぁ。 特に契約まわりの差が歴然で、土木エンジニアがIT業界の契約書見たら『素人さんの口約束？』となる感じ。そりゃトラブルも起… https://t.co/7p6Pz6B3KO"
