並び順

ブックマーク数

期間指定

  • から
  • まで

201 - 240 件 / 989件

新着順 人気順

仕様書の検索結果201 - 240 件 / 989件

  • RDFカレンダー -- iCalendarとRSSによるイベント情報の公開と活用

    イベントや会議の開催日や場所などがメタデータとして公開されると、情報の検索や共有・連動が大きく進みます。iCalendarのような広く使われるカレンダー・フォーマットとRDF/RSSを結びつければ、公開イベント情報が様々な形で利用できるだけでなく、これらをそのままPIMツール取り込むことも可能です。この延長線上には、レストランや病院検索といったセマンティック・ウェブの紹介でお馴染みの応用も視野に入ってきます。 This page is an introduction to RDF version of iCalendar. Most parts are written in Japanese, but you'll find a short summary at the beginning of each section. イベント情報とカレンダー iCalendarの基本構造と語彙 iC

    • プロジェクト管理者の道具箱

      「情報戦略の立案」のページを更新しました。 「調査の方法」のページを更新しました。 「システム化全体計画の策定」のページを更新しました。 「個別システム開発計画の策定」のページを更新しました。 「プロジェクト計画」のページを更新しました。 「スコープ定義」のページを更新しました。 「進捗計画」のページを更新しました。 「費用計画」のページを更新しました。 「組織計画」のページを更新しました。 「PMO (Project Management Office)」のページを更新しました。 「外注計画」のページを更新しました。 「品質計画」のページを更新しました。

      • Eテキスト「レポートの書き方」

        • System Requirements Specifications

          システム要求仕様書の書き方 IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより Table of Contents (目次) 1. Introduction (はじめに) SRSの「はじめに」では、SRS全体の概要を書く。 1.1. Purpose (目的) この小節では SRSの目的を描写する SRSが意図する聴衆を指定する 1.2. Scope (範囲) この小節では これから作るソフトウェア成果物に名前を付ける このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする 1.3. Def

          • 設計書仕様書テンプレート PocketDOC | 株式会社イーイノベーション

            弊社サービスをご利用頂き、誠に有り難うございます。 ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました! 今度ともご愛顧の程よろしくお願いいたします。 PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、 議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの ドキュメントやテンプレートも提供しています。 実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。 上流工程から下流工程まで広い範囲をサポートしているので、 必要なテンプレートだけをダウンロードして利用することも可能です。 ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。 ダウンロード後、すぐにお使いいただけるように

            • https://twitter.com/developer_quant/status/1551910433858400256

                https://twitter.com/developer_quant/status/1551910433858400256
              • iCalendar仕様

                iCalendar 仕様 iCalendar コンテンツの作成にとりあえず役立ちそうな情報の抜書き。(正確な仕様は RFC にあたること) 目次 仕様書 全般 構造 詳細 BEGIN, END VCALENDAR VTIMEZONE VALARM VEVENT テンプレート 実装 仕様書 iCalendar は RFC で定義されている。 RFC2445 (November 1998) Internet Calendaring and Scheduling Core Object Specification (iCalendar) RFC2446 (November 1998) iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Jo

                • Twitter API 仕様書 @tsupo いいえ、ケフィアです。

                  • パフォーマンスを改善するには仕様変更が1番はやい

                    PHPerKaigi 2024の登壇資料です。

                      パフォーマンスを改善するには仕様変更が1番はやい
                    • Filesystem Hierarchy Standard

                      Introduction This page is the home of the Filesystem Hierarchy Standard (FHS). The current version is 2.3. It was announced on January 29, 2004. The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and is not a tutorial on how to manage a Unix filesystem or directory hi

                      • Your Web, documented. · WebPlatform.org

                        Notice: The WebPlatform project, supported by various stewards between 2012 and 2015, has been discontinued. This site is now available on github. New documentation can be found at MDN Web Docs. Your Web, Documented. The latest information on how to use the technology that runs the web — HTML, CSS, JavaScript and more. WebPlatform.org is a work in progress. We could use your help in making it bett

                        • Web サイト制作時の参考文献リスト

                          完全に自分用メモ代わりですが、Web サイト制作時に参考にする機会の多いドキュメントをまとめてみました。とりあえずは仕様書関連のみ。 英語で書かれたドキュメントばかりを並べてもなんなので、参考までに日本語訳されたドキュメントも私が知っている範囲内で併記してみました。ただし、日本語訳は完全に原文との整合性を保障するものではありませんので、あくまで参考までにご利用ください。 HTML 関連 HTML 4.01 Specification -W3C Recommendation (日本語訳) ISO/IEC 15445:2000(E) ISO-HTML (日本工業規格 JIS X 4156:2000) ISO-HTML: Entities, element types and attributes (DTD) W3C から勧告されている、HTML 4.01 の仕様書に関しては現状、(X)HTML

                            Web サイト制作時の参考文献リスト
                          • パワポで極める1枚企画書

                            竹島愼一郎 著 PowerPoint2002、PowerPoint2003に完全対応 本体価格 1,800円/A5版, 224ページ(うち4色カラー192ページ) ISBN 4-7561-4753-4 発行 アスキー・メディアワークス 「企画書は一枚で」という一枚企画書のニーズに応える待望の1冊の登場です。さまざまなケースに対応した、ビジュアル性豊かな「1枚企画書」例を本文に100点掲載! この100点を含め、付録にはスピード企画&プレゼンに役立つ600例の企画書パターン(テンプレート)を収録! それらすべてを本ページよりダウンロードできます。 詳細目次 サンプルPDFをご覧いただけます 読者アンケート 本誌付録に収録した「600例の企画書パターン」をダウンロードして、ご利用いただけます、以下をお読みの上、お使いの環境に応じて必要なファイルをダウンロードしてください。なお、くわしい使い方は

                            • SPDY Protocol - Draft 3 日本語訳

                              この文書は「SPDY Protocol - Draft 3」の日本語訳です。 原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。 この日本語訳は参考情報であり、正式な文書ではないことに注意してください。また、翻訳において生じた誤りが含まれる可能性があるため、必ず原文もあわせて参照することを推奨します。 公開日: 2013-02-11 更新日: 2013-08-21 翻訳者: Moto Ishizawa <[email protected]> 翻訳協力: Shigeki Ohtsu 1. 概要 HTTP 実装のボトルネックの1つに、並列処理のために複数コネクションを必要とすることがあります。これは、接続確立のために追加で発生するラウンドトリップや、スロースタートによる遅延、そして1つのサーバーに対して複数の接続をおこなうことを避けるためのクライアントによるコネクシ

                              • OpenID

                                Our mission is to lead the global community in creating identity standards that are secure, interoperable and privacy-preserving. Founded in 2007, the OpenID Foundation (OIDF) is a global open standards body committed to helping people assert their identity wherever they choose. We are global vibrant community where identity peers and thought leaders convene to craft the identity ecosystems of tom

                                  OpenID
                                • RSpec: Overview

                                  Take very small stepsDon’t rush ahead with more code. Instead, add another example and let it guide you to what you have to do next. And don’t forget to take time to refactor your code before it gets messy. You should keep your code clean at every step of the way. View Documentation The BookEffective Testing with RSpec 3: Build Ruby Apps with ConfidenceThis definitive guide from RSpec’s lead devel

                                    RSpec: Overview
                                  • ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門

                                    ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門:プロジェクト成功確率向上の近道とは?(1)(1/2 ページ) ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ

                                      ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
                                    • ウェブの仕様は今どこにあるのか?

                                      Webの仕様 ウェブの仕様といえば、W3CやWHATWG、IETFとかが思い浮かぶかもしれません。 これらの仕様が最近ではメーリングリストやIRCといった旧来のところだけではなく、GitHub上で議論されて策定が進められている事が増えています。(両方使ってるという話) この記事はそのような方法で進められてる仕様等についての紹介です。 * 自分自身はそこまで仕様に対して強い興味があるわけではないので、もっと詳しい方が正しくまとめて頂きたいです。。 最初にMove The Web Forward | Guide to getting involved with standards and browser developmentを見ておくといいかもしれません。 JavaScriptの仕様 この動きが多く見られるのがJavaScript(ECMAScriptやDOM APIを含む)周りの仕様につい

                                        ウェブの仕様は今どこにあるのか?
                                      • プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ

                                        人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。

                                          プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
                                        • 発注者ビューガイドライン - 情報処理推進機構:ソフトウェアエンジニアリング

                                          要求・アーキテクチャ領域「機能要件の合意形成技法WG」の検討成果の前身となる発注者ビューガイドラインを公開します。 機能要件の合意形成技法WGでは、2006年から2007年にかけて活動が行われた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」(以下、「発注者ビュー検討会」といいます)の検討成果物である「発注者ビューガイドライン」をベースに検討活動を行います。 WGの本格活動に伴い、IPAでは発注者ビュー検討会の参加企業9社(株式会社NTTデータ、富士通株式会社、日本電気株式会社、株式会社日立製作所、東芝ソリューション株式会社、株式会社構造計画研究所、日本ユニシス株式会社、沖電気工業株式会社、TIS株式会社)から発注者ビューガイドラインの譲渡を受けましたので、それを公開します。 ※なお、発注者ビューガイドラインは改訂を行い、機能要件の合意形成ガイドとして2010年3月に公開しました。

                                          • テンプレートから学ぶ 受注する開発者のためのテスト仕様書

                                            1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう(図1)。 お客様(発注者)はプロジェクトを起案する際、何を作るかを「

                                              テンプレートから学ぶ 受注する開発者のためのテスト仕様書
                                            • Linux問題解決支援サービス

                                              変化はビジネスや業界に限定されません。 変化は世界中で、毎日のあらゆる瞬間に起こっています。 企業のリーダーにとって、意思決定はかつてないほど複雑になっています。競争して勝つには、機会に焦点を当て、ポジティブな変化を迅速に実行できる経験とスキルを備えた信頼できるパートナー、つまり市場で常に先を行く自信を持った意思決定を可能にするパートナーが必要です。 IBM は、ハイブリッド クラウドと AI 戦略を推進するために、Adobe Workfront コンサルティング部門と資産を Rego Consulting Corporation から買収する計画を発表しました。

                                                Linux問題解決支援サービス
                                              • 残業を減らすには、「最終完成物の摺り合わせ」のルーチン化から - モチベーションは楽しさ創造から

                                                ある飲食店チェーンの会議での話。 そのクライアントは、現在、システム導入に向けての最終段階に入っています。 会議では、ベンダーさんがマニュアルを作ってきており、その確認作業をしていました。 マニュアルは完成型で納入されてはいたのですが、それを見て、クライアントの担当者の一人がベンダーさんに向けて、注文をつけ始めました。 貰ったマニュアルをベースに、チェーン店別、パート、社員、店長用という形で社内で再マニュアル化をする必要がある その為には、再マニュアル化がしやすい形でのマニュアルの納入してくれないか?(マニュアルのレイアウト、マニュアルの構成等) また、エクセルでマニュアルを作ってあるのだが、再マニュアル化をしていく為には、ワードでの納品が望ましいという要望が出てきたのです。 「再マニュアル化」の話は、何度も行っていたのですが、 ・マニュアルの完成イメージ(レイアウト、アウトライン構成、、

                                                  残業を減らすには、「最終完成物の摺り合わせ」のルーチン化から - モチベーションは楽しさ創造から
                                                • ただし、チンポに摩擦はないものとする

                                                  先週給湯室で後輩がビールを捨ててい.. トラックバック(18) ネットde真実に目覚めた トラックバック(4) わたしは峯田和伸さんのファン トラックバック(3) 最近の森博嗣先生 トラックバック(1) 室内で帽子はとるものだろうか トラックバック(16) 件のブログを一通り読んでみて感じた.. トラックバック(2) デブって特権階級なの? トラックバック(7) 魔法のある世界で火薬を発明する馬鹿.. トラックバック(2) 過去の人気エントリをもっと見る

                                                  • 36歳のオッサンの取扱説明書 - ココロ社

                                                    こんにちは。取説ブームと聞いて飛んできました。 「ココロ社の取説読みたい」の声が殺到しているようです。また、わたくしとセックスしたいという女性が急増中と聞いていますが(幻聴もここまでくればアート)、もしものときにそなえて、ぼくの取説をつけておくので、わたくしと一戦交える前に熟読していただけるとWin-Winの関係になれるのではないかと思います。 シャワーを浴びたいなら浴びてください なし崩し的に始まった場合、シャワーを浴びるタイミングを失ったりしますが、こちらとしては問題ないです。もし「洗ってないマンマンちゃんを舐められるのははずかP」というのであれば、シャワーを浴びてくださって結構ですが、多少臭くてもこちらは気にしません。主にあなたの問題。 前戯がものすごく長いので、早く突いてほしい人は申告してください 当方、フェミニストでありますがゆえ、前戯が驚くほど丁寧です。自分本位の男としか交わっ

                                                      36歳のオッサンの取扱説明書 - ココロ社
                                                    • [ウェブサービスレビュー]ガントチャートを共有できる「みんなでガント.com」

                                                      内容:「みんなでガント.com」は、オンラインでガントチャートを作成、共有できるサービスだ。プロジェクトの細かいタスクごとに開始日と終了日を設定でき、それぞれについて担当者や進捗率を記入できるので、個人はもちろん、複数メンバーでのプロジェクト管理に重宝する。 「みんなでガント.com」は、オンラインでガントチャートを作成、共有できるサービスだ。プロジェクトの細かいタスクごとに開始日と終了日を設定してガントチャートを表示し、進捗率の記入などを行うことができる。個人はもちろん、複数メンバーでのプロジェクト管理にもってこいのサービスだ。 トップページの「ガントチャートを作成」ボタンを押すと、新しくガントチャートを作成するための初期設定画面が表示される。記入が必要な項目は、パスワードと初期年月の2つのみ。これらを入力して「表を作成」をクリックすると、Excelのワークシートに似た新しいガントチャー

                                                        [ウェブサービスレビュー]ガントチャートを共有できる「みんなでガント.com」
                                                      • Final: OpenID Authentication 2.0 - 最終版

                                                        Abstract OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。 OpenID は、分散方式であり、RP や OpenID プロバイダ (OpenID Provider 、以下 OP) の承認・登録を行なう中央集権的な機関は存在しない。エンドユーザは利用する OP を自由に選択することができ、OP を変更しても自身の識別子をそのまま継続して利用することができる。 プロトコル自体は JavaScript や最新ブラウザを必要としないが、AJAX を利用しても認証 (authentication) の仕組みは上手く機能する。つまり、エンドユーザは

                                                        • ibmURL(変更不可)

                                                          Noch keine Debug-Daten vorhanden Einen Moment bitte

                                                          • 日本規格協会 JSA GROUP Webdesk

                                                            ★商品の発送に関するお知らせ★ 2024/03/04 平素より当協会のJSA Webdeskをご利用いただき有難うございます。 3月29日(金)に実施いたします棚卸に伴い、3月27日(水)午後以降にご注文いただきました商品は、4月1日(月)以降に順次発送いたします。 ※ダウンロード商品は除きます。 お客様にはご迷惑をおかけいたしますが予めご了承願います。 ★閉店時間に関するお知らせ★ 2024/03/04 3月29日(金)に実施いたします棚卸に伴い、当日のライブラリ・販売所(三田MTビル1階)の営業時間を12:00までとさせていただきます。 お客様にはご迷惑をおかけいたしますが予めご了承願います。 工業標準化法改正に伴うJIS規格名称変更のお知らせ(2020年6月22日更新) 2020/06/22 2020年6月吉日 お 客 様 各 位 日本規格協会グループ 出版情報ユニット 工業標準化法

                                                              日本規格協会 JSA GROUP Webdesk
                                                            • [PDF]奈良先端科学技術大学院大学学術リポジトリ(NAISTAR)の構築について

                                                              受講の申し込み方法は、各研修のページをご参照ください。 NII教育研修事業のお申し込みの一部で「研修申込システム」を利用し、インターネット上から行っていただいております。申込から受講までの詳しい流れは「申込から受講まで」ページ、利用の詳細は、「研修申込システム利用手順」ページをご覧ください。

                                                              • わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク

                                                                IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は,HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても,ドキュメントよりは実際の画面で確認した方が分かりやすいので,手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ!ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要

                                                                  わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
                                                                • CSSデザインのページを作る際のスタイルガイド:phpspot開発日誌

                                                                  Drinking Rockstars and Programming Creating a Style-Guide for your site One thing you'll realize after you do alot of front-end work is that after you don't work with the CSS and HTML for a few days, you'll forget the classes that you defined and end up writing alot of similar CSS styles.サイトをCSSで綺麗に作っても、時間が経つとそれぞれのidやclass定義について忘れてしまいます。 時間が経ってからデザインを修正する場合、CSSの見直しや、実際の見栄えについて確認するのに手間取ってしまいます。 そこで

                                                                  • HTMLの基本構造 - 仕様書に見るHTML(1)

                                                                    3.3 属性リスト宣言と実体宣言 また、DTDでは要素タイプがどんな属性を持つのかも定義します。属性は、<!ATTLIST で始まる宣言文で、属性名、属性値のタイプ、省略時の扱いについて定義します。 さらにDTDでは、さまざまな名前や値の別名を定義しておき、個々の宣言ではこの別名を使うのが普通です。この別名の定義を実体宣言といい、<!ENTITY で始まる宣言で定義しています。 仕様書の3.3ではこれらについても詳しく説明されています。それほど複雑ではないので、できればひととおり目を通して、DTDの読み方を身につけておきましょう。 4 HTML文書の構造 では、HTML4の仕様書のさまざまな要素タイプの定義の中から、注目しておきたい部分を拾い読みしていきます。HTMLを書くときに、「ここはどうなっているんだろう」と疑問に思うような点の多くは、実は仕様書できちんと解説されているものなのです。

                                                                    • clearは「floatの解除」ではない:てんぽ

                                                                      コメント(1件) -:承認待ちコメント このコメントは管理者の承認待ちです 2013年02月20日(水)13:47:58 コメントの投稿 名前 件名 メール URL コメント コメントを編集・削除するにはパスワードの入力が必要です。 編集・削除用パスワード 非公開コメント 管理者にだけ表示を許可する トラックバック(3件) http://mb.blog7.fc2.com/tb.php/62-551cfb2b floatとclearの関係 昨日、「mixi」のコミュニティで見つけたサイト。 clearは「floatの解... 2006年03月27日(月)16:57:24 from ddy-w::blog フロート解除と上マージンは一緒に指定しない! フロート解除を指定した要素に、上マージンを指定しても、 上マージンが利かない(;´Д`)ノ。 -------------------------

                                                                      • 単体テスト計画書 (1) ― 表紙・目次・第1部・第1章

                                                                        CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

                                                                          単体テスト計画書 (1) ― 表紙・目次・第1部・第1章
                                                                        • CSS Nite Vol.7: Web制作現場の対立を解消する! XHTML CSSガイドライン作り [1]

                                                                          このスライドは誰でもアクセスできます スライドのURL http://www.cybergarden.net/cssnite07/ スライドシステム (モダンブラウザ向け) W3C® HTML Slidy (XHTML+CSS+JavaScript) 自己紹介 (1) 益子 貴寛 (Takahiro Mashiko) サイバーガーデン代表。Webプロデューサー。 大学院在学中の1999年5月に「CYBER@GARDEN」を立ち上げる。一般企業に勤務後、2003年5月に独立。 自己紹介 (2) 著書 『Web標準の教科書─XHTMLとCSSで作る“正しい”Webサイト』 『伝わるWeb文章デザイン100の鉄則』 『XHTML+CSSスタートアップガイド (仮)』 が毎日コミュニケーションズから7月出版予定 (現在、執筆中) 矢野りんさんとの共著がMdNから出版予定 (現在、執筆中)

                                                                          • 綺麗なだけじゃ意味がない!ディレクターが見落としがちな仕様書作成の4ポイント : LINE Corporation ディレクターブログ

                                                                            こんにちは。ウェブサービス本部の河野です。 ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。 そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。 1.ドキュメントを作ることが目的とならないようにする 当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。 きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョ

                                                                              綺麗なだけじゃ意味がない!ディレクターが見落としがちな仕様書作成の4ポイント : LINE Corporation ディレクターブログ
                                                                            • はてな:日本のIT・WEB制作業の人材確保裏事情 - カレーなる辛口Javaな転職日記

                                                                              http://q.hatena.ne.jp/1184913023 こっちは「こちら側」の話. 私はIT・WEB制作業に関する会社で人事をしております。 A:私も数年人事をしておりますから、面接時の受け答えや実績・履歴内容で判断しております。 まず人事の人間が技術者の面接をする.これがダメなIT企業の特徴です.*1 特に「面接時の受け答え」なんてのは,どーでもいい話です.履歴書もほとんど参考になりません.*2そんなものでしか判断できない人間を外して,現場の技術者に面接させましょう. なぜ、IT業界だけモラル低下がひどいのかよく理由がわかりません。 あんたみたいな『無能な』人事担当者がいるからでしょう. 一般的な制作料金(外注依頼費・給与)を計上しているつもりですし、(中略) 他の同業他社に聞くと、どこも同じような人材トラブルに見舞われているようです。 技術者が質・量共に,圧倒的に不足した結果

                                                                                はてな:日本のIT・WEB制作業の人材確保裏事情 - カレーなる辛口Javaな転職日記
                                                                              • OSS開発wikiツールのGROWI | 快適な情報共有を、全ての人へ

                                                                                無料で使える 高機能なwikiツール マニュアルや企画書の共有、議事録の同時編集など、 チーム内での快適な情報共有と作業効率化を支えるツールです。 GROWIを始める

                                                                                  OSS開発wikiツールのGROWI | 快適な情報共有を、全ての人へ
                                                                                • The Google Maps Javascript API V3 - Google Maps JavaScript API V3 - Google Code

                                                                                  How Do I Start? Read the Developer's Guide. Follow the Tutorial. Consult the Reference. Join the announcements group to receive important updates. Featured Video Watch other Maps API presentations V3: The Solution for Maps Applications for both the Desktop and Mobile Devices Note: The Google Maps Javascript API Version 3 documented within these pages is now the official Javascript API. Version 2