チームで盛り上げる ファシリテーション2022/08/04 開発PM勉強会vol.13の登壇資料です。
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita
※今回はほぼ実話です。 システム開発会社勤務 プログラマーワイ ワイ「さあ、今日も開発をしていこか」 ワイ「とあるWebサービスの管理画面を作らなアカンのや」 ワイ「今日は、どんな機能を作らなアカンのやったかな」 ワイ「せや、クライアントさんからもらった機能一覧.xlsを見てみよか」 ワイ「あとは、デザインデータも見ながら、詳細設計書でも作っていこか」 ワイ「・・・ふーむ、作るべき機能の一覧は書いてあるんやけど」 ワイ「なんか、やる気が出ぇへんなぁ」 ワイ「仕方ないから、社内のSlackで愚痴っとこか」 ワイ「今のプロジェクト、誰のために何を作ってるのかがイマイチ分からんから」 ワイ「モチベーションが上がらへんなぁ」 ワイ「この管理画面を使って、どんな課題を解決したいのか」 ワイ「どういう風にユーザーさんの業務をうまく回したいのか」 ワイ「そんなんがピンと来てないから、作るべきモノもはっき
中日新聞:自動車工場のガロア体 ＱＲコードはどう動くか
その誕生を地元新聞も経済新聞も記事にしなかった。２年後、『コードの情報を白黒の点の組み合わせに置き換える』と最下段のベタ記事で初めて紹介された時、その形を思い浮かべることができる読者はいなかった。いま、説明の必要すらない。ＱＲコードはなぜ開発され、どう動くのだろうか。 ＱＲコードは、自動車生産ラインの切実な要請と非自動車部門の技術者の「世界標準の発明をしたい」という野心の微妙な混交の下、1990年代前半の日本電装（現デンソー）で開発された。 トヨタグループの生産現場では、部品名と数量の記された物理的なカンバンが発注書、納品書として行き来することで在庫を管理する。そのデータ入力を自動化するバーコード（ＮＤコード）を開発したのがデンソーだ。 バブル全盛の1990年ごろ、空前の生産台数、多様な車種・オプションに応えるため、部品も納入業者も急激に増え、ＮＤコードが限界を迎えていた。63桁の数字しか
JavaScriptの進化で変わる身近なコーディング習慣
JavaScriptの進化で変わる身近なコーディング習慣 uhyo ( https://twitter.com/uhyo_ ) JavaScriptは歴史が結構長い言語であり、さまざまなベストプラクティスがあります。一方で、JavaScriptは進化を続けており、それに伴ってこれまでに蓄積したベストプラクティスも変化します。このトークでは、みなさんの手癖になっていそうなプラクティスのうち今後修正が必要になるところを紹介します。 2022年3月25日開催「UIT Meetup vol.15 『Relearn Modern Web Standard』」 https://uit.connpass.com/event/242359/
ドメイン知識が求められる開発をどのように乗り切るか - freee Developers Hub
こんにちは、freee会計のプロダクトマネージャー（以下PM）をしております、gokiです。 皆さん、「ドメイン知識」という言葉、聞いたことありますか？ ドメイン知識（英: Domain knowledge）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。 ドメイン知識 - Wikipedia freee会計での開発現場で例示すると「確定申告のプロダクトを作るには、開発技術だけでなくそもそも確定申告業務の理解というドメイン知識が必要だよね」みたいな使われ方をします。 freeeはスモールビジネスの皆さんのバックオフィス業務を改善するプロダクトを作っているので、このドメイン知識が開発においても必要な場面が多いです。 そこで、今回はドメイン知識が必要な開発をどのように進めるか、というコツをPM目線でご紹介しようと思いま
多摩ニュータウンの200年を歩く
多摩ニュータウンができて50年以上。総面積約3000ha、計画人口34万人という日本最大のニュータウン計画だったがゆえに、「第四の山の手」から「陸の孤島」「オールドタウン」まで、よくも悪くも世間の注目を浴び続けてきた街だ。 現代の東京に住んでいると当たり前の存在になっているが、「巨大な実験都市」とも言われるように、実は日本史上でも二度とあらわれない、貴重な場所なのかもしれない。 建造物は50年たつと文化財の仲間入りできるというけれど、一方で多摩ニュータウンは生きた街である。東京都は2040年代を見据えた都市計画を立てているらしい。 多摩ニュータウンの過去から未来へ。 これを機に、ニュータウン以前の多摩丘陵の面影、多摩ニュータウン黎明期、バブル～平成の多摩ニュータウン、そして未来の多摩ニュータウンについて…四世代にわけて、実際に歩いてみたい。 多摩ニュータウンのなにがすごいのか 1971年、
なんとなくプレイしてもそこそこ囲碁のルールがわかるようになる「ぷよ碁」
世の中には将棋やチェスなどさまざまなボードゲームがありますが、これらが駒を動かして「王(キング)を取った方の勝ち」であるのに対して、囲碁は石を置いて「多くの陣地を取った方が勝ち」というルールであるため、素人目では盤上で何が起きているのか理解するのが難しいもの。そんな囲碁の詳細なルールを理解していなくても、プレイするだけでなんとなくルールがわかるようになるのが「ぷよ碁」です。初心者が囲碁を楽しみながら理解するにはピッタリなゲームということで、さっそく囲碁初心者がプレイしてみました。 ぷよ碁 - 無料囲碁ブラウザゲーム https://puyogo.app/ 「ぷよ碁」の画面は以下の通り。上部に5×5の盤面が配置されており、その下に白石と黒石の数が表示されています。さらにその下には「パス」と「降参」というボタンが配置されており、文字通りパスと降参が可能。 初期状態だと白石の下に「対 AI」と表
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
RESTful API との比較で GraphQL API を作ることの難しさ｜qsona
上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま
これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
開発速度が速い #とは（LayerX社内資料）
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
プルリクを起点に検証環境が自動で構築されるようにしたら すぐにレビューできるようになったのでみんなハッピーになれた話
こんにちは。CacooチームのYAMLエンジニアの木村（@cohhei）です。「readiness」は「ready」の名詞形で「レディネス」と読むことをわりと最近知りました。今回はプルリクエスト向けに検証環境が構築される仕組みを作ったので紹介します。 忙しい人のためのざっくりとした説明 プルリクエストが作られたら自動で検証環境が構築される仕組みをつくりました。 環境まるごと作るわけではなく、フロントエンドJavaScript配信用のPodだけに対応しています。 レビュアーやテスターはクエリパラメーターが追加されたURLにアクセスするだけでその検証環境にアクセスできます。 プルリクエストをマージする前にそのバージョンを非エンジニアでも試すことができます。 プルリクエストごとに環境が作られるので、複数の開発プロジェクトが同時に走っているときに便利です。 コミットしてプルリクエストを作るだけです
GitHub Actions で簡単にバージョン番号付きリリースとリリースノートを作成する方法
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1: GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
プロダクト開発でドキュメントを書かないとどうなるか
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムと見積り
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
開発組織の持続可能性について
