並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 242件

新着順 人気順

見積の検索結果41 - 80 件 / 242件

  • エンジニアは顧客の要望をちゃんと聞こう 〜「うちの店でカレーを出したい」と言われたら?〜|Katsuma Narisawa

    こんにちは。SALESCOREのCTOの成澤です。 今日は、Webサービス開発に携わる方向けに「要望を正しく聞くのは大事だよ」という話を、飲食店の例え話で紹介します。 「うちの店でカレーを出したい」と言われたら飲食店のオーナーから「うちの店のメニューにカレーを加えたい。カレーを作る体制を整備してほしい」と相談されたとします。 敏腕料理人のあなたは何を考えるでしょうか? 普通に考えたら「野菜と肉とルーを仕入れて、あとは鍋と包丁を用意して…」と考えるでしょう。 カレー作りに知見がある人なら「スパイスから手作りした方が美味しく作れる!スパイスを独自ルートで調達しよう!」なんてことも考えるかもしれません。 しかし、ここであなたがするべきことは、オーナーへの追加ヒアリングです。 どんな店なのか? → 喫茶店かも 店内の調理設備は? → 狭い厨房がちょっとあるだけ。調理器具もほとんどない スタッフの体

      エンジニアは顧客の要望をちゃんと聞こう 〜「うちの店でカレーを出したい」と言われたら?〜|Katsuma Narisawa
    • プログラミングで一番難しいのは「見積もり」だと思う - Qiita

      前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか?」だ。厳しいところだと「何日に納品してくれるのか?」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか? 見

        プログラミングで一番難しいのは「見積もり」だと思う - Qiita
      • 「要件定義」のまえに、「要求定義」|しょーてぃー/ Experience & Prompt Designer

        多くのアクセスがあったので無料化しました 要求定義テンプレも記事内でDLできます。 はじめにはじめましてUX プランナーのShoty(@shoty_k2)です。 今回は「要求定義」をつかった、UX デザインについてご紹介します。 実践用テンプレートも記事内にて配布しておりますので、参考にしてください。 「要求定義」とは要求定義とは、「事業や施策によって実現したいこと」です。ユーザーにどのような状態になって欲しいのか・何をしてほしいのか、ビジネスで何が必要なのかなどを取り決めることです。 要求定義という言葉は、もともとはシステム開発の現場では頻繁に使われている単語で、非技術者の企画者がシステムに求める仕様を定義することです。 「要件定義」と「要求定義」の違い多くの方が「要件定義」という言葉を聞いたことがあるかと思いますが、「要件定義」と「要求定義」の違いについてご存知でしょうか? ★要件定義

          「要件定義」のまえに、「要求定義」|しょーてぃー/ Experience & Prompt Designer
        • ベイジのウェブ制作ワークフロー2021年版(約100のタスクと解説) | knowledge / baigie

          営業、受注、制作、納品、運用と、ウェブ制作の活動は長期に渡り、そのタスクの種類と量は膨大です。だからこそ、基本的なプロセスや使用するドキュメントなどを明確に定義しておかないと、サービスの品質が担当者により大きく変わることになります。 ベイジは社員がまだ5名の頃、各人に委ねた進め方によって以下のようなトラブルが頻発していました。 ミスが発生しても「次から気をつける」と精神論で終わらせてしまう 担当するディレクターやクリエイターによってタスクの抜け漏れが起きる 担当者それぞれが属人的な進め方をしてて品質が安定しない 役割が不明瞭なグレーゾーンのタスクが放置されてしまう 創造的な仕事の時間が、ルーチンや計画にないタスクに奪われてしまう 新しい社員が入る度に同じことを教えないといけない これら問題を解決するため、2014年頃からワークフローを整備するようになりました。ちなみに私が入社したのはこれ以

            ベイジのウェブ制作ワークフロー2021年版(約100のタスクと解説) | knowledge / baigie
          • 画面をデザインするということ - Qiita

            この記事は社内の勉強会で話した内容を再編したものです。 私自身はPC/ブラウザ/スマホのアプリ開発をしている1エンジニアにすぎないのですが、対客や要件定義から開発、運用、そしてUIのデザインを担当しており、自分なりに伝えられるものがないかと試みたものです。 デザインとは デザインとは単に見た目だけの話ではなく、「ビジネス」と「ユーザーが得る体験価値」から始まり、それを実データと結びつけながら人の認知を通してどう見せるのかという作業です。 始まりの部分は最近だとUXデザイナー、終わりの部分はUIデザイナーとかグラフィックデザイナーとか呼ばれるような人の仕事です。そしてそれらを形にするのがエンジニアです。 画面を設計するまでの作業 ギャレットのUX5段階モデルに従って、どういったことを考えないといけないのか確認します。 (実際にUX5段階モデルを意識して仕事してるわけではありませんが、何かしら

              画面をデザインするということ - Qiita
            • その状態のデザイン考えてなかった! UI Stackってナニ|kana

              アプリの画面をデザインする際、エンジニアさんに 「なにも登録データがない場合、どう表示しますか」「選択したときの状態ってどんなデザインですか」などと聞かれて 「ウワア考えてなかったすみません、今作ります。。」 (なんて自分はポンコツなんだ、、ウウウ) と、なりたくないですよね。 UI Stackは👆のような状況を回避するのに便利で大事な考え方だと思ったので、言葉の意味を知らない方はぜひ読んでってください! UI Stack アメリカのプロダクトデザイナー Scott Hurff さんが世に出した 「UIの考慮すべき5つの状態」という考え方です 5つの状態 ・Blank State(空っぽの状態) ・Loading State(ローディング状態) ・Partial State(部分達成状態) ・Error State(エラー状態) ・Ideal State(理想状態) 一つ一つ参考を交えな

                その状態のデザイン考えてなかった! UI Stackってナニ|kana
              • 1億円を投資した、プロダクトリニューアルが失敗に終わった理由|山田修 | Osamu Yamada

                こんにちは。Micoworks代表の山田と申します。 私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。 その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。 2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。 当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。 この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。 そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。 ※テッ

                  1億円を投資した、プロダクトリニューアルが失敗に終わった理由|山田修 | Osamu Yamada
                • 解像度を上げる 🔬

                  2023 年 4 月にアップデートしました。 ビジネスにおいて「解像度が足りない」という言葉が使われるようになりました。この解像度という概念を、深さ、広さ、構造、時間の4つの軸で整理して、それぞれでどうやって解像度を上げれば良いのかについて解説しています。 このスライドを使ったYouTube での解説動画はこちら (2023年4月版) 東京大学 FoundX の各種リソース •FoundX Review - 起業家向けノウハウ情報 •FoundX Resource - 整理された記事の紹介 •FoundX Online School - 30以上の学習ビデオ教材 •FoundX Founders Program - 個室の無償提供とコミュニティ

                    解像度を上げる 🔬
                  • 【重要な追記あり】元ラノベ編集の視点から見たお互いが納得する為のイラスト発注

                    【可視範囲内で見かけたもっともな指摘を受けていくらか補足・訂正】【100ブクマ突破してたのでちょいちょい追記。】 大昔にラノベの編集者をしてた。そのときの経験を書く。 基本的に、イラストレーターさんにとってラノベのイラスト仕事は割に合わない。締切は外道だし、イラストの量も膨大だ。 仮に、ラノベ1冊のイラストを発注するとする。カラーイラストはカバー1枚・口絵3枚(口絵4ページに対して単ページ2枚と見開き1枚)の計4枚、本文中のモノクロ10枚が1セットだろう。カラーイラストに5営業日、モノクロイラスト1枚に1営業日という計算で、最低でも1冊あたり30営業日=1.5ヶ月分の工数を割いてもらうことになる(厳密にはキャラクターデザインの工数も別途計算しなきゃなのだが、意図的に割愛してます)。 【本職の某氏から指摘を受けて気づいたので補足訂正。ここでの「1営業日」は稿料計算の為に出した仮の日数であり、

                      【重要な追記あり】元ラノベ編集の視点から見たお互いが納得する為のイラスト発注
                    • 「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita

                      ※今回はほぼ実話です。 システム開発会社勤務 プログラマーワイ ワイ「さあ、今日も開発をしていこか」 ワイ「とあるWebサービスの管理画面を作らなアカンのや」 ワイ「今日は、どんな機能を作らなアカンのやったかな」 ワイ「せや、クライアントさんからもらった機能一覧.xlsを見てみよか」 ワイ「あとは、デザインデータも見ながら、詳細設計書でも作っていこか」 ワイ「・・・ふーむ、作るべき機能の一覧は書いてあるんやけど」 ワイ「なんか、やる気が出ぇへんなぁ」 ワイ「仕方ないから、社内のSlackで愚痴っとこか」 ワイ「今のプロジェクト、誰のために何を作ってるのかがイマイチ分からんから」 ワイ「モチベーションが上がらへんなぁ」 ワイ「この管理画面を使って、どんな課題を解決したいのか」 ワイ「どういう風にユーザーさんの業務をうまく回したいのか」 ワイ「そんなんがピンと来てないから、作るべきモノもはっき

                        「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita
                      • 見積書の作り方・考え方(僕たちの場合)|岡村 旭 Webディレクター&エンジニア / foot llc.

                        鳥取県鳥取市で主にホームページの制作を行っている合同会社フットでWebディレクター兼エンジニアをしている岡村といいます。 このnoteは先日、各地でWebディレクターをされている方々と「Web制作の見積り」というテーマでZoomを使用した情報交換会を行った際に自身がカンペとしてまとめたものをnote用に加筆修正したものです。 情報交換会の実施後にTwitterで「こんなお話しましたー」とつぶやいたところ、普段あまり「いいね」がつかない僕のアカウントにしては結構反応を頂きました。 情報交換会でも「他の人の見積書の作り方を知る機会がないので新鮮だった!」「発見があった!」という声が挙がり、僕自身も新しい気付きがあったので、こういった情報を共有すると参考になる方がいるかも。ということで、非常にざっくりとしていますがまとめてみました。 タイトルにあるように、あくまでも僕たち(合同会社フット)の場合

                          見積書の作り方・考え方(僕たちの場合)|岡村 旭 Webディレクター&エンジニア / foot llc.
                        • 『はじめよう! 要件定義』(とそのシリーズ)を読んで、はじめよう!UIデザイン|金 成奎

                          『はじめよう! 要件定義 ~ビギナーからベテランまで』はそのタイトル通り、ソフトウェア開発に携わるエンジニアやPM向けに、要件定義の進め方について優しく解説してくれる書籍です。かわいいイラストと平易な文章がとっつきやすく、するすると読めてしまいますが、要件定義って何をどうやったらいいの?とお悩みの方に対して、まずはこれだけやっておくべき基礎知識を得ることができる、とてもわかりやすい内容になっています。 そしてそして、ここからが本noteの主な趣旨ですが、この3部作はデザイナー目線で読み解くと、極めて明瞭で本質的で実践的な、ユーザー体験設計とUI設計の進め方について学べるデザイン教則本と言えるのです。 以下、その理由と、本シリーズを使ってUIデザインを進めていく方法を実例を踏まえて解説していきます。 要件定義とはUI・機能・データを決めることいきなり『はじめよう! 要件定義 』のキモ・コンセ

                            『はじめよう! 要件定義』(とそのシリーズ)を読んで、はじめよう!UIデザイン|金 成奎
                          • Webサイト制作の要件定義書の確認項目|重松佑 / Shhh inc.

                            プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5

                              Webサイト制作の要件定義書の確認項目|重松佑 / Shhh inc.
                            • ソフトウェア開発の見積もりにおける問題点は何ですか?

                              回答 (10件中の1件目) ITプロジェクトの実態とは! - cagylogic とても有名なイラストですが当時(5年ほど前だったかな。。。)大笑いした記憶があります。見積もりにおける問題点にはフォーカスしていませんがそれぞれの立場で捉えた要件内容に違いがある事が原因なのは明らかです。簡単に言えば要件に解釈の余地がある場合ではないでしょうか。そのイマジネーションが膨らんでしまう余地がプロジェクトを良い方向に進めるケースは(希にある)ほぼないと心得て発注すべきだと思います。

                                ソフトウェア開発の見積もりにおける問題点は何ですか?
                              • 「急いで作って!」と言われたとき、私がまずやること→Miroだけでスクラム

                                VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します! ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の2つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード:https://miro.com/ja/online-scrum-agile-tool/ マインドマップ:https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算(100万円)に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 (「4月1日に夢を語る」という PR TIMES の企画だそ

                                  「急いで作って!」と言われたとき、私がまずやること→Miroだけでスクラム
                                • 要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita

                                  はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか?」 明確化 曖昧な表現を明確にする 例:「うまくできない」→「納期に間に合わない」 論理性チェック A

                                    要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
                                  • 本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ

                                    前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳

                                      本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
                                    • スケールする要求を支える仕様の「意図」と「直交性」 - Qiita

                                      はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の

                                        スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
                                      • 完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita

                                        これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ

                                          完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
                                        • スケジュールにバッファを設けるのは悪か? - ユニファ開発者ブログ

                                          こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト(以降「Rプロジェクト」)において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています! 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R

                                            スケジュールにバッファを設けるのは悪か? - ユニファ開発者ブログ
                                          • 某大手企業のプログラマー「これから皆さんがマスターしておくべき言語ってなんだと思いますか?」→その答えがジョークかと思ったけど後にマジだとわかった

                                            卜キワ・クロツグ🎂4/5 @TokiwaKrotzg 某大手企業のプログラマー「これから皆さんがマスターしておくべき言語ってなんだと思いますか?Java!C#!C++!Python!HTML!ハッハッハ惜しいですね~正解は日本語です!」 中学オレ「フッwジョークだろ」 今専門オレ「あれマジだったんだなぁ…」 2021-06-14 11:13:16 卜キワ・クロツグ @TokiwaKrotzg 17歳(7周目)のバーチャル存在です。ガラナとケバブとあくタイプのポケモンが好きです。ししのうさはいいぞ。🤍@oofmi2 Code:Cistus Discord:TokiwaKrotzg#1044 モノリス閉鎖中 📡→@amlgam14 VRC:2018-08-15 vrchat.com/home/user/usr_…

                                              某大手企業のプログラマー「これから皆さんがマスターしておくべき言語ってなんだと思いますか?」→その答えがジョークかと思ったけど後にマジだとわかった
                                            • スケジュールの見積もりを適当に答えたらコミットメントにされる問題について|きゅーい / koyo

                                              こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの?出来なかったらどうするの?」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕

                                                スケジュールの見積もりを適当に答えたらコミットメントにされる問題について|きゅーい / koyo
                                              • みずほ銀行のシステム開発裏話、なんかもう俺らからすると当たり前すぎて、逆に何言ってるか解らなくなるまである→「これはひどい」

                                                𝕏 𝕃(おおきなえる)🌸⚒️ @ellnore_pad_267 雑談垢だよ。 ホロ沼にハマッているよ。 消費税を納税しているよ。 ふぁぼは既読マークだよ。 RTは賛同じゃあないよ。 フォロバはしないよ。 Amazon アフィプログラムに参加してるよ。 ホロ箱推し member of 🌸⚒️🐏🌽🥐 sugaryo-pad.hatenablog.com

                                                  みずほ銀行のシステム開発裏話、なんかもう俺らからすると当たり前すぎて、逆に何言ってるか解らなくなるまである→「これはひどい」
                                                • 実践要件定義入門 - 勘と経験と読経

                                                  最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その2。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ:本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に

                                                    実践要件定義入門 - 勘と経験と読経
                                                  • 見積もりをがんばらない - forest book

                                                    スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この

                                                      見積もりをがんばらない - forest book
                                                    • Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata @takehora もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている。 そして、経産省の契約モデルにあるとおり、要件定義は、準委任契約であるのが妥当。 引用ツイート nori @00oichan · 2022年12月3日 要件定義に関わる人は3億回くらい読んでほしい

                                                        Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata @takehora もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている。 そして、経産省の契約モデルにあるとおり、要件定義は、準委任契約であるのが妥当。 引用ツイート nori @00oichan · 2022年12月3日 要件定義に関わる人は3億回くらい読んでほしい
                                                      • 3つの決めつけから見る失敗の要件定義

                                                        ## 今回発表したイベントについて PeerQuest Inc. ( https://peer-quest.jp/ )様主催の、#開発PM勉強会( https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query )の第7回目のイベント、「要件定義どうしている?共有LT」で発表させていただきました。 株式会社Speee プロダクトマネージャー 塚本尚 https://peer-quest.connpass.com/event/229463/ ## 発表した内容について 結局行き着いたのは、(あるある話だとは思いますが)**whyとwhatの定義をしっかりす定義すること** でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表し

                                                          3つの決めつけから見る失敗の要件定義
                                                        • お金に拘らないプロをどう扱っていくべきなのか問題 - ゆとりずむ

                                                          こんにちは、らくからちゃです。 毎日、製造業のお客様向けの原価管理システムの導入支援やらお問い合わせ対応やらをやらせていただいております。そんなお仕事をしている関係上、原価という単語が耳に入ったら、お耳がダンボになります笑 というわけで、こんな記事を読みました。 blog.tinect.jp いやあ確かにいますねえ。目に見える部分にだけ着目して、「なんでこんなに高いんだ!」って吹き上がるひと。 ライセンス料の決め方 我々のようなIT屋は、お客様からユーザー数ごとに「ライセンス料」という形で、お代を頂戴して飯の種にしております。そうしますと「たくさん売れたんだから安くしろ!」とか「ユーザー数が増えてもコストがかかるわけじゃないのに保守料高すぎだろ!」なーんてお小言は日々頂戴します。 お気持ちは分からんでもありませんがね。それに対して「目に見えないところにもコストがかかっているんです」なんて答

                                                            お金に拘らないプロをどう扱っていくべきなのか問題 - ゆとりずむ
                                                          • 進捗率を何で測るか? −−情報処理技術者試験の問題より | タイム・コンサルタントの日誌から

                                                            「プラント・エンジニアリング会社のように、物理的に目に見えるモノを作っている分野は、数量が測りやすいからいい。ソフトのように目に見えない成果物を作る仕事は、進捗管理がとても難しい。」 ・・こういう意味のことを、IT業界の方から何度か言われたこともある。いえいえ、どういたしまして。プラント・エンジニアリングのプロジェクトでは、設計業務だけで18ヶ月〜24ヶ月もかかる。この間、膨大な図面や仕様書が生成されるが、プラント予定地では1年後にやっと、基礎工事のための穴掘りが始まる程度だ。設計作業の進捗をどう捉えるかは、同じように悩ましい。

                                                              進捗率を何で測るか? −−情報処理技術者試験の問題より | タイム・コンサルタントの日誌から
                                                            • 見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる - Link and Motivation Developers' Blog

                                                              (※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。) はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね?」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ

                                                                見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる - Link and Motivation Developers' Blog
                                                              • 重要情報を扱うシステムの要求策定ガイド | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構

                                                                独立行政法人情報処理推進機構(IPA)は、経済産業省からの要請を受けて、重要情報を扱うシステムにおけるサービスの安定供給にあたって、そのシステムのオーナーである管理者が、必要な対策を策定できる「重要情報を扱うシステムの要求策定ガイド」を公開しました。 概要 通信や電力などをはじめとした重要情報を扱うシステムには、サービスの安定供給が強く求められ、非平常時でも自らの統制力を確保する「自律性」が要求されます。一方で、ビジネス環境や技術環境がめまぐるしく変化する今日では、変化への対応力など「利便性」を備えたクラウドサービスなどへの要求も高まっています。そこでIPAは、重要情報を扱うシステムの構築・調達・運用時に、管理者が「自律性」と「利便性」の双方を両立したシステムの要求仕様を策定できるようガイドを定めました。 本ガイドは管理者が環境の変化を捉え、それに伴う問題・リスクや利便性の要素を整理し、対

                                                                  重要情報を扱うシステムの要求策定ガイド | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
                                                                • 退職した社員のExcelの解析相談され見積もりを出したら「高い。他を当たる」となった企業が出戻ってきた話

                                                                  吉田拳/Excelで、経営は強くなる @sugoi_kaizen 累計50万部突破『たった1日で即戦力になるExcelの教科書』著者/株)すごい改善代表/中央省庁、自治体から大企業、大学、中小企業まで幅広くExcel支援中/DX推進のためのExcelから始めるリスキリング/面倒な作業はExcel丸投げ外注サービスへ/無期限サポート付Excel・VBA講座13年間開催中・受講者1万名超 https://t.co/SueMqGLuYT 吉田拳/Excelで、経営は強くなる @sugoi_kaizen 引き継ぎなく退職された社員が残したExcelが全く分からないとご相談あった企業様、弊社の費用が高いから「他を当たる」となったものの各所で弊社の数倍の見積もりになり「やっぱ御社に」となったが丁重に辞退。死ぬほど大変な作業なんですよ業務理解って。あと言い方で損してる。「他を当たる」ってw 2022-0

                                                                    退職した社員のExcelの解析相談され見積もりを出したら「高い。他を当たる」となった企業が出戻ってきた話
                                                                  • 「AWSって最近すごいらしいね?あれいくらで作れる?1000万くらい?」と聞かれたことがあるけど実際の価格はどれくらい?

                                                                    じゃすてぃ🍖🐈駆け出しVTuber @justy_AA zoomの話じゃないけど、「awsって最近すごいらしいね?あれいくらで作れる?1000万くらい?」と聞かれたことはある 2020-06-09 13:24:57

                                                                      「AWSって最近すごいらしいね?あれいくらで作れる?1000万くらい?」と聞かれたことがあるけど実際の価格はどれくらい?
                                                                    • 300万円でも安い?高騰し続ける「ホームページ制作費」の舞台裏(竹内 謙礼) @moneygendai

                                                                      ホームページ制作、SEO、リスティング広告……今やどんなビジネスでも必須のインターネット対策。どこに、どれくらいお金をかければよいのか、お悩みの人も多いだろう。近年、高騰しているホームページの制作費。『ホームページの値段が「130万円」と言われたんですが、これって相場でしょうか?』の著者、竹内謙礼氏によれば、「300万円」でも安い部類に入るという。一体どこまでお金をかければよいのか、竹内氏にアドバイスをいただいた。 30万円で作れたのは昔の話 ホームページが世に出始めたのが1990年代の後半。そのころは「インターネット」という言葉を知っている人も少なく、ホームページそのものがめずらしい時代だった。 私自身も、当時、ネットにくわしい知人から「近い将来、どの会社もホームページを持たなきゃいけない時代が来るよ」と言われて、「そんなバカな」と笑い飛ばしたことを覚えている。それだけ、インターネットが

                                                                        300万円でも安い?高騰し続ける「ホームページ制作費」の舞台裏(竹内 謙礼) @moneygendai
                                                                      • 見積もりは「イラスト1点10万円」より「ラフ4万円清書6万円」と出来るだけ細分化した方が色々都合がいいぞという話

                                                                        Studio-Takeuma @StudioTakeuma 案件によってはいろいろな事情で一度、精算をしておきたい場合がある。 その時にラフとフィニッシュで分けてあれば、ラフは終えたので、と請求金額を明示しやすい。 ラフ 1点 2万 ラフ 3点 3万 ラフ 1式 4万 とラフの提出点数をクライアントに選択させて誤解を除きやすい。 の2点です。 2022-09-06 17:41:11 Studio-Takeuma @StudioTakeuma あと、広告制作料金基準表によれば、デザイン事務所の見積もりではラフとフィニッシュは同価格か、 差があったとして、 フィニッシュはラフの2倍以内が多かったです。 最終請求価格に対し、 ラフ1 フィニッシュ9 ってことは無かったです。 つまり、見積書でも半々くらいで記すが吉です。 2022-09-06 17:43:56 Studio-Takeuma @St

                                                                          見積もりは「イラスト1点10万円」より「ラフ4万円清書6万円」と出来るだけ細分化した方が色々都合がいいぞという話
                                                                        • エンジニアの言う「技術的には可能です」を正しく認識してもらうために、こう伝えるようにしてる

                                                                          mizchi @mizchi 「技術的には可能です」を正しく認識してもらうために、「他の開発すべて止めて数年間社運を掛けた上で成功率が1割ぐらいです」と伝えるようにしてる 2021-03-03 14:40:46

                                                                            エンジニアの言う「技術的には可能です」を正しく認識してもらうために、こう伝えるようにしてる
                                                                          • システム会社の一台のWebサーバー(Nginx)でのSSL証明書の更新作業の見積もりが20万円でした。ファイルをアップロードして再起動するだけですよね?ぼったくりだと思いますか?

                                                                            回答 (14件中の1件目) ちょいちょいっと自分でできる人です。これまで20回以上作業しています。 その上で適正価格だと思います。 SSL証明書は、ハマりどころが実に豊富です。 1. SSL証明書自体の取得方法がベンダーによってかなり違い、日本の組織の存在証明など奇天烈な方法を要求するものもある。Nginx Apacheなどサーバーによっても変えなくてはならない。 2. 提供された中間証明書をこちらで一つのファイルにまとめなくてはならず、どのようにバンドルするか、ベンダーからの情報だけでは自明ではないものも結構あってハマる 3. SSLのプロトコルは実に余計なものがたくさんありそ...

                                                                              システム会社の一台のWebサーバー(Nginx)でのSSL証明書の更新作業の見積もりが20万円でした。ファイルをアップロードして再起動するだけですよね?ぼったくりだと思いますか?
                                                                            • ヘリウムが注文すらできなくなりました。その結果学生のオフライン実験は急遽禁止。今は見積もりの"予約"を出す状況に

                                                                              クロmium🐈‍⬛ @ztkszero ヘリウム、注文すらできなくなりました。 4月に7m3を3本購入したいと言ったら、納期を5月に変更&2本ならと言われ、それで見積もりをお願いしていたところ、今日になって見積もりもやめさせてくれと。 昨年の6割まで入荷が減ってるそうです。 学生のオフライン実験は急遽中止。 2022-03-30 12:24:01 クロmium🐈‍⬛ @ztkszero 多分、病院のMRIなんかの大口が優先されて、研究用みたいな小口には回ってきていないのだと思う。 ヘリウムを使わなくていい実験をちょっと考えなくては。 かなりまずい状況。 2022-03-30 12:32:11 クロmium🐈‍⬛ @ztkszero 納入数が読めないので、納入され次第順次対応…ということで、完全シャットアウトではないと。 ただ、とにかく確約はできない。 見積もりの”予約”は受け取るが、

                                                                                ヘリウムが注文すらできなくなりました。その結果学生のオフライン実験は急遽禁止。今は見積もりの"予約"を出す状況に
                                                                              • 要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ

                                                                                こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい!」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ

                                                                                  要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
                                                                                • 見積りしないスクラム/No Estimates Scrum JP

                                                                                  Regional Scrum Gathering Tokyo 2020 の資料です。

                                                                                    見積りしないスクラム/No Estimates Scrum JP