オリジナルは自分で生むしかない クーラーをつけている室内で、こつこつ編む。毎日最低1つ、定番のグラニースクエアを編む。そう、最近のマイブームは編み物です。手作りでオリジナルのものを作りたいという願望から。去年の春あたりにもやっていたんですが、急に1ヶ月ほどで飽きて終了。それから、先…
はてなブログ | 無料ブログを作成しよう
オリジナルは自分で生むしかない クーラーをつけている室内で、こつこつ編む。毎日最低1つ、定番のグラニースクエアを編む。そう、最近のマイブームは編み物です。手作りでオリジナルのものを作りたいという願望から。去年の春あたりにもやっていたんですが、急に1ヶ月ほどで飽きて終了。それから、先…
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは？ - livedoor ディレクター Blog
こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。 弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。 そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。 以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。 ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか？ 弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。 受託 = クライアントに詰め
ssb がすばらしすぎる件 - TokuLog 改め だまってコードを書けよハゲ
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？…
ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか？ プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。 そのため いつもつらい思いをしています。 環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。 マウスもゲーム用の高精度のものを使っています。 調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。 DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。 出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。 単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。 しかし開発速度は効率化とは無縁だとすら感じています。 仕事を減らすことが優先ではないか？と。 昔から創作活動は好
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
［資質編］説明できない言葉を使ってはいけない
プロジェクト・マネージャ（PM）の中には，やたらと横文字や英略字を使って会話する人がいる。そういう人に「よく分からないので，詳しく教えてください」と聞くと，きちんと説明できないことが多々ある。言葉を正確に理解せずに使っているのだ。相手に説明できない言葉は，その言葉について理解しているとは言えない。 あるPMがユーザーに「最適なシステムはSFAをパッケージ化したこの製品です」と提案したとしよう。ところがユーザーから「SFAとは何ですか？」と聞かれたときに「え～と…それは…SはSalesのSでして…」と，たどたどしい説明をしていたのでは，その提案に対するユーザーの興味と，PMに向けられていた尊敬の眼差しは，吹き飛んでしまう。 また，あるPMが各チーム・リーダーに向かって「工程を管理してください」と言ったとしよう。その際，あるリーダーから「工程を管理するとは具体的に何をやればよいのですか？」と聞
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
その「プログラム設計書」が何を指してるのかわからないから土壇場で混乱する - @katzchang.contexts
仕様書やプログラムを書く大変さ - GeekFactory http://d.hatena.ne.jp/oredoco/20080415/1208222548 プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - yvsu pron. yas 上の方々の記事を読んで、その「プログラム設計書」って何なんだろうと思ったわけで…。 例えば、契約が「プログラム設計書一式によりプログラムを製造する」みたいなのだとしますよね。 でも、そのプログラム設計書はクラス図+シーケンス図みたいなものなのか、一つのまとまった処理…バッチ処理とかユーザイベントとかgetリクエストとかの入力に対するDBとか画面への出力を示したものなのか、内部変数とか内部ループのブレイク条件とかも示したものなのか、よくわからない*1。だから、受け取る段階になって混乱する。よくある話じゃないですか。 正直なところ、
IT化支援ラボ株式会社:要件定義をできる人材とは？
要件定義書や、要件定義を含むRFPを作成するにはどのような知識や経験を持つ人が必要なのでしょうか？ 残念ながら、システムに詳しければ誰でもできるというわけにはいきません。 どのような要件定義でも共通して必須となる条件は、 「実際の要件定義の場面に少なくともアシスタントとして立ち会った経験が有る事」 「要件定義書をもとにシステム設計をした経験がある事」 の二つです。 前者は当然の条件です。 要件定義は人間的な要求をできる限り引き出しつつ、製造者にとって必要な情報に絞って定義・カテゴライズしてゆく作業ですので、パターン化が難しく書籍での学習やセミナーを受けただけのレベルでは決してうまく纏めることはできません。 ましてや発注者の要求内容が漠然としている場合や、システム化に逆行するような企業文化を持つ場合などでは、たとえ要件定義のプロが取り組んでもうまく纏められない場合があります。 もう一
よかろう、ではIBMの実情について語ろう - novtan別館
といっても観測範囲は決して広くありませんのでこれがすべてではありません。所詮若干付き合いがある先に過ぎません。 日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 はてなブックマーク - 日本IBMで何が起きているのか 訴訟続発に下請けとのトラブル（J-CASTニュース） - Yahoo!ニュース まずこの記事についていっておくと、別々なカテゴリの事案をまとめすぎｗ この中堅企業は開発の規模が膨らんだ時点で、追加支払いの約束をIBMがしたにもかかわらずこの約束が果たされなかったとして、IBMを相手
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
