[結] 2005年8月 - 結城浩の日記 - テストが困難な性質
目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日
やってはいけない、設計と実装の並行作業
“常識的な判断”って何？ 前編（「コレだけ準備すれば分散開発に失敗しない」）では、（遠隔）分散開発に携わる、アーキテクチャやチーム運営、設計手法に主な視点を当ててきました。後編ではむしろ、実装からリリースまでのより現場の中で起きていたことに焦点を当ててゆきます。この分散開発中に東京の元請けから発せられた言葉で非常に印象に残っているものがあります。興味深いと思われるので紹介します。プロジェクトの初期に画面設計書の記述をするに当たって、仕様の確認をしていたときに顧客から“そこは常識的な判断でお願いします”と仕様の不明確な部分に関して言葉を濁されてしまったことが何度かありました。 システムを作るうえで“常識的な判断”って何でしょうか？ 複数のラジオボタンが並んでいてもある人は当然単一選択だと思い、また別の人は複数選択できるかもしれないと考えるでしょう。この企業間、個人間の“常識”という言葉の食い
「はじめてのプロジェクトマネジメント」はお買い得
良い本に出合えてうれしいので、報告。枕詞「入門」「やさしい」が付く本はハナから使えねェと思っていたが、「はじめてのプロジェクトマネジメント」は優れた一冊。ただし、下手な小説仕立ての小話がなければもっと良し。 PMの入門書をイチから書くと、どうしても底本（PMBOK）のダイジェストになる。ところが、これは「実用企業小説 プロジェクト・マネジメント」のエッセンス本なので、より実践的なツールが紹介されている。二番煎じという声もあるが、これだけのノウハウが880円なのはコストパフォーマンスが非常に良い。 また、このテの本にありがちなのが、エラそうに一席ぶっている筆者の経験の「狭さ」「浅さ」を垣間見て思わず微苦笑を招くこと。しかし、この著者は本物の（残虐非道プロジェクトを潜り抜けかつ生き残った）人だなぁ、と気の毒に思った。なぜなら彼のいうプロジェクト成功要素の一つに、「犠牲者を一人も出さないプロジェ
生産管理講座 - トヨタ生産方式
トヨタ生産方式とは トヨタ生産方式の全体像は、いまだ公開されたことなく、“トヨタ生産方式”を標榜するコンサルタントによって断片的に知ることができるだけである、と言われている。 1980年代にアメリカで行われた日本の自動車産業研究でも、トヨタ生産方式を理想化し、リーン生産方式と名づけたが、トヨタ生産方式を理解しているかどうかは疑問である。 こんなエピソードがある。かつて米ビックスリーの１つだった旧クライスラーの会長兼最高経営責任者(ＣＥＯ)のロバート・イートンは、94年の年頭会見で、｢我々は日本メーカーに負けない生産効率を実現した。もはやトヨタに学ぶものはない｣と発言した。 コンサルタントを雇ってトヨタ生産方式を自社工場に導入し、大幅な生産性向上を果たすことに成功したからだ。 その数ヵ月後、クライスラーの１人の幹部が｢トヨタ生産方式を完全に学びとったかどうか確かめたい｣と、米ケンタッキー
IT屋のトヨタ生産方式：An Agile Way：オルタナティブ・ブログ
『実践!!IT屋のトヨタ生産方式―あるソフトウェア会社の挑戦』 http://www.amazon.co.jp/exec/obidos/ASIN/4833151472/xpjp-22 アマゾンにも並びましたね。いやー、熱いです。 最初のページをめくると、そこにはＶＭボード（ビジュアルマネジメントボード）がたくさんあります。とにかく「見える化」です。ぼくもお邪魔してアジャイル開発のコンサルをさせてもらってましたが、トヨタ生産方式とアジャイルって、実は同じことを言っていることが多いんですよ。そして、「改善塾」という中堅社員の巻き込み方はとても参考になります。 やっぱい、ものづくりは、人づくりなんですね。
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
CGIベースからHTMLベースへ移行する際のメモ
目次 2005年6月28日 - 時間がないときの朝の祈り / 2005年6月27日 - 仕事 / 2005年6月23日 - 失敗 / 2005年6月21日 - 今日も仕事 / 2005年6月20日 - 仕事のかけら / 2005年6月18日 - The Hyuki Support Team / 2005年6月16日 - Musical Baton (ミュージカル・バトン) / 2005年6月15日 - RSSに全文入れるときの注意点 / Yuki::Kakeraの修正 / CGIでRSSをフィードする工夫 / アクセスログで移行作業の効果調べ / 2005年6月14日 - 仕事 / 声のかけら。のRSSをファイル化 / 2005年6月13日 - まじめに仕事 / 2005年6月12日 - RSSフィードに全文を入れる / 2005年6月11日 - 二重の虹 / 2005年6月10日 - 自
先輩エンジニアが心得ておくべきこと（前編）
研修を終えた新人たちが現場にやってくる。皆さんの中には、先輩エンジニアとして彼らを指導する人も多いのではないだろうか。新人を迎え、指導するために必要なのは、相手を知り、自分を知ること。新人と自分との間にあるギャップを意識し、成長の手助けをしよう。それが先輩エンジニアとしての心得だ。 新入社員を迎えるに当たって こんにちは。「5月病」の時期も終わり、いよいよ梅雨に入ろうかという季節になりました。皆さんの部署には、今年は新入社員はいらっしゃいますか。ここ2～3年の緩やかな景気の回復に伴い、いままで凍結していた新卒採用を再開した企業も多いのではないかと思います。6月ともなると、研修を終えた新入社員たちが皆さんの部署にも配属されてくるのではないでしょうか。 新入社員を迎え入れる先輩となる皆さんの中には、メンターやOJTリーダーに任命される人もいらっしゃることと思います。新入社員を迎えるに当たって、
わたしが知らないスゴ本は、きっとあなたが読んでいる: ブログでプロジェクトマネジメントする10の方法
マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開
＠IT：初めてのプロジェクトリーダー（4）開発中、リーダーは何をしている？
1週間単位で、タスクと日付の交差する場所に担当者の名前を書き、完了したタスクには印を付けていきます。また、重要なマイルストーン（イベント）も同時に記入し、いまの作業は何を目的にして行っているのかを明示します。この例ですと、5月12日のデモに向けて各タスクを進めていることがよく見えます。 納期にかかわらず、開発メンバーは目の前のこと、いま作っているプログラムに意識が集中します。このような場合に、タスクの相互関係、タスクの組み合わせが達成する目的をはっきりと見せて、メンバーに期限優先の意識を持ってもらうことが狙いです。これはよくあるスケジュール表（ガントチャート）ですが、印刷して配布するよりも、このようにかんばん化して掲げることの方がより効果的です。 どのようなかんばんを使う場合でも、掲げただけで満足しないことが重要です。上手に機能するまで、時と場合に応じてかんばんと、その運用を改善していく必
＠IT：開発プロセス標準化への道（2） 開発プロセスは継続的かつ段階的に改善すべし
今回は、継続的、段階的なプロセス改善についてお伝えしたいと思います。皆さんの中には、「継続的、段階的なプロセス改善」と聞くと、CMM（I）を瞬間的に連想される方もいると思います。そのように連想される方は、おそらくCMM（I）を正しく理解されている方だと思われます。ところが、いろいろな方と話をしていると、CMM（I）を何かライセンスのようなものと勘違いしている方が多く、せっかくの良いものが正しく理解、活用されていないなぁと残念に思うことがよくあるのです。ただ、今回は、CMM（I）に特化した内容ではありません。もっと基本的で、しかも、このことをみんなが理解したら、ITプロジェクトの現場がもっとハッピーになる、そんな話です。 究極の目的は、全員の成長 前回、「開発プロセスの標準化は、開発力を高めるための取り組みの1つにすぎない」ということを書きました。そして、標準プロセスは、参照はするけれど絶対
JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]
代表中山陽平 ブログ「苦手意識を無くせばWeb活用はうまくいく」弊社では「がんばる中小企業」のWeb活用をサポートしています。今の時代、第3者である、制作会社や代理店におまかせでは勝てません。同じような商品・サービスが溢れる中、選んでもらうためのコンセプトを立て、それを実現するためにネットもリアルも総動員しながら戦う必要があります。 みなさんが世の中に・自社の従業員に実現したい幸せや提供価値を、しっかりと実現していくためには、みなさん自身が主役になり、私達のような専門会社が側面支援するのがベストです。 このブログでは御社が中心となってウェブ活用できるヒントを配信しています。お悩みの方はお気軽に問い合わせフォームからご相談ください。 最新の記事一覧
![JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e43158a9b02ff4438d55128491865b833395bd4d/height=288;version=1;width=512/https%3A%2F%2Froundup-inc.co.jp%2Fwp-content%2Fuploads%2F2019%2F09%2F9106fa4d7b0fdf2534aa97dea102e186.png)
上司が求めるのは、「カイゼン」であって、「カイカク」ではない。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日のブログで、「上司の頭の中」という話をしたのですが、今日は、じゃあ、上司はなにを部下にもとめるのか？という話。 それは、結局 今ダメな状況を変えるのに、 新しいことや、追加して何かをやるカイカクではなく、 今やっていることを、「自分の権限の範囲で」よりよく変えていくカイゼン を求めているような気がします（自分が上だったとき、下のとき、両方比べて考えると） やっぱり、今の与えられた仕事がこなせないのに、「それは、いまの体制がわるい、こうかえるべきだ」と主張しても、仕事ができないから、言っているとしか思われないと思います。こう受け取られると、いいこといっても（その意見が正しくとも）評価さがると思います（＝自分のできないのを棚に上げて、言い訳してるように聞こえるから）。 今の仕事を
[を] アナログ進行管理システム「あしか」を導入
アナログ進行管理システム「あしか」を導入 2005-04-08-4 アナログなタスク管理「あしか」 <http://d.hatena.ne.jp/jkondo/20050331> - タスクカード：コピーの裏紙など - 進行管理箱：ダンボールを四つ（終わった、すぐやる、そのうちやる、 ペンディング）に区切ったもの やっぱ（ある種の）ToDo管理はアナログが最適だよなあ、と思いつつ、 会社の机は散らかってて箱を置く隙間がない問題。トレーを使ってやる 方法[2003-12-28-3]なんかもあるけど、これもまた場所を取る。 とはいえ「とりあえずやってみる」というのが私の方針なので、 小さな箱を作ってさっそく導入。どうなるか。 一説では「はてな しんこう かんり」で「はしか」だったのが「あしか」 になったらしいです。 「あなろぐ しんこう かんり」で「あしか」、という由
朝会を15分で終わらせるには理由がある
前回（第2回 「なにはともあれ、まずはチームビルディング」）はチームの基本的な作り方を解説しました。今回のテーマはチームの運営に不可欠な「会議」の上手な行い方です。 会議・会議・会議 プロジェクトにかかわる以上、会議は避けて通れません。特にリーダーなら、なおさらです。いままでは、どこかしら「関係ないや」と感じていた会議にも参加しなくてはいけません。会議にも大小さまざまありますが、今回はその中から、「朝会」「進捗（しんちょく）会」を取り上げて、それぞれの運営のコツをお話しします。 ・朝会 まずは小さな会議代表として、朝会です。朝会は、チームの状況をチーム内部で素早く共有することを目的とした、非常に短時間の会議です。最近何かと話題の朝会ですが、その理由として、「手軽に、すぐに始められる」「効果が見えやすい」「ソフトウェア開発チーム以外にも有効」などがあるでしょう。以下、概要だけ説明します。 朝
プロジェクトファシリテーション実践編：ふりかえりガイド
ここでは、PF=Project Facilitation(プロジェクトファシリテーション)について議論しています。 プロジェクトを活性化し、楽しくプロジェクトを成功に導くための、実践的な課題を扱います。 プロジェクトの成功に大切なものはなんでしょうか？ 個々人のスキルは重要です。そして、ここで取り上げるのは、集まった個人のスキルを１００％以上に発揮させるチーム作りとしての、「プロジェクトファシリテーション（PF）」です。 プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チーム
ITエンジニアを続けるうえでのヒント
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■ITエンジニアの経験年数と悩みとの関係 ITエンジニアとしてのキャリアは何年になりますか。連載の第1回の冒頭としては乱暴か書き方かもしれませんが、皆さん、いかがですか。 3年以下であれば、悩みはまだ少ないでしょう。石の上にも3年とはよくいったものです。まずは3年を目安に無我夢中でキャリアを磨いてください。3年持たない人はエンジニアに向いていないのでしょう。多くのITエンジニアを私は見てきました。その中で、ITエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】(後半)
目標管理ツール - checkpad.jp
笑わないプログラマ - 【軍曹が】携帯電話開発の現状【語る】