https://findy.connpass.com/event/318375/ での登壇資料です。
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
プロジェクトマネジメント(PM)の重要性は、あまり認知されていないように見える。 うまく回っているときは「あたりまえ」扱いでスルーされ、いざ暗礁に乗り上げたときに「どうなってるんだ!?」と糾弾の的となる。 プロジェクトをうまく回していくコツというか勘所は確かにあり、相応のトレーニングが必要だ。にもかかわらず、なぜか蔑ろにされている。ろくに訓練もしないまま、「見て学べ」「やって覚えよ」と実践に放り込み、メンタルをやられず生き延びた者が幹部になる。 これは悪手だ。 よく、「失敗から学ぶほうがより身につく」などと唱える輩がいるが、しなくていい失敗は避けたほうがいいに決まってる。そして、この「しなくていい失敗」のほとんどは、基本を押さえるだけで回避できる。 この、PMの基本を押さえているのが本書だ。 『プロジェクトマネジメントの基本が全部わかる本』には、プロジェクトを回していくために「あたりまえ」
IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』(翔泳社)。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章 プロジェクトマネジメントのスキルの全体像」と「第1章 プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載
一部報道にございますように、弊社運営のゲーム『アズールレーン』につきまして、公式番組『アズレンTV』と一部WEB広告コンテンツに、他社の登録商標を誤って文言に記載するという事象が発生しておりました。 関連企業の皆様ならびに、「アズールレーン」のファンの皆様、「艦隊これくしょん」「戦艦少女R」のファンの皆様に多大なご迷惑をおかけしましたことを心よりお詫び申し上げます。 このたびの事態を真摯に受け止め、取り急ぎ今まで使用した全ての広告素材の精査を再度行い、問題素材の差し止め及び差し替えをいたしました。 下記、他社様の登録商標に関する不適切な表記の状況と原因へ対する弊社の対応をご報告申し上げます。 ■不適切表記の状況と対応について 他社の登録商標の不適切な表記の状況と現状及び対応について説明いたします。 ・AbemaTVで放送した『アズレンTV』動画内の不適切表記「艦娘」について 2018年5月
この記事は freee Developers Advent Calendar の17日目です。 自己紹介 freee 株式会社で、PM(Product Manager)をやっているfuji_tipです。 freeeに入ってから4年で、マーケティング/事業開発 —> データ分析 —> 事業戦略 —> PM という変遷で、社内ジョブホッパーです。フルスタック社員と自称しています。 趣味は飲酒です。 PMってなにやってるの 社内外から、PMって何やってるかわからない、どういう能力があればPMになれるのかわからないなどの声をもらうことが多いので、具体的な案件のリリースまでのプロセスを振り返りながら、PMの仕事について理解いただければと思います。 ある機能を作る!とか既存の機能改善をする!となったときの大体の流れを簡単に下記の通り説明します。 課題選定・ゴール設定 それが本当に課題なのか?課題だとし
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括(開発は外部委託) サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク(チケット)運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育(五十六メソッドを採用した) 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー
こんにちは、IT系母ちゃんの平 愛美(id:mana-cat)です。職業は夫婦ともにITエンジニアで、2人の子どもたちと一緒に都内で暮らしています。子ども2人を育てながらの生活には、家庭特有のさまざまな課題が山積みです。そんな課題を解決するため、2年ほど前にプロジェクト管理ツール「Backlog」を家庭に導入しました。導入するに至った経緯と、導入してから生活がどのように変化したのかを紹介します。 ■ プロジェクト管理ツール導入のきっかけ 我が家の家族構成 プロジェクト管理ツール導入前の課題 カレンダー機能だけで課題を解決するのは難しい ■ 家庭にもプロジェクト管理ツールを導入しよう 「Backlog」を選んだ理由 ■ Backlogの使い方 Backlogの登録について (1)無償プランでBacklogを登録する (2)メンバーを追加し、課題を登録する (3) 課題のステータスを変更する
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。>技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) 1年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
アメリカにNeal Whittenという著名なプロジェクト・マネジメントのコンサルタントがいる。何年か前に、ボストンで彼の講演を聴いたことがあった。彼はその中で、プロジェクトが失敗する三つの主な原因を挙げていたのだが、それがずっと頭にひっかかって残っている。彼のいうプロジェクトの三つの失敗理由とは、以下のようなものだ: (1) プロマネのハード・スキル不足 (2) プロマネのソフト・スキル不足 (3) プロジェクト・スポンサーシップの不足 プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く