網羅的なPRDやDesign Docを書かなくなった - kosui
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか？」 明確化 曖昧な表現を明確にする 例：「うまくできない」→「納期に間に合わない」 論理性チェック A
自チームのエンジニアに System Design Interview をやってみた - pospomeのプログラミング日記
エンジニアのスキルレベルチェックという文脈で System Design Interview が気になっていたので、自チームのエンジニアにやってみた。 System Design Interview とは? どうやって実施したのか? 実際にやってどーだったか? エンジニアとしてのレベル感がそのまま結果として出る傾向にある コミュニケーション能力 得意分野と不得意分野が明確に出る 出題する側も難しい Spannerへの圧倒的な信頼 まとめ System Design Interview とは? ググれば出てくるので説明は割愛します。 どうやって実施したのか? チームメンバーには System Design Interview のことは伏せて、 ミーティング開始時に「System Design Interview をやります」って感じで始めたので、 System Design Intervie
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想
Web制作フリーランス13年目の経験から
補足しました 2019/1/17 4:05 AMhttps://anond.hatelabo.jp/20190117033500 ブコメやトラバに一部お答えしています ※本文ここから↓ https://anond.hatelabo.jp/20190113133500 元増田へのブコメでも指摘されていたが、ひとくちに「フリーランス」といっても業種、業態、経験、実力、性格などによってその態様は異なる。 そこでひとつのケースとして俺がWeb制作業界でフリーランスとして約１３年間やってきた経験と、そこから得られた知見などを書いてみたい。Webデザイナー、Web系プログラマーには参考になるのではないかと思う。 どういう人間か満員電車やだ遅刻癖あるので会社員向いてない 朝に弱い、生活不規則自分に甘い。問題先送りタイプ。眼の前の楽しそうなことに飛びついて（増田執筆とか）やらなければならないことを後回しに
フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと｜Pittan｜note
フロントエンドエンジニアとデザイナーさんは日々協力してプロダクトを作っていく関係にあります。デザイナーさんが作ってくれたものをエンジニアが素早く実現できるよう、いくつかエンジニアから意識してほしいことをまとめました。 なんでこんな話になったのか（前置きなので次の章まで飛ばしてOKです） デザイナーさんから「この画面をこんな風に作ってください」とXDやSketch、PSDなどいろいろな形で渡されることがあると思います。 僕の個人的な意見・経験ですが、いざ実装するぞとなったときに 「あれ…ここってどうしたらいいんだろう？」 と迷って作業のスピードが落ちてしまうことがとてもストレスに感じていました。できればノンストップでいきたいなあと思うわけです。 手が止まるたび、デザイナーさんに「ここってどうしたらいいですか？」と質問するのが何か新しい画面を作るときに必ず発生していました。 「（いつも聞いてる
高齢者に対してパソコンの大先生をした知見を共有したい
70歳過ぎの高齢者にフリーWiFiの接続方法について尋ねられた。 ここはショッピングモールのカフェ、「WiFi接続無料」を売りにしている。 自分も、通信容量節約のためによく使っている。 いつも通りradikoを聴きつつ、増田ブラウジングをしていたら、あるご老人から話しかけられた。 「このへんってWiFiつながるんですか？」 しかし、カフェでいきなりこの質問をされたら大抵の人は戸惑うんじゃないか？ 今オレが、この話の前提とこれから起こることを先に提示したから「この老人はフリーWiFiにつなぎたいんだな」と分かるだろう。 だが、何の前提もなくこの質問をされたら一体何のことかと思うだろう。 （WiFiって、どのWiFi？） （つながるって、電波強度の話？） 先読みエスパーならシチュエーションと文脈から分かるのかもしれない。 人工知能ならフレーム問題で機能停止を起こすところだ。 （ためしにSiri
なぜ製品仕様を合議制で決めてはいけないのか。
プロダクトマネジメントにおいて「製品仕様を合議制（多数決）で決めてはいけない」というルールがあるが、それは何故なのか。そして、だとしたらどのように人の意見を取り入れるのが良いのか、を考えてみた。 なぜ製品仕様を合議制で決めてはいけないのか。合議に参加している人たちは、その問題の責任者ほど制約条件や問題の背景を深く理解をしていないから。合議制や多数決で物事を決めると、必ずその結果に満足している人たちの方が満足していない人たちよりも多くなる。これは素晴らしい手法だ。 しかし、製品開発の目的は社内の人を満足させることではない。正しい製品をつくることだ。製品にとっての正しさとは、「その製品を顧客（市場）が求めていること」であり、これを満たすためには様々な調査や知識が必要だ。 製品仕様のように、問題の複雑さが一定を超えると、知識を持っている人と持っていない人の意見に違いが出始める。世の中（「社内」と
スタートアップのデザイン責任者がやるべきことまとめ｜坪田 朋
最近、相談を受ける事が多いデザインマネージャーの役割を経験をもとに書き出してみました。長いですが、迷った時の辞書代わりに使ってもらえるとありがたいです。 ここでは会社の規模が30名以上、デザイナー5名程度を超えた組織をイメージしてます。ユーザー体験に責任を持つサービスデザイン責任者と組織責任者の話は混同しないほうが良いので、今回は組織責任者にフォーカスしてます。 全体のストーリーはこのスライドで掴めると思いますが、もう少し具体的に実行した事などをリスト化したので参考になればと思います。 デザイン責任者として実行した事まとめデザイン責任者の仕事は何かを学ぶために行動してみた ・実績を上げてる会社へ一週間研修に行かせてもらい、成果をあげてる理由を分析して、100ページ位のレポートを作った。 ・池田さん、土屋さん、深津さんなど有識者に相談して感覚を掴んだ。 ・それらの行動は自分自身の勉強にもなっ
デザインを批評するということ｜pujisi
この記事は2016年6月くらいに書籍「みんなではじめるデザイン批評」を読み、勤務している会社の社内メンバー共有ブログ的なものに綴った私のポエム書評に加筆修正を加え、どの組織にいっても再利用再布教できるように改めてインターネット上に乗っけさせていただいたものの、さらなるnote転載です。2018はnote書くぞ。 デザインを評価することは難しい。 なにが難しいって判断基準を明確にするのが難しい。 でも、意思決定する根拠となる判断基準を明確にしないと、いつまでも難しいままである。さらにはレビューする行為自体、面倒だと煙たがられかねない。デザインとは問題解決なのに、問題になるという本末転倒。 デザインとはなにか。それを評価することとはなんなのか。 「レビュー」と「批評」の違いは一体…！？ そんな悩みを抱える私が書籍「みんなではじめるデザイン批評」を手にとり、読み進めながら、この目の眩むほど崇高な
どういうデザイナーとだと仕事しやすいか - Konifar's ZATSU
デザイナーさんと昼飯を食っていたら急に「どういうデザイナーとだと仕事しやすいですか？」と聞かれ、しばらく考えて色々話したけれどいい感じに伝えられなかったのでここに書き出しておきたい。 先に言っておくと、これはデザイナーさんの良し悪しの話ではなく、あくまで自分の経験的にこういうことを意識してくれていると楽だったなーやりやすかったなーという感想でしかない。人によって仕事のスタイルが違うのは当たり前だし、やり方を強要するつもりはない。ただ、お互いにこういう振る舞いだと仕事しやすいというのを伝え合うのは大事だと思うので、あくまでこういう風に考える開発者もいるんだなぁくらいにとらえてもらうのがいいのかもしれない。 1回目に見せるラフを作るまでがとにかく速い 人に見せる時に、今の完成度やどういう粒度のフィードバックを期待してるかを先に伝えられる 何かフィードバックを受けた時に、なぜ自分がそうしたかを論
「物乞い」の行為をデザインする
Summary*English report here ストリート・ディベートは路上で問題提起をし、世論を硬貨で可視化する職業である。これは、路上での「ものごい」に代わる行為でもあり、尊厳を損なわずにお金を稼ぐことができる誰もが出来る方法である。 路上で暮らすことを余儀なくされた人々が、友好的な会話を通して社会へ対等な立場で再接続する最初のステップとなることを目指している。 ロンドンではストリート・ディベートで１時間に平均13.5ポンドを稼ぎ、12.5人を議論に巻き込むことが明らかになっている。 Why I started designing the act of beggingもしあなたが、ロンドンやパリといったヨーロッパの都市を訪れたなら、道端で「ものごい」を行なう人を見ることは、そう珍しいことではないだろう。
【追記あり】Re: inside 売れないサービスの開発現場から
http://anond.hatelabo.jp/20170509183828 を書いた増田です。 こんなにたくさん反応があると思っていませんでした。 開発に対してモチベーションが保てずに、愚痴まとめてスッキリしようとか、そういう気持ちで殴り書いたものだったので。 本当にありがとうございます。 「俺、こんなんドン・キホーテと一緒やん」みたいな気持ちでやってたことが、少し報われました。 自分発信のものに反応もらえるってこんなに嬉しいんですね。（何しろ二年くらいそういうのないもので。） はてブ、ツイッターでの反応は全部読んでます。ありがとうございます。（二年なかったので許してください。気持ち悪がらないでください。） どうせお前のスキル不足だろ！！！バカが！！！働け！！！死ね！！！みたいなの予想してたので、9割くらいの人に同調されてるのに少しびっくりしています。 と同時に、そんなんやっぱりどっか
【追記あり】inside 売れないサービスの開発現場から
この二年間、ある一つの売れないサービスを開発し続けてきた。 GWに実家に帰ったときに地元の友達に話したら面白がってくれたのでちょっと書いてみようと思う。 今作っているアプリは、売れていない。 二年前に開発が始まって、リリースして一年半ほどになるが、一円も稼いでいない。 エンタメ系snsのはずなんだが、アクティブユーザーが増えるはずの大型連休で、起動したユーザーがたったの三人だった日があるほど、売れていない。 売れてないが故に常駐しているエンジニアは僕一人だ。外部のエンジニアにスポットでたまにタスクベースでお願いする程度。 ディレクターっぽい人が二人（マーケティング兼任）と、デザイナーが一人いて、 この3人と僕とのやりとりを地元の友人は面白がってくれた。 いわゆる「エンジニアあるある」ではあると思う。 例えば新機能の開発が始まったとき、 ーーーーーーーーーーーーーーー ディ「〇〇な機能が欲し
実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
傘を持っていくべきか答えてくれるLINE Botを作ってみて分かったこと - noriaki blog はてな出張所
忙しい人のためのサマリ 「傘を持って行った方が良いか」教えてくれるLINE Botを作ったので、コミュニケーション設計として重要だった3つの考え方を書きました。「入力方法」「返答方法」「名称やキャラクター設定」を考えたら、コミュニケーションプラットフォームでBotサービスを作るときに大切にしたいことが分かりました。 カサいる？ LINEのBOT API Trialを利用して、「カサいる？」というBotを作ってみました。 画像にあるとおり、LINEトークの基礎機能である「位置情報を送信」すると、傘を持っていくべきか（その地点に今雨が降っているか、1時間の間に傘が必要なくらい雨が降るのか）を教えてくれるもの*1です。 よかったら試してみてください。 （LINEアプリ内のQRコードによる友達追加から上の画像を読み取ってみてください） というBotサービス紹介だけでは申し訳ないと思うので、ここでは
【ソースコードの品質向上】デザイナーもコードレビューしよう｜dwango creators' blog（ドワンゴクリエイターズブログ）
ドワンゴデザイナーのマカロフです。 私がドワンゴに入社したのはニコニコ動画のバージョンが原宿の時でした。それからPS4生放送対応等を行ったり、ニコニコ生放送のサービスに携わって来ました。仕事の領域的にグラフィックデザインをするより、エンジニアさんと連携を取りながらコードを書くことが多いです。 そんな背景もありコードレビューの大切さを日々痛感しておりますので、今回はデザイナーの開発環境の紹介としてコードレビューを取り上げたいと思います。 デザイナーもコードレビューをする時代 ドワンゴのデザイナーも世間のデザイナーと同じくimage、HTML、CSS、JavaScript等を日々、編集してコミットしています。 新しいテンプレートエンジンの採用によりHTMLの記述方法が変わったり、自動化したり、コンポーネントなcss設計を考えたり、JavaScriptも日々進化していき新しく採用したフレームワー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
