ぼくのかんがえた最強の?マネージャ - 言語ゲーム
半年くらい前からソフトウェア業界のマネージャをやってます。 マネージャってどういう仕事かというと、お客さんの言うことを聞いて見積もりを立ててスケジュールを立てて開発者を集めて期限を交渉して終わらせます。コードは書きません。一昔前だと Excel とパワポを駆使するのが仕事でしたが、今は Redmine とか JIRA とか言う Web ツールを使って仕事がどこまで進んだかを確認します。結構これが辛い。 実は僕が前十年ほど前に一度サラリーマンを辞めたのは、マネージャと言う仕事があまりにもくだらなかったからです。プロジェクトをぐいぐいと引っ張って良い製品を作るお仕事が出来ればやりがいがあると思いますが、実態は営業がついた嘘の尻拭いをして誤魔化したり謝るのがお仕事です。なので、今の会社に入ってからも、企画とか、開発リーダーはします。でもマネージャはしません。マネージャはしません。マネージャはしま
ソフトウェア開発プロジェクトの利益率とかリスク率とかのお話 | ぽんぽんぺいんなう＼(^O^)／
最近、来季（４月〜）のお仕事のお見積りの嵐。そこで気になっている話をしてみる。 ソフトウェア開発の依頼を受けた場合のお見積りの流れはこんな感じ。（数字は究極の社外秘なのでてきとーです。） １）まずは純粋に工数見積り 依頼された工程（設計・開発・単体試験・結合試験とか）について、機能毎の難易度などを考慮しながら工数を出す。 今回は１００人月（例えば１０人で１０ヶ月）だったとする。 ２）コストを試算 予定メンバーのコスト（その人の給料や手当や共通配賦（事務所の家賃や間接部門の人達のお給料をみんなで負担する分）などの合計）からプロジェクト全体のコストを試算する。 例えば、全メンバーの平均コストが５０万円／月だったとすると、コストは５０万円×１００ヶ月＝５０００万円。（そのほかの経費などもあるが省略。） ３）リスク率 今回は１００人月と見積もったけど、始めてみたら話が違ったりトラブルがあったりで１
落ち込んだりもしたけれど、IDEは元気です
IDEは高機能なので、落ち込んでいる時に飲む酒の種類で、コードの出来が変わります。次回は「オフショア開発」です。 →他の用語解説も読んでみる ■「IDE」：おすすめ記事・超まとめ IDE（＠IT情報マネジメント用語事典） ソフトウェア開発に用いられるツール類の機能を1つにまとめ、一連の作業を統一されたユーザーインターフェイスから行えるようにしたアプリケーションソフトウェアのこと。一般に、ソースコードエディタやビルダ、デバッガ、GUIビルダなどから成る 理想のコンピュータ×理想のプログラマ（？） 計算機の制御──これこそが、プログラミングの本質だったはずだ。しかし、すべては巨大なブラックボックスと化し「計算機を制御する醍醐味」はどんどん希薄になっている
アラン・ケイ - 「ソフトウェア工学」は矛盾語法か？ [邦訳]
アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と
日本SPIコンソーシアム (JASPIC) - トピックス
●JASPIC 夏のソフトウェアプロセス改善セミナー（JASPIC夏セミ） ソフトウェアプロセス改善に関する講演とチュートリアルをセットにした1日セミナーを、 東京と大阪にて開催します。みなさまの参加を心からお待ちしております。詳細はこちらをご覧下さい。 東京：2009年 6月22日（月）全国情報サービス産業厚生年金基金会館（JJK会館） 大阪：2009年 7月3日（金）エル・おおさか（大阪府立労働センター） ●SPI Japan 2009（ソフトウェアプロセス改善カンファレンス） 開催期間： 2009年10月5日(月)～7日(水) 開催場所： 朱鷺メッセ：新潟コンベンションセンター 発表募集を開始いたします。皆様の積極的なご応募をお待ちしております。詳細はこちらをご覧下さい。 ●SPI Japan 2008（ソフトウェアプロセス改善カンファレンス） 当日の発
Fine Software Writings
最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か？ (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか？ (Nick Bostrom) 厄介な問題を解決したい？ ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W
Linux Kernel Module programming (Kernel 2.4, デバイスドライバ)
○ はじめに 本文書では、筆者が Linux® でデバイスドライバを作成しようとした際に、カーネルに動的に追加機能を組み込むことが出来るカーネルモジュールの書き方について勉強したことを説明していきたいと思います。 筆者は、コンピュータでハードウェアを制御するプログラムを作りたいと思いながら社会人になったのですが、会社でそういう仕事がどんどん減ってしまって全然機会がありませんでした。しかし、雑誌等でデバイスドライバを作成して自作のハードウェアを制御する記事を読む度に、自分もやりたいという気持ちが大きくなっていきました。 そしてある日、「電子工作を勉強して自分のハードウェアを作り、それを動かすためのソフトウェアを書こう！」と決意しました。Linux でデバイスドライバを作成するには、カーネルに最初から組み込んでしまう方法と、動的に追加機能を組み込むことが出来るカーネルモジュールという形式で作成
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
ソフトの配布とライセンス
可知 豊 この文書は、SOFTBANK Cマガジン2004年8月号にて、「特別記事:自作ソフトの利用条件をどう決める? ソフトの配布とライセンス」として掲載された記事の一部を加筆訂正したものです。このような記事を執筆する機会を与えてくれた C マガジン編集部に感謝します。 なお、この文書は、ソフトウェアを利用する上で一般的な理解を助けるためのもので、法律的なアドバイスを与えるものではありません。ソフトウェアを利用・ 配布する際には、自社の法務担当者に相談することをお勧めします。 自分で作ったソフトウェアを、他の誰かに使って欲しいと 思ったことはありませんか? そのような、ソフトウェアの公開にあたって気をつけなければならないのが、そのソフトウェアをいったいどんな条件で使っても らうか、です。本稿では、ソフトウェアを公開/配布するときの利用条件（ライセンス）について、具体的にどんなライセンスに
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
「日本語テキストを分類するベイジアンフィルタ」を簡単につくるyo - download_takeshi’s diary
数週間前の話になりますが、「はてブのリニューアル会見」の記事を読んでいたところ、はてブにも「自動カテゴライズによる記事分類」の機能が搭載されるとか。。。 同じようなタイミングで「似たようなモノ」というか「ほぼ同じようなモノ」を作っていたので、すごーくインスパイアされてしまいました。ジュワ〜。（アドレナリンの放出音） 数週間たってもいまだ興奮冷めやらぬ状態なので、今日はその件について書いてみようと思います。 Lingua::JA::Categorize - a Naive Bayes Classifier for Japanese document. http://search.cpan.org/~miki/Lingua-JA-Categorize-0.00001/ 「はてブのパクリ」ではありません。「ベイジアンによる日本語テキスト分類器」を「簡単に作る」ことを目的としたモジュールです。 も
連載：プログラミングの光景｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
テクノロジー : 日経電子版
電通、三菱UFJ信託銀行など大手企業が相次ぎ参入を表明する「情報銀行」。ここに挑むベンチャー企業がDataSign（東京・渋谷）だ。同社の太田祐一社長は情報銀行という言葉が生まれる…続き 中部電力が「情報銀行」参入へ 電力データを活用 ［有料会員限定］ 「情報銀行」説明会に２００社 データ流通の枠組み始動
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
Subversion メモ
基本概念と特徴 リポジトリ Subversion は共有情報の一元管理システムであり、情報はリポジトリに格納される。 リポジトリは情報をファイルシステムツリー（一般的なファイルとディレクトリの階層構造）の形で保持する。 Subversion ではリポジトリの場所は URL によって表現される。 リポジトリにアクセスするための URL には以下のようなものがある。 file:/// リポジトリへの直接アクセス (ローカルディスク上) http:// Apacheサーバ への WebDAV プロトコル経由でのアクセス https:// http:// と同じだが、SSL による暗号化 svn:// svnserve サーバに対する独自 TCP/IP プロトコル経由でのアクセス svn+ssh:// svn:// と同じだが、SSH トンネルを利用する ほとんどの場合、Subversion の
Makefile は簡潔に書きましょう - pyopyopyo - Linuxとかプログラミングの覚え書き -
仕組みが判ってしまえば Makefile は簡潔に書けます．$(CC) とか $@ とか $< なんて変数は使ったら負けです． 基本(その1) ソースコード hoge.c から 実行形式のバイナリ hoge を生成するMakefileは，以下のように書きましょう all: hogeこれだけです．これで $ make all とすると hoge が生成されます 重要な点は，間違っても all: hoge hoge: hoge.c $(CC) hoge.c -o hogeのようなMakefileを書かないことです．このようなMakefileでは #!/bin/sh CC=gcc $CC hoge.c -o hoge というようなシェルスクリプトと同程度の使い勝手しかありません． 基本(その2) ここで例えば-O3 を付けてコンパイルしたい場合や，-lm を付けてリンクしたい場合は以下のようにし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://chikura.fprog.com/index.php?UID=1186645498
IBM developerWorks:わかりやすいコードを作成するための6つの方法
