Webエンジニア武勇伝 第29弾 竹迫良範 氏 | サイボウズ・ラボ（Cybozu Labs）
今回は、武勇伝第26回に出て頂いた角谷信太郎氏からの紹介で、サイボウズ・ラボ（Cybozu Labs）の竹迫良範さんにお話をお聞きしました。竹迫さんは、サイボウズ・ラボにて研究開発の実務を行う傍らで、「Shibuya Perl Mongers」の２代目リーダーとしてPerlプログラマのコミュニティ活動を企画・運営したりと、幅広いフィールドで活躍されています。今回は赤坂にあるサイボウズ・ラボさんのオフィスにて、そんな竹迫さんにじっくりお話を伺いました。竹迫さんの「日本のIT業界の将来像」についてのお話は示唆に富んでおり、IT業界に身をおく者として、とても勉強になりました。 竹迫 良範(TAKESAKO) 氏 ◆中学校２年生のとき、父親の購入した富士通「FM TOWNS」に触れてコンピュータに興味を持つようになる。 ◆高校のころF-BASIC 386 でプログラミングをはじめる。 ◆大学では情
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
MOONGIFT: » Rails製のソースコードレビューシステム「宍道湖」:オープンソースを毎日紹介
ようやく一段落したので公開。 ソースコードのレビューをするとどういったメリットがあるのか。お互いに人にソースを見てもらう、逆に見ることは知識の共有化や勉強材料として非常にためになる。プロジェクトチーム内でのレビューは、中長期的にみた時のシステム把握や標準化で役立つことが多い。 問題の表示 そんなソースコードレビューを手軽に導入できるシステムを開発したのでご紹介。Google App Engine上で動作するRietveldクローンだ。 今回紹介するオープンソース・ソフトウェアは宍道湖（しんじこ）、Ruby on Rails製のソースコードレビューシステムだ。 宍道湖は、Rietveldクローンとして、見た目をほぼそのまま踏襲して開発している。ただし認証周りや、メール周りの処理は異なるものになっている。パッチファイルの表示やダウンロード、旧版と新版を横並べにした差分表示が可能だ。 差分表示
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
バージョン管理が原因だとしたらかなりヤバイよ三菱東京UFJ - novtan別館
一昔前、とにかく早く上手く新機能を追加しようぜ、セキュリティー問題のパッチ当てようぜ、な時代にはまあそこそこあったんだけど、最近はバージョン相違と言えばもう蛇蝎の如く嫌われる最悪の障害であると言って良いでしょう。 かいつまんで書くと「テストは充分にしていたが、バージョン違いのモジュールを本番リリースしてしまった」ということのようです。 三菱東京UFJのトラブルの原因が日経コンピュータに載ってます：栗原潔のテクノロジー時評Ver2：オルタナティブ・ブログ 日経コンピューター読まねば！ 最近のシステム開発ではモジュールの関係が複雑にならないように頑張ってはいますが、やっぱりJavaやらなんやらで作ると本数は増えますので管理は大変です。旧態依然としたホストのプログラム管理方式では一モジュールにつき一枚のプログラム管理票の起票が必要になったりして大変です。beanごとに起票とかしてらんないよね。
きちんと学びたいSEのための会計入門：ITpro
企業における会計業務の目的，財務諸表ができるまでの仕組み，会計ルールの基本原則である企業会計原則，主要な業務プロセスにおける会計処理，期末における決算処理の流れなど，会計の基本的な知識を学びます。 ■コンテンツ中の用語解説は機能しません。あらかじめご了承ください。 はじめに 講座ガイド 第1章 会計の基本を理解する（標準的な学習時間 30分） 第1節 SEが会計を学ぶ意義 業務知識はSEの必須教養 会計は最も優先度の高い業務知識 第2節 会計の役割と実務 企業外部向けの報告：財務会計 企業内部向けの報告：管理会計 会計の実務 チェックテスト 第2章 財務諸表の作り方と読み方を理解する（標準的な学習時間 90分） 第1節 複式簿記で財務諸表を作成する 経営状態をストックとフローで測る 家計簿では企業活動を把握できない 露天商で複式簿記を体験する 単式簿記で営業成績
「IT野麦峠」「うさぎ症候群」を改善した在宅勤務の魅力
劣悪な労働環境が問題となっているIT業界において、大手企業を中心に在宅勤務制度の導入が進んでいる。各企業の制度導入までの道のりはさまざまだったが、共通の効果も見えた。制度化に当たり外せないポイントは何だろうか。 3K（きつい、帰れない、給料が安い）、エンジニアの人材不足……IT業界を形容する言葉にはネガティブなイメージがつきまとっている。日付が変わるまで働くためプライベートな時間が取れない、残業時間が月に100時間を超えるなど、過酷な職場環境が問題となっている。 そのような中、2006年に大手ITベンダー4社が在宅勤務制度の本格導入を掲げ、2007年11月に日本HP、2008年2月にNTTデータが在宅勤務制度の全社導入を相次いで発表した。この動きはIT業界において、多様な働き方を認める制度として注目を集めている。 在宅勤務制度の導入には、管理やセキュリティ、社員のモチベーション維持などが問
反復型開発はプログラマだけでなく QA も幸せにするんじゃないかな - kagamihogeの日記
散々いろんなとこで語り尽くされている感はあるけど。デスマ中に QA との様々なやりとりからも、ウォーターファール的なやり方*1はもう限界だよなぁ、と感じている。 少し前のデスマで QA とこんなやり取りがあった。 「（渡されたアプリケーションを見て）事前の情報を遥かに超える規模のアプリケーションなので予定してテスト工数では足りない。話が違う、もっと機能少なかったんじゃないの？」 「完成度が低すぎる機能がある。QA の意味が無いので一時テスト作業を凍結する（もう要員割り当てちゃったよ。どうしてくれるんだ的な意味で）」 これらはテスト期間と要員の見直しが急激かつ大きく必要になるので QA からしたらたまったものではないだろう。QA は他プロジェクトの開発スケジュールと合わせてにらめっこしながら一つのプロジェクトのテスト期間と要員を割り振る。そのため、一つのプロジェクトにリソースをふりすぎると他
ソフトウェアマネージャへの公開書簡:Geekなぺーじ
「An Open Letter to the Software Managers of the World」という記事がありました。 世界のソフトウェア開発者から、世界のソフトウェアマネージャへの公開書簡らしいです。 原文は、マネージャへの要求と、要求を約束するのであればソフトウェア開発者が果たす義務の2部構成になっています。 最初に義務の部分が書いてあります。 ほどほどに面白い内容でした。 以下、要約です。 かなり省略/意訳しているので、詳細は原文をご覧下さい。 我々ソフトウェア開発者は、以下の事項を約束する。 我々は、要求されなくても任務遂行に必要な行動を自主的に起こす。 残業もこれに含まれる。 (ただし、次章の項目1を満たす限り) 我々は、つまらない仕事を任されても文句は言わない。 他人のコードの管理も行う。 (ただし、次章の項目4と5を満たす限り) 我々は、可能な解決法の提示するな
安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayang's diary
機内で読んだWall Street Journal（紙媒体版）2007年12月7日金曜日A1面の記事より Boeing Scrambles to Repair Problems With New Plane 要旨 次期旅客機787Dreamlinerの開発が遅れている 最大の理由は自社開発ではなく、アウトソース活用を試みたこと 機体の設計開発をアウトソースしたのはボーイング91年の歴史で初の試み アウトソースした理由 機体素材に炭素繊維を使う787は基礎研究だけで大きな投資が必要だった 開発投資額は100億ドル(1兆1000億円)に達する 開発投資を抑えるため、部品供給メーカ達に設計開発を委託（アウトソース） 発生した問題 多国にまたがるアウトソース 言語の壁 米国では想定していなかった各種規制 孫請けに仕事を分散させることによるオーバーヘッド 同じ企業なら会って話せば済むのに、大量の文書
Matzにっき(2007-10-23)
<< 2007/10/ 1 1. [Ruby] ロゴコンテスト締め切り 2. [Ruby] Rubyで自治体の業務システム構築、松江で実証実験 − ＠IT 3. On Off and Beyond: 何かを好きになるために努力すること 4. U-20プロコン表彰式 5. 経済産業大臣表彰 2 1. [言語] プログラミング言語「ドリトル」 - Dolittle 2. [Ruby] 【CEATEC】東芝がCell上でRubyを使った家電向けユーザー・インタフェースをデモ：ITpro 3 1. [言語] The Transterpreter 2. 5時間以下の睡眠続け死亡率1.7倍に 7時間寝よう｜Ameba News 3. This is making me angry 4. [Ruby] Ruby on Rails Development: Justify Your Choice of R
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
FPN-ゼイヴェル・大浜史太郎社長へのインタビューを読んだ
4．インプリケーションと提言 リサーチを通じて気付いたことは？公開情報から点と点を結ぶイン… インサイダー情報はそのままでは役に立たない！？ビジネスリサーチの依頼の中で、「業界の空気感はどうなっているか？」「この技術が主流になっているというのは信憑性があるか？… 2021.01.27 2021.05.13 185 view 1．ビジネスリサーチの基本・心構え すべては「依頼」から始まる〜社内リサーチャーと社外リサーチャ… 【 リサーチャー とは 】企業で企画系の仕事をしていると、上司の依頼で調べものをして資料にまとめるという仕事が多いと思います。企画系の業務では課長クラスまではこうしたリサ… 2021.01.18 2021.05.13 340 view 2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネット
IT業界を不人気にした重鎮たちの大罪:インフラコンサルティングの最前線 - CNET Japan
現在、IT業界が空前の人手不足に喘いでいるのを知ってますか？ たとえば、転職市場におけるベンダー各社の動きで一番分かり易いのが、中途採用の紹介料を軒並み倍増しているという点です。 今年の初め、人材紹介会社やヘッドハンターに支払う紹介料金の相場は、大体20％程度だったと記憶していますが、それが今や紹介料40％！年収が1000万円の人物を企業に紹介したら、400万円が紹介報酬として貰えるのです。 なぜここまでIT業界が人手不足に陥っているのか？ 色々な要因がありますが、最近とても深刻になっているのが、「そもそもIT業界に魅力を感じる人が減ってきている」という事実でしょう。 10月30日に情報処理機構（IPA）がIPAフォーラム2007でこんな企画を実行しました。 『IPAはIT業界の重鎮と理系学生による討論会を開催した。テーマは「IT産業は学生からの人気を回復できるのか」だ。 討論したのは
第1回 20年は遅れているITプロマネ | 日経 xTECH（クロステック）
近年，システム開発のプロジェクトマネジメントについての関心が高まっており，プロジェクトマネジメントに関する資格を取る人も増えています。しかし，そのために「システム開発の失敗事例が減ってきた」という話はあまり聞きません。 システム開発プロジェクトは，建築やプラント建設，船や工作物などの機械組み立てのプロジェクトと比べて，失敗事例があまりにも多く，納期どおりに完成する例は多くありません。実際，日本情報システム・ユーザー協会（JUAS）の「ユーザ企業IT動向調査 2006」でも，500人月以上の大規模プロジェクトでは相変わらず5割近くで工期遅れ，4割近くで予算超過が発生しています。スケジュールが遅れ，その結果としてコストが増加することが当然と受け取られています(図1）。 図1●プロジェクトは基本的に成功するもの プロジェクトは，プロジェクト・マネジャーがしっかりと顧客とメンバーを把握して，品質（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チーム専用の部屋は、より生産性の高いチームを生み出すか？
Do Dedicated Team Rooms Make for More Productive Teams?
com.com - owned and operated since 1995
長文日記
長文日記