実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
Herokuの代替サービス30選、使ってみた参考記事リンク付き - Qiita
先日Herokuの完全有償化が発表されて以降、蜘蛛の子を散らすようにHerokuからの脱出が図られています。 そんなわけで概ねHerokuの代替となりそうな無料サービスを紹介していきます。 ほとんどの代替サービスは完全無料というわけではなく、機能の少ない無料プランと高機能の有料プランが存在します。 有料化前のHerokuと同じということですね。 各サービスについて、実際に使ってみたという参考記事を貼っておくので、実際の使い勝手等はそちらを参照してください(他力本願） Qiita内に使ってみた記事が見つからなかったサービスは、日本では人気がないのだろうということで選外にしました。 また概要は、各サービスの説明やドキュメントに記載されているものです。 代替サービス一覧 FLy Flyはグローバルなアプリケーション配布プラットフォームです。 Turbokuを使えばHerokuアプリをFly.io
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
個人開発者とCovid-19 Radarプロジェクト - laiso
Endless road | During our roadtrip we turned off the highway… https://www.flickr.com/photos/98063470@N00/326044514 GitHubリポジトリ Covid19Radar に対して起ったことがかなり特殊な状況だったため、開発を追い掛けていた視線からレポートをします。 この記事の著者について 代表作のない個人アプリ開発者(かなしい) Covid-19 Radar Japan の人ではない GAFAMやCode for Japan の人でもない 4/8 Covid-19 Radarを発見する Covid-19 Radarとは、この時点ではシンガポールのTraceTogetherの日本版を目指した個人開発者 廣瀬一海さんのアプリのリポジトリ 4月にContact Tracing技術について
タスク管理を破綻させないためのTips 5選 | Backlogブログ
仕様や画面は現行バージョンと異なる可能性があります。 Backlogの最新版についてはこちらからご確認ください。 突然ですがあなたのチームはタスク管理がうまくできていますか？ チームで仕事をしていく上で発生するタスクを、プロジェクト管理ツールやタスク管理ツールで管理することは一般的になってきています。 ツールを使わない場合と比較して、タスクが見える化され、状態や期限日、担当者が明確になり、「タスク管理ツールなしの働き方には戻れない！」という方も多いのではないかと思います。 一方で、タスク管理ツールを導入してはみたものの、管理が破綻してしまい、導入以前のやり方に戻ってしまったという声もよく聞きます。 タスク管理ツールは「導入すればすべてを自動的に解決してくれる夢のツール」ではありません。チームの構成やツールの目的、管理の状況にあわせて、適切な運用を行う必要があります。 本記事では、「タスク管
米PMIが知識体系の新版「PMBOKガイド 第6版」を発行、アジャイルを取り込む
米PMI（Project Management Institute）は2017年9月6日（米国時間）、プロジェクトマネジメントの知識体系「PMBOK（Project Management Body Of Knowledge）ガイド」の改訂版である第6版を発行した。PMBOKガイドはエンタープライズ分野のシステム開発における事実上の標準。いわばプロマネの“教科書”というべき存在である。 第6版の主な特徴は、アジャイル開発に適用する際に役立つ情報を取り込んだこと。最近のシステム開発プロジェクトにおいて、アジャイル開発の採用が増えていることを考慮した。 このほか、プロジェクトに合わせて各種マネジメント手法をカスタマイズして適用する「テーラリング」に関する考え方や、ビジネスの視点に立ってプロジェクトの「ベネフィット（便益）」をマネジメントするための考え方などを追加した。 英語版と同時に、日本語版の
404 File Not Found ｜ 宇宙科学研究所
404 File Not Found お探しのページもしくはファイルが見つかりませんでした。サイトリニューアルにともない、移動したか削除された可能性があります。 トップページ、もしくはサイトマップ等からご覧になりたいページをお探しください。
IPA、企業のITモダナイズを支援する「システム再構築を成功に導くユーザガイド」を公開
IPA、企業のITモダナイズを支援する「システム再構築を成功に導くユーザガイド」を公開：開発会社と正しく意思疎通を図るための「要件定義ガイド」も用意 IPAのソフトウェア高信頼化センターが、ITシステム再構築における課題解決を支援する「ガイドブック」を公開。システムの再構築／モダナイズで必要となる、「企画と計画の工程で留意すべきポイント」などを提言している。 情報処理推進機構（IPA）のソフトウェア高信頼化センター（SEC）は2017年1月31日、システム開発時の課題となる「上流工程の作業不備に起因した手戻り」の解決を支援するガイドブック「システム再構築を成功に導くユーザガイド」と「ユーザのための要件定義ガイド」を公開した。 「システム再構築を成功に導くユーザガイド」は、企業が現在運用するシステムを再構築する際に、「システム開発会社と正しく意思疎通する方法」や「どのように最適な手法を選択す
工数見積もりやスケジュール管理で参考になる記事10選
プロジェクトを遂行するためには、工数の見積もりやスケジュール管理が必要になります。正確な見積もりは難しく納期に間に合わなかったり、残業や休日出勤で埋め合わせたりした経験はありませんか？ 今回は、より正確に工数の見積もるための手法や、差し込み作業を考慮したスケジュール手法などについて解説されている記事をまとめました。 マネージャー、エンジニア、デザイナーなどすべての方に参考なる内容だと思います。 開発の見積もりとスケジュール管理 クックパッド株式会社の方が実践している見積もりとスケジュール管理方法について紹介されています。工数を見積もるステップや、スケジュールを立てるときの注意点、スケジュール管理の方法について学びたい方におすすめの記事です。 開発の見積もりとスケジュール管理 不安とストレスから解放される見積りとスケジュール方法 開発をしているとき、納期に間に合わなかったらどうしようと不安に
Javaで業務系システムを開発するときの鉄板構成(2015年12月版) - Qiita
はじめに Javaにはたくさんのフレームワークやライブラリがあります。 新規のプロジェクトでは何を採用するか検討する必要がありますが、最近Javaを始めた人や長い間レガシーなシステムをやっていて新しい技術に触れる機会がなかった人にとっては、たくさんの候補の中から選択していくのは大変なのではないでしょうか。 そこで、大部分のプロジェクトで無難に対応できるような鉄板ともいえる構成をまとめてみました。 想定システム 業務系システムと呼ばれるもの。金融系、人事系など、比較的お堅い感じのシステム メンバーが複数人で中規模以上のプロジェクト Webアプリ＋バックエンドのバッチ 対象外 比較的カジュアルなWebサイト(そういうサイトでJavaを採用する事自体少ないですし) メンバーが一人で個人の趣味でプロダクトを自由気ままに選択できるようなプロジェクト Androidアプリ デスクトップアプリ 自分が鉄
EclipseのGradleプロジェクト作成方法比較 - Qiita
概要 EclipseでGradleのJavaプロジェクトを使う場合、プロジェクトを作成する方法がいくつかあります。各方法の違いが知りたかったので調査してみました。 プロジェクトの作り方を大別すると、コンソールからgradleコマンドで作成する方法と、Eclipseにプラグインを入れてメニューから作る方法に分かれるかと思います。さらに、Eclipseのプラグインは何種類かあるようなので、メジャーそうなのをためしています。 方法１：コンソールからgradleコマンドでプロジェクトを作成 方法２：Gradle IDE Packプラグインで、Eclipse上からプロジェクトを作成 方法３：Gradle (STS) Integration for Eclipseプラグインで、Eclipse上からプロジェクトを作成 方法４：Eclipse公式のBuildshipプラグインで、Eclipse上からプロジ
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
Gradleでマルチプロジェクト - PukiWiki
FrontPage Javaでアプリケーションを作成する場合、ひとつのアプリケーションを 複数のプロジェクトから構成する場合もよくある。 Gradleでは、どのようにして複数プロジェクトのビルドを行うことが出来るのか、 以下に記述する。 マルチプロジェクトビルドの例 † 以下のようなプロジェクト構成で、ビルドを行えるようにする。 gradle-multi │ ├─app └─common gradle-multiが親プロジェクトで、その下位プロジェクトのappがcommonへ依存するとというよくある形である。 ↑ settings.gradleの定義 † 親プロジェクト直下にsettings.gradleを定義する。 以下のように記述する。 include 'common', 'app' これでサブプロジェクトを認識するらしい。 以下でもOK。 include ':common', ':a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
J-Quants API
主体性を失わせるアンチパターンをやってしまっていた話 | ドクセル