オリンパス事件と日本企業のコーポレート・ガバナンスの欠如と
オリンパス事件は、タックス・ヘブンであるケーマン諸島に席を置く会社が出て来た時点で何かあるとは思っていたが、やはり不正会計であった。 注目すべきは、「バブル期に株式投資で失敗したこと」が悪いのではなく、「その投資の失敗を株主に秘密にしたこと」である。誰にでも失敗はあるので仕方が無いとしても、上場企業であるオリンパスの経営陣が投資の失敗による損失を株主から隠したことは、明らかな「犯罪」である。 ホリエモンが投獄される事になった不正会計が「スピード違反」であるならば、オリンパスの損失隠しは「ひき逃げ」に相当する重罪である。当時の責任者は、当然、投獄されるべきである。 ちなみに、問題の本質は、経営陣がこれほどまでに悪質な不正会計をしながら、それを監視する仕組みが全くなかったということ。米国の会社であれば、株主を代表する取締役会が経営陣の上部組織として監視をするのだが、取締役会が基本的に社内の重役
進捗会議はなかなか進まない - rabbit2goのブログ
進捗会議と称する打合せに参加すると、その開発チームの状況がよく分かる。「分かる」と言ってもその報告内容ではない。チームの実情をよく示しているのは、むしろ、その打合せの進め方だったりする。 例えば、状況が宜しくなく、課題山積みのチームで良く見かける光景はこんなものだ。 リーダがチーム全体の状況を把握しておらず、打合せの場で初めて状況を理解している。 やたらと会議の時間が長い割に、発言する人は限られている。 当事者間でしか分からない個々の問題に関する議論が延々と続いてしまう。 問題の事後対応の報告ばかりが続き、事前対策等の前向きな話が全く出てこない。 先週の打合せで出たアクションアイテムをフォローしないし、そもそも誰も覚えていない。 今後の工程、予定、展望についてリーダの発言が無く、チームが進む方向性が見えない。 議事録の記載内容がお粗末なので、参加者以外には内容が全く理解出来ない。 会議が終
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
弊社東京オフィスの完璧な危機管理対応について - やまもといちろうBLOG（ブログ）
このような話がtwitter上に流れておるわけです。 http://twitter.com/#!/neohawk/status/116397707832197121 [引用]今までウダウダしてて、今から帰宅指示とかいう会社は早めに止めたほうが良いよ。状況把握能力と判断力に欠ける＝経営もヤバいでしょ。 弊社の場合はというと、まずシャチョーであるわたくしが運良く長期海外出張で東京に不在。取締役である伊藤さんが腰痛のため今日はお休み。同じく取締役である根津さんは日々重役出勤のため、会社にそもそも辿り着かず不在。つまり、取締役は全員会社に不在。 埼玉の僻地で暮らすもっとも遠い営業幹部は風邪のため午前半休中。若手社員は一個前のプロジェクトでアホほど溜まった代休を絶賛消化中。残りの社員はTGS明けで企画書納品や受注作業を進めている状態でありました。ということで、管理部社員が台風禍について話し合い、社と
システム開発におけるフリーマンの役割について : mwSoft blog
という資料を捏造したい気分だったので書いてみた。特に意味はないしオチもない。 フリーマンを置く目的は、以下である。 ・システムの品質向上 ・プロジェクトに潜伏している問題の早期発見 ・メンバーの技術レベルの把握と向上 フリーマンは明確なタスクを持たず、名前の通り、手の空いた状態でプロジェクトに携わるエンジニアである。 システム開発におけるフリーマンが行うべき主な作業は以下である。 ・ソースコードレベルでの問題の発見と指摘 ・テストコードの不足分の拡充 ・仕様が曖昧且つ後日問題となりそうな点の明確化 ・メンバーの技術レベルの把握と作業分担の適正化 フリーマンは直接コードは書かない。その代わり、製造されているすべてのソースコードを把握し、問題があれば指摘を行う。 また、技術レベルに問題があるメンバーがいる場合は、指導もしくは適切な作業の割り当てを提案する。 フリーマンの存在が効果を発揮するのは
安全策が後手後手を生む - レベルエンター山本大のブログ
場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を選んでしまうことは、 「現実をみた大人の意見」のように思えるかもしれないが、 僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。 保守で、既存プログラムの修正をやろうという後輩から相談を受けた。 既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。 メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。 僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。 後輩は、我が意を得た
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
僕なりの業界の変え方 - レベルエンター山本大のブログ
僕は開発現場にも出ていますが、ITの講師もしています。 毎年4月には、他社さんの新人教育を担当しています。 教え子たちにはJavaの基礎と共に、この業界の問題点についても教えます。 技術の空洞化や、大手SIerのゼネコン化についても教えます。 若年層から「マネージメント経験」と称して、 人のマネージメントをやらせ、 技術のマネージメントができず、実質はただの人材ブローカーに なってしまっている現実についても教えます。 君たちの入った業界には、こういった問題がある。 君たちの入った会社にも、恐らくその問題はある。 料理をしたことの無い人が一流シェフにはなれないし、 厨房を仕切れはしないし、レストランの経営もできないんだ。 IT業界も同じだ、とも教えます。 教え子らの中には、ショックを受ける人もいます。 夢と希望を持って入社してきた人もいるからです。 こう付け加えます。 「正しいことをしたけれ
上流でもプログラミングを意識するべきだ。そしてプログラマも上流について知るべきだ。 - レベルエンター山本大のブログ
先日のエントリのとおり、僕は上流工程でもプログラミング技術のことを考えておくべきだと考えています。 それとは反対に、プログラマも要件のあいまいさについての認識を持ち、 要件の本質の追求方法について知っておかなくてはなりません。 なぜなら、言われたとおりに実装だけを行うという行為は、プログラマの地位を下げるからです。 プログラマを取替え可能な部品だという地位にしてはいけません。 過去に出会ったすばらしいプログラマは、例外なくすばらしい要件分析者でした。 例えば、すばらしいプログラマの多くは、実装に入る前に仕様を一読して、 その矛盾を突いて先手を打ちます。 このスキルを身に着けるには経験や洞察力も大事ですが、それだけではありません。 なぜ顧客の要件はぶれるのか?なぜ仕様は根本から覆るのか？を知り、 また、どうすれば本質的な要件を引き出せるのかを知れば、 顧客が本当に求めている仕様を読み解くこと
できる人が偉く、偉い人ができる組織 - レベルエンター山本大のブログ
エンジニアばかりの組織の中では、単純明快なルールが一つある。 できる人が偉い ってこと 組織を強くするには、 偉い人ができる人でなくてはならない。 できるとは、テクニカルであってもいいし、マネジメントであっても、営業であってもいい。 「顧客の要件に答えることが”できる”」能力を持ってる人を「できる」と呼ぶ。 エンジニアは、単純明快にできるできないかを判断できる。 ここに一つの力学があり、これを無視して組み立てても到底上手くいかない。 部下も不幸だし、尊敬を得られない上司こそ不幸だ。 偉い人には情報が集まる。 集まった情報を上手くさばくにもできる人でないとつとまらない。 それから僕は、年功も加味したいと思う。 年功をまったく加味しないのは「年功序列 VS 実力主義」を意識しているせいだろう。 けど、それは過剰な反応だと思う。 在籍年数という数値には、ひとつの力があると思うからだ。 だから、パ
ただただコーディングの喜びを書いた日記 - レベルエンター山本大のブログ
いや〜、なんといってもコーディングが好きだ。 今年32歳になるし、会社では重い肩書きがついてしまったけど、 コーディングができるって、すばらしい。 要件定義や設計も面白い部分はあるし、マネージメントも悪くないけど。 なによりもコーディングが最高だ。 もしも僕が独断で会社を動かせるなら、 偉くなっていくほどにコードを書く時間を長くできる会社にする。 だってこんな楽しいこと部下にやらせておくのはもったいないやん。 部下の人は、要件定義や設計から下積みしなさい。 マネージメントとかも下積みの一環でお願いね。 野球少年だって、プロ野球選手になるときに監督を目指してなるわけじゃないでしょう。 野球がしたいんだ。一流の野球選手になりたいんだ。 プログラマーになろうと思ったわけで、マネージャーになろうと思ったわけじゃない。 まぁ、マネージャーも楽しいってことは分かったけど、コーディングのほうが楽しい。
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
概要設計工程でRedmine導入してみた事例 - T/O
やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの？ チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが
これはおもしろいな - 思考のスキマ
品質保証最近は手動テストとかのつまらんクソ仕事にウンザリして、なんとかもっと楽して、かつ正確さを向上させられないかと常に考えているけど、そんな中でこのような記事を発見した。よくわかりやすく書かれているし、大変おもしろい。 @ITの連載記事「山浦恒央の“くみこみ”な話」http://monoist.atmarkit.co.jp/fembedded/index/kumikomi.html 例によってサボリ中なので真面目にはあとで読むつもり。最近はテストの理論とJUnitを集中的に自習していて、これが意外と楽しい。それが終わったら一旦日記にさらりとまとめた後、さらにメトリクスの理解をもう少し深めてから、Redmineのタスク管理手法について次の本を買って勉強するつもりだ。Redmineによるタスクマネジメント実践技法作者: 小川明彦,阪井誠出版社/メーカー: 翔泳社発売日: 2010/10/13
プログラマが知るべきではない97のこと - Cube Lilac
プログラマが知るべきじゃない97のこと - Togetter を読んでいたら面白かったので，赤文字で強調されているものを抜き出して適当に並べ替えてみましたｗ ちなみに，元ネタは プログラマが知るべき97のこと です．類似ネタの プログラマの嫁が知るべき97のこと，プログラマが体験するべきではない50のこと も併せてどうぞ． サーバ室に祀られた盛り塩の存在意義 言語やエディタ、IDE を disる と勃発する聖戦 VSS Boost プリプロセッサ PHP brainf*ck Lisper の態度 他言語のプログラマの Lisp へのイメージ 人月計算 エクセル方眼紙 受注確定と同時に赤字が確定していた 受注時に営業が顧客に提出した資料 見積書に勝手に足された項目の意味 この仕様が誰の気分で決まったのか 今必死で実装しているその機能が実は PM の好みで追加された仕様であること 依頼されたア
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
速さはすべてに勝る - 速さを身に着けるための５つのルール - 読んだものまとめブログ
時間をかけてじっくりやることは誰にでもできます。ただ、速さを意識しない人はパフォーマンスが非常に悪いということを認識しなければなりません。ああでもないこうでもないと試行錯誤を繰り返している間に好機を逃して、時代遅れの答えに努力を重ねる結果になります。日進月歩の情報化が進んだ今の時代に学歴、資格、技術があっても『速さ』がないのは有る意味で致命的ともいえます。遅ければ何事も後手に回り、やるべきことが級数的に増えて手に負えなくなります。 図解 超高速勉強法―「速さ」は「努力」にまさる! 作者: 椋木修三出版社/メーカー: 経済界発売日: 2004/11メディア: 単行本購入: 41人 クリック: 500回この商品を含むブログ (45件) を見る 速度が落ちる理由 昔と異なり、大卒が溢れている今では既に知識が豊富な人が揃っているわけで、その知識を活かす場が存在しないというより足枷になっていると言わ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インドアジャイル西遊記 | オブジェクトの広場