ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ | 書籍・刊行物 | IPA 独立行政法人 情報処理推進機構
編集・発行元 独立行政法人情報処理推進機構（IPA） 社会基盤センター 発行日 2019年12月20日 サイズ B5変形判 ページ数 498ページ ISBN 978-4-905318-72-9 定価 2,500円（税込） 書籍概要 概要 デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション（DX）」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
Cat as a service (CATAAS)
Is a REST API to spread peace and love (or not) thanks to cats. Have 0 cats for now Give me a cat Hey cat lovers, new major version of cataas : Now JSON will returns if request contain application/json header, API doc updated hereFix tags search and fix tags combined with "," separator (see documentation)
ちゃんと公式ドキュメントで確認するプログラマのリンク集 - Qiita
バグ調査やサポート状況確認するためにオフィシャルなドキュメントで確認することが多いので、公式リンクまとめてみた。 2019/06 最近ちょこちょこ観てる人いるっぽいけど古いままで申し訳ないので更新してみた。自分が参照したやつのメモだったりするので全然網羅してません(｀・ω・´)
システムプログラミング会 - 兼雑記
すごい久々にイベントの(共同)主催的なことをしました http://connpass.com/event/34995/ イメージとしては言語雑談会的な感じで、closedに人集めてウダウダやるつもりだったんですが、途中でPFNさんに場所貸していただけるということで、不特定な人を呼ぶことになって、当初想定してたより大袈裟な会になりました。適当に募集すると人が集まって自己顕示欲が満たされるとか、普段得られない種類のフィードバックが得られたり交流ができる、てのがあるわけですが、めんどくさいのとグダグダ雑談がしにくいのが難点ですね。まあ自分自身が一般的に募集されてる会で勉強した面もあるわけで、そういうのの恩返しになるかもという面もあり、まあ色々。 まとめとしてはkoieさんのブログやtogetterがまとまってそう http://blog.livedoor.jp/hkoie/archives/55
面倒な手続き不要！「Web API」の超お手軽活用術をJavaScriptコード付きで一挙大公開！ - paiza times
どうも、まさとらん（@0310lan）です。 今回は、面倒な登録手続きやトークンなどが一切不要で、今すぐ利用できる便利な「Web API」を厳選してご紹介しようと思います。 これらのAPIを使うことで、Web制作がちょっと便利になったり、独自性のあるユニークなサービスを構築できるようになるでしょう。 また、簡単に扱えることから、「Web APIを使って何か作ってみたい…」と思っている初心者の方にもオススメですよ！ ■「Web API」の使い方！ 今回ご紹介する「API」は、いずれも「JSONP」形式でデータが取得できるので、普通のJavaScriptだけで試すことが出来ます。 以下のコードを、HTMLファイルに記述するか、新規にJSファイルを作って読み込むようにしましょう。 var script = document.createElement('script'); script.src
コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント・エンジニアリング- レガシーコードのメンテナンス担当になったら新人はどうすればいい クソコードに対する怒りとコー
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
Google JavaScript Style Guilde をリビジョン 2.64 にあわせて修正しました - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20121229.html
頑健なJavaプログラムの書き方
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 ＜アレスネットをご契約のお客様へ＞ 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
Google Japan Blog: 日本のデベロッパーの要望に応え、多くの技術ドキュメントを日本語化しました
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
オープンソース開発ツールドキュメントの紹介
テレビでCMをやっているような大手消費者金融ならともかく、 あまり名前を知られていない業者はきちんとした会社なのかどうかわかりづらいですよね。 最近の闇金はツイッターやＦＡＣＥＢＯＯＫなどＳＮＳを使った勧誘が多いです。 電話の対応も良かったから、とよく調べないで借りてしまったら実は闇金だった！ と後から大変なことになります。 借りようとしている業者が闇金なのかどうか調べる方法としては、 「登録貸金業者情報検索入力ページ」というものがあります。 貸金業を営むには、必ず都道府県知事や財務局長への登録が必要になりますので、登録している業者であればこの検索で引っかかってくるはずです。 登録番号、所在地、会社名、代表者名などを入れる欄がありますが、どれかひとつを入力しただけでも該当するものがあれば出てきますので、 業者の商号しかわからないという場合でも検索することができます。 厄介なのは、正規の登録
jQuery 開発者向けメモ
jQuery 開発者向けのメモです． ずっと以前に，jQuery に関する日本語の情報がまだ少ない頃に作ったページですが， その後 jQuery を再び利用する機会があったので，最新バージョン向けに記述を更新しました． 住宅ローンシミュレーションです． jQueryを利用したフォームの動的な追加や，flotプラグインによるグラフ描画などを行っています． 本ページの記載に間違い等見つけた方はブログのエントリまで連絡いただけるとうれしいです． 最終更新：2009/1/10 jQueryとは jQuery は様々な処理を短く簡単に書ける JavaScript ライブラリです． 独自のXPATH/CSSセレクタを利用することで，多くのDOM操作を非常に簡単に書くことが出来ます． JavaScriptのDOM操作や，XMLHTTPRequest，XMLの操作などを覚えなくとも， Ajaxを利用したイ
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミングスキル不要の無料ゲーム制作ツール「GDevelop」の日本語解説サイトが公開／英国Google社のエンジニアFlorian Rival氏が中心となって開発
プログラマが欲しい仕様書とは