高原芳浩のKeep-Alive - ソフトウェア開発会社を作ろうという小資本理系学生向けのメモ
私は8年前の8月、23歳で会社作ったのだが、経営なんて興味なかったんで会社を作るとき知らなくてはいけない事を後から知った。それでまぁいろんな人に迷惑をかけているわけだから、やっぱり普通にプログラム書けるだけで起業しちゃだめだよね（反省）参考になるか判らないけどとりあえずメモ。資本金今はいくらでもいいらしいけど昔は有限会社つくるのに300万円必要だった。でも資本金の2割は現物出資できたのでパソコンを出資して240万円。結局、自分はこのうち180万円を出資した。良く考えたら自分の収入源がディノだけなので今に至るまで自分の投下資本は180万円のみ。もちろん、役員報酬→増資を繰り返すことで名目上もっと出資した事になっているのだが。設立登記最近は司法書士に頼むとネット経由で登記して割安らしい。無理せず専門家に頼もう。売上計上は納品基準。売上予測受注と開発期間を元に基準に売上を予測する。この予測は傾向
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
優秀な人材に変身するキッカケに出会うか、未熟なまま老いていくか
頭が良く、意欲的に仕事にとり組むんだけど、いまいちアテにできない人というのがときどきいる。 ポテンシャルはあるのに、どこか独りよがりなところがあるために、暴走するリスクがあり、安心して、重要な案件を任せられないタイプの人間である。 そういう人は、「きっかけ」があると、大化けする。本当にすごい人材になる。 しかし、きっかけが無いと、つまらない脇役仕事や日陰仕事ばかりやらせられ、未熟なまま老いて、どんどん腐っていってしまう。 この記事で描かれている坂本君は、いかにもそういうタイプの人だ。 芦屋：坂本，この「貴方の営業ご担当者様が販売活動しやすいように工夫しています」という表現は，抽象的で意味不明じゃないか。意味が分からないから，「先方へのアピール」になってないんじゃないか。説得力もないよ。ここは，具体的な事例を使って修正すべきだな。どう修正すればいいか考えてよ。 坂本：いや，ここはこれでいいん
モチベーションを高めたいなら達成すればいい ― ＠IT情報マネジメント
第3回目となる今回は、第1回「優秀なプロマネはメンタルな働きかけもうまい」で触れたゴールアライメントについて、もう少し詳しくお伝えしようと思います。さらに、プロジェクト成功には欠かせないメンバーのモチベーションを高めるためのポイントや、当たり前過ぎてやっているプロジェクト、組織がほとんどないけれど、実は絶大な効果がある“ルール”についてもお伝えしますので、ピンと来た方は最後までお付き合いください。今回もオムニバス形式でお届けします。 ばかばかしいほど簡単で大切なルール あらためていうまでもないことですが、プロジェクトや組織を運営していくためにはルールが必要です。会議運営のためのルールや、個別の作業を行う際のルール、あいさつのルールなどなど、組織によって本当にさまざまなルールがありますが、私が非常に強力な効果があると感じているのは「言葉遣いのルール」です。小学生じゃあるまいし！ と驚かれた方
POLAR BEAR BLOG アイデアを殺す22の方法
久しぶりに箇条書きネタ。How Blog > Core 77's Design Blog という経由ですが、「アイデアを殺す台詞/態度」というエントリがありました： ■ Idea killers: ways to stop ideas (Berkun Blog) で、内容はというと： 「それはもう試したよ。」 「そんなのうまく行かないよ。」 Would you like a pony? （※すみません、ここ意味分からず。検索すると割とヒットするフレーズなんですが・・・。pony = 子馬、重要でないものということで、「そんなつまらないことしたいのか？」という意味？） 「ばかげているな。」 「君はクビだ。」（※失敗すれば処罰される、という雰囲気では新しいアイデアは表にでない、という意味？） 「君には強く反対する。」 （笑い） 「予算にないな。」 「それは重要な問題じゃないよ。」 「時間がない
「アート・オブ・プロジェクトマネジメント」読書感想文（その4）
いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。 本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。 ■シンプルにすると、本質が見える これをスゴい本だと感心だけでなく、かなり気に入っている。なぜなら、著者の考え方がものすごくシンプルだから。ひょっとすると、"rule#1 : Be Simple!"という標語が壁に大書きされているのかも、と思うぐらい。 どれぐらいシンプルに考えているか、次の例で確かめてほしい。 スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます（p.30） 極限までシンプルにし
「優秀なIT部門」を維持するために──激しい雇用競争の中ですぐれた人材を探し、確保する方法 | OSDN Magazine
米国経済の回復基調が持続し、求人市場の競争が激化する中で、自社のIT戦略に大きく貢献できる、すぐれた能力を持った人材を見つけ、確保し続けることはますます困難になっている。今年7月、管理職クラスに籍を置く300名のうち、IT部門の責任者を対象に実施した調査によると、31％の企業が今後数カ月以内にIT管理職を外部から雇用する予定を立てているという。 この調査は、米国の管理職スカウト企業ランドール・ジェームス・モンロー（本社：ダラス）が定期的に行っているものだ。同社のCEO（最高経営責任者）であるランドール・ニール氏は、「31％という数値は、これまでの調査と比べても非常に高いものとなった」とコメントしている。 時には優秀な管理職を外部から得ながら、一定のレベルを保ったチームとしてIT部門を機能させ続けていくことは、今日の厳しい求人市場においては至難の業だ、とニール氏は指摘する。優秀なIT管理職た
報奨金制度の提案に起因する、Debian開発者の活動意欲に関する論争 | OSDN Magazine
現在、自らをDunc-Tankと名乗る開発者たちの集団が、特定のプロジェクトを完成させたDebian開発者に対して金銭的な報酬を支払うための準備を進めている。こうしたDunc-Tankによる活動の第一目的は、Debianの次期バージョンをスケジュールどおりにリリースさせることにあるのは分かるとしても、このアナウンスについて懸念されるのは、以前にもプライベートな議論として取り上げられたことのある問題、つまり「従来は個人的な動機から仕事を進めてきたフリーソフトウェア開発者に対し、唐突に金銭的な報酬が与えられるような事態になったらどうなるか」というものである。 Dunc-Tankが最初に発表したニュースリリースによると、この組織は一種の“実験”団体であり、「開発者とユーザおよびDebianのサポータをメンバとする独立団体」であるとのことだ。実際Dunc-Tankには、Debian開発者の間でも特
プロジェクトリーダの罷免が提案されたDebian | OSDN Magazine
Debianのプロジェクトリーダ（DPL）であるAnthony Towns氏について、罷免の投票が行われる可能性がある。問題となっているのは、Dunc-Tankへの関与についてだ。Dunc-Tankとは、Debian etchを12月初頭に予定どおりリリースできるよう、寄付を集めてDebianのリリース・マネージャに財政的支援を行うことを目的とした(OTP翻訳記事)非公式グループである。 この決議の内容や、Debian憲章の下でのこの決議の正当性については、当記事の執筆時点でも議論が続いているが、仮にこれが可決された場合、次のリリースに向けて障害となる可能性が大いにある。未解決の重大なバグの数々に比べても、克服がはるかに困難な障害である。 Debian憲章では、個々の開発者が「一般決議の草案を提案する、またはその賛同者となる」ことができるということと、開発者が集合体として「プロジェクトリー
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
【中級】一流エンジニアのタイムマネジメント 第4回：ITpro
「どうして時間内に完了できなかったのだろう。下調べが不十分だったのか。それとも，タスクの分解の仕方が甘かったのかも。もしそうなら，どうしたらよいか」――。札幌スパークルの桑原里恵システムコーディネーターは夜にノートを見ながら，その日の仕事ぶりを検証することを日課にしている。 ノートには桑原氏が書いた1つの表がある。それは今日1日で行った主要なタスクごとに，予定していた所要時間と実際にかかった時間を対比したものだ。桑原氏はこれを見ながら，所要時間の予定と実績が食い違ったタスクを1つひとつ取り上げて，なぜ遅れたのか（もしくはなぜ早く終えられたのか）という要因を探り，対策を練る。いわば，1人で行う「カイゼン活動」だ。 「予定以上に時間を要したということは仕事のやり方か，そうでなければ所要時間の設定に問題があるはず。なのに『次回はもっと頑張ろう』で片づけていては，また同じことを繰り返す」（桑原氏）
【中級】一流エンジニアのタイムマネジメント 第2回
あなたが普段使っているスケジュール表を開いて欲しい。紙の手帳でもパソコン・ソフトでも構わない。そこに，どんな予定を書き込んでいるだろうか。おそらく予定が詰まっている日もあれば，空欄のままになっている日もあるのではないか。 ダスキンの加盟店大手である武蔵野（東京都武蔵野市）で，企業向けを主力としたプロバイダー事業を担当する斎木修インターネット事業部課長のスケジュール表は違う。毎日びっしりとスケジュールが詰まっている（図2）。ITエンジニアとして飛び抜けて多忙だからというわけではない。スケジュール表の使い方が，普通とは違うのだ。 開始時刻が決まっている会議や打ち合わせ，顧客訪問などのアポイントメントは，誰もがスケジュール表に書き込むだろう。斎木氏はそんな時刻の決まった予定だけでなく，期限までにやればよい「提案書作成」のようなタスクも記入している。すべてのタスクについて，いつ行うかを決めているの
【中級】一流エンジニアのタイムマネジメント 第3回
【中級】一流エンジニアのタイムマネジメント 第3回 実行編 集中できる時間，場所，プレッシャーを作り出す このままでは期限に間に合わないかもしれない――。そんな状況になって，一気に集中力が高まった経験はないだろうか。俗にいう「締め切り効果」である。 タスクを実行する段階において重要なのは，集中力を高めて維持することだ。その有効な方法の1つが，適度なプレッシャーを自分に与えること。いわば，「締め切り効果」の自己演出である。“適度な”というのは，あまり焦り過ぎると逆効果という意味だ。これを日々実践しているのが，コクヨの福田氏である。 「さて今から1時間。ヨーイ，ドン」――。福田氏は，企画書の作成や仕様書のチェックなどのタスクに取りかかるときに，決まって時計を見て心の中でこうつぶやく。今まさに仕事に着手したことと，完了予定時刻を“宣言”することで自分にプレッシャーをかける。「終わるかどうかギリギ
【中級】一流エンジニアのタイムマネジメント 第1回
タイムマネジメントは誰もがマスターすべき「仕事術」。基本的なテクニックを習得・実践すれば「時間欠乏症」の解消はもちろん，仕事のやり方そのものを継続して洗練できる。ここでは事前準備，計画，実行，検証・改善という4つの段階に分けて解説していく。 「ええっ，もう朝かぁ」――。自宅に資料を持ち帰って提案書の作成を続けた田中氏は，いつの間にか窓の外が白み始めたのに気づいた。「まあ，それなりの出来にはなったな」。目の前のパソコン画面では，提案書がほぼ出来上がっている。田中氏は安堵の表情を浮かべたが，疲れの色も濃い。眠い眼をこすりながらの作業だったために思うように仕事がはかどらず，ついには朝になってしまったのだ。 「我ながらよく頑張ったけど，これじゃあ体がもたないよ」。田中氏はプリンタで提案書を打ち出しながら，以前に上司から聞いたタイムマネジメントのことを思い出した。「やっぱり会社にいるときに，どれだけ
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
働いてはいけないIT企業
とアジったタイトルつけてはみましたが、問題の記事はこちら。 働いてみたいIT企業ランキング（1） ITproで出ていました。 で、なんですが、ちょっと突っ込んでみようかと。 えーとですが、まず、ランキング１～３位までは問題ないと思います。 マイクロソフト、野村総合研究所、日本ＩＢＭですね。ランキングトップのうち、二つが外資系というのもアレですが、マイクロソフトとＩＢＭは財務的には問題ありません。 というか、マイクロソフトは財務的には最強臭い企業です。市場独占力をいかして儲け過ぎだなんて世界各国で嫌われちゃったりしてますし、株価はここ５年くらい緩やかに下がったりしてますが、財務面では文句無し超優良企業です。 ＩＢＭも、財務的には問題のない企業です。１９９３年、アメリカ企業史上最悪の５０億ドルという大赤字だしたりしましたが、ガースナ―さんの下でリストラしたり、経営改革したりして、持ち直していま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
目標達成ログ (Joe’s Logbook.com) | 100SHIKI
