タグ

2006年4月12日のブックマーク (6件)

  • ドラッカーに学ぶ,ITプロジェクトの問題・課題

    林@アイ・ティ・イノベーション代表です。こんにちは。 ピーター・F・ドラッカーは,1946年に書いた「企業とは何か - その社会的使命」の中で,企業のマネジメントについて次のように述べています。「重要なことは,正しいか,間違いかではない。うまくいくか,いかないかである」。私もプロマネや経営者の経験を通して,ドラッカーの言うことはまさにその通りだと思っています。 ドラッカーはさらにマネジメントの値打ちについて,「医療と同じように,うまくいくか,いかないかによって判断しなければならない」とも言っています。マネジメントを正しく理解するために医療を例に出すとは,さすがドラッカーです。 さて,ドラッカーは企業のマネジメントについてその質を説いたわけですが,企業のマネジメントをITプロジェクトのマネジメントに置き換えて考えると,ITプロジェクトの問題が浮き彫りになってきます。 ドラッカーの最近の著書

    ドラッカーに学ぶ,ITプロジェクトの問題・課題
    wildcats
    wildcats 2006/04/12
  • Rolling with Ruby on Rails

    Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi

    Rolling with Ruby on Rails
  • Martin Fowler's Bliki in Japanese - 建築家

    http://martinfowler.com/bliki/BuildingArchitect.html 「ソフトウェアアーキテクト」という言葉を使うとき、 アーキテクトの役割を理解しやすいように、建築のメタファーを使う。 だが皮肉にもこのことが原因で、建物のアーキテクト(建築家)の来の役割が正しく理解されずにいる。 ソフトウェアアーキテクトとは、チーフ設計者であり、 プロジェクトのメンバを率いる存在である。 しかしこれは、建築家がやっていることではない。 建築家は、クライアント(建物が欲しいひと)とのやり取りに専念しており、 クライアントにとって重要なことにしか関心がない。 たとえば、建物のレイアウトだとか外観だとか、そういったものだ。 けれども、建物に必要なものは他にもまだたくさんある。 建築家には、建物の構造が確かかどうかについての責任はない。 それは、私のCindyのような、建

  • TheServerSide | Your Java Community discussing server side development

  • 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由

    水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更

    wildcats
    wildcats 2006/04/12
  • ソフトウエア開発を理解しない人々

    http://itpro.nikkeibp.co.jp/article/COLUMN/20060327/233447/ またこれか. 品質を向上させる最も基的な取り組みは,一言でいうと手戻りを減らすことである。 ダウト. 手戻りの少なさは良い開発を測る指標の一つではあるが,絶対的な指標というわけではない.ましてやそれは品質向上の最終目的でもなければ,手段でもない. 手戻りを減らすことによって改善を進め,技術者のモチベーションを高める。モチベーションが高い職場は自ら改善していく。 ダウト.*1 手戻りの削減とモチベーションの因果関係はほとんどない.モチベーションを下げるには「横並び評価」や「年功序列」「成果を測らない『成果主義』」を使えば簡単. 現在,組み込みソフトウエア技術者の大半は,「ハードウエアより低い品質でも仕方がない」と思っていないだろうか? ソフトウエア開発はハードウエアでいう

    ソフトウエア開発を理解しない人々