議事録が効力を発しない現場
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45671 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
無いデータをどう扱うか～表が大好きな日本の業務
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45671 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
頭の中にプログラムを入れる
Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題
大学でコンピューター工学を習ってもシステムが出来ない理由、逆に習わなくても出来る理由 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 大学で、情報処理学科で勉強しても、現場ですぐに役立たない、一方、情報処理学科でないひとが、コンピューターの会社に入って、それも情報処理学科の人と一緒に研修をうけて、ＳＥとしてやっている。おかしいじゃないかという意見をきいた。 おかしくないとおもう。 情報処理学科で習うのは、コンピューターサイエンスであって、 会社で、システム開発でＳＥが行う作業は、「業務のモデル化」であって、それは、情報処理学科とも、いや、理系とも関係ない、というか、もっというと、文系に近い。 コンピューター工学は、コンピューターの（要素）技術をならう。 ＣＧとか、ネットワークとか・・・ でも、システムを開発するとき、それらの要素技術を使ってもいいけど、使わなくてもいい（ローテクで固めてもシステムである。例：Ｅｘ
何故か使われないUNICODE項目
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45675 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
第11回 プログラマが知らない，デザイナーの苦労
今回は，デザイナーとして，世間やプログラマに対して言いたい放題書かせてもらう。どうか怒らずに最後まで読んでもらいたい。デザイナーの皆さんには，大いに賛同していただける内容になっているはずだ。 デザイナーだって，タイヘンなんだ！ まず，デザイナーという仕事は，非常に誤解されやすい。例えば次のような誤解をうけて，暗い気持ちで日々の作業をこなしているデザイナーも少なからずいるはずだ。 1) デザイナーという職種に対する，先入観がある 世間（顧客やエンドユーザー）には，「すべてのデザイナー」＝「技術に無知」だという先入観がある。「デザイナー」とは「Webページの配色とレイアウトをする人」だから技術を知らなくて当然，むしろ知らなくてよいとする傾向すらある。開発ツールが完全分業に向けて進化しているのだから，デザイナーはビジュアル・デザインのことだけ考えていればいいという意見を持っている人もいるだろう。
要求仕様戦争（その2）
■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
