自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
IIS 5.1のインストール-FAXサーバーソフト WebSTARFAX-メガソフト
■インストール前の準備を行う Windows XPのインストールCDを用意します（後で必要になります）。 Administrators権限をもつユーザー（コンピュータの管理者）でログオンします。 ■IIS 5.1をインストールする Windowsの［スタート］メニューから［コントロールパネル］を選択します。 ［プログラムの追加と削除］をクリックします。 ［Windowsコンポーネントの追加と削除］をクリックします。 ［インターネット インフォメーション サービス（IIS）］のチェックボックスにチェックを付けて、［詳細］ボタンをクリックします。 ［FrontPage 2000 Server Extensions］のチェックボックスのチェックを外し、［OK］ボタンをクリックします。 ［次へ］ボタンをクリックします。 次の画面が表示されたら、Windows XP のインストールCDをパソコンにセ
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
ソフトウエア仕様書の書き方 | research in MIT
IEEE830で示されている内部仕様書の書き方 1. 仕様書の概要（何を作るのか？） 1.1 目的 ・仕様書の目的を書く ・仕様書を読む開発者を指定する 1.2 範囲 ・作るソフトウエアに名前を作る ・ソフトウエアはナンであるか説明する ・ソフトウエアを使用しての利点、目的、目標を記述する ・上位レベルの仕様書の記述と矛盾がないようにする（ソフトウエアが大規模、改良などの場合） 1.3 定義、略語、短縮形 ・仕様書を解釈するのに、必要な用語、略語、短縮形の定義を書く。 複数の資料、他のドキュメントを参照する形で提供しても良い。 1.4 参照 ・仕様書のどこで他の資料を参照しているか完全な一覧を書く ・それぞれのドキュメントの題名、レポート番号、日付、出版組織を記述する ・参照ドキュメントの入手元を指定する 1.5 概要 ・仕様書の残りの部分に書かれていることを記述、仕様書の構成を説明する
Webサイト閉鎖のお知らせ
お客様各位 ビジネスコミュニケーションのWebサイトをご利用いただき、ありがとうございます。 開設以来、多くの皆さまにご利用いただきましたが、 「月刊ビジネスコミュニケーション」の休刊に伴い、2024年10月31日を持ちまして、閉鎖させていただきました。 これまでご愛顧賜りました皆さまに、心より感謝申し上げます。 長らくのご愛顧誠にありがとうございました。
パブリックコメント−経済産業省
当省では、情報システムを主に外注により調達しています。この場合、システム開発企業に当方の要求を的確に伝えるための媒体である外注仕様書が非常に重要なものとなります。この調達を適正かつ効率的に行うため、平成１４年度に行った「システム開発仕様書の作成における調査分析」（外注先：株式会社三菱総合研究所）を基に「システム開発に係る外注仕様書作成マニュアル（案）」を作成しました。 本マニュアルは当省の情報システム室が関与するシステム調達に使用することを主な目的としておりますが、今般、本マニュアルを取りまとめるに当たり、広く国民の皆様からの御意見をいただきたく、以下の要領で御意見（パブリックコメント）の募集をいたしますので、忌憚のない御意見をお寄せいただきますようお願い申し上げます。
仕様書の書き方 - CATchy programming
仕様書というと以下の例のように行の先頭に番号が付いているものをよく見かけます。噂によると、「全てに番号を付けろ」などと言う人が昔いたようですが(今でも？)、何故そのようなことが言われたのでしょうか？ 1. 顧客情報をほげほげの条件で検索する。 2. 1. の検索でデータがあった場合。 2.1. データを１件取り出す。 2.2. 2.1. の情報をキーに あばば を検索する。 2.3. 2.2. で検索したデータを出力する。 2.4. データがまだある場合、2.1. に戻る。 3. 1. の検索でデータがなかった場合。 3.1. 「データがありませんでした」と出力する。 4. 終了処理をする。 この章では、このような番号の付いた仕様書のことを、「番号付き仕様書」と呼ぶことにしましょう。番号を付けろと言うのは、例えば上の例で言うと、「1. の検索で...」とか「2.1. に戻る。」と書くときに
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
矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH（クロステック）
今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連
＠IT：XMLデータベース開発方法論（1） 1/4
本連載の目的は、XMLデータベースから可能な限り多くの価値を引き出す指針を示すことである。つまり、本連載で示された指針に沿ってXMLデータベースを扱えば、「ああ、確かに（ほかの技術ではなく）XMLデータベースを採用してよかった」と思っていただけることが筆者たる私の目標ということになる。 それとは別に、本来の意図とはやや異なるもう1つの目標がある。それは、日本におけるXMLデータベースへの期待を盛り上げるムードづくりである。残念ながら、XMLデータベースへの注目度は高いものの、入手可能なソフトウェアの種類は少なく、商用ソフトには目の玉が飛び出るほど高価なものが多い。しかし、値段というものは、利用者が増えれば下がるものである。また、オープンソースなどの非営利プロジェクトであっても、やはり利用者が多ければモチベーションも高まり、より優れたソフトウェアが生まれてくることが期待できる。そのようなムー
やねうらお−よっちゃんイカを買いに行ったついでに家を買う男 - 儲かる会社の作り方教えます(1)
「お盆休みを利用して会社を設立しよう！」という話をさせてもらう。 私が会社を興したときは、会社設立の本を買ってきて読んだだけだった。判子を作るのに2,3日かかったが、判子が到着した次の日には会社が出来ていた。 会社を作ることは難しくない。たぶん資本金と登記費用さえあれば小学生でも出来る。難しいのは、そのあといかに会社を維持していくかだ。今日は、設立までの流れ〜事業計画書について考えてみる。 参考としてid:yoosaki:20050413を見ていただきたい。yoosakiさんは、XAAフレームワークというオープンソースプロジェクトをやっていて、有限会社エクステンションポイント(http://www.extensionpoint.jp/)という会社を経営されている。しかしyoosakiさんは、 実はまだ、事業計画書は書いたことがない。 のだそうだ。実は私も事業計画書なんて書かないし書いたこと
Pythonのグイド・ヴァンロッサム氏へのインタビュー | スラド
dseg 曰く、 "昨年は/.-Jにもインタビューセクションが創設され、本家のインタビュー記事が多数翻訳・掲載された。 その中には、Perlの作者であるラリー・ウォール氏へのインタビューや、Rubyの作者であるまつもとゆきひろ氏へのインタビューも含まれており、 言語の生い立ちから設計者の思想まで興味深く読めたのではないだろうか。 そこで今回は、本家/.の過去ログ倉庫にひっそりと収まっていた、Pythonの作者・Guido van Rossum氏へのインタビューの翻訳記事を、 言語繋がりという事もありお届けしたいと思う。 Pythonは海外での人気が先行したオブジェクト指向スクリプト言語。 キラーアプリケーションのZopeの登場などもあり、近年その普及度・重要度は増すばかりだ。 本家/.での掲載が2001年春の記事であり、内容的に多少賞味期限が過ぎている感は否めないが、 言語の設計思想やPy
本家インタビュー：Perl開発者ラリー・ウォール
yh曰く、"本家インタビューの翻訳シリーズの第4回目は、Perl開発者のラリー・ウォール氏にご登場いただきたいと思います。インタビューは、ちょうど半年前、本家に掲載されたもので、Perl 6にまで通底するその設計思想と哲学、そして、宗教の影響が語られています。 なお、この翻訳は多くの方々の共同作業で実現しました。別に記して感謝申し上げます。"(…) 1) 「スクリプト言語」あるいは「プログラミング言語」としてのPerl Marx_Mrvelousによる 私はPerlを主にスクリプト言語として長いこと使っています。実にほとんど、文字列の抽出とレポート作成に使うのですね。しかしながら、最近のPerlの発達を見ると、Perlは、（「単なる」スクリプト言語としての互換性を維持しつつも）もっともっといろんなことができるようになりそうです。 現在、Perlがどんな風に使われているとお考えですか？ 大部
本家インタビュー：リチャード・Ｍ・ストールマン | スラド
yh 曰く、 "近々来日予定のリチャード・Ｍ・ストールマン(RMS)だが、かつて本家Slashdot.orgのインタビューに答えている。 質問の素材になっている事例にはちと古いものもあるが、その答えに表れるRMSの信念は今も変わらない。タレコミ子としては、彼のファンよりも、RMSってよく聞くけど、どういう人？ という人に読んでほしい。では早速、本家掲載の際にリード文に記された警告を収録してはじめたい。" 警告： 以下のインタビューには、成熟したコンセプトと強力なオピニオンが含まれている。ストールマン氏と見解がぶつかってカッカしやすい読者には読むのに適さないかもしれない。 1) 次は何？ by banky ――ちょっとここで、フリー・ソフトウェアがビジネスになってしまうような具合になったと仮定します。どの会社も、ともかく株式価値を維持しようと思い、ソースをオープンにし、ソフトウェアとフリーに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
舛岡富士夫教授「日本発の三次元半導体で歴史を創る」｜【Tech総研】
エンタープライズ：国内代表者に聞くオープンソースの今
https://srad.jp/story/03/03/14/0258247/
http://www.python.jp/Zope/PyLog//1117488444/index_html