 
|
はてなキーワード: マネージャとは
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書
始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！
1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。
これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。
入札前の情報漏れにしても、その後のNTTDとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。
共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラーな方法で流れている。特許庁, NTTD, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的に情報不足だった感が伺える。ここを改善する必要があるよね。
極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。
入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。
報告書だと、上流の話しか出てこない。だから、｢設計もろくにできないで55億無駄にしたのか！｣って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るわけがないってことなんだよ。特に、このプロジェクトは既存システムを0から作り直すのだから、既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。
既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るわけがないという問題があると思うんだ。
6年？そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ？6年経つ間に色々変わっちゃう。
どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システムの仕様まとめプロジェクトから開始するのが良かったんじゃないかな。
6年まとめてどん！だと中断の決断もなかなかできないよね。
これだけプロジェクトが炎上していたのに、汚職がきっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね？もし汚職が見つからなかったら、炎上のまま･･･
これは国のプロジェクトだから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。
もうね、
ＴＳＯＬによる設計作業は ，平成１８年当初６０人体制でプロジェクトをスタートさせたが，翌年初めには遅延が 始まったため，順次増員を行い，同１９年３月には２００人，同年５月には４５０人体制とした。
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ＴＳＯＬは ，工程の遅れの解消に向けて，大幅な人員の増強でこれに対処しようとし，平成２０年１１月以降に は １３００人もの体制を整えたが
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。
大量の下請け同士の連携や情報共有がされていなかった。経験やノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウの管理はもっと意識されるべきだよ。
人数増やしてプロジェクトが炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。
開発や設計って？という人にもわかりやすいように説明する。
例えば、優れた売れっ子のマンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう？殆どの人はそれは無理じゃない？と思うだろう。1000人でも無理かもしれない。
開発も同じなんだよ、本質的にはね。
でもそう思われにくいのはなんでだろう？それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマの仕事だと思われているからだ。実際それをプログラマなのだと定義している会社もある。技術はお金にならない低俗なものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。
売れっ子のマンガ家のような設計(マンガで言えばネームや原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ、勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。
でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。
それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者のモチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。
これは間違いない。
このまま続けていたら、沢山の技術者の尊い人生がデスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。
このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。
時間ができたら後で読む
http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm
実際の業務の内容がある
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554 良いまとめ
私はIT系専門学校に通っている。わかりやすく言うとプログラマ養成校だ。これからそういう学校に行こうと思ってる奴、考えている奴らに、長所短所をシェアしようと思う。
・良いところ
基本情報がとれること。あえてあげるならこれであろう。今のシステム開発業界はリーマンショック以来の冷え込みがつづいている。昔ならプログラム未経験でもホイホイやとってくれたものが、今ではベテランでもどんどん切られる。そういう時代である。私も面接時に基本情報をもっていることが評価された。大学などでは基本的に資格取得のための授業をしてくれない。そのため独学でやる必要がある。もちろん独学で取れない資格ではないし、独学がのぞましい。しかしこれは全ての情報系検定の基礎になるものである。できるならば誰かに教えてもらうのが好ましいと思う。私は今はプロジェクトマネージャ試験という、試験の勉強をしている。これは情報系国家試験の中で”Level4”に区分される高度試験である。（ちなみに基本情報はLevel2）実はこのプロマネ試験、基本を取っていれば以外と独学でいけるのだ。これは他のLevel4試験にも言えることだと思う。基本的な知識は基本情報で勉強し、高度試験ではそれの読解、論述が出題されるイメージだ。高度試験取得のためにも、基本情報はしっかりと教師に教わったほうがよいと私は考える。
・悪いところ
企業側からの専門学校の評価が低い。これにつきる。正直そのへんの大学よりは授業内容も深く、仕事に活かしやすい。しかし、最低学歴として大卒を設定している企業が非常に多い。とくに中堅・大手にはその色が強い。そのため、それまでITとは無縁だった文系大学生にも追い抜かれてしまうのだ。ただこれについては本人のやる気しだいだといえる。yahooやドワンゴなどの一部の企業は専門からでも採用している。そういった大手を狙うならば、入学したその日からそれに向けて努力すべきである。情報知識などは正直ほどほど。求められるのは圧倒的自主性とコミュ力。例えば自分でサーバつくっちゃったよ～とか、クラスメイト巻き込んでサイトたちあげたったなど、クリエイティブな活動が評価される。
結論から言うと、純粋にプログラマを目指したいならこれほどよい教育環境はないだろう。短期間で資格習得することができ、実務に近い授業を受けられる。しかし大企業などを目指したいなら専門学校に来るべきではない。３流でも４流でもいいから大学に行くべきである。そして目標が曖昧な奴な絶対に来ないほうがいい。そのへんの専門とは違い、ほとんどの授業が座学である。それに耐え切れずに挫折したクラスメイトも普通にいる。適当に遊びたいならファッション系か３流大学にいくべきだ。この記事が、未来ある若者のためにならんことを
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
Windows 7 - Firefox 8.0 - Norton Internet Security(NIS) 2011 の場合。
（xはバージョン番号）
1. NIS - 設定 - その他の設定 - 製品セキュリティ で「Norton製品の改変対策」を「OFF」にする。
2. C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_xx.x.x.x\
・coFFPlgn_xxxx_x_x_x → coFFPlgn_xxxx_x_x_xOLD
・IPSFFPlgn → IPSFFPlgnOLD
※WindowsXPでは C:\Documents and Settings\All Users\Application Data\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\NIS_xx.x.x.x\ (未確認)
元に戻したい時は、リネームしたフォルダを戻して「Norton製品の改変対策」を「ON」にする。
なお、OSを再起動するとフォルダが強制的に作成されるようなので、その都度2.の実施が必要。
C:\Program Files\Mozilla Firefox\extensions\
原文: Schumpeter blog: Angst for the educated(http://www.economist.com/node/21528226)
裕福な国の何百万人もの卒業生が、泣く泣く両親に別れをつげて、大学での新生活を始めようとしている。学生の一部は純粋な学問への愛ゆえに大学に向かうのだろう。しかし、ほとんどの学生は、大学で3年か4年過ごせば、そのために多額のローンを組むことになったとしても、実入りのいい安定した職に付ける見込みが強くなるのだと信じて大学に進んでいるのだ。
大人たちは常に「教育こそがグローバル化した社会で成功をつかむための最良の道だ」と子供たちに言い聞かせてきた。そしてこのお馴染みの話は次のように続く。ブルーカラーの仕事はやがてオフショアされるか機械化されてしまうし、中退したら金に困る一生を送ることになる、世を勝ち抜くのは学士号を手にしたエリートだ、と。これは証拠によって支持されている見解でもある。ジョージタウン大学の教育・労働力センターが最近発表した研究によれば「中等教育以上の学位を取得すれば、ほぼ必ず十分なリターンが得られる」という。学歴と収入には強い相関関係があるのだ。専門学位をもつアメリカ人の生涯賃金は360万ドルだが、高卒の場合はせいぜい130万ドルでしかない。さらに、学位を持てるものと持たざるものの差はますます広がりつつある。2002年の研究では、大卒は高卒の1.75倍の生涯賃金を得ているという結果が得られたのだが、今日ではこのプレミアはさらに大きくなっている。
しかし、過去というガイドは未来において役に立つだろうか？ むしろ、私たちは仕事と教育の関係が変化する時代の境目に立っているのではないだろうか？ 実際のところ、古いパターンが変わりつつあり、今は不況によって引き起こされている西欧社会の大卒需要低迷という事象も構造的なものに転化しつつあるのだと考えるべき根拠は十分にある。数十年にわたって多くのブルーカラー労働者を揺さぶり続けた創造的破壊の強風は、今や教育エリートにも牙を向こうとしているのだ。
大卒者の供給は急速に増大しつつある。高等教育統計によれば、1990年から2007年の間に、大学に進学する学生の数は、北アメリカでは22%、ヨーロッパでは74%、ラテンアメリカでは144%、アジアでは203%に増大したという。2007年には世界中で1億5000万人もの人が大学に通い、そのうち7000万人はアジアの大学に在学している。経済的新興国、中でもとりわけ中国は欧米のエリートに対向しうるだけの大学の育成にリソースを注いでいる。この新興国では、タタ・コンサルタンシー・サービスやインフォシスのような専門サービスを業とする会社も生まれつつあり、これらの会社は新卒生を世界クラスのコンピュータープログラマやコンサルに育て上げている。詰まるところ、富かな国の最優秀層は、より少ない賃金で沢山働いてくれる貧しい国の最優秀層と競合しつつあるのだ。
同時に、教育を受けた労働者の需要のあり方もテクノロジーによって変わりつつある。この状況は19世紀に農業労働者が直面し、20世紀に工場労働者が直面したそれと非常に似ている。コンピューターは反復的な知的作業のみ成し得るというわけではない。コンピューターは、アマチュアにプロのごとく仕事をこなせるようにする力を与えるのだ。どうして生身の会計士を雇って納税申告をしてもらう必要があるだろう？ そんなものは、Turbotaxを使えばわずかな費用でやれるのだ。今後、論調と言語的曖昧さを処理できる機能が備わるようになれば、コンピューターがこなせる仕事の種類は今の何倍にもなるだろう。
Paul Krugmanを含む経済学者の一部は、ポスト工業化社会の特徴は絶え間なく続く知的労働者需要の増大ではなく、巨大な「空洞化」にあるのだと論じている。この「空洞化」は、中級職が賢い機械によって取って代わられ、上級職の増加が鈍化することによって起こるのだという。MITのDavid Autorによれば、このコンピューター時代におけるオートメーション化の主たる効果は、ブルーカラー職の消失というより、ルーチン化できるあらゆる職の消滅にあるという。プリンストン大のAlan Blinderは、低賃金の仕事よりも、大卒が伝統的にこなしてきた仕事の方が比較的「オフショアしやすい」と論じている。配管工やトラック運転手はアウトソースすることができないが、プログラマの仕事ならインドに頼むことができるからだ。
大学教育は、未だに医療・法・学問といった巨大なギルドの入会資格になっていて、このギルドは安定した高賃金な職を生み出している。これらのギルドは前世紀において非常に強力な参入障壁として機能してきた。この障壁は時には正当な目的に出たものだったが（誰も床屋に手術されたいとは思わないしね）、他方で自分たちの利益を目的としたものでもあった。しかし、ギルドは次第に没落しつつある。新聞はブログとの戦いに負けつつあるし、大学はテニュア付きの教授をテニュアの無い職に置き換えつつある。法律事務所は「discovery」（訴訟に関係のある資料を探し出す仕事）のようなルーチンの仕事を、Blackstone Discoveryに代表される電子検索の専門集団に外注しはじめている。医者ですら安泰ではない。患者たちはオンラインでアドバイスを受けた上で、ウョルマートの新しい医薬品センターを利用して治療を求めるようになりつつあるからだ。
MITのThomas Maloneは、このようなオートメーション化・グローバリゼーション・自由化といった流れは、もっと大きな変化 - すなわち「知的労働の分業化」という流れの一局面かもしれないと論じている。アダム・スミスの工場マネージャがピンの生産を18の手続きの分割したように、企業はますます知的労働を細切れにしつつあるのだ。例えば、TopCoderはITプロジェクトを小さな塊に分けたあと、その細切れをフリーランスのコーダーに分配するという方式を採用している。
このような変化は間違いなく知的労働者の生産性を高めるだろう。消費者はサービスに対して高い対価を要求する専門家ギルドを避けて通れるようになるし、多くの知的労働者は退屈な仕事を外注することで自分の最も得意な仕事に集中できるようになるのだ。しかし他方で、この知的労働の再編の流れは、次の世代の大卒者の人生を、はるかに不確定で安住できないものにするのだ。
読まずにハックルさんを批判することは許さん。読んだ上で、この記述でハックルさんが言うような読みが可能であるかどうかを判断するべし。
私自身としては、みなみが変な子であることは認めるが、小説版の書店員さんの行為にはそれほどの過失がない、と擁護したい。
おそらく普通の人は、他に野球部にマネージャーというものがいれば、まずその人に聞いただろう。
しかし、なぜか彼女は目の前のマネージャーの活動を観察したり、彼女に質問したりするより本を読むことにした。
彼女が目の前の現実よりも本に書いてあることや理論、自分の頭のなかにある理想を重視する人物で有ることがよくわかる一文である。
ようするにみなみはちょっと変わった子なのだ。
そこで、家にあった広辞苑を引いてみた。すると、そこにはこうあった。
マネージャー【manager】 支配人。経営者。管理人。監督。
また、すぐ隣にはこんな言葉も載っていた。
これを読んで、みなみは「マネージャー」というものを「管理や経営をする人---つまりマネージメントをする人」だと理解した。
この時点で、みなみは「管理や経営をすること」だということを受け入れていることに注目。
普通ならここで、あれ「野球のマネージャーは？」とか「管理や経営ってどういうこと？野球と関係ないんじゃないの？」って思うかもしれないが、
彼女はなぜかこれだけ読んで「管理や経営をする人になろう」と納得できてしまうのだ。そういう子なんです。
で、肝心のシーン。
次に、今度は近所の大型書店に出かけていった。
そう、みなみはこういう聞き方をしたのだ。
なぜ彼女が野球部のマネージャをやってるんだ、とか甲子園に連れていきたいんだ、とか言わなかったかはわからない。
でも、書店員がこの質問に対してべつにプロのビビッとした感覚がなくても「マネジメント」を手渡すことにそれほど違和感はないだろう。
余計な説明はいらないところだ。別にハックルさんがマンガ版でやったように空想を働かせてもいいけども。
するとその若い女性店員は、一旦店の奥に引っ込むと、すぐに一冊の本を手にして戻ってきた。
「これなんかいかがでしょうか？ これは『マネジャー』あるいは『マネジメント』について書かれた本の中で、最も有名なものです。世界で一番読まれた本ですね。
もう三十年以上も前に書かれたものなんですけど、今でも売れ続けているロングセラーです。これはその要点を抜き出した『エッセンシャル版』です。
何も聞かずに「マネジメント」の本を手渡すのは、ありだと思う。
だが、それはここでｇｄｇｄと説明することとの整合性が悪い。
ハックルさんがいうようにビビっと来たと主張するのなら余計な説明なしに「コレがいいと思います」でよかったはずだ。
こんだけ長々と説明するくらいなら、その前にもうちょっと相手の話を聞いても良かったはずだとやねうらおさんが思うのはむしろ自然な反応だと私は思うね。
（まあこう言えば、「書店員さんはビビッと来て何が何でもみなみに読んでもらおうと努力したのだ。それがプロの店員というものだ」とか返すんだろうけど。
もしそう返すなら、みなみは真剣味が足りなかったんですかって返したい。なんで自分の状況をもっとちゃんと伝えようとしないんですかってね。）
そこでみなみは、その本を手にとって見てみた。タイトルにはそのものズバリ「マネジメント」とあった。
著者はピーター・F・ドラッカーで、編訳者は上田惇生、出版社はダイヤモンド社となっていた。
そうして彼女は、中身も見ずにその本を買い求めた。値段は二千百円と少し高かったものの、世界で一番読まれた本というのが気に入った。
それに、あれこれ考えてもしょうがない---という思いもあった。
本を買ったみなみは、家に帰ると早速それを読み始めた。
繰り返しになるが、みなみはあまり深く考えない子、自分の思い込みで突っ走って周りを巻き込む子として描かれている。
その思い込みが間違っていても、痛い目を見ないとわからない子なのだ。
だから「なぜ中身も見ずに買ったのか」とか突っ込んではいけない。
ここでハックルさんが「みなみは運命を感じたんだ」とか色々説明したがるかもしれないが、読者としては「ああ、この子はアホの子なんだな」程度の認識で構わない。
そのほうがこの作品を楽しめる。 というかなんでも「経験とか勘とか運命」とかで説明てんじゃねーよハゲ。それは説明になってねーんだよ。
それでも、すぐに気持ちを切り替え、その先を読み始めた。
こういうのはよくない。
ところが、そうやって読み進めてみると、その本は意外に面白かった。
また、単に「企業経営」についてだけ書いてあるわけではないというのも次第にわかってきた。
そこには、企業を含めた「組織」の経営全般についてが書かれていた。
そして、それなら野球部にあてはまらないこともなかった。野球部も、広い意味での組織だった。
だから、組織の経営について知ることは、野球部の経営を知ることにもつながった。
それが分かって、みなみはホッとした。---この本も、全くのムダではなかったのだ
なぜみなみは「マネージャー」という単語さえ広辞苑で調べないとわからないのに
「組織」については、広辞苑を引かなくても理解できているのか。
違和感を感じるかもしれませんが、この部分は読者がちゃんと想像力を働かせてください。
そうしたことは抜きにしても、この本は面白かった。
みなみはそこに書かれていることを完全に理解できたわけではなかったが、何かとても重要な、だいじなことが書かれているというのは良くわかった。
言葉の一つひとつが、とても重く、とても貴重なものとして受け止められた。
それに魅了されたみなみは、夢中になって読み進めていった （続）
はい、参考にはなりました。ムダにはなりませんでした。
ではなぜみなみはこの本を参考にした後「野球のマネージャー」に関する本を買おうとしなかったのか。
その答えは実際に本を読んで確かめてみましょう。
今まで出来ないものだと諦めていたが先日ついにできたので備忘録として書き留めておく。
【環境】
Win7 Pro 32bit
WinVista HP 32bit
※恐らくWin7、WinVistaであれば何でも出来る。
GW-US54GXS
【大まかな流れ】
・無線子機（私の場合GW-US54GXS）のドライバ環境を整える。
・あとは普通にKaiをやる。
【はじめに】
・今まであったすべての接続方法で出来なかった人が対象である。
【やり方】
①http://www.planex.co.jp/support/download/wireless/gw-us54gxs.shtml
ここから「ドライバ・ユーティリティWindows Vista/XP/Me/98SE版」をダウンロード。
※※理由：ドライバ・ユーティリティWindows 7版にはPSPXlinkModeプロパティがないためKaiが出来ない。
②展開後、中にあるインストーラのプロパティから互換性→Windows Server2003(SP1)、管理人モードで実行をチェックしておく。
③無線子機を接続する。このとき勝手にドライバをごちゃごちゃやり始めるがすべてキャンセルする。
※これ重要。
④Windows+Breakキーでシステム画面を開き、デバイスマネージャを起動する。
⑤開くと自分の無線子機の名前があると思うので右クリックし、「ドライバソフトウェアの更新」をクリックする。
⑥「コンピュータを参照してドライバソフトウェアを検索します」を押す。
⑦先ほどインストールしたフォルダの中の「USBIrv」（うろ覚え）みたいなフォルダを参照させる。
⑧更新が終わったらデバイスマネージャ上の無線子機を右クリックし、「プロパティ」をクリックする。
⑨「詳細設定」→「PSPXlinkMode」を選び、「Enable」にする。
⑩ネットワークと共有センターを開き、Win7:アダプタの設定、WinVista：ネットワーク接続の管理を押す。
⑪PSPのアドホックを1chに設定して、オンライン集会浴場に入る。
⑫⑩で開いたところに無線子機のアイコンがあるので右クリック→接続からPSP_AUL……を選び接続する。
あとは他の入門サイトにあるようにkaiを起動してください。
そもそも計算機システムにできて紙の台帳にできないことなど存在しない。存在しないんだぞ。なのに何故人は計算機システムを作るのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から考えてる輩はいないにせよ、システム構築とは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか？ じゃあなぜシステム構築と運用をやるんだ？
翻ってSIerでのシステム構築はどうかといえば、これは不幸でしかない。SIerの不幸はあげればキリがないから、マネージャが技術に全く無知だとか、プロジェクト管理方法が狂ってるとか、マトモに技術情報を収集するプログラマをほとんど全く欠如するとか、あるいは「ExcelとWordしか使えないエンジニア」が一定数いてこれが老害になっているとか、まあその程度を列挙しておくに留めるが、ともかく様々な原因により、SIerに発注することを選ぶとトラブルが出た際メンテナンスがとても困難になる。もちろんトラブルのないシステムなど(少なくともハードウェアが必須なコンピュータを使う以上)ありえず、たとえシステムがユーザーの負担を減らしたとしても、そのぶんSE(と呼ばれるSIer所属のサラリーマン)が背負ってるだけに過ぎない場合が多々見受けられる。それは要するに搾取対象が移動しただけなわけで、全体の幸福の総和が上昇しないようなものの存在を、我々はけっして赦してはならないのだ。
すでにSIerによって構築された既存のシステムを今すぐ根絶やしにするのは難しかろう。過去にそれらが果たしてきた歴史的役割まで否定するつもりもない。しかし今、この瞬間にも意味もなくSIerに発注され続けているシステム。なぜSIerに発注する必要がある？ ないはずだ。ないはずなんだよ。ちゃんと調査すれば自社エンジニアとか、ひょっとしたらフリーランスの数人をチーム化するくらいでも用は足りる場合がほとんどなんだ。SIerは捨てろ。これ以上SIerの業火を背負うな。未来に禍根を残すな。少なくともSIerが作るシステムを諦めをもって受け入れる時代は、我々の世代で最後にするべきだ。体罰の伝統じゃないんだから。我等の子孫にSIerのない明るい未来を。そう願ってやまない。SIer死ね。
このエントリは cpanm Devel::REPL が完了するまでの待ち時間に、以下のエントリから絶大な示唆を受けつつ書きました。このエントリはすばらしい。
卜部昌平のあまりreblogしないtumblr - どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。
by tagomoris
Windows2003Serverの実稼動OSをWindows2008 R2のHyper-Vへホストするために
Sysinternals配布のP2Vソフト「Disk2VHD」を使ってみた。
http://maniax.ddo.jp/archives/250/
http://www.forest.impress.co.jp/docs/news/20091009_320701.html
C:ドライブのVSSでスナップショットをとって、イメージを書き出してくれた。
Hyper-Vマネージャから仮想ゲストをつくり、VHDをマウントさせると...
10分近く「変更を適用しています」のプログレスバーが出っ放し。
こりゃ失敗だな。あきらめて、P2V計画は中止。
地元の同級生と比べてくる。
誰それは課長になった。とか
誰それは休日に親の手伝いをする。とか
でも、出来ちゃった結婚した挙句、生活できなくて実家に寄生するほど恥知らずじゃない。
それに俺はまだ課長になってない。普通の会社で言うところの係長だ。
でも、うちの会社で課長＝マネージャっていうと、上場企業の部長級～取締役クラスになる。
それを縁故採用で入った地元の小さい会社で、課長になった奴より格下だっていうのか？
あと、俺は休日に親の手伝いがあまり出来ない。
そりゃ大学出てから一度も定職につかずにフリーターやってる奴は時間が有り余ってるんだろう。
でもその代わりに去年、家立て直すときのローン、俺が払ってるじゃないか。月に30万も！
息子が建てた新築に住んでてまだ親孝行が足りないって言うのか？
それなのに、たまにプロジェクトの合間の休みで毎回disられてたら何もする気なくなるよ。
俺が間違ってるのかな。
プロジェクトリーダーも任されるようになって、会社でも一人前扱いを受けられるようになった。
それなのに母さんは、俺に地元の連中みたいに、出来ちゃった結婚して、資格浪人とは名ばかりのフリーターやって、地元の会社に縁故採用で入社して、一生世間にうだつの上がらない生活をすべきだとでも言うの？
http://t.hash.bz/archives/2342621.html
1年目なのによく分かっているなあと感動した。
で、いくつか思うことがあったので書きます。
＞ 妙な線引きをして「あんたら作る側だろ、俺知らねーよ」という態度のマネージャ
これ、もし自分がそんなことされたら、その瞬間から一切その人を無視して仕事します。
進捗を訊かれたら「順調です」とだけ答えておく。
そして、どうしてもその人の判断が必要になった時だけ「承認をもらう」形で相談する。
だって、それが貴方の望んだことでしょ？
もちろん間に合いそうになければ「順調」なんて嘘はつきません。
「あーこれ間に合わないですねーw」と他人事のように言ってケツまくる。
10年近く仕事をしてきて、こういうタイプの人とはうまく行った試しがないので、
嫌われるのが少し早くなっただけ。
それに自分にとってどうでもいい人から評価されなくても関係ないし。
それから技術云々については、最初に技術的な部分で仕様を確認した段階で怪しいと思ったら、
「あの人とは日本語で相談ができないので一緒にやるのは無理です、辞退させてください」
みたいなことを即効ステークホルダに持っていく。
つくづく最低最悪の技術者だと思う。
BBSの住民が同人ゲームを作ったらしい。そのゲームはチープだが、味があってなんとも斬新だった。それを見た秋葉原通のプロジェクトマネージャは、
「すばらしいゲームだね。どれくらいの時間、開発をしていたの」
と尋ねた。 するとプログラマは
「そんなに長い時間じゃないよ」
「もっと開発に時間をかけたら、もっと完成度が上がったんだろうね。おしいなあ」
と言うと、プログラマは、自分と自分の友達が楽しむにはこれで十分だと言った。
「日が高くなるまでゆっくり寝て、それから開発する。飽きたらTwitterでつぶやいて、facebookでイイネしあって。
夜になったら友達と一杯やって、アニメを実況して、ニコ動でミク曲を聞いて…ああ、これでもう一日終わりだね」
「ハーバード・ビジネス・スクールでＭＢＡを取得した人間として、きみにアドバイスしよう。
いいかい、きみは毎日、もっと長い時間、開発をするべきだ。インディーズゲームとして企業に売る。お金が貯まったら開発者を雇う。
そうするとゲームの完成度は上がり、儲けも増える。その儲けで開発ラインを２本、３本と増やしていくんだ。やがてしっかりしたソフトハウスができるまでね。
そうしたら同人流通にゲームを売るのはやめだ。JANコードを取得して、商業流通にゲームを扱ってもらう。その頃にはきみはこのちっぽけな村を
出て広島市に引っ越し、名古屋、東京へと進出していくだろう。きみは六本木ヒルズのオフィスビルから企業の指揮をとるんだ」
プログラマは尋ねた。
「そうなるまでにどれくらいかかるのかね」
「二〇年、いやおそらく二五年でそこまでいくね」
「それからどうなるの」
とPMはにんまりと笑い、
「今度は株を売却して、きみは億万長者になるのさ」
「それで？」
「そうしたら引退して、地上波アニメに不自由しないぐらいの地方都市に移り住んで、日が高くなるまでゆっくり寝て、それから同人ゲームでも開発して、夜になったら友達と一杯やって、アニメとかニコ動で一日を過ごすんだ。どうだい。すばらしいだろう」
ショートスタッフミーティングにて社長からERP事業をグループ内で統合する新しい組織を構想中との話があった
どの会社にどういう形でというのは未定とのこと
どのような形であってもHCJが中核となりリードするとのこと
オールスタッフミーティングにて初めて日立製作所への出向を明言
マネージングディレクターも一緒に移り奴らの好き勝手はさせないと説明
マネージングディレクターが考えている出向者をマネージャ以上に限り公表
個人別に調整し9/2に全員発表予定と説明
出向期間は最低一年その後は調整との説明
調整も発表もなく経過
それもそのはず、マネージングディレクターは8/27からこの日まで連休取得
示達の日程調整依頼
メール送信から土日を挟んで月曜、調整がつかないことを理由に
半年間の出向後転籍を予定との記載
マネージングディレクターから出向と転籍に関する考え、社員に向けた言葉はなし
「やることは変わらないでしょ」
「人事と総務の話を聞いて滞りなく事務処理やって」とのこと
これを質す質問に人事は「検討している」と返答
出向初日。
日立製作所の期首総会
旧HCJ部隊の上に立つ部長から部の方針説明
「まだ何も決めてない」
「何も言わないわけにはいかないので方針を書いた」
「まだはじまって一週間なので早くなれてほしい」←えっ
真摯さゼロ
転職活動は順調
マネージャ「まぁ俺たちは売られた身だからな」
アナリスト「売られてないです！だって対価はもらってないでしょ？売れてないです！」
彼女のパソコンの調子が悪い、ということを聞いたので見てみようと思う。どこを見ればいいかをリストアップしてみる。ちなみにWindows。普段はUbuntu使ってるのでWindowsの動作を段々忘れつつある。
パソコン調子悪い、とか壊れたとか言う人は大抵自分のパソコンのスペックが分かっていない。とりあえずスペックを見て、どの程度のものなのか、それに対して妥当な使われ方をしているのかということについて見る。チェックするのは、
など。
常駐ソフトが多ければ多いほどもちろん不安定になるので、なるべくスタートアップの状態で消すことにする。たぶんskypeが不具合のかなりの原因を占めているのだと思うのでそこを見てみる。バージョンを落とすことも考える。音声のドライバとかもみる。
タスクマネージャでいま起動しているサービスがどれだけメモリを食っているかを見る。謎なものがあればぐぐって消す。また、同時にスタートアップで起動してしまっているものがないかを探す。いらなかったらこれもぐぐって消す。solutoを入れてみてもいいかもしれない。
ウイルスとかスパイウェアの類を探してみる。これはひたすらチェックするだけ。
探すの難しそうだけど、たまにある話。ひとつひとつはずしてみてみるしかないと思う。
いらなさそうなのがあったら消しておく。
Windowsをあきらめてもらってubuntuを入れる。10.04は起動速いしネットしかしないのならむしろこれでいいのではという気がする。
自分は 組織の成長 == 組織特有の有用な行動パターンの増加だと思ってる。
有用な行動パターンを組織に定着させるためには、普通に考えると
ってのが不可欠に思う。
しかし、うちの会社はいっつも個人の技術に頼って問題を解決している。
こうやっているので、特定の人に作業が常に集中して、
という状態になっている。
こんな、組織を育てる気がないなんてホトホト腹がたつ。
そもそもどこに行こうとしているのか全く見えず、ただ単に消耗戦をしているように見える。
消耗戦をしている会社には居たくない。
利益率がかなり低いのだけれど、この低さが何のためなのか説明して欲しい。
何かに投資している風にも見えないし、既存の顧客から上がる売上だけで利益率を上げられる
ような大胆なリストラをやるわけでもない。
いったい何をやりたいんだと思う。
古い社員は、奴隷なのに「最近採用された社員は。。」とか言ってる。アホかと、お前が見えてる世界は
どれだけお花畑なんだと。
２流は３流を採用したがるというのは、まさにホントだよ。馬鹿なマネージャが自分がコントロールできる
これ以上この組織にいたら、自分の人生を相当無駄にしてしまう。
ホントにまずい。
黒執事の作者問題について、個別に考えると
伊藤さんみたいに問題を「わざわざ作者の前でいらんこといーなや」という点に限らず
違法云々についてまで言及した作者バカで終わり、である。
それより面白いのが、今回の件って
２００５年頃、芸能人が２ちゃん叩きして反撃を受けブログ閉鎖を連発するという
なんていうかさ、自分のところに問題が来てはじめて
「あ、業界にはこんな問題が」ってのにさも自分が初めて気付いたかのように感じるのか
「この問題をみんなに知らせなければいけない（キリッ」ってやってしまうのよね。
基本的に、マンガの作者とか芸能人ってのは裁判官くらい世間知らずだと思うのよ。
そんだけ周りが見えないくらい自分の世界に焦点を絞っているとも考えられるので
悪いとは思わないけれど、ちょっと自分たちがいかに物を知らないか、
いや知ってる部分が偏ってるかは自覚して頂きたいと思う。
もちろん、彼らが誰よりも目立ちたがりであり、
またそうでなくてはつとまらない、ということはよくわかる。
ネットに書く前に、なぜ周りに相談や確認をできる奴とかいないのか、それが不思議なのである。
具体的に言うと、本人もそうだけれど、アシスタントとかマネージャはそこまで面倒みてこそなんぼだとおもうのよね。
大事な金づるや尊敬する先生に、つまらないことで恥かかせるのは君たち的にいいのかい？
というか作品にこだわるよりtwitterで練れていないメッセージを伝えようとする作家なんか尊敬できるのかい？
極めて無知でありながら、極めて目立ちたがりであり、また知名度故に影響が強い。
最近に至っては平気でtwitterやブログで日常的な感覚でしゃべる。で、それがまたテレビでネタになり広まる。
これはとっても日本を駄目にしてるような気がするのだな。
というか皆さんは有名人に等身大の人間像なんて求めていらっしゃる？
彼らの生の姿を知りたい？ 一人の人間として会話がしたいの？
少なくとも私はそれは何かおかしいと思うんだけれど。
商売のためでもないのにtwitterとかブログに多くの時間を費やしてるクリエイターとかバカなの？
とか思ってしまうんだよね。
で、だ。基本的に彼らが物を知らないのはもう分かってるじゃないですか。
私らはそこだけ求めてればいいんじゃないでしょか。接してればいいんじゃないでしょか。
彼らが自分の専門以外のところについて何か語ればそりゃ一周遅れにもなりますって。
でもそこでバカ晒しても、彼らは目立ちさえすれば興奮するようなタイプなんだから相手にしても無駄。
あほなこと言ったやつは無視するのが一番だと思うのよ。
秀逸なタイトルだと思う。
http://readingmonkey.blog45.fc2.com/blog-entry-355.html
思うに、ある職務において有能な人を「昇進」させるのが悪いんである。
そりゃ現場の仕事内容を知らないと管理職はできない、というのは正しい。
でも現場で有能な人が、管理職になったときに、より有能さを発揮するとは限らない。
実際に頭と手を動かして能力を発揮し、功績をあげてきた人を、その功績をたたえ、担当や主任から「昇進」させて予算管理をする役職につけた。
プロスポーツ選手のコーチが、必ず元プロかといえば、そうじゃない。
逆に元スター選手でも、コーチや監督に向いてない人はたくさんいる。
役職として「昇進」ではなく、単純に「昇給」するようにすればいいんじゃないか、と思う。
ヒラの担当としてイマイチ能力が発揮できない奴は、別の業務(いわゆる管理職とか)に「転任」させてみればいい。
担当から課長(マネージャ)になるのは、「昇進」ではなく、「転任」という位置づけ。
主任として有能だった人が、今は社内の調整(＝流行りもの大好き・キーワードトーク大好きの、気分で発言する偉い人たちの機嫌取り)やら予算管理やらで精彩を欠いている様子を見て、そしてその上の人間のピントのはずれ具合を見て、非常に残念に思う。