http://dkse.sblo.jp/ 文章書きの訓練です。 ja http://dkse.sblo.jp/article/36970991.html 開発プロセスの統一や標準化を目指す会社や部門は多いようだ。しかし例えばあるプロジェクトでうまくいったやり方が他でうまくいくとは限らない。複数の現場に受け入れやすいプロセスが持つ特徴は何か？そのひとつがスケーラビリティだ。 日記 いまきち 2010-04-09T08:46:32+09:00
しかし例えばあるプロジェクトでうまくいったやり方が他でうまくいくとは限らない。

複数の現場に受け入れやすいプロセスが持つ特徴は何か？

そのひとつがスケーラビリティだ。 ]]> http://dkse.sblo.jp/article/36891619.html リスク管理こそがプロジェクト管理の要諦ではないかと思うことが多い。 日記 いまきち 2010-04-06T00:30:18+09:00 http://dkse.sblo.jp/article/35480295.html 少々前のことになりますが、梅田望夫の講演会に、潜り込んできました。ちょっとしたツテを使って。で、感想。言っていることは、二次情報ばっかり。この人は「もの作り」したこと無いんじゃないか！？とにかく薄っぺらいです。あの程度ならカネ払っていくのは馬鹿らしいですよ。私といっしょにその講演を聴いた人も同じ印象だそうです。しかし、そんな薄っぺらい講演をフムフムと真顔で聞いている偉そうなオッサンがたくさんいたのには驚いた。人の怒りを買っても、儲けたモンがちってことですね。とにかく「もの作り... 日記 いまきち 2010-02-22T00:57:59+09:00 梅田望夫の講演会に、潜り込んできました。
ちょっとしたツテを使って。

で、感想。

言っていることは、二次情報ばっかり。
この人は「もの作り」したこと無いんじゃないか！？
とにかく薄っぺらいです。
あの程度ならカネ払っていくのは馬鹿らしいですよ。
私といっしょにその講演を聴いた人も同じ印象だそうです。

しかし、そんな薄っぺらい講演をフムフムと真顔で聞いている
偉そうなオッサンがたくさんいたのには驚いた。

人の怒りを買っても、儲けたモンがちってことですね。
とにかく「もの作り」に携わる人はこの人に近づかない方がイイです。
反吐が出そうだ。 ]]> http://dkse.sblo.jp/article/35229366.html ＞一流プログラマーは、そのような仕事はしません。＞（中略）＞プログラミングをよく知らない人が決めた仕様とはレベルが違う、＞現実的な仕様を検討することが可能です。＞（187ページ）私は（一応の区切りとしては、だが）プログラマーではなく、SEである。一流のSEはエンジニアリングをよく知らない人が設計した仕様とはレベルが違う、現実的な仕様を検討することができる。しかし、最近自分はSEではなくSI（インテグレーター）ではないかと思うようになってきた。一流のSIerはインテグレーション... 日記 いまきち 2010-02-10T00:20:00+09:00 ＞（中略）
＞プログラミングをよく知らない人が決めた仕様とはレベルが違う、
＞現実的な仕様を検討することが可能です。
＞（187ページ）

私は（一応の区切りとしては、だが）
プログラマーではなく、SEである。

一流のSEはエンジニアリングをよく知らない人が
設計した仕様とはレベルが違う、
現実的な仕様を検討することができる。

しかし、最近自分はSEではなくSI（インテグレーター）
ではないかと思うようになってきた。

一流のSIerはインテグレーションをよく知らない人が
策定した仕様とはとはレベルが違う、
現実的な仕様を検討することができる。

言ってしまえば何とでも言えるのだが
現実にはキッチリとレベルの差がある以上
逆にその差を見極めるのは大変難しい。
私もSE、SIerのレベル差を見切ることはできても
プログラマーのレベルを見切るのには少々手こずるだろう。

ましてや顧客からは余計見えにくいに違いない。

結論はただ一つ、人月商売からの脱却なのだが
コレがなかなか難しくてね・・・ ]]> http://dkse.sblo.jp/article/33303316.html ＞作り直した方が結果的には早く安定した＞システムが得られる場合が多いものです。＞（152ページ）これはすごくよく分かる。他人の作った物はもちろんのこと、自分が作った物でさえ作り直した方が早いことがある。ま、自分が作ったものというのは自分がダメダメなので致し方ないのであるが。ここで言うのはドキュメントがそろっていないとか引き継ぎが上手くいっていないということ以前に『前任者の仕事の品質が著しく低い』場合に起こること。なぜそういうことが起こるかというと単純にその人のスキルがなかった... 日記 いまきち 2009-10-31T01:57:59+09:00 ＞システムが得られる場合が多いものです。
＞（152ページ）

これはすごくよく分かる。
他人の作った物はもちろんのこと、
自分が作った物でさえ作り直した方が早いことがある。

ま、自分が作ったものというのは自分がダメダメなので
致し方ないのであるが。

ここで言うのはドキュメントがそろっていないとか
引き継ぎが上手くいっていないということ以前に
『前任者の仕事の品質が著しく低い』場合に起こること。

なぜそういうことが起こるかというと
単純にその人のスキルがなかった可能性が最も高いが、
そうでなくても（高スキルであっても）、
・納期がタイトすぎた
・サポート体制が整ってなかった
という場合には簡単に発生する。

だからマネジメントをする人は
ドキュメントの整備状況とか、引き継ぎ状況とか
そういうのをチェックするのは目に見えやすくて
やりやすいのかもしれないが
そもそも技術者達に「よい仕事」をやってもらうことに
注力したほうがいい。 ]]> http://dkse.sblo.jp/article/33009409.html ＞「得意な分野は何ですか？」と聞かれて、＞返答に困る人が多い気がします。＞（69ページ）おれ困るわ。強いて言えばシステム開発ができる。どういえばいいのか。この筆者の方であれば「ネットワークプログラミング」と答えるのであろう。私は、DBもNWも業務分析も要件定義も設計書書きも設計書レビューもシステムテストもプロジェクト管理もユーザ研修もユーザインタフェース設計もそれなりにできる。すべて平均よりは上だろう。が、その道のスペシャリストにはてんで敵わないだろう。それってダメなのかなあ... 日記 いまきち 2009-10-19T01:03:15+09:00 ＞返答に困る人が多い気がします。
＞（69ページ）

おれ困るわ。
強いて言えばシステム開発ができる。
どういえばいいのか。
この筆者の方であれば「ネットワークプログラミング」
と答えるのであろう。

私は、DBもNWも業務分析も要件定義も
設計書書きも設計書レビューも
システムテストもプロジェクト管理も
ユーザ研修もユーザインタフェース設計もそれなりにできる。
すべて平均よりは上だろう。
が、その道のスペシャリストにはてんで敵わないだろう。

それってダメなのかなあ。
dkseってそういう人多いよ。
その中でハイレベルゼネラリスト兼プロジェクトマネージャ
というのがdkseの生きる道だと思っているのですが
どうでしょう。

いやでもマジでプロジェクトに
一人おいといてくれたらいいしごとするよ。
っとにわかに不安になったdkseでした。 ]]> http://dkse.sblo.jp/article/32989267.html 大変です！「現場リーダーの技術」の本がどこかへ行ってしまいました。おっかしいなあ~~~。というわけで、見つかるまで別の本の感想文を書きます。「プログラミングでメシが食えるか！？」という本です。ではその１から。＞作りながら動作確認を完璧にするのが、＞品質アップと性能アップのこつと覚えておこう。＞（53ページ）いきなりプログラミングの専門的な話で申し訳ありません。プログラムを作るときにどのように作るのがよいかという話です。これはプログラムについてだけではなくてその前の設計作業とか... 日記 いまきち 2009-10-18T00:33:05+09:00 「現場リーダーの技術」の本がどこかへ行ってしまいました。
おっかしいなあ～～～。
というわけで、見つかるまで別の本の感想文を書きます。
「プログラミングでメシが食えるか！？」という本です。
ではその１から。

＞作りながら動作確認を完璧にするのが、
＞品質アップと性能アップのこつと覚えておこう。
＞（53ページ）

いきなりプログラミングの専門的な話で申し訳ありません。
プログラムを作るときにどのように作るのがよいかという話です。
これはプログラムについてだけではなくて
その前の設計作業とか、もっと一般的ないわゆる「事務全般」
についても言えるのではないでしょうか？

やってからチェックするより、
気合い入れてその場その場で確認しながら進んだ方がいいです。
特に、プログラムならば機械がその場で
何度でも実行してくれますからね。

人間相手だと何度も何度もやらせると怒り出すので
その辺の難しさがあります。

ところが、困ったことに
今の（うちの会社だけではなく）日本の仕事の仕方が
全体的にこういうのを否定する方向に流れていると感じます。
上記の方法の欠点は何かというと、
・作成作業とチェック作業の切り分けが曖昧。
・証跡がない。
なのですよ。これは現代ビジネスの風潮と合いません。

「完成したプログラム自体が証跡」なのであり、
現場レベルでは理解できるのですけども
そんなの理解できる人はどこの会社の上層部にもいませんからね。 ]]> http://dkse.sblo.jp/article/32590877.html ＞意図を正しく伝えるには、15分という時間では短すぎるからです。＞（53ページ）朝会の話。朝会でリーダーが語るなという部分での一節。15分がリミットですよね。だから本気で語りたいことがあったら朝会（15分）という場を使うなということ。しかし、では意図を伝えるためにはどうしたらよいか。15分といわず5分でも3分でも使って伝えないとしょうがないんじゃないかなあ。しかしリーダーにはもっと大事なことがあると思います。それは「聞くこと」。なぜならリーダーは元々しゃべるの得意なんですよ。... 日記 いまきち 2009-10-02T01:47:50+09:00 ＞（53ページ）

朝会の話。
朝会でリーダーが語るなという部分での一節。
15分がリミットですよね。

だから本気で語りたいことがあったら
朝会（15分）という場を使うなということ。

しかし、では意図を伝えるためにはどうしたらよいか。
15分といわず5分でも3分でも使って
伝えないとしょうがないんじゃないかなあ。

しかしリーダーにはもっと大事なことがあると思います。
それは「聞くこと」。
なぜならリーダーは元々しゃべるの得意なんですよ。
だから引用部分もしゃべりすぎを戒める書き方になってる。
そんなことよりメンバーの話をちゃんと聞くほうが
よっぽど気にしなくてはいけないこと。

話を聞くこと。
いつも話を聞くこと。
自分から話を聞くこと。 ]]> http://dkse.sblo.jp/article/32525039.html ＞ここで、あまり話を広げすぎてはいけません。＞（45ページ）議事録ドリブンのお話。自分が仕切る場合はいいんだけど、自分が呼ばれたらどうする？というトピックについてなんだけど、目的の確認にガッツリと食いつくとよいのだそうだ。あまり大きく構えてもしょうがないんじゃないかなあ。議事録ドリブンの面白いところのひとつは前回のOUTが今回のINになることかな。議事録ドリブンのとても重要なことはなんといっても記事録を書く人が高速タイプができること。次に、要約する能力が高いことです。 日記 いまきち 2009-09-30T01:59:27+09:00 ＞（45ページ）

議事録ドリブンのお話。
自分が仕切る場合はいいんだけど、自分が呼ばれたら
どうする？というトピックについてなんだけど、
目的の確認にガッツリと食いつくとよいのだそうだ。

あまり大きく構えてもしょうがないんじゃないかなあ。
議事録ドリブンの面白いところのひとつは
前回のOUTが今回のINになることかな。

議事録ドリブンのとても重要なことはなんといっても
記事録を書く人が高速タイプができること。
次に、要約する能力が高いことです。 ]]> http://dkse.sblo.jp/article/32472146.html ＞増えすぎた課題は「トリアージ」しなくてはいけません。＞（23ページ）以下トリアージの説明が続くが、災害救助現場での「トリアージ」というのは重症患者、軽症患者、手遅れの患者を選択して全体の救命率を上げることなんだそうだ。つまり、助かる見込みの少ない患者は優先度下げる。こういう話聞くとやっぱりこの業界とかまだまだだなという気がする。さてトリアージである。実はこういうのは大企業の方が得意だ。課題の整理と優先順位付けが大好きな人、またそれを報告させるのが大好きな人がいくらでもいる。... 日記 いまきち 2009-09-28T03:00:16+09:00 ＞（23ページ）

以下トリアージの説明が続くが、
災害救助現場での「トリアージ」というのは
重症患者、軽症患者、手遅れの患者を選択して
全体の救命率を上げることなんだそうだ。

つまり、助かる見込みの少ない患者は優先度下げる。

こういう話聞くとやっぱりこの業界とか
まだまだだなという気がする。

さてトリアージである。

実はこういうのは大企業の方が得意だ。
課題の整理と優先順位付けが大好きな人、また
それを報告させるのが大好きな人がいくらでもいる。

しかし災害救助現場においては、
「全体の救命率を上げる」という明確な目標があるのに対し
システム開発（大企業）の課題整理では
明確な基準が無いことが多い。これが大問題。

・見た目上、進捗があるように見せる
・重要度と関係なく、解決率を上げる
・単なる好み

という、本質とはあまり関係ないことで
決まっていることが多い。
ただし、そのような決め方をしたトリアージ結果は
ほぼ間違いなく現場に無視される。

現場の人間はちゃんとわかっているのだ。
私も最近、課題の整理とかやることが多いので
気をつけている。 ]]> http://dkse.sblo.jp/article/32383791.html ＞ピンポイントでお客様の求めていること、＞つまり「うれしさ」をすくい取る感覚＞（3ページ）この「うれしい」というキーワードはとても重要です。私が上流工程の実務を経験する過程で奇しくも同じ結論にたどり着きました。結局SE、ひいてはSIerってのはユーザーさんにうれしさを提供するサービス業なんだろうなって思います。だから、その「うれしさ」をすくい取る感覚というのはリーダーだけじゃなくてメンバーにも必要です。もっとも顧客折衝がないメンバーには無縁かもしれませんが。折衝があるメンバー... 日記 いまきち 2009-09-25T00:19:46+09:00 ＞つまり「うれしさ」をすくい取る感覚
＞（3ページ）

この「うれしい」というキーワードはとても重要です。
私が上流工程の実務を経験する過程で
奇しくも同じ結論にたどり着きました。
結局SE、ひいてはSIerってのはユーザーさんに
うれしさを提供するサービス業なんだろうなって思います。

だから、その「うれしさ」をすくい取る感覚というのは
リーダーだけじゃなくてメンバーにも必要です。
もっとも顧客折衝がないメンバーには無縁かもしれませんが。
折衝があるメンバーには間違いなく必要。
それができないとSE向いてないと思います。 ]]> http://dkse.sblo.jp/article/32110510.html ＞現場リーダとは＞（2ページ）PMの下にいきなりリーダーがいるのですがうちのプロジェクトだとそんなのないよ。PMの下にグループリーダーがいて、その下が現場リーダーだよ。ある程度大きなプロジェクトになるとマネージャーが何層にも居るのは仕方がないかもですけど。とはいえ、うちの会社は確かに1階層多い気がする。この辺はその会社の歴史もあるし、組織の考え方としてフラットなのが良いか、師弟関係が築きやすい階層がよいか意見が分かれるところではある。しかしいずれにしても私の現在のポジションは... 日記 いまきち 2009-09-14T01:48:13+09:00 ＞（2ページ）

PMの下にいきなりリーダーがいるのですが
うちのプロジェクトだとそんなのないよ。
PMの下にグループリーダーがいて、
その下が現場リーダーだよ。

ある程度大きなプロジェクトになると
マネージャーが何層にも居るのは仕方がないかもですけど。

とはいえ、うちの会社は確かに1階層多い気がする。
この辺はその会社の歴史もあるし、組織の考え方として
フラットなのが良いか、師弟関係が築きやすい階層がよいか
意見が分かれるところではある。

しかしいずれにしても
私の現在のポジションは現場リーダーなので
この本に書かれていることは
役に立つのではないかと思う。

と思って読んでみたのです。つづく。 ]]> http://dkse.sblo.jp/article/32091123.html ＞新しい責任と肩書きを与えられたこの女店員の仕事ぶりはガラリと変わり、＞自分の任務を完全に遂行するようになったという。＞（318ページ）いよいよ最終回ですよ、カーネギー著「人を動かす」いやあ長かった！って私がさぼっているだけです。肩書きやポジションが人を作る、というお話です。ここはうがった見方をするのではなく素直に肩書きやポジションを「ツール」としてその人に誇りやモチベーションを持たせることができれば文字通り「人を動かす」事ができるというものです。これどちらかというと、やった... 日記 いまきち 2009-09-13T00:46:06+09:00 ＞自分の任務を完全に遂行するようになったという。
＞（318ページ）

いよいよ最終回ですよ、カーネギー著「人を動かす」
いやあ長かった！って私がさぼっているだけです。

肩書きやポジションが人を作る、というお話です。
ここはうがった見方をするのではなく素直に
肩書きやポジションを「ツール」として
その人に誇りやモチベーションを持たせることができれば
文字通り「人を動かす」事ができるというものです。

これどちらかというと、やった記憶はなくても
自分がそうなった記憶がある人は多いんじゃないですか？

私もあります。
責任のあるポジションについたらやたらとやる気が出たことが。
（いつまで続くかはさておき）

要するにあれです。

『この本さえ読めば、他の自己啓発本は不要です！！』 ]]> http://dkse.sblo.jp/article/31817691.html ＞自分について良い評価が与えられた以上、＞その評価にたがわないようにつとめるのは人情である。＞（305ページ）ここでの文脈は対人交渉、セールスなどのノウハウと読めるが、企業における評価に適用するのは少し難しいところもある。金銭と、相対化がつきまとうからだ。「良い評価」とは何だろうかと考えたとき、昨今の企業はだいたい評価はボーナスと連動している。だからいくら口先で良い評価と言ったところで内容が伴っていなければその人はふて腐れるだけである。また、組織で働く場合、誰と比べて良い評価... 日記 いまきち 2009-09-03T01:56:17+09:00 ＞その評価にたがわないようにつとめるのは人情である。
＞（305ページ）

ここでの文脈は対人交渉、セールスなどのノウハウと読めるが、
企業における評価に適用するのは少し難しいところもある。
金銭と、相対化がつきまとうからだ。

「良い評価」とは何だろうかと考えたとき、
昨今の企業はだいたい評価はボーナスと連動している。
だからいくら口先で良い評価と言ったところで
内容が伴っていなければその人はふて腐れるだけである。

また、組織で働く場合、誰と比べて良い評価なのか
という相対的な問題はいつもつきまとう。
みんなに勲章を与えたら、それは何もしていないのと同じ。
かといって誰かを表彰すれば、表彰されない人が出てくる。

だからこの法則の適用には注意を払う必要がある。
例えば、
・人に評価を与えるのではなく、チームに評価を与える。
・ボーナスや査定に縁がない人から評価してもらう。
と言うやり方だ。
そう考えれば引用した法則もじゅうぶんに活用できる。 ]]> http://dkse.sblo.jp/article/31792338.html ＞われわれには、他人から評価され、認められたい願望があり、＞そのためにはどんなことでもする。＞だが、心のこもらないうわべだけのお世辞には、反発を覚える。＞（300ページ）と言うことは結局、評価するぞ評価するぞー、と言って働かせておいて、結果に心服すればよいがそうでない場合の扱いが非常に難しい。「うわべだけでも心のこもった」事を言う必要がある。そういうのはどうだろうか。カーネギーの思うところとは別の方向に行ってしまいそうだ。やはり普段から感謝の心をわすれずに結果を残した人には惜... 日記 いまきち 2009-09-02T00:36:27+09:00 ＞そのためにはどんなことでもする。
＞だが、心のこもらないうわべだけのお世辞には、反発を覚える。
＞（300ページ）

と言うことは結局、評価するぞ評価するぞー、と言って
働かせておいて、結果に心服すればよいが
そうでない場合の扱いが非常に難しい。
「うわべだけでも心のこもった」事を言う必要がある。

そういうのはどうだろうか。
カーネギーの思うところとは別の方向に行ってしまいそうだ。
やはり普段から感謝の心をわすれずに
結果を残した人には惜しみない賞賛を与える人間にならないと
成功はおぼつかないということだ。

それにしても、
評価されたいがために人は頑張るというのは
ずばりと真実を言い当てているなあと思います。

その認められたい内容を、組織目標とリンクさせるのが
マネジメントなのでしょう。そうすることができれば
ハッパをかけることなくチームメンバーは頑張っちゃうという
ことですからね。

目標設定と評価制度の運用をしっかりとすることが重要です。
モラルやモチベーションの低下には必ずこのあたりが
絡んでいます。 ]]>