System of Record と System of Engagement補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802
エリート集団が「あいさつ」にこだわった理由
「IT（情報技術）部門の人はね、ちょっと元気がないんですね。朝のあいさつもなくて皆すーっと席について端末に向かってしまって。だから職場がしーんとしてて活気が感じられない」。以前ある大手企業のCIO（最高情報責任者）にインタビューした際に、こんな話を聞いた。営業部から転じてシステム部門を統括する立場になったそのCIOは、着任早々、部下たちの覇気のなさにショックを受けたが、その象徴として語られたのが「あいさつレス症候群」だったわけだ。 このCIOの場合、営業時代の職場では朝のあいさつが徹底されていたということだったが、実際のところ「あいさつレス」は様々な業種、職種に広がっているように感じる。営業部門では「朝から立ち寄りが多く、出社時間がばらばらなので」という理由で、研究部門では「理系で内向的な人が多いので」という理由でやはりあいさつが少ないと聞いた。若手が多い職場では「最近の若い人はそもそもあ
優れたチームのリーダーは自らが効率化を求めるべきではない - 思っているよりもずっとずっと人生は短い。
メモ。 メンバーが優秀であれば、最適化は原則メンバーに任せるべき。リーダーのするべきことは、評価関数を作り、示すこと。 ある程度以上の権限を持っているリーダーは、いざとなれば評価関数を自由に設定・変更できるはず（状況によってはそれをしなければならない立場にある）。そういう役割の人間が「勝ち」を求めるのはよろしくない。そうではなく、適切な勝利条件を示し、そこを目指せばよいとメンバーやその他関係者に示すべき。そしてそこを目指すことはメンバーに委ねる。 メンバーが優秀であればメンバーがなんとかしてくれるし、メンバーの力に余るのであればリーダーだけが頑張ったところでどうにもできない。 メンバーが優秀でない場合、メンバーに合わせて評価関数を変えるか、評価関数に合わせてメンバーを変えるべき。どちらが良いかは、プロジェクトの目的、あるいはプロジェクトを実行することの目的（プロジェクトに対して一つメタな目
安物買いの銭失い...開発をアウトソースしてはいけないという事例 - masayang's diary
機内で読んだWall Street Journal（紙媒体版）2007年12月7日金曜日A1面の記事より Boeing Scrambles to Repair Problems With New Plane 要旨 次期旅客機787Dreamlinerの開発が遅れている 最大の理由は自社開発ではなく、アウトソース活用を試みたこと 機体の設計開発をアウトソースしたのはボーイング91年の歴史で初の試み アウトソースした理由 機体素材に炭素繊維を使う787は基礎研究だけで大きな投資が必要だった 開発投資額は100億ドル(1兆1000億円)に達する 開発投資を抑えるため、部品供給メーカ達に設計開発を委託（アウトソース） 発生した問題 多国にまたがるアウトソース 言語の壁 米国では想定していなかった各種規制 孫請けに仕事を分散させることによるオーバーヘッド 同じ企業なら会って話せば済むのに、大量の文書
開発プロセスを設計するという発想 - プログラマの思索
最近興味があること。 それは、「開発プロセスを自由自在に設計して、運営できるか？」ということ。 こんな本「SEの仕事を楽しくしよう」を読んでみて、色々と考えさせられる所があった。 RUP、XP、CMM/CMMI、ソフトウェアプロダクトラインなどを聞きかじって、自分で少しだけ試してみた経験を振り返ってみて、考察してみる。 【１】新規開発と派生開発～ＩＴ業界特有の開発プロセス 開発プロセスを勉強すると必ず「ウォーターフォール型開発よりもインクリメンタル型開発の方がいい」という文句に良く出る。 でも、実際の現場では、ウォーターフォール型開発でもインクリメンタル型開発でも、プロジェクトを制御できていない。 その原因は、2種類の開発プロセスがある事実を知らないことにあると思う。 最初からスクラッチ開発する時は、小さなサイクルでウォーターフォール型開発を行う時が多い。 最近なら、オブジェクト指向言語で
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
満足せる豚。眠たげなポチ。:なぜ顧客は受入テストで仕様変更に気がつけるのか？
「リーンソフトウェア開発」P219から。 システムが、顧客の意図どおり動くことを確認するテストは「顧客テスト」という名前で呼んだ方がよい。それは、テストの目的が、顧客がシステムに期待したとおりシステムが動くことを確かめるためだからである。 そう。そのとおりだ。そして、本書ではその顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチを取る。 その主張も正しい。一つの解決策として非常に参考になる。 だけど、ここで一つ大きな疑問がある。顧客はなぜ「顧客テスト」をするとしっかり仕様の漏れ、ミスを発見できるんだろう？ ちょうど今日もそうだった。すでにシステムはリリース間近。まさに「顧客テスト」が行われていた。そして発覚した仕様の漏れ。 その対応自体はけっきょく事なきを得たのでここで話題にはしないけれど、不思議なのはその仕様はけして「ビジネス環境の変化」で昨日今日浮上した
角谷HTML化計画 - Kent Beck "Trends in Agile Development"
■1 Kent Beck "Trends in Agile Development" アジターソフトウェアジャパン主催のAGILEフォーラム2006。セミナーの詳細は報道なり、英語が得意な人がまとめてくれることに期待。自分なりに勝手に乱暴にまとめると、ヒーローでもなければ世捨て人でもない普通のプログラマは善く生きるべきだ。正直は割に合う。不遜なことを言えば、だいたい昨日の招待講演でしゃべったことと同じ(w メモラブル・クォート: "Defect is a choice." (文法合ってる?) "Testing is my responsibility." どうみてもスーツなセミナーであるにも関わらず、壇上の腰リールを下げたKentBは、一貫してプログラマに向けて話していた。カッコいい。KentBの後のセッションはアジャイル事例とかテスト重要とかいった話題。しかしなんだろうね、この、そこはか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
http://spring-net.jp/blog/2006/09/it_1.html