2010年4月28日水曜日

勝兵は先ず勝ちてしかる後に戦いを求む

気が向いたので孫子の一節を。

古の所謂善く戦う者は、勝ち易きに勝つ者なり。故に、善く戦う者の勝つや、知名なく勇功なし。

故に、その戦い勝ちてたがわず。たがわざるは、その措く所、必ず勝つ。
すでに敗るる者に勝てばなり。
この故に、勝兵は先ず勝ちてしかる後に戦いを求め、敗兵は先ず戦いてしかる後に勝ちを求む。
(軍形篇)
 
非常に簡単に言うと
『上手に戦いをする人は勝ちやすい状況を作り、勝ちやすい相手と戦う。だから、立派な働きをしているように見えないのに戦えば勝つ。それは既に負けが決まったような相手と戦うからだ』
という程度の意味です。
 
孫子は格調高い、まとまった文章が特徴であることが知られているので、状況を置き換えた文章を並べた本がずいぶんと出回っています。
なので、単純な置き換えではなく、実際の現場に即した書き方を試してみたいと思います。
 
『デスマーチと無縁に見えるプロジェクトリーダーは、要件と期間から”自分たちが”出来るかどうかを判断して出来る案件を優先的に請けるし、難しい案件でも条件を交渉して出来るように持っていく。
そのうえで予定通りに作業を進められるように準備・管理を行うので、大して仕事をしていないように見えるのに予定の期間と費用で仕事が終わっている。』
 
実際にはそんな案件ばかり請けることは難しいのですが、以下の循環に入る企業が多く見られます。
 
 案件(仕事の受注)や単価(売り上げ)が減って経営が厳しい
  ↓
 少しでも売り上げがほしいのでどんな案件でも請ける気持ちになってしまう
  ↓
 明らかに厳しい案件だが請けてしまう
  ↓
 プロジェクト炎上&デスマーチ発生
  ↓
 若手や中堅から戦線離脱&熟練者を含めたメンバーの退職を誘発
  ↓
 作業効率の低下
  ↓
 顧客からの評価が低下して案件や単価が減る
  ↓
 以下、エンドレス
 
この悪循環に近いことをしている企業を見たことがありますが、そこでは中途採用を積極的に行ってカバーしている様子でした。(4月に入社した新人十数名全員が翌年2月までに退職したと聞きましたが^^;)
明らかに「敗兵は先ず戦いてしかる後に勝ちを求む」状態ですね。
 
悪循環からの脱出方法は正直書くことができません。しかし、悪循環に陥らないようにとは言えますので、自分たちに出来そうにもない(作業量的に、です。技術や知識は補えることが多いので)仕事は請けないようにしましょう、としか言えないのです。孫子が生きていたとしても同様でしょう。
 

2010年4月26日月曜日

誰がためにドキュメントを書く

あからさまなタイトルですが、解りやすいので採用。

ドキュメント、という言葉もある種専門用語なのですが、SEはパソコンに向かってプログラムを書いている時間よりも、ドキュメントを書いている時間のほうが遥かに長いということをご存知でしょうか?
ドキュメントとは、簡単に言うと仕様書や設計書のことです。
 こんなものを作りたい⇒仕様書
 こういう手順で作りたい⇒設計書
誤解を恐れずに簡略化するとこんな感じです。

やりたいことは簡単なのですが、間違いなく・漏れなくドキュメントを書くのはじつに難しかったりします。
仕様書や設計書はいろいろな種類のドキュメントに細分化されるのですが… 細分化し過ぎて何のためのドキュメントか解らないこともしばしば。
 「このドキュメントは何のために書いているのか?」
 「このドキュメントは誰が読むためのものか?」
こんな基本も考えられないほど追いつめられるプロジェクトも存在します。
存在するというか、SEなら誰しも経験しています。
推測でなく断定してもかまいません。それくらい追いつめられているプロジェクトは… 話がずれるので割愛^^;

ドキュメントの意義について認識が合っていないと無駄な作業だけが増えるので、必要なドキュメントに絞って作業を進めるのが理想です。
しかし、現実にはそうもいかない(発注元の流儀で形だけでも必要・納品物として必要(←こういうのは大抵読まない))ので、なかなか難しいですが、一般的なドキュメントの意義を知ることで多少は理想に近づけるかな? と思っています。

2010年4月23日金曜日

読書、読諸、毒書

読書家というわけではありませんが、本を読むのが好きです。
どれくらい好きかというと、図書カード(10000円分)が2か月で残高0になる程度。
何故図書カードかというと、金券ショップで買えば多少安いから。
具体的には年間で新書3~4冊分くらいお得です。

そんな筆者の本を選ぶ基準は
 1、その時興味を持っている分野の本
 2、実体験からその世界(業界・社会)について考えることのできる本
 3、読みやすく翻訳された古典や洋書
 4、特定アジアをとりあげた本(親日/反日のいずれであれ、偏向し過ぎなものは却下)
の4つのいずれかに合うもの、というのが基本です。

 1、 はわかりやすく、特定分野について知りたいとき、この基準で選んだ本が常に手元にある状態になります。新技術を仕事で使うときなど、その技術の固有名詞がついた本が数冊並ぶ状況がみられます。(数冊=諭吉さん、その他何人かさようなら な価格です)
 2、 は普段読む本ですね。筆者的に普通の「読書」です。
 3、 は視野を広げたい時や『温故知新』などとかっこつけたいとき。その本を読むというよりも、読むことを通していろいろ考えたり知ったりするきっかけなので「読諸」と造語してみます。副産物として、故事成句や偉人の名言に詳しくなれます。
 4、 は時々マスコミや日本政府がヒステリックになるネタです。『アジア諸国が』と言いつつ実は『中国・韓国が』と言ったほうが相応しかったり、『歴史を鑑に』と言っている側が歴史を鑑にしていなかったりするので「毒書」してでも知識を仕入れておこうとする場合の基準です。相手の言うことを鵜呑みにすると『三国人とはなんだ、差別だ』などと間抜けな事を真顔で言うことになっちゃいますので、知識は重要です。

話題の本や人気作家といったあたりはスルーする傾向にあるので、読書好きの人と話が合わなかったりします(ピーター・ドラッカーも東野圭吾も読んだことがありません)
そう考えると、自分が楽しく、必要な情報が手に入ればOK なのかな?

2010年4月21日水曜日

プロジェクト管理に欠けたるもの

プロジェクト管理、と一言にいってもいろいろな意味がありますが、筆者のようなSEにとっては数名~十数名程度のチームの管理がまず連想されます。
予定と実績の管理と乖離した際の対応・メンバーの配置や士気、勤怠への配慮・チームの作業をいかにスムースに進めるか… と言った話はいくらでも雑誌などで取り上げていますが、今回はそれらで取り上げていないものについて書いてみます。

 取り上げられていないもの:管理者(リーダー)不在時の対処方法
リーダーだから、というだけでへろへろになりながらも出勤してくる人がいます。
しかし、リーダーだからそこまでしなくてはいけないというのはチームで仕事をする意味がないともいえます。
リーダーの役割は意外と単純で
 ・方針決定を行う
 ・チームの全体最適を指向する
 ・進捗の調整(特に遅れの取り戻し)を行う
 ・雑用その他諸々の事柄を処理する
という程度です。
コーディングはAさんに、DBのことはBさんに、会議の連絡調整はCさんに、といった具合にチームに必要な機能単位で実質的な担当分けを行っておけば、リーダーは機能不全に陥らないように状況を把握するだけでうまくいきます。
この方法の良い点は、リーダーでなければできないこと(発注者との折衝など)を除けば、担当分けを行ったA~Cさんに”いつもどおりに”確認して、仕事を進めることができる点です。長期の大まかな予定と、直近1ヶ月くらいの作業分担ができていればリーダーがやることは大してありません。

権限委譲の話に近いですが、普段から機能単位の担当分けを意識していれば「リーダー個人」ではなく「チーム」が仕事を回してくれます。
この状態を作り出すことこそ重要なのではないかな? と思います。

2010年4月20日火曜日

人材類型を考えてみる… ?

今回はかなり弱気ですが、システム開発にかかわる人材の類型を考える手掛かりとして、あるドイツ軍人が言ったとされる名言を取り上げてみます。
かなり歯切れが悪いですが… この名言は誰が言ったのかちゃんとした情報がないそうです。
詳しくは「ハンス・フォン・ゼークト wiki」でぐぐってみて下さい。

――――――――――――引用開始――――――――――――――
軍人は4つに分類される。


有能な怠け者。これは前線指揮官に向いている。
 理由は主に二通りあり、一つは怠け者であるために部下の力を遺憾なく発揮させるため。そして、どうすれば自分が、さらには部隊が楽に勝利できるかを考えるためである。

有能な働き者。これは参謀に向いている。
 理由は、勤勉であるために自ら考え、また実行しようとするので、部下を率いるよりは参謀として司令官を補佐する方がよいからである。また、あらゆる下準備を施すためでもある。

無能な怠け者。これは総司令官または連絡将校に向いている、もしくは下級兵士。
 理由は自ら考え動こうとしないので参謀や上官の命令どおりに動くためである。

無能な働き者。これは処刑するしかない。
 理由は働き者ではあるが、無能であるために間違いに気づかず進んで実行していこうとし、さらなる間違いを引き起こすため。
――――――――――――引用終了――――――――――――――


これの何処が手掛かりになるか?
「有能/無能」と「働き者/怠け者」のマトリクスで考えていますので、他への応用がしやすいのです。
まぁ、どんな組織でも「有能/無能」と「働き者/怠け者」のマトリクスは使えますのでそのままでもOKですね。
さすがに処刑はなしですけど^^;

システム開発的に、「有能/無能」と「働き者/怠け者」のマトリクスを使うとどうなるか…
――――――――――――改変開始――――――――――――――

SEは4つに分類される。

有能な怠け者。これはリーダーまたは教育者に向いている。
 理由は主に二通りあり、一つは怠け者であるために部下の力を遺憾なく発揮させる、若しくは部下の力を引出し、伸ばそうとするため。そして、どうすれば自分が、さらにはチームが楽に仕事を達成できるかを考えるためである。

有能な働き者。これは開発主任に向いている。
 理由は、勤勉であるために自ら考え、また実行しようとするので、部下を率いるよりは開発の中心人物としてリーダーを補佐する方がよいからである。また、あらゆる下準備を施すためでもある。

無能な怠け者。これは作業者に向いている。
 理由は自ら考え動こうとしないのでリーダーや主導的立場の人間の指示どおりに動くためである。また、定形化された業務を行うことにも向いている。

無能な働き者。これはコーダに向いている。
 理由は働き者ではあるが、無能であるために間違いに気づかず進んで実行していこうとし、さらなる間違いを引き起こすため。設計書通りの作業を与えるしかない。
――――――――――――改変終了―――――――――――――

どうしても、「有能な怠け者」のほうが「有能な働き者」よりも上の立場にいきますね。
「有能な働き者」が他の人にも自分と同じレベルの働きを求めてしまうと上には立てないから、というのが切実な理由なのですが、どこか抜けている上を下が支え、フォローしていく形の成功例が多いのも事実ですね。
尚、「無能な怠け者」は実は組織に欠かせない存在です。
非常に人聞きの悪い分類ですが、「有能な」人材は単調な作業を嫌う傾向にあるので補完関係になるわけです。

2010年4月18日日曜日

せと陶祖まつり に行ってみた

筆者は電車で通勤しているのですが、駅のポスターで「せと陶祖まつり」なるものを見かけたので行ってきました。
名前の通り、会場は瀬戸市。
名鉄瀬戸線の終点:尾張瀬戸の駅周辺でやっていたのですが、2箇所の広場と商店街で陶器などが大売出しという感じでした。

活気のあるまつりだなぁ、と思いつつ、手に取った陶器に違和感を感じずに入られませんでした。
というのも、使いやすさを意識していない品が多いのです。
昔ながらの厚手の器はそれはそれで良いものですが、持ちづらいのです。
日用品なのでその分厳しい目を向けてしまうのかな? とも思いましたが、使うことを考えると… ですね。

我々の作るシステムもこのレベルの目を向けられているとすると… 細部に気を配らないといけないな、と思わされました。

2010年4月16日金曜日

便利で危険なonLoad()

技術を書くはずがあらぬ方向に進んでいる当ブログ。
軌道修正も兼ねて技術ネタを一つ。

JavaScriptは何らかの動作(イベント)で処理を始めます。
一般的なものとして
 onClick():ボタンなどをクリックした時
 onMouseOver():マウスカーソルが乗った時
 onKeyDown():キーが押された時
などがあります。
今回のonLoad()もその一つです。
読んで字のごとく、画面を読み込んだ(ロードした)時に処理を行います。

よく目にするのが、画面読み込み時に見た目が勝手に変化するページ。
こういうページのソースをみると、<body …… onLoad="***" >と書いてあると思います。
画面読み込み時に "***" という処理で見た目の変更を行っているわけです。
ページを作る側にとってはずいぶんと便利なイベントなのですが……
便利であるがゆえに悪用も容易です。

怪しげなサイトに良くある仕掛けですが、ページを開くと勝手にウィンドウが立ち上がる。
そして、次々と新しいウィンドウが出来てきてしまってパニックになる…
身に覚えのあるあなた、怪しいサイトの利用はほどほどに^^;

このような仕掛けはonLoad()で簡単に実現できます。
具体的には、
 1、onLoad()で新しいウィンドウを開く
 2、新しいウィンドウに今開いているページを表示させる
これだけです。
ページを読み込むと、新しいウィンドウが開く⇒新しいウィンドウでページを読み込むと、新しいウィンドウ’が開く⇒新しいウィンドウ’でページを読み込むと…(以下略
ですね。

実物を用意しようと思ったのですが、開いたせいでOSがフリーズしたなどの被害が出るといけないので自重。
便利で危険なわけですが、道具は使いようということですね。

2010年4月15日木曜日

知りて言わざるは…

プレジデントのある記事を読んでいて出てきた言葉。
 不知而言不智 知而不言不忠
 (知らずして言うは不知 知りて言わざるは不忠)
韓非子の言葉で、言うまでもない内容なのですがせっかく目にしたのでネタにしてみます。

 「知らずして…」は『知ったかぶり、カコワルイ』と言っているだけなのでパス。
「知りて言わざるは不忠」こちらがエンジニア的に難しいところです。
直接の意味は『知ってるのに(上司・目上に)言わないのは不忠である』という程度になります。
それだけなら大したことではないのですが… 諫言する/しない に繋がっていくのではないかな? と思うのです。
韓非子は組織のなんたるかを考えた思想家なので、「知っているのに情報共有しないのは良くない」と言っているわけではありません。
組織の上位になればなるほど、組織内から上がる情報は濾過されたきれいなものになりがちと言います。
また、下位の者は「自分にしかできないこと/自分しか知らないこと」を持つことで相対的な優位を確保しようとする場合があります。
いずれにしても組織のTopには不都合な話です。
このように考えると、『自分や組織に不都合な情報こそ、上役に言うべきである。それをしないのは不忠である』という程度の意味になります。
ここまでは普通の組織に属する人に共通の内容です。
エンジニア的に難しい理由が、お客様(発注者/利用者)に対して『不忠』にならないようにしなくてはならないこと。(『不忠』を『不実』と言い換えるべきかもしれませんが、韓非子準拠ということでご了承ください)
システムを業務に完全に合わせるとさまざまな不都合が出ますし、業務自体が非効率というのも見えてくるかもしれません。
『不忠』にならないためにはそれらを言うべきなのでしょうが… なかなか言えるものではありません。
さて、どうするべきか。最終的にはその場その場で考えて判断するしかないかもしれません。

2010年4月14日水曜日

理想の人材って?

今回は「就活って何だ  人事部長から学生へ」(森健著 新春文庫)を読んで考えたことです。
この本は、就活の人気企業の人事部長(採用の責任者。肩書きはバラバラです)に直接取材をしたとあるのですが、2010年の採用活動直後の取材ということもあってか臨場感たっぷりの内容です。
各企業6ページ前後にまとめられているので読みやすく、比較しやすいのがポイント高いですね。

まとめの部分で『理想の人材像』なるものが提示されているのですが…
 「コミュニケーション能力に長け、困難に出会っても知恵と根気でやり遂げる知力と胆力があり、新しいことに挑戦するチャレンジ精神に富み、集団を率いるリーダーシップを持ちながらも、チームワークを重んじ、協調性も欠かさない」(242ページより)
……何処の完璧超人ですか? コレ と思いました。
実際、この直後に「実際にいるのかは不明だが」とあるのですが、私はこれを見て転職市場における採用基準(表向き)を思い出しました。
 「対人能力が高く、高度な専門性を持ち、チャレンジ精神に富み、困難に喜んで立ち向かい、教育なしに成果を上げつつ、チームワーク/協調性を持つ」
たぶん、このような感じになると思います。
コミュニケーション能力・協調性のあたりは集団で何かを行う以上必要ですが(必要とされるのは応募者だけではく企業の既存の構成メンバーもです。意外とこの辺を「郷に入りては郷に従え」で切り捨てる企業に限っていい人材がいないとぼやいているように感じます)そのほかの要素は併せ持つ必要はないと思うのです。

困難なことを避ける社員ばかりでは困りますが、困難を困難と解らないのはもっと困ります。
チャレンジしないと縮小均衡まっしぐらですが、チャレンジしない人が無価値というわけではありません。
リーダーは居ないと困りますが、リーダーばかりでは「船頭多くして船山に上る」でしょう。
チームワーク皆無は困りますが、ヒット商品の多くは個人の発想を伸ばした結果生まれています。(当然、最初は売れるわけないと言われます)

新卒にしても、中途にしても、その人の特徴があればいいのではないかな? というのが今の私の結論です。
適材適所という言葉がありますが、人材の特徴を生かせる仕事(例:チャレンジ精神豊富な人は前例の少ない仕事、堅実な人には前例のある仕事)を割り振るのが管理職の仕事であって、万能選手をそろえて楽をするのが管理職の仕事ではない、と。
管理職などという偉そうな立場ではありませんが、開発チームの進捗管理をする身としては常にこのことを気にかけていかないと、と思いを新たにさせられた本でした。


蛇足ですが…
ソニーなりホンダなり松下なり、いずれの創業者も得意分野を持つと同時に苦手分野を他者にフォローしてもらっています。(荒っぽく言うと、ソニーとホンダは技術屋と営業系の組み合わせなのでわかりやすいですね)
「名経営者に学ぶ」とか言って書籍を読んでいる人が冒頭の「理想の人材像」を持っているとしたら、何を学んだのか聞いてみたいですね。

2010年4月12日月曜日

話して解る、雑誌の中身

社内の勉強会でのこと。
私は何故かお勧め雑誌の紹介をすることになってしまいました。
そこで日経コンピュータを取り上げてみました。

その際、当然ですがお勧めの理由やポイントを話します。
話そうとして、ふと「日経コンピュータってどんな雑誌?」と思ったのです。
コンピュータと付く割にハードウェアの話はあまりない。
じゃぁ、ソフトウェアなのか? アプリケーション作成の話はやはり多いわけではない。
強いて言うならシステム開発にまつわる話題がメイン…

結局、システムの発注者・開発者、そして経営者の3者の視点を意識しているのかな? と結論付けることとなりました。
これが、DBの話メインであれば「DBについて詳しい雑誌」の一言で終わったのでしょう。
他人に説明することの難しさと、説明をまとめる作業の学習効果の高さを再認識した気がします。

2010年4月9日金曜日

iGoogleのある日常

Googleで無料で作成できる個人用ページ「iGoogle」というものがあります。
フリーメールを使ったメール管理はずいぶん昔からやっていましたが、iGoogleを使ってよく使う機能などを集約&どこからでも使えるようにしてみようと思い立ちました。

iGoogle自体はすでに使っていたのですが、翻訳や地図のガジェットしか入れていなかったので
 ・Gmail
 ・Blogger
を追加してみました。

さっそく、Bloggerのガジェットからこの投稿を行っていますが、結構便利です。
他人のPCからでも
 Googleのページを開く(http://www.google.co.jp だけ覚えていればOK)
⇒iGoogleにログイン
⇒表示されるガジェットにタイトル・本文を書き込んで公開
でブログへの投稿ができます。

今更感もありますが、パソコンの使い方が変わりそうです^^;

2010年4月8日木曜日

JavaとJavaScriptの境界

JavaとJavaScript
知らない人からしてみると「同じじゃないの?」と言いたくなる名前です。
どちらもプログラミング言語なのですが、用途や使い方は全く異なります。
今後、このブログでどちらの言語もよく登場すると思いますので違いについて書いて見たいと思います。
尚、詳しく知りたい方はGoogleに「Java wiki」とか「JavaScript wiki」と打ち込んで検索してみてください。
きっと詳しく正しく長々しい説明を見ることができます。

Java【じゃば】
 MicrosoftのVC++や.netと並んで、システム構築に使用される事の多いプログラミング言語。
ビルド(書いたプログラムをコンピューターが理解できる形式に変換すること)してから、コンピューター上で動かす。
インターネットを利用するシステムの場合、サーバーで動くのはこちらの言語で書いたプログラムが主体。

JavaScript【じゃばすくりぷと】
 IE(インターネットエクスプローラ)やFireFox(ファイアーフォックス)と言ったブラウザで表示するWebページ(今見ているブログもその一つです)の表示などに使用するプログラミング言語。
書いたプログラムはブラウザが読み取って実行してくれる。

簡単に書こうと心がけたのですが、専門用語を使わずに説明できませんでした ○| ̄|_
Javaは普段使うようなソフトを作る事が出来る言語、JavaScriptはWebページを使いやすくするための言語。つまり全然守備範囲が異なる言語になります。
守備範囲が異なるのに似た名前を持っている為、システム開発現場では2つを混同してしまうこともよくあります。
私自身、社会人1年目にこの2つを混同して困ったことに…
しかし、この2つの言語の境界は以下の事がわかると非常に簡単だったりします。
それは
 『JavaScriptはブラウザ上でしか動かない』
です。(原則、ですよ。例外はあります^^;)
ブラウザというのはHTMLファイルを読み取って表示するものです。
JavaScriptが動くのは、サーバーでJavaがHTMLファイルを作った後の話になる、というわけです。

これがJavaとJavaScriptの境界
…って、ちゃんと技術を勉強している人に怒られそうな説明ですが、区別するための一つの見方ですね。