タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

設計/管理と感銘に関するWackyのブックマーク (23)

  • K のこと -- steps to phantasien t(2007-11-03)

    友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも

    Wacky
    Wacky 2007/11/11
    K は以前よく <泥の中で一歩を踏みだす> 重要性を語っていた. デスマーチの混乱の中, 理想からほど遠い環境でいかに最初の改善を始めるか. その難しさと戦略を K は議論した.
  • [徳力] 見える化-強い企業をつくる「見える」仕組み (遠藤 功)

    最近、話題になっている「見える化」のです。 会社のブログで、見える化のまとめ記事を書いたのですが、こちらにも読書メモを書いておきます。 書かれていることは非常に基的な話ではあるのですが、改めて具体的に自分の身の回りに落として考えると、実はこういう視点で自分が仕事をできていないというのを痛感させられるです。 個人的に非常に印象に残ったのは、IT偏重による落とし穴。 自分自身、システムやソフトウェアで企業やビジネスマンの生産性向上をするというのが目的なわけですが、どうしてもソフトウェア会社なだけに手段をPC等のIT手段に頼ってしまいがちです。 質的には問題の改善ができれば良く、何もかもIT化する必要は無いわけで、そういう意味では、はてなのようにデジタルの先端にいるようで意外に仕事をアナログに処理している会社っていうのは正しいなぁと思ったりします。 【関連記事】 ・見える化とは (1)

    [徳力] 見える化-強い企業をつくる「見える」仕組み (遠藤 功)
    Wacky
    Wacky 2006/07/02
    会社のブログで、見える化のまとめ記事を書いたのですが、こちらにも読書メモを書いておきます。
  • neutral23の日記 - 自分で自分を管理し、自分で学び続けるということ

    前回のエントリー(id:neutral23:20060502) さらに、もっとも重要な自分で知識を獲得し、整理し、他人に受け渡すということだ。 で、おわっていた。 視点は、管理者ではなく最低限のお仕事が出来るようになった方への内容となっています。 大抵の上司が出来てほしいと思うことなんじゃないかな。 あ、もちろん忠誠心とかに関しては一切情報はないですよ。(あるといえば、参考URLにあげた平林さんの記事ぐらい)あくまでテクニカルな部分だけですから、メンタルな部分だとかは別の話ですよ。 メンタルな部分でモチベーションを高めるための努力がされなければおそらくテクニカルな話は、意味がないままですよ。 知識を獲得するには、しなければならないことは、たった2つ。 与えられる状況から、自己で獲得し武器にして自分で戦況を判断し、自分を強さを最大にできる場所へ行くためのプロセスです。 受動的に学ぶというステ

    neutral23の日記 - 自分で自分を管理し、自分で学び続けるということ
    Wacky
    Wacky 2006/05/14
    非常に参考になる。
  • 組み込み開発フォーラム - MONOist

    ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第6回は、開発方法の整備やスパイラルモデルなど、前回に続きさまざまな問題がある要求仕様フェーズの対処法について解説します。

    Wacky
    Wacky 2006/04/22
    最初の半年間は、専任の担当者を置いてください。
  • 大西 宏のマーケティング・エッセンス:知れば知るほど分からないことが増える

    2006年03月08日12:35 知れば知るほど分からないことが増える カテゴリ実践的知識&知恵 kinkiboy Comment(1)Trackback(3) 404 Blog Not Foundの小飼弾さんが、プロと評論家の違いをについて核心に触れることを書いていらっしゃいます。 知れば知るほど無知を思い知らされ、力を出せば出すほど無力を思い知らされ、そして経験を積めば積むほど臆病になる。 (略) そうして「逃げ」たくなった時、やるかやらないかが「プロ」と「評論家」の違いなのだと思います。どちらも知識は大いにあるので、「それが出来ない」理由ならいくらでも思いつきます。 このお話はとても重要だと思います。ビジネスに携わる人たちは、いつも3つのことを頭の片隅に置いておいた方がいいと思うからです。 ひとつは、知れば知るほど、分からないことが増えてくるということです。いろいろ体験し、また情報収

    大西 宏のマーケティング・エッセンス:知れば知るほど分からないことが増える
    Wacky
    Wacky 2006/04/01
    知れば知るほど無知を思い知らされ、力を出せば出すほど無力を思い知らされ、そして経験を積めば積むほど臆病になる。そうして「逃げ」たくなった時、やるかやらないかが「プロ」と「評論家」の違いなのだと思います
  • プログラマが騒ぐ時 - Kazzz's diary

    あるシステムの開発プロジェクトにおいて、実装を任されているプログラマがいるとしよう。そのシステムでは、他のシステムのサーバとの通信を行なうことが必要あり、プログラマは、そのサーバとの通信部分を実装しなければならない。サーバとの通信仕様は曖昧で仕様書や資料を見てもよく解らないし、周りに聞くが誰も事実を知らないようだ。仕方が無いのでサーバ側の人間にお願いして、実際にサーバにアクセスしている、他のシステムのプログラムのソースコードを送ってもらい、独自に調査を開始する。 こうして細かいサーバとのやりとりはある程度判ったので、プログラマは実装を開始した。実装はほぼ期待通りの仕様であり(調べたので当たり前だ)サーバとの通信部分は問題無く動いた。 よくいる立派なプログラマのケースだが、この進め方は駄目だ。 サーバとの通信の方法を知っているのは、プロジェクトメンバ中あなただけだ。おそらく今後も、未来永劫そ

    プログラマが騒ぐ時 - Kazzz's diary
    Wacky
    Wacky 2006/02/25
    騒いで、一度仕様が明確になっていないことを訴えてプロジェクトの中で問題として採りあげてもらうべきだ
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その1)

    ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な(?)グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その1)
    Wacky
    Wacky 2006/02/18
    続きがありますよ
  • ★★★ ダメな会社ほど社員をコキ使う 宋文洲 | タイム・コンサルタントの日誌から

    宋文洲氏は中国出身の元留学生で、今や著名な経営者である。創立した会社・ソフトブレーン(株)がまたたく間に店頭公開から東証一部まで上場したことで、経営者としてのビジョンがいかに正鵠を射たものであったか、皆が知るところになった。 しかし、宋さんは最近、そのソフトブレーン社の代表権を返上し、単なる会長職に退いてしまった。「上場した会社は公器だ。いつまでも創業者兼経営者が牛耳っているべきではない」との信念からだという。たしかに、一般にワンマン組織は、その経営者個人の器を超えて大きくなることができない。だから、この出処進退の見事さはさすがだ。だが、たいていの経営者はそれができずに、老害や後継者問題で会社をぐちゃぐちゃにしてしまう。宋さんができた理由はなぜかというと、おそらく彼は何よりも、自分の信じる理念・原則に忠実なのだ。理念原則に忠実というところこそ、工学博士号をもつこの人を理解する鍵だと思う。

    ★★★ ダメな会社ほど社員をコキ使う 宋文洲 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/02/18
    “まかせるから失敗すんな”という社長は、じつは何もまかせていないに等しいのだ。
  • コーチングを身に付けよう(5)

    第5回 コーチングを日常の仕事に生かす 小田美奈子(執筆)、竹林一(監修・執筆協力) 2005/5/14 ここ数年、新聞、雑誌でも多く取り上げられ、注目を集めている「コーチング」。連載では、ITエンジニアが身に付けておくと役立つコーチングの考え方、活用事例を紹介するとともに、職場や生活ですぐに実践できるコーチング・スキルについても解説します。 連載ではこれまで4回にわたって、コーチングの概念や基スキルなどを紹介してきました。「第1回 コーチングが注目される理由と定義を知る」ではコーチングが注目されている背景や基的な考え方、「第2回 プロジェクトリーダーのコーチング実践記」ではビジネスにおける活用として、プロジェクトリーダーがコーチングを実践した事例、「第3回 コーチングの基スキルを会得しよう」では、コーチングの基スキル「聴く(傾聴)、質問、認める」の3つの紹介、そして「第 4回

    Wacky
    Wacky 2006/02/04
    真のコミュニケーションとは単純に相手を説得し動かすことではなく、その人の立場に寄り添って感覚を共有することで、相互に理解し合い、アイデアを出し合って、共通の問題解決を図ること
  • NameBright - Coming Soon

    NameBright.com - Next Generation Domain Registration designnewsjapan.com is coming soon

    Wacky
    Wacky 2006/01/28
    個々の部品の品質に注目する代わりに、日本のエンジニアたちはシステムとしての品質に注意を向けていた
  • チャンスやリスクには、兆しがあるもの―平穏なときこそ情報収集のためのパトロール活動を―

    チャンスやリスクには、兆しがあるもの―平穏なときこそ情報収集のためのパトロール活動を―:ビジネス刑事の捜査技術(5)(1/2 ページ) チャンスを逃したり、リスクを見落としたりすることは日常的に起こるものだ。これらの事象には、警察官が平時に行う地道な警ら活動が非常に有効である。今回は、チャンスを逃す、リスクが見えないということについて捜査の技術の視点から考える。 チャンスを逃す、リスクを見落とす ビジネスには良いときもあれば悪いときもある。しかし、10年に1度のチャンスを逃したり、会社倒産の憂き目に遭ったりというようなリスクを見過ごしてしまっては、次があるなどといっていられない。 チャンスを逃したり、リスクを見落としたりする人は、「あのとき、こうしておけばよかった」と愚痴をこぼす。しかし、チャンスもリスクも誰のところにもやって来ることだし、1度だけでなく何度でもやって来るものである。要は、

    チャンスやリスクには、兆しがあるもの―平穏なときこそ情報収集のためのパトロール活動を―
    Wacky
    Wacky 2006/01/28
    変化が起きる前には、変化の兆候がある。その兆候にさえ気が付けば、その後に起きる大きな変化を先取りすることができる。
  • 社内ブログ(ナレッジマネジメント)を成功させるためには - ロシニョール社が作ってます。

    ・sta la sta - 社内ブログが失敗する7つの理由 そういえば僕も昔からナレッジマネジメントには興味があって、実際に社内でも何度か挑戦してみたけれど、うまく行った試しがない。そんな中で、ブログっていうのは使えるツールだと思うのだけれど、まずは「なぜ今まで、ナレッジマネージメントが失敗したのか」を考えなければいけない。 それを元に、じゃあどうすればいいのだろう、ということを書いてみた。 ■経営者の心得:情報発信者を評価すること 「縦の情報流通」よりむしろ「横の情報流通」を重視するくらいの気持ちが必要。横の情報流通(共有)は、成果が見えにくい。見えにくいが、実際に成果が出ることについては、高く評価する必要がある。 ■経営者の心得:ITへの偏見を持たないこと まったく馬鹿馬鹿しいことだが、自分がパソコンを理解できないからといって「パソコンのできる若い者は気に入らない」と思っているおじさん

    社内ブログ(ナレッジマネジメント)を成功させるためには - ロシニョール社が作ってます。
    Wacky
    Wacky 2006/01/14
    情報を出すのはコストがかかる、情報を出しても上から特に評価されない、でもクレクレ君は多い、まぁ容易に閉ループに陥る訳
  • 実行力不全 なぜ知識を行動に活かせないのか - kinneko@転職先募集中の日記

    実行力不全 なぜ知識を行動に活かせないのか (Harvard business school press) 作者: ジェフリー・フェファー,ロバート・I・サットン,長谷川喜一郎,菅田絢子出版社/メーカー: ランダムハウス講談社発売日: 2005/12/23メディア: 単行購入: 2人 クリック: 66回この商品を含むブログ (20件) を見る長いけどこのの前の訳の書評から引用。 http://d.hatena.ne.jp/roumuya/20060106#p1 このは、成功と失敗を分けるものは「知識」ではなく「行動」であるという。知識は成功した企業にも失敗した企業にもある。知識はビジネス・スクールで学べるし、おカネがあれば、コンサルタントにカスタム・メイドさせることもできる。失敗した企業にないのは「行動」である。 なぜ行動できないのか。このは、知識を持つ人はたくさんいるが、行動から

    実行力不全 なぜ知識を行動に活かせないのか - kinneko@転職先募集中の日記
    Wacky
    Wacky 2006/01/14
    まず行動して、行動から得られた本当の知識をふまえて戦略をつくるべきだという。
  • 優先順位をつけよう - sanonosa システム管理コラム集

    何事でも優先順位をつけることは重要です。この習慣がつくのとつかないのでは時間や空間の利用効率が10倍や100倍も違ってきます。今回はそんなテーマです。 【ToDoの優先順位をつける】 自分がすべきことをリストアップして優先順位をつけて実施する。如何にも時間を効率的に使えそうですよね。これができてないという人はこれを何故やらないのでしょうか。時間を無駄に浪費している人は100%自分自身のToDo管理が出来ていないと断言できます。今すぐにでもToDoリストを作り優先順位をつけて実施するクセをつけましょう。この習慣がつかないと時間を無駄に浪費している割には全然成果が出ないという悪循環に陥り、負け組へ真っ先に転落するのは明白です。 【必要な物の優先順位をつける】 物が捨てられない人がいます。整理ができない人がいます。両者に共通するのは自分にとって重要なものが何なのか自分自身でわかっていないことです

    優先順位をつけよう - sanonosa システム管理コラム集
    Wacky
    Wacky 2006/01/09
    ToDoにしても物にしても、まずは捨てることから始めるとよいと思います。どうでもいいものを持ちすぎる人は大切なものを無駄に失っていきます。
  • 忙しい人 - sanonosa システム管理コラム集

    忙しいという言葉は日常的に頻繁に使われますが、使わないほうがよい言葉の一つです。「忙しいという字は心を失うと書く」というのはまさにその通りだと思います。ところで、忙しい人というのは2種類いると思っています。どちらの忙しい人もあまり好ましくないですが、今回はそんなテーマでいきたいと思います。 【忙しい人その1:無駄なことを抱えて忙しい人】 いろいろな人のblogを徘徊していると無駄なことばかりしていて忙しい人がよく目に付きます。その前に何が無駄で何が無駄でないのか定義しておきましょう。仕事なり趣味なりで何か成し遂げようとしていて質的なこと以外の行動が無駄なことです。無駄に忙しい人というのは余計なことにかける時間が長く、かつ困ったことに人はそれが無駄であるということに気づいていないことが多いと言えます。 例を挙げます。 例1:仕事用に買ったノートPCのセットアップに数日かけてありとあらゆる

    忙しい人 - sanonosa システム管理コラム集
    Wacky
    Wacky 2006/01/09
    仕事なり趣味なりで何か成し遂げようとしていて本質的なこと以外の行動が無駄なことです
  • 「走れ!プロジェクトマネージャー!」 > 納期を守るか、顧客を守るか : ITmedia オルタナティブ・ブログ

    これまたすごいタイトルですが、中身はありがちな話しが掲載されています。要約すると、納期が迫ったがモノが出来ていない。だったら、要求を若干削ったり、テストを減らして時間を節約する。で、納品後に徐々に直したり、追加していく、という方法(?)のことです。結果的には、顧客を怒らせてますね、ということが書かれています。 皆さんの周りに、こういったプロジェクトは存在しないでしょうか。 もちろん納期が最優先で、時間的に間に合わないのであれば、機能を削ってもらったりする必要があると思います。問題は、それを顧客の同意無しにやったり、ギリギリのタイミングでやるからいけないのだと思います。 納期が優先されるプロジェクトは、時間も足りないことが多いです。なので、ついつい細かいことを確認せずに見切り発車してしまうことが多い。しかし実は、これが問題を引き起こす可能性が高いのです。 QCDというものがあります。Q=Qu

    Wacky
    Wacky 2006/01/09
    QCDというものがあります。Q=Quality(品質)、C=Cost(コスト)、D=Delivery(納期)です。
  • プロジェクト採算管理は重要か | タイム・コンサルタントの日誌から

    はたしてプロジェクトの採算管理は当に重要か、などというと、常識知らずのレッテルを貼られるかもしれない。とくに、受託開発をビジネスとしているシステム・インテグレーター(SIer)ではそうだ。システム開発プロジェクトは一つ間違うと、億の単位で赤字が発生し、他の数十のプロジェクトで稼いだ利益が吹っ飛びかねない。 だからプロジェクトの綿密な採算管理は必須だ。個別のプロジェクトがいかなる採算状況にあるのかを、マネジメントの側がチェックできる仕組みが求められている。いや、それだけでなく、部門単位でも収支の集計を行なって、採算で目標管理するべきだ--こういう理由から、最近、大手のSIerではプロジェクト採算管理システムの構築が活発だ。そもそも、システム開発はお手のものだから、自社ニーズにマッチした仕組みを自社内で作ってしまおう。そう考えられておられる会社もかなりある。 でも、ちょっと待ってほしい。かり

    プロジェクト採算管理は重要か | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    進捗管理とは、「どれだけ進んだか(工数を費やしたか)」ではなく、「あとどれだけ仕事が残っているのか」で測るべきものだからだ。
  • プロジェクト・ダイナミクスの構造 | タイム・コンサルタントの日誌から

    PMBOK Guideの編纂者たちが、いわゆる「9つのマネジメント領域」を定義したとき、そこにProject Integration Management=プロジェクト統合管理を入れたのは卓見だった。これ以外の8領域、すなわち、コスト管理、時間(スケジュール)管理、スコープ管理、品質管理、人的資源管理、調達管理、リスク管理、コミュニケーション管理、は、それぞれが独立した管理対象範囲を持っている。 (ところで、以前「マネジメントと管理はどこが違うか」にも書いたとおり、私は『管理』という日語が嫌いだ。だから、こうやって8回も9回もくり返して書かされると、ちょっとうんざりしてくる。管理という用語はあまりにも多義性の言葉で、あらゆる物事を曖昧に片づけてくれるので、ひどく便利な魔法の道具になってしまう。私は、仕事の内容を正確に表現したいので、普段はあえて、マネジメント/コントロール/アドミニストレ

    プロジェクト・ダイナミクスの構造 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    プロジェクトの採算が悪化する直接原因は、スケジュールにある。元をたどっていくと、コミュニケーションやリスクの問題につきあたる。
  • 納期短縮三か条 | タイム・コンサルタントの日誌から

    私はタイム・コンサルタントである。「時間の悩み」を抱えるクライアントに対して、解決へのアプローチを示すことで、プロフェッショナルとしてのビジネスを成立させている・・・と、自己紹介には書きたい。できれば。 しかしまあ、現実はなかなかそう甘く行かない。タイム・マネジメントの仕組みを提案するだけでは、なかなかビジネスにはならないのだ。生産スケジューリングやプロジェクト・スケジューリングの仕事をしていてつくづく感じるのは、『やっぱりコスト削減が優先』という圧力の強さである。製造業や流通業向けのSCMシステム構築の課題は、物流費の削減が真っ先にくる。納期短縮は、「それもできたらやりたい」であって、部分目標でしかない。だから私は、パート・タイム・コンサルタントという存在だ。 コスト競争はすでに行き着くところまで行ってしまった。あとは非価格競争力の問題で、性能だとか品質だとかも大事だろうが、納期で勝負す

    納期短縮三か条 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    「隘路に集中すべし」「進捗を皆に見せるべし」「時間はお金で買うものと思うべし」
  • 設計の価値 | タイム・コンサルタントの日誌から

    最初に、ブルネレスキのことからはじめよう。日ではほとんど名前を知られていないが、初期のイタリア・ルネッサンスを代表する人物の一人だ。フィレンツェに旅行に行く人が必ず目にする、花の聖マリア大聖堂の半球形ドームは、彼が作った。 「彼が作った」という言葉を、私は意図して使っている。彼は設計しただけでなく、建設工事の責任者でもあったのだ。つまり今風に言えばプロジェクト・マネージャである。彼は石の積み方にも工夫をこらしたし、二重ドームの間に作業者が立って歩けるスペースを確保する設計にした。施工しやすい設計をしたわけだ。職人のストライキにも見事に対処した。 彼が設計者・兼・建設責任者だったことは特筆して良い。日光東照宮の左甚五郎の立場と同じである。設計者が実作も行う。それは近世以前はあたりまえのことであった。たとえばミケランジェロ作の彫刻が、じつは彼のデッサンをもとに弟子が好きに刻んだものだったとし

    設計の価値 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    モノにはお金を払うが、設計という知恵にはお金を払わない。いわば「実物経済」である。こうした実物経済主義は、最終的には設計の品質低下をまねくのだ。