問題解決能力（Problem Solving Skill)：自ら考え行動する力 - ある組込みソフトエンジニアの日記
正月休みに『世界一やさしい問題解決の授業』（渡辺健介著）という本を読んだ。 いつものように、まえがきを紹介したいと思う。 【世界一やさしい問題解決の授業のまえがきより】 みなさんの将来の夢は何ですか？ 今どのような悩みがありますか？ 壁に直面したとき、自分の力で乗り越え、人生を切り開いていけるという自信はありますか？ それとも、あきらめてしまいそうですか？ この本で紹介する「考え抜く技術」、そして「考え抜き、行動する癖」を身につければ、たとえば苦手な教科を克服する、部活でよい成績を残す、文化祭を盛り上げるといった、日常生活で直面するさまざまな問題を解決できるようになります。そして、自分自身の才能と情熱が許すかぎり、夢を実現する可能性を最大限まで高めることができるようになります。 つまり、自ら責任が持てる人生、後悔しない人生を生きることができるようになるのです。 どんなに大きく複雑に見える問
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
「『単調な仕事を自動化したい』という“態度”が技術者には必須」，永和システムマネジメント角谷氏 | 日経 xTECH（クロステック）
「『単調な仕事を自動化したい』という“態度”が技術者には必須」，永和システムマネジメント角谷氏 Developers Summit 2006（デブサミ2006） 「キー入力がやたら速かったり，記憶力がよかったり，機械的な作業を間違わずにできたりすることは，優秀な技術者になるのを妨げるかもしれない」。永和システムマネジメントの角谷信太郎氏は2006年2月10日，東京・目黒で開催された開発者向けカンファレンス「Developers Summit 2006（デブサミ2006）」の講演でこう語った。技術者には，単調な仕事をコンピュータにより自動化する「プロジェクト・オートメーション（PA）」の考え方が必須だという。 角谷氏は，オブジェクト指向やソフトウエア設計に造詣の深かった故 石井勝氏が，技術者の必須項目として挙げていた2項目をまず紹介。石井氏が挙げる「同じことを2度しない（Only and O
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
システム開発のプロジェクト・ファシリテーター (arclamp.jp アークランプ)
僕がやりたいことを説明するのに「システム開発のプロジェクト・ファシリテーター」という言葉を使ったことがあります。ファシリテーションを日本語にすれば促進。狭義には円滑に会議の進めるというのになりますが、広義にはチームの力を引き出すということで良いように思います。 さて、そんなファシリテーターですが、じゃ、それがシステム開発で可能かといわれると、実は悩んでしまうことがあります。それは本当に答えを見つけさせられるのか、ということです。 システム開発で答えを見つけるのは知識が必要 ファシリテーターがやることは、答えを与えるのではなく、答えを見つけさせることです。チーム全員で答えを見つけることで、チームの方向を定め最終的なあるべき姿を考えます。皆で相談しながらキャンバスに絵を描くようなものです。 しかし、システム開発においては、この"答え"というのが非常に難しい。もちろん見つけるというプロセスが重
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
プロジェクト・ファシリテーション－ファシリテータ型リーダの資質：An Agile Way：オルタナティブ・ブログ
プロジェクトの場作り（ファシリテーション）を行い、チームメンバーの能力を１００％以上発揮させ、１＋１を２以上にする、新しい形のリーダーシップが必要だ。そのたの人材像について、考えている。株式会社ITイノベーションに伺ったとき、Harvard Business Review をパラパラと見ていたら、こんな文章が！ 人々に学び 人々と一緒に計画し 人々が持っているもので始め 人々が知っていることの上に築きなさい。 リーダーが真に優れていれば、 終わってみると 人々は口々にこういう 「自分たちの力でやり遂げた」と。 －老子 うーん、まさに、これが理想だ。。。 ITイノベーションの林衛さんには、前回のオブジェクト倶楽部で主賓講演を頂きました。今回は、「ザ・プロジェクトマネジャーズ」のインタビューを私が受けました。 http://topic.promane.com/iti/dtdisp.asp?en
リーダーシップは天性ではない
連載内容のおさらい まずは連載内容のまとめとして、それぞれの連載内容の要約と、「どのような人が、どのようなときに読むと効果的か」を説明します。もちろん連載内容は、初回から順次読むと効果的なように組み立ててありますが、それぞれの回を単独で読んでも、なんらかの気付きがあるはずです。 第1回 開発者からリーダーへの視点の切り替え 連載初回は、プロジェクトリーダーが持つべき価値観と、従うべき原則論について説明しました。メンバーとリーダーでは全く違う視点を持つ必要があり、これらの切り替えが最も難しい課題となります。いままで何回かリーダーの経験があるけど、どうもチームがうまく機能していないと感じるリーダーは、まずは初回から読み進めてください。 第2回 なにはともあれ、まずはチームビルディング リーダーにとって、チームビルディングは最も重要な活動の1つです。第2回は、プロジェクトチーム計画書作成を通じて
かっこいいホワイトボードを教えてください。…
かっこいいホワイトボードを教えてください。 ・移動が簡単（重くない） ・書いたものが保存できる（紙でもデータでも可） ・かっこいい! ・べらぼうに高いのは困る 以上の条件に合致するものを探しています。
偉くない管理職
CNET Japan : ［近藤淳也の新ネットコミュニティ論］ 開発者が楽しく仕事できる環境とは http://blog.japan.cnet.com/kondo/archives/002275.html はてな近藤さんのブログは、最近いちばん更新が楽しみなブログのひとつだが、この最新エントリは特に面白い。 ＸＰのペアプロも、開発合宿も、残業しないメリハリ流も、「絵に描く」のはかんたんだが、はてなではちゃんと実践していて、効果をあげているというんだからスゴイ。 しかしそれにも増して、「偉くない管理職」というのが、個人的にはツボにハマった。 ＜人を管理する仕事は上司の仕事であり、社員は上司の管理の下で業務にいそしむ、といった上下関係ではなく、例えば開発者が「この案件を10日後に完成したいので工程管理をして欲しい」と若い社員に管理をお願いする、といったものです。実際に最近では、新しく入った社員
開発者が楽しく仕事できる環境とは:近藤淳也の新ネットコミュニティ論 - CNET Japan
立って会議をするだけでなく、はてな社内では他にも色々なことを試みています。その中でも、開発者が楽しく仕事ができるように、という観点でいくつか紹介してみたいと思います。 まずはペアプログラミング。これは、2人1組になってプログラムの開発を行うスタイルで、XP（エクストリームプログラミング）のプラクティスの一つとしても提唱されているものです。 2人でプログラムを開発するというのは、1人がプログラムを書き、もう一人が横からそれを見ている、という方法です。この方法を聞くと、1人がそれぞれの作業を行うよりも作業量が2分の1になってしまいそうな気がするものですが、実際はそれぞれが別々の作業をするよりも効率が上がる、という興味深い逆説的な現象が発生します。 ペアプログラミングの様子。こういうときはなぜかコーラが似合います。 なぜ2人1組でプログラミングをする方が1人ずつでやるよりも効率が上がるのでしょう
会議の無駄をなくそう - CNET Japan Blog - 近藤淳也の新ネットコミュニティ論
社内の情報共有についてあれこれ書いていますが、ちょうど先週からはてなで面白い取り組みをしていますので、まずそれを紹介したいと思います。 はてなでは毎朝開発陣によるミーティングを行っているのですが、先週からそのミーティングを「ユーザー参加型」にしました。 ユーザーさんにSkypeの会議通話機能を使ってミーティングに参加してもらう、という試みです。 これが会議の様子ですが、マイクでミーティングの音声を流しつつ、スピーカーからユーザーの声が聞こえるという仕組みになっていて、思った以上に普通に会話ができています。 先週から始めたこの取り組みには、これまでに2名のユーザーさんに参加して頂いていますが、リアルタイムで意見を聞けるメリットは予想以上で、今後さらに参加者を増やして続けていければと思っています。 会議の模様ははてなアイデア日記というブログからmp3ファイルのダウンロードも可能になっていて、P
『見える化への挑戦』～九州が熱い：An Agile Way：オルタナティブ・ブログ
福岡で行われた、デベロパー対象のセミナー https://rss.npo-aip.or.jp/com/mieruka_event.asp すごい講師陣。萩本さん、羽生さん、比嘉さん。 ぼくは羽生さんの「マジカ」を聞く、という目的が大きかった。やっぱりすごくおもしろいわ、これ。よく考えられているし、進化している。 飲み会で、縣さんから「会議の初めに自分の素直な気持ちを話す時間をとる」というアイスブレークを教えてもらう。意見、ツッコミ禁止。これを言ってから、各自会議に「チェックイン」すると。 マインドマップで今日の気づき共有を１０分だけやったが、失敗。後ろの人と話をして、というのが唐突すぎた感じ。時間も短すぎて、不完全燃焼。うまく導入しなければ。
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
プロジェクトの「ふりかえり」 -- Retrospectives by Norm Kerth：An Agile Way：オルタナティブ・ブログ
Project Retrospectives、とはプロジェクトを全員でふりかえり、そこで何が起きていて、メンバーがどう感じたのか、をあぶりだすファシリテーション技術である。プロジェクトの途中で次のフェーズに有用なアウトプットを出すという使い方もあるし、プロジェクト終了時に、全員の健闘を称えあい、次のプロジェクトに生かす、という使い方もある。 私は「反省会」（ちょっとネガティブな感じ）と訳さずに、「ふりかえり」と訳すことにしている。 「ふりかえり」が、従来の「反省会」や「問題分析会議」と違うのは、それが全員参加で、かつ、参加者の「感情」部分の働きかえるものであり、建設的だ、ということ。誰かを非難したり、問題を抽出することが目的ではない。メンバーが、次のステージへ向かうための勇気を得ることが目的だ。だから、Norm が最初に書いているグランドルール、 「この会では、プロジェクトの全員が置かれた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to destroy commitment and motivation
Dorset House Publishing - Norman L. Kerth
Back to Basics: A Retrospective on Retrospectives – thekua.com@rest