Where we came from
Born out of desperate necessity to stop embarrassing ourselves in front of our clients, the story of how Basecamp was born is likely your story, too. Hey there— I’m Jason Fried, one of the co-founders here. I’ve been running 37signals — the business that makes Basecamp — for 23 years. People often ask me why we built Basecamp. They’ve never seen anything like it before, so they’re curious where th
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力（ばりき）のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク（＝作業）の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
仕事・雇用・ライフスタイル - D-6 [相変わらず根無し]
仕事・雇用・ライフスタイル とくにまとめず、だらだらと書きます。 「日本のサラリーマンのようになれないwので辞任します」を読んで思うのは、仕事＞家庭（個人の時間）である必要は全くないんだけど、それであるなら被雇用者は単位時間当たりの生産性を最大限にあげる努力をしないといけないと思う。 だって日本の会社ってダラダラ会社に居続ける人いっぱいいるじゃない。9-5時で仕事びしっとやってびしっと帰ればいいじゃないの、といつも思ってるのだが。 それと同時にこういう非生産的な風潮を取り締まるのも難しいんだよね。例えば日本の企業では雇用者が雇用関係を解消するのに手かせ足かせをはめられている。これは会社が雇ったからにはその個人の面倒を見ろ、という事だと思うんだけど、それだと逆に生産性の著しく低い人と雇用関係を結んでしまった時に困るんだよね。経営者としては潜在的な赤字を生み出す原因は取り除かないといけないわけ
ゆーすけべー日記
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
株式会社マジカジャパンの羽生章洋が書いてるブログ:指摘だけでは過去に生きるだけ - livedoor Blog（ブログ）
日頃私たちは身の回りに数多くの問題を目の当たりにして生活しています。問題は何も社会とか政治とかそんな大きな事ばかりではありません。そしてそんな身近な問題を放置しておくと色々と困ったことになったりもします。 問題というのは過去の何かによって引き起こされた現象の積み重ねが表出したものです。ですからその問題を指摘するというのは、過去の行いを指摘することそのものです。一方で人間は時間をさかのぼることは出来ません。過去に戻ってやり直すことは出来ません。ですから反省するにせよ何にせよ、問題を解決するためには「今後何を改めるのか」ということが重要になります。 そして「何を」だけでは解決には至りません。「何に変えるのか」ということも大切です。現在の問題を引き起こしている「何か」を別の「何か」に改めなければ、同じ事の繰り返しになってしまうでしょう。ではその「別の何か」とは何か。それが目標だったりゴールだった
ノートPCの持ち出し禁止問題を再考する 第1回 IT技術者の13％がノートPCを持ち出せない：ITpro
“いつでも、どこでも”利用するために生まれたノートPC。それが今、内部統制や情報漏洩対策の強化を理由に、持ち出しを禁止されたり制限されたりしている。日経コンピュータ誌とEnterprise Platformサイトが共同で、ノートPCの利用実態を調査すると同時に、持ち出し禁止の見直しにつながるテクノロジの最新状況を追った。 Enterprise Platformではこれまで、「持ち歩けないノートPC」について数回にわたり取り上げてきた（関連記事1、関連記事2、関連記事3）。ノートPCは持ち歩いてこそ、その特性が生きる。しかし、持ち出しを禁止している企業の例も少なくない。現実問題として、ノートPCを持ち出せないIT技術者はどの程度いるのだろうか。 8人に1人がノートPCを持ち出せない 実態を把握すべく、EnterprisePlatformでは2008年12月10日から2009年1月28日にかけ
となりのあの人の生産性を殺す９つ（+1）の妨害工作
Nine Ways to Devastate Productivity | Productivity 501 誰にだって調子がのってこないという日はあるものです。そんなときにとなりのあの人はなんだか表情も明るく、充実して仕事をしているようにみえる。どれ、ひとつあいつの足をひっぱってやろうじゃないか…。 なんて、邪悪なことを考える人はいないと思いたいものです。Productivity 501 で、人の足をひっぱるための９つの方法という記事があって、あまりの反面教師ぶりに笑ってしまいました。 意訳でこの９つをざっくり紹介しますが、どうでしょう、身近にこんな人いませんか？ 会って話すべきことでも必ずメールで連絡する ちょっと質問して、ちょっと答えるだけの会話ですむような話題をわざわざメールで行います。会話だったら数十秒のやりとりですむことが、５つか６つのメールのやりとりと化して相手の時間を奪いま
開発と運用の分離
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括部の駒田です。 昨今、内部統制やJ-SOXといった言葉を良く耳にしますが、 ヤフーもご他聞に漏れず、粛々と対応を進めて参りました。 今回は、その対応の一環として行った、 「開発と運用の分離」に関してのエントリーをさせていただきます。 例えばですが... 開発成果物であるソースコードをテスト終了後に改ざんし、 不正に利益を得る様なエンジニアが存在していた場合、 それはヤフーにとって、一般のお客様に対する裏切りであり、 信用の失墜となってしまいます。 このような事態を回避するため、 当開発部では開発者と運用者とを明確に分離し、 開発者はリリースモジュールに触れる事が出来ない。 運用者はソースコードに触れる事が出
「アドバイス」について考える : 小野和俊のブログ
アドバイスというのは他の人に対する助言なわけだから、基本的にはそれなりにありがたく受け止められるはずのものなのだが、世の中にはあまりありがたくないアドバイスというものがあり、その原因は、本人が自覚的かどうかは別として、裏側にアドバイス以外のものが隠れていることが多いように思える。 人生における何らかの意味での先輩が、後輩に対して、アドバイスという形で、過去の苦労や輝かしい実績や知識といったものをひけらかしたい欲求を満たす。 2. 注意する側にまわる喜び 自分が規範とする尺度で見て許せない行為に遭遇した場合に、そういうことはやめた方がいいのだという一般化した物言いで、自分がこれまでに人から言われてきたことを別の人間に対して指摘し、自分も注意できる側に回ったのだという、規範内における勝者としての立ち位置を確認する。 3. 負けていないことのアピール 学生における学業の成績や、スポーツ選手におけ
大半のSIerが3次下請け禁止
コンピュータメーカーや大手SIerなどによる、再々委託禁止の動きはごく当たり前のものになってきた。 既に富士通や伊藤忠テクノソリューションズ（CTC）、CSKシステムズ、新日鉄ソリューションズ（NSSOL）などの大手から中堅SIerまでが、3次の下請けを禁じる「再々委託禁止」の規則を導入（表1）。今回の取材で回答を得られなかったが、取引関係のある複数の企業によると、日立製作所も同様の方針である。 NTTデータと野村総合研究所（NRI）、NECは、現在のところ多重下請けを一律には制限していない。ただし、協力会社が外注を活用する場合は必ず報告と許諾を求めるなどして、下請けの管理を強化している。 再々委託禁止より厳しい外注制限を課すケースも出ている。キーウエアソリューションズやシーエーシー（CAC）は2次への業務委託も禁じるようにしたのだ。また、ある中小SIerは「最近、日本IBMの2次下請けと
上司力、部下力
上司って存在は、常に部下より仕事ができなくちゃいけないし、部下の足りないところを全力でフォローできてないといけないと思いこんでいた。 実際は、それだけじゃなくても良くて、できたチームは、部下もまた上司をフォローしている関係性なのではないだろうか。 単純な理想状態はこんな感じだけど、 こんな感じでも良い。良き部下である。 こういう風に、「のりしろ」がクロスするのが一般的だしチームとしては理想的。 まちがってもこういうのはダメ。真ん中に穴が開いている罠。 結局のところ、上司はどれだけ部下のフォローするか？というところに上司力という能力があるとするならば、逆に部下は、どれだけ上司やチームをフォローできるか？という部下力というのもあると思う。 結局、上司が部下を評価する際に重要なのは、この「部下力」だったりもする。 相対的なところにこそ大事なことがあるということだ。 これが上司にしろ部下にしろ、「
日本のIT業界はなぜ重層的な階層構造をとっているのか - Thoughts and Notes from CA
外資系のソフトウェア・ベンダーに転職して1年が経つ。転職するまで日本のIT業界の構造についてじっくり考えることなどあまりなかったのだが、今の会社で仕事をしていると否が応でも考えなければならなくなる。日本のIT業界はアメリカと構造が異なる点が色々あるが、その中でも重層的な下請・階層構造をとっている、ということは特徴として際立っている。本国が作成したパートナー契約を締結しようとか、本国で構築された社内システムをロールアウトしようとすると、大体重層的な下請・階層構造という問題が立ちはだかる。本国アメリカのパートナー契約はバラエティに欠き、多様なパートナーに対応できないし（例えば、システム・インテグレータに対する考慮が足りない）、社内システムも階層の深さへの思慮が足りなく、折角手にした情報を入力する受け皿もなかったりする。また、階層が深いためソフトウェア・ベンダーはお客様との距離が遠くなり、この距
IT企業の経営者として、不景気だとしても守り続けたいこと : 小野和俊のブログ
「この不景気ですから」という言葉が 挨拶の常套句として定着しつつある今日この頃、 昨年末の時点では、今回の不景気はアプレッソにはあまり影響がなさそうに 見えていたものの、昨日、四半期に一度の全社でのキックオフミーティングで 営業の人たちの発表を聞いて、やはりある程度意識していかなければならないな、 と感じた次第である。 そんな中で、もしこれから不景気が自分の会社にも影響を及ぼした場合にも、 こういうことは守り続けたい、と思うことを、エントリにまとめようと考えた。 とりわけ不景気な情勢の中では、「企業は利潤追求団体である」という前提の元に、 取りかかろうとしていることが収益を生み出すものなのかどうか、 ということについて重点を置いて物事を考えがちになるのではないかと思う。 ちょうど昨日知った二宮尊徳の言葉で、 「道徳を忘れた経済は罪悪であり、経済を忘れた道徳は寝言である」 というものがあるそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自分戦略研究室 ― ＠IT自分戦略研究所
長文日記
効果的にアジャイルをやるための仕事場
