板橋発 システム開発の考察 - 問い合わせは info@moonmile.net まで

2005年12月の記事です。

コンサルティングという仕事をするならば、如何に単価を釣り上げるか、が問題になります。つまりは、時間給です。時間売りです。

ただし、受けるお客さんの方も、「手早く」＝「安く」という考えが染みついているので、「時間がかかる」＝「高い」は擬似的に正しい認識なのですね。今だと、更にそう思います。

で、余った時間をどう使うか。これが、人生の楽しみ方なのかなと。

時間に追われる仕事なのか、時間を制御する仕事なのか、というお話です。

〜〜〜

「ライト、ついてますか」を再読していたのですが、「彼らの問題をあまりやすやすと解いてやると、彼らは本当の問題を解いてもらったとは決して信じない」（「ライト、ついてますか」の39頁より）を見つけました。



これは重要です。例えばですね、500万円の仕事を1日で終わってはいけないのです（終われたとしても）、500万円の仕事は月100万であれば、５ヶ月間じっくりかけないと信用して貰えません。このあたりは、作業数＝金額の幻想（労働力の金額への変換の幻想かな）を持っている場合には、支払う金額と解決された問題（解答）との差は、作業時間に比すると思います。



と、一方で、JCOMの株を狙ったり、宝くじを狙ったり、一攫千金のアイデアをひねり出そうと頑張ったり、するわけで、そういうのは、作業時間とは違うところにあります。アイデアをひねる場合には、ひねっている時間＝作業量として換算することもできますが、ひねった後に解決する時間（コーディングとかパソコンがかたかた動いている時間とか、人がばたばた動いている時間とか）のほうが、目に見え易いので、人はそちらを重視したりします。



なので、「彼らの解決方法を問題の定義と取り違えるな」というのを忘れないと同時に、「彼らの問題をあまりやすやすと〜」を忘れずにしないと、一生懸命頑張って徹夜仕事をして、やっとこさ結果を出している人のほうが評価されたりします、のでご注意を。



さて、このバランスをソフトウェア業界での実例に照らし合わせてみると、


とあるフレームワークの導入が難しいんだが、効果的な教育をして欲しい。皆しろうとなんだ。けれども絶対導入したい、先々が効率的になるし。できれば２日で！

ここのバグが解決されないと、オープンができないんだ。とっても重要なんだ。効率的で素早くて間違いがない修正方法はないだろうか？　絶対明日までに！

この部分は重要なので、はずせない機能なんだよ。絶対必要で、ユーザへのアピールが一番。このプロジェクトのコアな部分なんだ。だから絶対取り入れてよ。だけど、予算がないので、安く仕上げて！


という話は、よくあるもので、こういう場合は「何が問題か？」を再検討せずに、手始めに気分で取り組んでしまうとどつぼに嵌ります。最悪、健康を害します。



なので、最近の私の場合どうするかと言えば、ひとまず、２、３日間、間を置きます。ほおって置いて、別なことをやります。そうして、もう一度同じことを聞いてみます。本当の問題ではない場合、その問題は自然消滅します。あるいは、別の人が解決してくれていたりします。コンサルだと高時給でこういう手はいいのですが、開発者だと、仕事をしていないように見える（実際していない！）ので、これが目下、私の悩みですね。。。

2004年に書いた時には、「サバイバル規則」という杖が必要だったのです。

今はどうかと言うと、「孤独でもきちんと結果に結び付けられる自分」を獲得したかな、と。

# いえ、それほど便利にはできていませんが ^^;

〜〜〜

サバイバル規則は（「スーパーエンジニアへの道」が初出かな？）、自分がこうと決めていることに深層的に縛られて、どうにも分かっているけれども行動が取れない／行動を取ってしまう、という奥底にある規則です。これは、大人になるうちにいろいろな傷を負ってしまったため、何かを避けたり何かから自分を効率よく防御するための「生きる知恵」でもあります。

ですが、それが一度規則として確定していまうと、とある変化に弱くなります。一般的な話で言えば、

• 年寄りは頑固になる
  
  


• この社内規則で万全だから、それに沿って動けばよい
  
  


• マネージャ／上司の言うことに従う
  
  


• いつもこの方法でうまく行っているのだから絶対大丈夫だ
  
  
  
  みたいなものです。アジャイルに反するところのウォーターフォール方式であったり、アジャイルに固執する自称アジャイルな人（苦笑）もそうだったりするでしょう。
  
  
  
  さて、この頑固な規則に自分が縛られていると分かったとき、どのようにしていくのか、が問題なわけですが、ラジカルに規則を破壊することも可能ですが、心理的な障壁が多く結局のところ頑固な規則はそのまま、というパターンに陥りかねません。
  
  そういう場合には、「規則をガイドに変換する」（「スーパーエンジニアの道」147頁より）を行うわけで、
  
  
  
  


• 第１段階　規則を明確かつ具体的に述べる
  
  


• 第２段階　その規則のサバイバル上の価値を承認し、自分の無意識と取引する
  
  


• 第３段階　自分に選択の余地を与える
  
  


• 第４段階　確実性から可能性への変換をする
  
  


• 第５段階　規則の中の全体性を、非全体性に変える
  
  


• 第６段階　一般を個別に変える
  
  
  
  という流れを踏みます。例えば、朝９時に出社しなければいけない会社の規則に囚われてしまった場合、朝起きるのが辛い人（私を含む）には非常にキツイ規則であるため、反抗的に11時出社を繰り返したりしてしまいます。これを、すこ〜し直すためには、
  
  
  
  


• 第１段階　朝９時に会社に出社しなければならない。
  
  


• 第２段階　朝９時に出社することは、午前中に仕事ができるし、午前11時に出社して遅く帰るよりも価値があることだ。でも眠いときもあれば、調子が悪いときもあって、いつもいつも朝９時に出社するのよいわけではない。
  
  


• 第３段階　調子の良いときは朝９時に出社すればよいし、調子の悪いときには朝11時出社でもよかろう。たまに寝坊は許そう。
  
  


• 第４段階　だから、ひょっとして朝９時に出社することも可能だろう。
  
  


• 第５段階　その気になれば、朝９時に出社すればよい。毎日でなくてよい。
  
  


• 第６段階　調子のよいときには朝９時に出社しよう。少し仕事が詰まっているときは、遅く帰るのはやめて朝９時に出社してみよう。
  
  
  
  という流れにします。勝手に。そうすると、「毎日朝９時に出社しなければならない」という恐怖政治のような規則（朝の辛い人にはそうなのです）から逃れることができて、「調子がよいときには、朝早く行くのもよかろう」という気になってきます。
  
  ちなみに、私は朝９時には出社しておりません。が、朝10時には来れるようになりました。その前は、午前11時だったり、午後2時だったりするので、かなりの進歩です。
  
  
  
  このサバイバル規則ですが、誰もが持っています。例えば、
  
  
  
  


• 何故、この上司は、こんな不思議なことに固執するのだろうか？
  
  


• 何故、この顧客は、こっちの案件がいいのに最初の案に固執するのだろうか？
  
  


• 何故、このメンバは、私の言ったことを聞かず、前と変わらない方法でやっているのだろうか？
  
  
  
  と疑問があるときには、大抵、なんらかの固定化された「サバイバル規則」を彼／彼女が持っています。そういう場合には、それなりの動機付けや誘導が必要になり、圧力や頑固な規則は好ましくありません。
  
  
  
  ・・・とか、言っている私自身、そうそう相手の話を聞く気にもなれなくて脊髄反射的になってしまうことも多々ありあます。そういう場合は、１０数えて深呼吸して、あきれるか（「上司は思いつきでものを言う」より）、微笑するか（「上機嫌の作法」より）、することにします、、、いえ、しようと努力しています、なかなかうまくいかんけど。
  
  

2004年当時、ユビキタスコンピューティングの黎明期。今でこそ、携帯電は誰でも持つツールであり、電話機能だけでなく小型化されたコンピュータとしてスマートフォン（特にiPhone）を一般の人が使い始めているけど、当時は「コンピュータ」は、まだまだPCと直結していた頃の話。

三冊とも、まだ家で現役です。

〜〜〜

「パソコンを隠せ、アナログ発想でいこう！」

原著タイトルは「見えないコンピュータ」（こっちのほうが良さそう…）



「誰のためのデザイン？」の著者、Ｄ．Ａ．ノーマンの本を池袋ジュンク堂で購入。どちらも、心理学の本棚にあるところが不思議、、、というか認知学なので、当然といえば当然なのかもしれない。



まだ、序文と最初の数ページしか読んでいないので、感想というわけではないのだが、昨今の家電コンピュータ＝ユビキタス→T-Engineなんてものを考えると、それぞれのユーザに合ったデザインなり動きなり振る舞いなりを考えないと、それはパソコンの画面の延長でしかなくて、かえって不便になった「コンピュータはむずかしすぎて、使えない！」ことになる。

坂村教授曰く「大根を収穫しているときはバーコードなんか使えない。汚れるとすぐエラーになってしまう」、というわけでＩＣタグを使うとか、ウェアラブコンピュータという大層な装置を使うわけではなく、T-Engine時計ぐらいに隠してしまうとか、そういうインフラの部分にコンピュータを沈めていかなくてはいけない。

実は、この記事は

Internet Archive http://www.archive.org/web/web.php から拾ってきてる。

なので、そのままリンクを辿ると、その先の頁がない状態が多い（つまりは、それだけ情報が消えてしまっているということだ。もったいない）。

2004年に見つけた「教師になったホテルマン」だが、実は2001年の記事。

アジャイルと教育をうまく組み合わせた例で、ホテル経営なんだけども、十分ソフトウェアの現場でも使えるという話。

そうそう、板橋区で行われれる「こども起業塾」みたいなものです。

夏休み子ども起業塾

http://www.itabashi-kigyou.jp/kodomo.html

〜

教師になったホテルマン

ホテル経営学のページなんだが、アジャイルかつブレーンストーミングを行った良い例。マネージメントとか役割分担とか、プロジェクトが流れていくときのツボはソフトウェア開発とまったく一緒。

2004年7月に結城さんが書いた記事

デスマーチの起きる理由

マネージメントレベルからみた制約理論。マネージャ同士が協力し合わない理由が、あるデスマーチを支えているということを示している。何故、デスマーチになるのか、というよりも、デスマーチになったプロジェクトがどうして回復できないのか、何故プロジェクトはデスマーチであり続けるのか、という証明をしている。…なので、微妙のところを突くと、デスマーチの救済策ではあるのだが、デスマーチにならない方策というものではない。

が、プロジェクトのスループットを上げる＝プロジェクトを納期以内に終わらせることによって、次のプロジェクトに着手ができる、という意味が明確になれば、マネージャ自身の評価は、いかに大変なプロジェクトを切り盛りするか、という後ろ向きな経営方針そしてマネージャに対する評価のゼロサムゲームから抜け出し、プロジェクトを計画通りに終わらせる、プロジェクトがきちんと終わるような見積もり＆計画を立てるという能力を発達させることができるだろう、という気がする。

〜

当時、ゴールドラット著「ザ・ゴール」が流行っていて、小難しい話を小説風に解説する、という記事がいくつかあった。この、「デスマーチの起きる理由」を巡ってもいくつか議論があったのだが、今考えると、

• 当時、結城さんも部外者（デスマーチになるプロジェクトにリアルな段階で関わっていない）
  

という点で、外側からの指標にしかならない（これは、結城さんという立場の限界でもある）。

で、今、私は「会社という組織から抜けた身」なので、「デスマーチ」を語る資格はない。現状、デスマーチに織り込まれてしまっている方々に対する言葉は、「参考意見」でしかない。

が、あえて言えば、

デスマーチとなる匂いを察知せよ。

察知して、あなたが「責任者でなければ」、逃げる方策を考えよ。

察知して、あなたが「責任者であれば」、デスマーチの核となる人（必ず人が原因）を「排斥せよ」。

としか言えない。

それくらい「デスマーチ」は「デス＝死」を意味するし、身体的にも精神的にも病気になるし、人生の無駄と言えるぐらい恐い。

もちろん、この不況下に転職先があるだろうか？という不安も募る。

1. 第一の方法は、会社を辞めずに、デスマーチプロジェクトを回避する。
   


2. デスマーチプロジェクトに放り込まれたら、避けるのみ。
   


3. 核になってしまったら、「病気」になって、辞めることも考えろ。
   

という流れがよい。

後ろ向きだが、墜落しつつある旅客機の乗客は、旅客機を助けられない。あなたが映画のヒーロー/ヒロインでなければ。

「ナレッジマネージメント」という単語が広まって随分経ちましたが、以前、野中教授の講演に行ったときのメモが出てきたので再投稿しておきます。

2004年当時、企業内の知識をどのように活用していくのか？どのように管理していくのか？が話題になっていました。

ジャストシステムをはじめとして色々なナレッジマネージメントのツールが出てきましたが、最近では、文書管理と社内SNSに落ち着いているようです。

ですが、本質なところは、「いかに会社内に知恵を廻すか」というところです。時には社外も含めて「廻さない」とダメですね。

ここに出てくる「奥山部長」は、

富士通導入事例レポート - 対談:アサヒビール株式会社 [業務プロセス改革]

マイクロソフト導入事例 : アサヒビール株式会社

に出てくる「業務システム部長」です。

---- 以下は、メモです ---

概要

基調講演：野中教授、講演：アサヒビール：奥山部長、大成建設：木内部長



基調講演 野中教授

客観的な視点分析と主観的な取り組みが大切

客観的な経営体制に問題がある



講演１ アサヒビール 奥山部長

ナレッジマネージメントを7年間行っている。

ここ数年間でビール・発泡酒以外を発売していきている（２０００年から事業ドメインの拡大）。

IT部は１１名（戦略、企画、管理）・・・総勢１万人の会社にしては小さい？

情報カードで共有、営業情報玉手箱（１９９９年）、技術情報知恵袋（２０００年）

新商品開発にコンセプトメークの過程を導入

情報の清流化（依頼、報告、集計、伝達）、第一線の意見が社内につながっていく。

PDAの活用（ツールの活用）

ITに関する再考察

→ あるべき企業のひとつの姿「変化にすばやく対応できる」

→ 後天的使命（部門の壁を壊す、組織のスピードを高める、新たな価値を創出する）

フレッシュ・マネジメント活動

→ ITとは、各部門の一生懸命を、横串を通してまとめる役割

Offence（後天的使命）

早いとは、すばやく感知して、共有して、即対応するという流れをいう。

会社の強みをKMで強化する。文化を社内で定着させる。KMは、部門活性化の手段より経営革新に活用したほうが効果が大きい。

頭に汗をかく組織でありたい。

「アサヒは、１０年後も元気でいたい」、「１０年後も皆様に元気をお届けしたい」

→ そのために、ナレッジ・マネージメントを展開

講演２ 大成建設 木内部長

建築業界全体の受注額の低迷

建設業界の付加価値が他業界に比べて低い

3年前からKM活動を行っている。２つの活動を同時進行で行った

→ BPI活動（パワープロジェクト）

→ システム構築（IT戦略プロジェクト）

業務プロセスの可視化、データ設計の可視化（ER図をユーザ部門で使っている）

ITプロジェクトを成功に導くポイント

・経営者のコミットメントが欠かせない（変革を起動させる原動力）

・プロジェクトへのユーザー部門からの参画

・部分最適から全体最適へ

・ビジネス設計ができるのは業務従事者だけ。

・可視化が重要（ルール、標準化、コストの可視化）

。横断的組織だったからできた（情報システム管理部が社長室付だった）

→ 社長室長がCIOという経営者の後ろ盾を得た

→ 経営企画部と連携が取れる強み

→ 全体最適をすすめるに許される口出し

→ 俯瞰する目

建設業は工場を持たない受注型製造業と考えられる。

→ 日本のゼネコンは、プロジェクト管理型アセンブラ

→ 資材も機材も持たないヒューマンな生産活動

生産拠点に必要なものは「現場力」である。

「作業所Net」という構想

→ 作業所Netは作業所業務のポータルサイトである

知識管理の１０原則

→ IT管理だけでは駄目。人を管理しなければいけない。

→ 日本とアメリカの文化の違いがある

背景の違い日本の場合には、固有のKMが必要ではないか。

ガバナンスの強化

→ 経営システムとしての知識管理

人材の育成

→ 「知」を生成できる創造型人材の育成

企業のカルチャーの定着

とある理由で、中断していましたシステム開発の道具箱シリーズを再開いたします。

昔の道具箱は、http://moonmile.net/mymy/ を参照してくださると幸いです。

ここのブログでは、

• システム開発をする上でのコツ（ウォータフォール開発、アジャイル開発を問わず）
  


• システム開発を発注する上での注意点
  


• 要求定義とは何か？
  


• 設計とは何か？
  

を話していきたいと思います。

過去の引き出しからも交えつつ、ツイッター @moonmile も交えつつ、やっていきますので。

よろしく。