要件定義、基本設計、詳細設計の流れを総復習
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
「タスクを切る能力」の本質について。
もうかなり前の話だ。 ある会社で、「会社案内・パンフレットのリニューアルをする」と言うプロジェクトが持ち上がった。 社長は一人の人物をプロジェクトマネジャーとして任命し、予算を付け、 「後はよろしく」 と、仕事をまかせた。 ところが半年後、ようやく社長は気づいた。 全くプロジェクトが進んでいないことに。 「どうなっているのか」とプロジェクトマネジャーを問い詰めたところ、彼は外注に丸投げしたまま、何もしていなかった。 外注側も、仕様が固まらず、プロジェクトは完全にスタックしていた。 社長は彼に話を聞いたが、彼は「外注から返事が無くて」の一点張り。そこで、社長は彼に要求した。「資料を出せ」と。 ところが彼は「出せない」という。 何か隠しているのではないか、おかしいのでは、ということで、皆でメールのやり取りや資料などを調べると、実質、彼が事実上、「外注に依頼をし、あとは本当に何もしていない」こと
「小説家になろう」運営会社、経営体制を刷新 創業者は退任へ
小説投稿プラットフォーム「小説家になろう」を運営する株式会社ヒナプロジェクトが、代表取締役及び取締役の変更を知らせている。 この変更により、2024年2月29日付で代表取締役社長及びヒナプロジェクトの創業メンバーだった梅崎祐輔さんと平井幸さんが退任。 同年3月1日より、新たな代表取締役社長として青山侑矢さん、取締役に塩川和就さんが就任した。 「ユーザーへの収益還元」機能を示唆3月2日、「小説家になろう」は20周年イベントを東京都港区のニューピアホールで実施。新社長も登壇し、催しや発表が関係者やユーザーに対して行われたほか、かねてより待望されていた「ユーザーへの収益還元」が行える機能の実装を示唆。 2023年11月30日には、男性向けR-18イラストサイト「onaco」をリリース。2024年1月16日には「小説家になろう」のコア機能であるランキング機能をリニューアルするなど、大きな動きが続い
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
論文系 高度情報処理試験 合格のコツ - NRIネットコムBlog
こんにちは、上野です。 この記事では、出題形式に論述式が含まれる、以下試験の勉強方法や解き方について解説します。 ITストラテジスト試験 システムアーキテクト試験 プロジェクトマネージャ試験 ITサービスマネージャ試験 システム監査技術者試験 私自身は上記の高度情報処理試験はすべて合格しています。なお、高度情報処理試験すべてで言うとエンベデッドスペシャリストだけ持っていません。社内では同期の小林さんがすべての情報処理試験区分に合格しているため、私は社内でドヤ顔できません。 論文形式の試験ですが、基本的にはどの試験も傾向と対策は似ており、ポイントを掴むとどの試験も取りやすいという特徴があります。「論文なんて難しい・・」と言うイメージのある方も是非本記事を読んでトライしてみてください。午前は簡単に私がやっていた勉強方法を共有します。難しくなってくる午後Ⅰについては解き方を紹介し、論述となる午後
日立製作所「同期SEの2割が、病気休職か治療中」――労務管理システムをハックして改ざん、360度評価は機能せず
戦後のメンバーシップ型雇用を維持する日立では、スキルギャップから成果を出せなくなった中高年社員の雇用を維持するため、若手が余計に働いて稼がなくてはならない。そのなかでも、デキる人に仕事が集中する構造があり、過重労働がはびこりやすい。「仕事が終わらないから、社内の労務管理システムの抜け道を使って、残業時間が増えすぎないよう、改ざんします。具体的には、WindowOSに指示を出して、労務管理システムを停止させます。これは上司から強制されるわけではなく、同期やチームメンバーの間でやり方を教え合うんです。あとは、労務管理の対象外となっている（接続履歴が把握されない）別のパソコンを使って仕事をしたり…」（SE職） Digest 責任感から自滅していくパターン 行動規範SQDCとフェーズゲート QFマインド醸成会議、落穂（おちぼ）拾いの会 週休3日制の現実「有休消化で精いっぱい」 週1日丸ごと副業に費
「なろう系」で有名な日本最大級の小説投稿サイト『小説家になろう』は枚方の会社。中の人にインタビューしてきた - 枚方つーしん
「なろう系」で有名な日本最大級の小説投稿サイト『小説家になろう』は枚方の会社。中の人にインタビューしてきた 俺は平凡な高校2年生。 ある日、道路に飛び出した子どもを助けようとしたところ、トラックに轢かれちまって俺は死んだ。 ……と思ったんだけど。あれ、どこだここ。 え、もしかして…俺って異世界に転生しちゃった！？？ きたる異世界転生の日に備えて修行に励むイメージ図（のガーサン） ……ていう感じの展開のお話、ひとつくらい聞いたことがあるんじゃないでしょうか？ そう、上記のような異世界転生モノをはじめ、「主人公最強系」や「作品名がやたら長い系」などなど、これらの作品を総称し巷で親しみを込めて呼ばれているのが、 いわゆる「なろう系」という創作ジャンル！ 「なろう系」の起源となったのは、日本最大級のWeb小説投稿サイト『小説家になろう』から生まれた作品たち。 異世界での戦いに備えてエネルギーを溜め
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
「プロジェクトマネジメントの基本が全部わかる本」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基本が全部わかる本」 （ @paradisemaker 著）が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
ハードワークで人は成長するか - SaaSベンチャーで働くエンタープライズ部長のブログ
「成長するためにはハードワークは不可欠」。こういう言説は常に世に出ています。そして、それを信じた真面目な若者が「成長」するためにハードワークをこなすという流れ。知っているだけでも10年以上同じサイクルがあるように思います。 思いつくだけでも、サイバーエージェント創業者の藤田晋氏が著書「渋谷ではたらく社長の告白」で月に440時間働いていたという話や、テスラ創業者のイーロンマスク氏が世界を変えるためには最低でも週80時間は働くべきだと主張があったり、成功者がハードワークを乗り越えた話があります。 一方で自分自身の経験を振り返ると、必ずしも労働時間の長さが個人の成長につながったとは思えません。この認知の違いはどこからくるのか。自分自身の経験を振り返ってみたいと思います。 自分自身の労働時間経験 ハードワークだが成長しなかった経験 ワークライフバランスを保ち、成長した経験 成長の定義を「今できない
プロダクトマネージャーの役割と育成、評価
プロダクトマネージャーの育成や、役割などの悩みに対する取り組み方法を記載しています。 1. Product Managerの役割や立ち位置は？ 2. Product Managerをどう育成している？ 3. Product Managerってどう評価したら良い？
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
人月の神話
人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パナソニックコネクトの｢社内ChatGPT｣全社導入。1カ月使い倒して見えてきた成果とは
プロダクトマネジメント組織立ち上げの課題と落とし穴と楽しみ #pmconf2022
