Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » 仕事術   (RSS)

MSDN Flash: 藤山編集長の「ふと考えました!」

皆さん、 MSDN Flash はご購読いただいているでしょうか? 長沢の所属するグループには、なんと!その編集長もいるのですが、今までの MSDN Flash ではあまり扱われないようなネタが先週に配信された MSDN Flash 2009/3/10 No.309 の 2番目の大きな記事(さすが編集長!強権発動? (^^))にあります。 顔がもっともっと見えるマイクロソフトでは、こういった試みもいいのではないかなと個人的には思うのですが、皆さんはどう思われましたでしょうか? ☆ ☆ ☆ ☆ ☆

Tech・Ed | アプリケーション ライフサイクル ラフスケッチ

こんにちは。Tech・Ed で実施するセッション資料をせっせと作成している最中ですが、現在こんな感じです・・・ということで、 手書きのメモ で恐縮ですが、情報共有をさせていただきます。 私のセッション資料の作成方法については、以前に投稿しましたので、そちらをご覧いただければと思います。 現時点では、全体の構成の案(方向づけフェーズ)が固まってきた段階です。なので、PowerPoint の PPT の作成はまだまだといったところです。 今回公開させていただいた手書きのもの(非常に見づらくてすみません
Posted by Tomoharu Nagasawa | 0 Comments
Filed under: ,

【コラム】改めて、QCDS

Content style: text only, Content type: column QCD や QCDS という言葉を聞いたこともあるでしょう。私のセッションでも結構な頻度でこの言葉はでてきているので、私のセッションを聞いていただいた方には「Yes!」とお答えいただきたい言葉ではあります(^^) この言葉・・・というか略語は、いくつかの単語の頭文字をとっているわけです。略語は、Microsoft だけではなく、IBM などいろいろなところで多様されますし、同じ略語でも意味が全くことなるものもありますので、文脈や話題に応じて読み手/聞き手が判断しないといけないので、厄介ですね。私はあまり略語を使わないように気をつけています。

【1枚でズバリ!?】チーム開発実践のカギは2つの見える化(MSCセッションから)

こんにちは。今回は、『1枚でズバリ!?』ということで、1枚のスライドにてちょっと書きます。 MSC のセッションでは、チーム開発を実践するために気にしなければいけないこととして見える化を取り上げました。2つの見える化と題して、システムの見える化とプロジェクトの見える化という形で説明をしていきました。 システムの見える化とは?、プロジェクトの見える化とは?ということは、またの機会にスライドで説明したいと思いますが、太極図で表現したように、この2つは非常に密接な関係にあります。どちらか一方だけでは成立しないといってもいいくらいです。

【1枚でズバリ!?】人、作業、青果物じゃなくって成果物 (^^;

人、作業、成果物を理解することが重要(画像をクリックすると拡大表示されます) 前からやりたかったのですが、プレゼンテーション スライドを1枚だけ取り出し、解説するというのを。ちょっと新たな試みとしてやってみることにしました。 ソフトウェア開発だけではありませんが、多くの仕事が人と作業と成果物で成り立っていると言えます。その証拠に、ソフトウェア開発プロセスは多々あれど、どれをとっても必ずこの3つの要素が基本として扱われています。 たとえば、Microsoft Solutions Framework

【お知らせ】Visual Studio & .NET Framework プロダクト フィードバック センター

こんにちは。皆さん、 MSDN Flash は購読していますか?まだの方はぜひ購読してみてください(^^) さて、MSDN Flash 2008/3/4 配信のトップでお知らせしていますが、 というのが、開設されました。 Visual Studio や .NET Framework における障害報告やご提案を受け付けています。もちろん!日本語での入力をしていただくことができます!!いただいた内容は、開発部門が直接確認を行い、回答や製品への反映の検討などをさせていただくことになります。 今まで以上に、日本の皆さんからの

コラム {Parking-lot とタイムボックス}

こんにちは。 以前に触れたように 、このブログのタイトルを変えてみました。といってもまだ(仮)です。何に変えるか検討中ですが、変えるという意思表示をさせていただいております(なんだそれ)。 さて、以前に Parking-lot について 触れました。実はこれ、プロセス改善の際のブレーンストーミングや実行計画の作成時に大活躍します。 議論が白熱するとついつい話が脱線することってありますよね?そんなときは、「その議題は Parking-lot へ」ということで、脱線した議論を本来の議論へ戻すことができます(^^)

プレゼン作成も反復型開発で(^-^)(3)番外編

プレゼン作成も反復型開発で(^-^)(1) プレゼン作成も反復型開発で(^-^)(2) 私のプレゼン作成方法について、書いてきましたが、今回が最終回(番外編)となります。パート2の最後に番外編について触れておきながら、投稿のタイミングを逸していました(というか忘れてました。すみません)。 プレゼンを作成するときには、毎回スクラッチから作成するのは効率的ではありません。それゆえに私は、再利用可能な資産(Reusable Asset)をできるだけ準備するようにしています。 プレゼンにおける再利用の単位は、1

プレゼン作成も反復型開発で(^-^)(2)

前回 に引き続き、私のプレゼン作成方法について書きたいと思います。 私が実施している反復型開発は、Unified Process に基づいています。したがって、 方向づけ(Inspection) - 推敲(Erabolation) - 作成(Construction) - 移行(Transition) というフェーズがあります。 各フェーズでどれくらい反復しているのか?というと・・・この辺は実に適当であったりします。だいたい 方向づけフェーズ: 1 ~ 2 回 (I1, I2) 推敲フェーズ: 2

プレゼン作成も反復型開発で(^-^)(1)

本日は私のプレゼン作成方法について書こうかと思います。先日のイベントでご参加いただいた方と雑談していた際に、「どうやって作成しているのか?」を聞かれたので、「ソフトウェア開発と同じノリですよ」とお答えしたのですが、細かいことはお話ししてませんでした。 私がプレゼンを作成する場合は、反復を意識して作成しています。要するにプレゼン作成を繰り返して実施しています。まずは、作成方法の前にメリットをご紹介しましょう (^0^/ メリットA: 締切までに完成しなくても途中のものでも提出することができる メリットB:

【コラム】匠の技を伝承するために(も)・・・ABM という考え方

こんにちは、新年からいろいろと作りものをしております。1/21 の Visual Studio 2008 Ready Day のプレゼンテーションとデモ環境や、新しい Microsoft On のコース・・・(あといろいろありますが、おいおいこのブログでもご紹介させていただきます)。 さて、いろいろと作りものをしていると、作業の過程で紆余曲折して、いろいろと変更(コンテンツの変更だけでなく、テーマの方針変更なども含めて)があります。これはソフトウェア開発においても同様で、変更がないプロジェクトはないといっても過言ではありません。システム管理の現場でも同じですね。

【コラム】ソフトウェア開発における対症療法と原因療法(4)

こんにちは。いやーしかし Spam コメントが多くなってきました。年末だからでしょうか??このブログはコメントもトラックバックも何も制限をかけない方針です。それは今までもこれからも変えないつもりでいますが、 Spam のターゲットにされてしまった投稿については、泣く泣くコメントを制限または、コメントできないようにしてしまっています。あらかじめご了承ください。 さて、無計画連載の第四回目です。 ソフトウェア開発における対症療法と原因療法(1) ソフトウェア開発における対症療法と原因療法(2) ソフトウェア開発における対症療法と原因療法(3)

【コラム】ソフトウェア開発における対症療法と原因療法(3)

こんにちは。無計画連載の第三回目です(^^; だいぶ間が開いてしまいました。。。 ソフトウェア開発における対症療法と原因療法(1) ソフトウェア開発における対症療法と原因療法(2) 原因療法なのですが、実はなかなか成果が出ていないということをよく耳にします。途中で頓挫してしまうんですね。なぜなのでしょうか。主な要因のひとつに、 継続して実施していくことが難しい ということが挙げられます。 どうしても、人は、チームは、結果をできるだけ早くにあげたがります。そしてそれ自体は、非常に効果的でもあります。誰でも目標が達成可能なところに見えているとモチベーション向上にもつながります。

【コラム】ソフトウェア開発における対症療法と原因療法(2)

こんにちは。無計画連載の第二回目です(^^ ソフトウェア開発における対症療法と原因療法(1) 前回は、対症療法と原因療法というのがあり、それはソフトウェア開発の現場、とりわけ開発現場の業務の改善、プロセスの改善で考えてみるといいですよという話しをしました。 何か が起きたときにそれを短期的に解決する手段として対症療法が効果を発揮します。そのときには、ツールを活用することで非常に効率よく、対応することができます。 たとえば、ソースコードの保守性があまり好ましくなく、何らかの方法で、現状を把握しないと収拾がつかない・・・といった場合には、静的なコード分析がそれを解決する一つの手段となります(コード分析だけしたら解決するということではないのですが)。

【コラム】ソフトウェア開発における対症療法と原因療法(1)

こんにちは。MSDN オフラインセミナー<全国ツアー>チーム開発編が、12 月より開始されますが、そこでも軽く触れる予定のプロセス改善のポイントのようなものを何回かにわけて(無計画ですが・・・)書いてみたいと思います。 対症療法と原因療法とは、医療関係で用いられる言葉で聞いたことがない方はいないと思います。よくいろいろなものごとを自分の体や健康にたとえ話をしたりするとより現実味がでてきたり、理解しやすかったり、危機感が高まったりすることがあると思いますが、ソフトウェア開発の現場においても、同じことが言えます。
More Posts Next page »
 
Page view tracker