管理志向とか規律とか - miyaniyanのブログ
最近、読んだ記事で考えさせられたこと 人間は誰でもミスをする、システムは必ず障害を起こす──トラブルを減らす“6つの知恵” | 日経 xTECH（クロステック） 人は必ず失敗する、その前提で考えたら、がちがちで手足を縛って行動させるか、 ミスすることを恐れずに、経験値として高める工夫をすることと、ミスがあっても、それをいかにリカバリしていくか。 その重要性を感じた。 これは、SI業界で起きている、プロジェクト管理偏重で管理が行き過ぎていることの弊害を想像させることだ。 たった１日進捗が遅れただけで、それをどうリカバリーするんだ、どんどん遅れていくぞ、 大丈夫です。すこし残業すればリカバリーできます。 みたいな不毛なやりとり。 なんで、なぜ遅れている状況になっているのか、もともとの計画に誤りはないのか、を突き詰めないのか。 進捗はいつも平均速度であって、ここには速度が違っているってことを考え
情報科の授業は教養に過ぎないという話 - 木更津工業高等専門学校編 - Captivate
2013-12-22 情報科の授業は教養に過ぎないという話 - 木更津工業高等専門学校編 この記事は情報科の授業は教養に過ぎないという話 - 東京工業大学附属科学技術高校編 に触発されて書かれています はじめに 僕は所謂クズ高専生です 毎年単位ギリギリで進級してきましたし、今年度は授業にほぼ出ないでひたすら図書館で読書かプログラミングしていました。 漠然と「退学したいなー」と思っていましたし、現在休学中なのでここまでに至った経緯を書いてみたいと思います。この記事は高専を批判するものではありません。単純に僕が高専に合わずドロップアウトしたという内容です。そこはご確認ください。よろしくお願いします。 入学 僕が高専を志したのはたしか中学2年生のころで、その時の僕はVBSでmsgbox呼んでwaiwaiしたりHSPでくだらないゲームを作ったりしていました。そして情報系の学校行ってみたいなーと
ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。
私は宮崎出身ではありません。 目標管理シートドリブン開発はくそ - razokulover publog を読んで同意しました。 目標管理シートについて、私も感じる問題点と対策を挙げておきます。 （重複意見は抜いておきます） 事前にコミットするために目標の変更が利かない 表題のとおり。 ちょっとフィクションの話を。 半期の初めに目標設定をしました。 仮に「Ruby を業務で使えるレベルになる」とでもしましょう。 （この時点で別の問題もはらんでいるが、それは後述。） 少し勉強を重ねた1か月後、 Ruby が陳腐化しました。 実際 Ruby という言語自体のような手堅い目標であればいいでしょうが、 今さらそんな目標設定することはないでしょう。 登場したばかりの新しい技術を試してみることのほうが多いと思います。 しかしその技術は陳腐化する可能性があれば、 1か月後にもっといい技術が出てくる可能性
「なぜプログラミングは必要なのか」～プログラミングの2つの側面 - WirelessWire News（ワイヤレスワイヤーニュース）
さる12月2日、「なぜプログラミングは必要なのか？」と題したシンポジウムが開催された。先日、主催者のアスキー総研取締役兼主席研究員である遠藤諭氏にこのイベントを開催するにいたった思いを語っていただいたが、本稿では、当日の登壇者の発言を交えながら、「なぜプログラミングが必要なのか」について考えてみたい。 当日は、15名の登壇者が4つのセッションでそれぞれ異なる角度から「プログラミング」について語るというものだった。5時間の長丁場、飽きることなく興味深い議論が展開された。 檀上にいないサイレント・マジョリティのプログラマー達 なぜプログラマーはプログラマーになったのか。最初のセッション「プログラミングの重要性」に登壇したまつもとゆきひろ氏（Rubyアソシエーション理事長、アスキー総研主席研究員）は「コンピューターが教えた通りに動くのがかわいい、楽しいと感じた。ラジコンのように操作した通りに動く
ネット時代には「読み書き」を学ぶようにプログラミングを学ぶ必要がある - WirelessWire News（ワイヤレスワイヤーニュース）
12月2日、アキバホール（東京・秋葉原）にてシンポジウム「なぜプログラミングが必要なのか」が開催される。なぜ、今「なぜプログラミングが必要なのか」を問うのか、主催者である角川アスキー総合研究所取締役主席研究員の遠藤諭氏に聞いた。 「ソフトウェアが何をしているか」を知り、表現する力の源 ――なぜこのようなイベントをやろうと思われたのでしょうか。 遠藤氏：理由は２つあります。１つは、「誰もがプログラミングを学ぶべきだ」という議論がいま盛り上がってきていること。ネットやデジタルの時代に個人がどうやって生きていくか、企業や学問分野がこれからどうやっていくかを考えてみると、プログラミングは、"読み書き"に匹敵するベーシックなことだと思うのです。ところが、今の日本には、漫然とそれに対処しようとしない空気がまだある。時代は変わったのに、あたかも蒸気機関で世の中をまわそうとしているようにしか感じられないと
IT業界にも蔓延する「偽装表示」 | スラド IT
先日食材についての「偽装表示」が話題になったが、IT業界でも「偽装表示」が蔓延しているという（Tech総研）。 エンジニアへのアンケート調査によると、「バグを仕様と言い通した」「想定外の試験結果に対し、資料を修正して対処した」「仕様通りでないものに対し設計書を変更して正しいこととした」といった仕様に関するものや、「契約どおりでない納品物をこっそり納品した」、「実施していないテストを実施したと偽った」といった納品物に関する作業に関するものなどが実際にあった「偽装」案件として紹介されている。 また、「保有していない資格を保有しているとして業務を請け負った」「工数を削減したにもかかわらず費用はそのまま」「下請け会社の社員を自社社員のように見せかけて受注」など、悪質な話も掲載されている。 読者皆様はIT業界の「偽装」に直面したことはあるだろうか？
「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログ
<追記> 追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949 エクセルでできることができない何百万のシステム・・ 多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。 オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。 大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。 まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。 本当にやりたいことを見つける システムの要件定義のキモは 必要なこと やりたいこと やらない
システム化の目的は、Excelの焼き直しであってはならない - GoTheDistance
これは興味深い問題提起。 エクセルでできることができない何百万のシステム・・ 「Excelで出来ることが出来ないシステムとかいうものに、なんで数百万も突っ込む必要があるのか」という話には、キチンと整理して説明できるようにしておきたいもの。 機能面ではExcelには勝てない Excelが提供している豊富な機能群は、世界でも選りすぐりのソフトウエア開発チームが途方も無い期間と金額をかけて作り上げたものです。Excelで出来る機能と同等の機能を提供することは、納期も予算も上限がある業務システム開発プロジェクトにおいて、非常にハードルの高い機能要件でしょう。業者からすると「ウサイン・ボルトに100m走で勝利しろ、期間は2ヶ月で」って言われても的な・・・ でも、「Excelとかいう最強の業務ソフトと同じこと望むなよ、そんなもん無理」で突っぱねてしまうのも違う。Excelには無い価値ってどこにあるかを
システム更新による障害で、カリフォルニアの公営高速鉄道システムが数時間にわたって全面停止 | スラド IT
米カリフォルニア州の公営高速鉄道システム、BARTでシステムの更新に起因する障害が発生し、列車の運行を管理するコンピューターが数時間にわたって使用できなくなってしまったそうだ(ニュースリリース、 SFGateの記事、 SFGateの記事2、 本家/.)。 BARTはサンフランシスコとベイエリア各地を結び、平日は40万人程度が利用するという米国で5番目に大きい通勤電車システムだ。障害が発生したのは21日。システム更新は定期的に行われる通常のもので、適用直後には特に問題が発生しているようには見えなかったという。しかし、徐々にパフォーマンスが低下していき、12時間ほどたった深夜0時ごろにメインコンピューターがシャットダウン。終電前の時間だったため、ポイント切り替えを人の手で行うなどして運行を続けたとのこと。しかし、手作業でのポイント切り替えには5～10分程度かかるため大幅な遅延が発生し、翌午前3
【書評】なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術 - GoTheDistance
日本実業出版社の今野様より献本御礼。 なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術 作者: 細川義洋出版社/メーカー: 日本実業出版社発売日: 2013/09/27メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る 東京地方裁判所でIT事件担当の調停委員を努めておられる細川氏が、ご自身の経験をまとめてシステム開発のモメるポイントを整理し「人の振り見て我が振り直せ」を啓蒙する位置づけの図書になっております。 こう書いてしまうと非常に堅苦しいですが、モメるポイントをわかりやすく伝えるために「IT事例に詳しい美人弁護士に相談する」というカジュアルな設定になっています。塔子さんがその弁護士役で、厳しい指摘がコンビネーションブローのように続いており、爽快感がありました。 一部、本書の会話内容をご紹介します 彩音 「もう設計も終わる時期なのに、ま
まだ使えるXPパソコン 「住所録」の整理で復活 WinXPの遅い・重いを解消（下） - 日本経済新聞
2014年4月にメーカーのサポート終了を迎えるウィンドウズXP。長年使って「遅い」「重い」状態になってしまったXPパソコンを、最後まで快適に使い切るための方法を紹介します。前回の記事「出費ゼロ、厳選ワザで『XPパソコン』の起動速く」で採り上げたウィンドウズ・アップデートの履歴削除に続いて、今回は「不要な『レジストリ』の修復と最適化」および「常駐ソフトの停止や遅延」について解説します。レジストリの修復&最適化で動作を軽く
Blog vs. Media 時評 | デジタルデバイド問題が表面化した国際成人力調査
<< October 2013 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >> Profile Facebook dando Dando's Site これまでの記事閲覧は親サイト インターネットで読み解く!へ 《教育・社会》 《環境・資源》 生涯未婚なら《人口・歴史》!!! Japan Blogs Net…ブログ界を分野別に定点観測 サイエンスネット…幻ネット復刻 Japan Research & Analysis…英語版サイト Category 月別エントリー総目次 (45) 社会・教育・文化 (124) 政治・経済 (201) 食・健康・医療 (86) ネット (93) 科学・技術 (56) 資源・環境・災害 (191) 人口・歴史・スポーツ (38
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 9月12日と13日の2日間、都内で開催された日本におけるソフトウェア品質に関する最大級のイベント「ソフトウェア品質シンポジウム 2013」（日本科学技術連盟主催）の特別講演として行われたのが、米谷氏の講演「進化するIT組織と開発スキーム ～リクルートのサービス開発の事例紹介とともに～」でした。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（開発スキーム編）～ソフトウェア品質シンポジウム 2013
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（開発スキーム編）～ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。 本記事は「組織編」「開発スキーム編」「マインド編」の3部構成です。いまお読みのページは「開発スキーム編」です。 品質優先、納期優先、コスト優先など5つのスキームを用意 次は開発スキームについての話です。 プロジェクトを推進するときにはQCDについて、バランスとプライオリティで判断するの
この1年の優れたIT系書籍はどれか？「Jolt Awards 2013」が5冊を発表
デベロッパー向けに情報発信をしている「Dr. Dobb's Journal」が、この1年に出版されたIT系書籍の中から優れた本を選ぶ「Jolt Awards」が今年も発表されました。 選ばれた書籍を見てみると、まずNoSQLの書籍が入っていることにやや驚きます。しかも著者の1人はあのMartin Fowler氏です。米国では引き続きNoSQLに熱い視線が注がれているのですね。 2冊目のTeam Geekは日本語版が出版されていたので、そちらを紹介しています。これは多くのエンジニアが読みたいテーマではないでしょうか。また、5冊目のリーンUXもチームによる開発について触れられているようです。そのほか、テキスト処理、.NETにおける依存性注入と、どれを見ても濃いテーマが並んでいます。 （以下の各書籍の紹介は、Amazonでの紹介をざっくり訳したものです）。 Jolt Awardsを受賞した5冊の
どっちの言い分もわかる気はする。 発注側はどんなものができるか製品がわ..
どっちの言い分もわかる気はする。 発注側はどんなものができるか製品がわからないのに製品代を出したくない。 受注側は製品を設計する事は片手間でなく本業のうちだから設計の代金が欲しい。 すれちがう原因はお互いにあって、 発注側は大量生産品や「設計済み」の受注生産品を買う認識でいること。つまり設計の労力を過小に見積もっている。 受注側は相手がシステム開発の発注について熟知してることを前提にしていること。つまり設計の手間が工業製品とはまるで違い、設計が仕事のメインだと顧客に認識させずに話をすすめている。 これが原因だ。 システム開発の大部分の労力は設計にあるといってもいい。 要望を満たすために「顧客が事細かく話した内容をシステムに落とし込んだらどうなるのか、どんな画面でどんな印刷物がでて、顧客ごとのの入金の流れとか、その他諸々がどんなふうになるのか」を考えることがシステム開発のメインとなる作業だ。
ITエンジニアのCAPの定理 - from scratch
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ベテラン製造マン、iPadを大いに使う――タイの日系工場にみるタブレット持ち込みの効果
IT業界関係者がトラブルの再発防止で「なぜなぜ分析」に大注目、無くならないヒューマンエラー
システム構築での「ヒヤリハット事例」ビデオ、恐ろしいと話題に | スラド IT