2009年03月08日

管理しているという状態のための基本行動

プロジェクトにしろ、資産などの管理にしろ、管理しているという状態を維持するためには以下の4つの基本行動を実施しなくてはいけません。

1. 更新
2. 監視
3. 周知
4. 共有

1. 更新は管理している情報を常に最新にしていくことです。これは逐次情報を更新しなくては、いつのまにか現状との乖離が発生し、管理している情報が陳腐化・古くなって利用できなくなってしまうためです。更新されていない管理表がある場合、それは管理にはなっていないと言えます。

2. 監視は、管理者が常に情報の変更事由が発生していないかをチェックする必要があります。その事由をトリガーにして、情報を更新しなくてはいけませんが、何を持って更新するかが分かっていなければ、またその更新タイミングが分からなければ情報の更新が出来ません。

3. 周知は、管理者が勝手に管理しているという状態を防ぐ目的があります。管理されている側は何が管理されているか分からなければ、管理者に協力などできません。よって、何か変更があったとしても管理される側は当然勝手に実施しますし、管理者も監視が難しくなります。よって、何を管理しているか、常に管理者はメンバーに周知する必要があります。

4. 共有は、管理している情報を共有し、メンバーもどんな情報が管理されているか、また無駄な調査が発生したりしないようにすることを目的としています。最も重要なのは、メンバーに管理されているということを意識させることになることです。


この4つの基本行動を実施できない管理は、結局管理情報と実際に乖離が発生し、年に数回の棚卸しが発生します。
正しく管理されていれば棚卸しなど不要なはずですし、その工数も無駄になります。であれば、管理されていなくても多少情報収集が楽になるぐらいで、あまり意味がないと思います。

2009年02月28日

情報共有と取捨選択

仕事を行う上で、情報を共有していくことはとても重要です。
情報とは、原則連絡網で動いていきますし、動いていくべきです。
例えば、このようにシステムを作ろうと決定していくのは、特定の人だけが会議に出て実施されます。会議に全員が出れば早いのでしょうが、会議の人数が増えるほどに会議時間は増加してまとまりがなくなるため、一般的に会議参加者は絞られ、その結果は上から下に情報連携されるのが一般的です。

よく以下のような会話を聞きます。
A:「そんな話、だれも聞いていなかったよ。」
B:「ごめん、情報の連携が不要だと思っていた。後でメールで送る。」

これは以下の問題があります。
1. 会議出席者が情報共有の重要性を認識しておらず、情報連携をしない
2. 会議出席者が情報の取捨選択を主に行う
3. 情報連携が無いことによる無駄な作業等が発生している
などなど。。。

今回の話のポイントは2番目の取捨選択です。

社会人において重要なスキルの一つに情報の取捨選択があります。これはつまり、必要な情報を自分で見つけ出し、不要な情報は破棄できる能力を身につけるという事です。
このポイントは、何が自分にとって必要な情報なのか等の判断能力が求められるという事です。

この情報の取捨選択というものは、情報を送信する側と情報を受信する側のどちらが実施しなくてはいけないでしょうか?
答えは当然両方ともなのですが、それぞれ何を取捨選択しなくてはいけないかが違います。
情報送信者は、情報受信者が知ってはいけない情報を送信するかどうかを取捨選択しなくてはいけません。その情報には権限上の制限がかかります。
逆に情報受信者は、その情報が自身のタスクに関係するかを取捨選択しなくてはいけません。その情報には自分の仕事との掛け算がかかります。
この情報受信者が実施するべき取捨選択を、普段、情報送信者が勝手にやっているわけです。これは情報共有でもなく、それ以上に情報受信者の取捨選択スキルを向上させることもできません。

当然、情報送信者が受信者を混乱させないために意図的に情報を連携しないケースもあります。が、それはレアケースであることが多いです。つまり、情報連携が足りないことが多いのです。
逆に言えば、情報送信者の取捨選択スキルがないために情報連携の過不足が発生しているのです。

一番厄介なのは、これを情報送信者が問題であると認識していないことです。
ある程度オブジェクト指向を知ったSEは、これが情報のカプセル化と勝手に思い込むようですが、どんな情報が受信者で必要となるかまでを完全に理解していないのであれば、私は情報送信者は全情報を情報受信者に連携しても良いと思います。

勝手な作業やタスクをしているという人がいる場合、情報連携に問題がないかどうかも一度検討してみてください。
全く業務と関係ない方向に進む人は情報連携以前ですが、業務に関連して方向性が違うタスクを実施している人がいる場合、それは情報送信者の情報連携・取捨選択に問題があるケースも多いと思います。
一度、自身が発信・受信する情報が妥当か確認することを推奨します。

2008年12月28日

設計書を横串で見る

20万ステップを越えるようなソースや、40画面以上の構築案件など、中規模から大規模な開発は結構多いと思いますが、こういったプロジェクトで実施すべきことがあります。
それは設計書を横串で見るということです。

通常、設計書は各機能単位で作成し、その単位でしか管理されません。私はこれを縦串で見ていると呼んでいます。
これに対し複数の機能を設計書の目次単位で比較することを横串で見ると呼んでいます。

設計書を横串で見ることで、以下のような開発のメリットがあります。
1. 共通機能を提供できるため、各機能を用意に構築できる
2. テスト期間を減少させることが出来る。これは共通機能を厚くテストすれば、機能を利用しているものは機能が利用されていることだけを正しく確認すればよいのです。
3. 用語の違い等を是正できます。つまり、人によって表現が違う部分を統一できます。それはつまり、設計書の品質向上に繋がります。
4. 共通機能を別設計書にし、固有の設計書は共通機能の設計書を参照することにより、設計書の修正のしやすさを向上できます。
5. どの機能がどの共通項目を利用するか、横串で確認しまとめることで、全体にわたる修正が発生したときにどの画面が対象かを即座に調査できる。逆に言えば、それをすることが横串で見るという事。


設計書は縦串で見ると、例えば画面設計書であれば以下のような目次を考えることが出来ると思います。

1. 画面の概要(だれが、どういった目的で利用するかなど)
2. 画面遷移(どの画面から遷移し、どの画面に遷移していくか)
3. 画面設計(画面のレイアウトなど。こちらは要件定義で作成したモックが多いと思います)
4. 画面項目(画面の入力項目の一覧、入力可能な文字種、文字数、バリデーションなど)
5. BL(Business Logic)呼び出し(実質の業務処理を呼び出し方や引数など)
6. セッション管理(どの情報をどのタイミングで保存したり破棄するかなど。)

こういったものを作りはじめる前から、通常は共通機能の設計が始まっていると思います。ですが、共通機能は先に実施されているという認識が一般的なため、要件定義の後、外部設計フェーズレベルから共通機能の設計が始まり、その後縦串の各機能の設計が始まります。
私の経験上、この最初に作られた共通機能の洗い出しが不十分であることが多いです。正確に言えば、共通機能を本気で洗い出していないか、洗い出すスキルがないことがほとんどです。そして、そのまま縦串の設計が始まり、共通機能の洗い出しは、以降実施されることはありません。

これに対して、私は共通機能の洗い出しは外部設計終了後に実施すべきだと考えています。
この際、上記の設計項目1〜6を複数機能で並べて見る必要があります。そうすることで、最初に共通機能を洗い出すよりも適切な洗い出しが出来ます。
そして、その洗い出しと共通機能の設計、それを外部設計に反映してから内部設計に行くべきだと考えます。
こうすることで、共通機能を外部設計レベルで適切に開発でき、開発工数を減少させることが出来ます。

ここで疑問が複数出ると思います。
A. どのレベルまで共通化したらよいのか?
B. 共通化すると、画面固有の機能が出た場合、例外が出るから共通化できないのでは?
C. 開発期間は本当に縮小するのか?

A.
私は全てを共通項目とするべきだと考えます。「え?画面固有のものもあるよ」と思う方もいると思います。
まずは画面項目や入力項目を共通化していきます。
例えば、普通は名前入力欄は各画面でtextboxとして定義するでしょうが、これを1つのタグで表現できるように共通化していきます。これを名前、住所、電話番号のように各項目の部品を作ります。
次に、複数項目を共通化していきます。例えばユーザ登録の場合、複数画面で名前、住所、電話番号を入力させる場合は、このセットを共通化項目として1つのタグで表現できるようにしていきます。
このようにしていくことで1つの画面はいくつかの意味的に分かれた項目のみのタグで表現されます。
こうすることで、画面の構築は用意されている部品を使うだけなので、全体にわたる横断的な修正に強くなります。

B.
これは二つの考えを持つべきです。
一つ目は、複数の項目を組み合わせると例外だが、各項目単体では共通化できると判断する。
二つ目は、その差を吸収できる共通化機能を作成する。
これは二つ目を優先し、一つ目は二つ目が難しい場合のみに適用するべきです。
これは、全体にわたる横断的な修正も共通機能が吸収できるため、各機能の修正の範囲を極小化させるための方策です。

C.
これは、本当はあまり変らないケースもあります。ですが、なぜか共通化されていないほうが工数が多くかかります。
これは技術云々ではありません。同じことを何度も修正させられると、人間ですので飽きたり、何でこんなことを一つにまとめられないんだと感じ、モチベーションが低下するためです。
モチベーションの低下は生産性の低下を意味します。メンバーには最小の修正で大規模な修正ができることをアピールできるほうが、やる気が出ます。


今まで、どのプロジェクトも設計書を横串で見たことがありません。つまり、いつまでも同じ開発を行って、仕様変更やバグによって今までと同じように、各画面の影響調査から入って、がんばって全体を調査し、全体の再テストを行うといったことをしているのです。
いつまでもシステム開発が属人的で、システム化されていないといえます。
そうではなく、フェーズの中で事前に影響調査に役立つ共通化というものを入れて、システマチックな開発を実施すべきだと私は考えます。

この行為は、短期的には工数の増大を招きますが、後々修正や保守フェーズに至ったときの工数抑制を考慮すると、いわゆる急がば回れになります。

どういった観点で設計書を見ていくべきか、設計者は設計書の書き方、見方、設計の進め方、リーダーはフェーズの進め方を再度検討する必要があると私は考えています。
今回のお話は難しく、意味不明なことも(説明不足もあって申し訳ありません)多いと思います。が、この設計書を横串で見るというフェーズについてはまだまだ考え方は完璧ではないので、より現実的で分かりやすいものを検討していきたいと思います。

最後に、駄文と長文で失礼しました。

2008年12月19日

新規参画者のための開発ポータルサイト作成

どのプロジェクトでも、またプロジェクトに関わらず企業において新しくきた人間(新規参画者や新人)にはすばやく業務に慣れて、活躍して欲しいと思うものです。
ここでは特に、プロジェクトの新規参画者に関して述べたいと思います。
現実的に新規参画者に対して、プロジェクトメンバーが直接教育することは少ないと思います。通常はプロジェクトのリーダーやプロジェクトマネージャが、新規参画者のみを呼び、会議室でホワイトボードでも利用して以下のことを説明するぐらいです。

1. このプロジェクトの名前
2. このプロジェクトのお客様
3. 何のためにこのプロジェクトをしているか
4. このプロジェクトのゴール、何を作らないといけないか
5. 体制とプロジェクトの期間
6. あなたの役割
7. ドキュメントのだいたいの場所と、誰に聞けばよいか

さて、これだけであなたは、いきなり「じゃぁ、このシステムのここのプログラムを作って」と言われて作れますか?
通常はまず、慣れるために存在している成果物を眺めたり、設計書等のドキュメントを読んだりします。そして、当たって砕けろです。
分からないことは都度、隣の人に聞いてみることを実践すると思います。他にもいろいろとやるかもしれませんが、この最初の作業が"システムを作っている人たちの作業がシステム化されていない"のです。

同様のことは、ある程度プロジェクトに慣れて、忙しさのあまり混乱してきたメンバーへのフォローにも言えます。
そのたびに、プロジェクトリーダーやプロジェクトマネージャは人を集めては、上の1〜7+αを説明するのです。

私はこの部分をどうやって解決するべきか、ずっと考えています。
現状では、「開発ポータルサイトを作成する」という意見に至っています。

開発ポータルとして、Wikiを利用することをおすすめします。WikiといってもWikipediaではありませんが。
Wikiのシステムとしては、導入の簡単さや利用方法、見た目の美しさ等から、JAMWikiをおすすめしています。JAMWikiは、MediaWikiというWikipediaのWikiシステムを目指したシステムです。
データベースを利用しなくても良いため、簡単に利用できますし、全文検索ができるので、利便性が高いと言えます。Tracのようなプロジェクト管理にもってこいのツールもありますが、それを利用しないことを検討しています。Tracならばバグ管理、バージョン管理、Wikiを構築できますが、それだけにハードルも高くなると思います。

Wikiに、プロジェクトについてまとめていき、このWikiを新規参画者に読んでもらうことで上記を解決できないかと検討しています。
Wikiには以下の内容を記述するべきだと考えています。

・トップページ
- プロジェクト名と良く見るページへのリンク。
- 暇つぶしに見るとよいニュースサイト等。これがあると、メンバーが息抜きしやすくなりますし、技術サイトへのリンクによって、メンバーが自分で技術情報を探せます。

・プロジェクトについて
- 概要
- スケジュール
- システム全体図と開発範囲
- 何を作りたいのか?誰が何に使って、それでお客様は何をしたいのか。そういう内容を意識させられるように記述する。

・用語説明
- プロジェクト内の用語について

・メンバーの連絡先
- リーダーやメールアドレス一覧など。

・技術的なまとめ
- プログラム技術や設計書の書き方。標準化等。

・設計書情報
- 設計書へのリンク。ポイントはフォルダとファイルへのダイレクトリンクの両方を作ること。

・バグ管理等
- バグ管理システム Trac 等へのリンク

・方針
- たとえば、テストはこういう方法で、ここを検証してください等

・ツール
- 良く使うツールや、メンバーが独自に作ったツールのリンク等

・リンク集
- おすすめの飲み会のお店のリンク

メンバーが比較的自由にページを記入できるようにするべきですが、必ず管理者をたてて、利用者の管理を行うようにする必要があります。そうでなければ、管理が行き届かず、荒れてしまいます。
同様に記述を推奨し、記述しやすい環境を構築するべきでしょう。


Wikiだけでなく、Blogシステムも構築すると良いと思います。
Java用Blogシステムについては検討したことがないため、良く分かりませんが、Blogを利用して日報の代わりにしたり、自慢話みたいなものや意見、提案、飲み屋の情報を、公序良俗に反しない犯意で自由に記入してよいようにすると、リーダーはメンバーの考えを理解しやすいのではないでしょうか?

ただし、どちらも記述内容をどこまで制限するか、どうやって記入を促進するかが課題です。書かない人はとことん書きません。
同様にして自分の情報を出さない人も多いです。情報を共有することの重要性を理解していないことが最も多い理由です。そこはどんなに優秀な人でも実施してくれないケースがあります。
義務化も優先すべきは業務なため、難しいです。

そこの部分はどうするか、まだ検討中です。この案は、まだ私自身が実施していないことです。もしすでに実施している方がいれば、参考意見を聞けたらうれしい限りです。


このように、プロジェクトに対するまとめを記述した開発ポータルサイトを構築することで、新規参画者はサイトを見ればプロジェクトの概要やゴールを知ることができ、すでに参加している人も検索やまとめられた情報からすばやく情報を取得でき、効率的なのではないかと考えます。

2008年12月13日

金融若手SEにおすすめしたい本

金融を相手にSEをしている人にとって、金融の業務を理解することはなかなか大変です。扱うのはお金とその流れなのに、何をやっているのか、どんなパッケージやサービスがあるのか、全量を把握しにくいと思います。
そんな中で表層だけでもどんなものがあるのか知りたいことがあると思います。「SEのための金融の基礎知識」という本は、そういう表層部分を得るには良い本だと思います。

この本の内容は、まずは、金融業界を軽く紹介してくれます。
その後、金融業の各業態について、業務を簡単に教えてくれます。
最後にトラブル事例等の事例集と用語集がつきます。

広く浅く知るにはもってこいだと思います。
私が経験したことがあるSWIFT、CAFIS、全銀、保険やクレジットカード、いろいろと載っています。日銀Netについては扱いが小さく、RTGSも用語集ぐらいでした。今年から来年にかけて、SEにとっては金融は大きなニュースが多いので、目白押しな感じです。

この本は自分が金融を相手にスキルアップやキャリア上どんなことをやってみたいかを考える上でも、とても参考になると思います。
ただし、内容については中堅社員には物足りない本かもしれません。あくまで若手向けとして、お勧めしたいと思います。

2008年11月02日

モチベーションは確認できないものなのか?

IT業界では、特にプロジェクト参加メンバーは、リーダーやプロジェクトマネージャの一つ一つで簡単にモチベーションが上がったり下がったりするものです。
リーダーにとってはメンバーがモチベーションを下げてしまうことを極端に嫌がります。それは、メンバーにモチベーションがないと、メンバーは「どうでもいいや」といった感情を持つため、作業が遅くなったり、作業の質自体が低下します。
メンバーのモチベーションを下げてしまうことが簡単に発生してしまうため、リーダーはいかにメンバーのモチベーションを維持するか(あげるのではなく)に注意を払います。

よくリーダーが思うことは、
・メンバーのモチベーションは簡単に下がるけれど、おいしいことを言えれば簡単に上がる
・自分はメンバーのモチベーションを維持できるし、下げないノウハウがある
というものだと勝手に思っています。

私はリーダーになったことは実はないので、ここら辺は本当か分からないのですが、もし自分がなったとしていたら今までであればそうだったろうなと思います。
そして、周りのリーダーを見ていてそう感じます。

一般的に、多くのIT系サイトではリーダーの心構えみたいな特集が良く乗っています。そこにはリーダーがメンバーに対して何を言わなくてはいけないかなどの、ノウハウ集みたいなものがあります。
コーチングのタイプ診断も私には似たものに感じます。
リーダーはそれを読んで、メンバー一人ひとりの性格を分類して、それぞれにかける言葉を変えたりするわけですね。

考えれば当たり前ですが、例え分類しても、分類できても人それぞれ性格は違います。分類した中でも違います。
そもそも、その分類はイメージです。本当の当人の性格を当てはめたものでは全くないのです。が、それでリーダーは満足している傾向が強いです。
そんな誤った内容を適用していくわけですから、メンバーのモチベーションは維持することが精一杯で、上がることはなく、下げるだけです。

ここで、モチベーションには以下の変化があります。
・上がる
・下がる
・維持される(これは変化しそうな状態に対して、その状態のままにする行動をとった場合です)
・変化しない(これは維持に対して、何も効果が無くて変化していないことを指します)

メンバーのモチベーションは、どんなことで上がるか、下がるかなんて、当人にしか分からないのです。
例えば、私のモチベーションの場合、褒められたり叱られたりといったことで上がることも、維持されることもありません。変らないか(これは維持ではなく、単純に無感情なだけですよね)下がることしかないのです。
私の場合、問題が発生したときにリーダーが適切な行動を取っているところを見ると、モチベーションが上がります。
逆に、メールや打ち合わせ等で、必要な情報を適切なタイミングで提供できないリーダーを見ると、モチベーションが大幅に下がります。
簡単に言えば、このことをリーダーが知っていれば、リーダーは少なくとも私のモチベーションを下げなくて済みます。

え?っと思う方もいるのでしょうが、リーダーにとってコミュニケーションが重要だと思うのでしたら、忌憚のない意見をメンバーから吸い上げられることが必要かつ、本質的にコミュニケーションの重要性を認識していることだと私は考えます。
ただ馴れ合いのようにすることもコミュニケーション重要でしょうが、プロジェクトであればビジネスですので、知らない方とも一緒になる場合があります。それは協力会社の方だったりします。
彼らに対して、まず彼らの考え方、モチベーションはどうやったら上げられるのか、下げられるのかを直接聞いてしまっても言いと思います。

「そんなことを聞けるのであれば最初から聞いている」等の言い訳は、リーダーという立場上認められないはずです。
「お金がたくさんもらえれば」というメンバーもいるかもしれませんが、その場合はメンバーの認識も甘いと言えますが、インセンティブ制度を取り入れる会社もありますので、主張は正しいとは思います。が、メンバーも自分がどうしてもらいたいのか、単純な答えだけではなく自分の考えを正しく伝えられるべきだろうと思います。

プロジェクトの進行を考えるならば、それは難しいと言っている場合ではないと思います。
が、なかなか立場上言えないとも思いますし、メンバーから主張することも難しいと思います。

リーダーのコミュニケーション能力がただのおしゃべり能力ではないことが、こういったメンバーのモチベーション管理等に表れると思います。
それとも、「あなたはどのようなことがあるとモチベーションが上がりますか?逆に下がりますか?」とメンバーにモチベーションについて確認できないものなのでしょうか?
今一度、通り一辺倒な行動を考えてみる必要がありそうです。

2008年10月18日

日本のIT企業のオフショアは成功なのか?

先にお伝えしておきますが、私は決してアジア圏の方が嫌いなわけではありません。

ここ数年、日本のほとんどのIT企業はアジア圏に進出し、各国で子会社・関連企業を作り、いわゆるオフショア開発を実施しています。
私の会社も例にもれず、中国に進出しています。私の会社は行動力が遅いため、早い段階で進出した企業よりも数年遅れての本格参入です。そのため、いわゆる前半のうまみも苦味も大きく経験していない企業です。

私は日本企業の現在の考え方に基づくオフショア開発には否定的です。
日本のオフショア開発は、まさに人件費のみの抑制を目的としています。これはもちろん米国であっても主な目的としてオフショア開発した場合には、費用抑制を目的としています。
海外の企業では中国に研究所を開き、多くの研究を中国の方と実施しています。それは多くの戦略に基づいてのことでしょうが、決して人件費抑制のためだけでは中国に研究所を開くことはないといえます。
しかし、日本の費用はまさに人件費のみです。用は日本人にやらせても中国人にやらせてもあまり変らないと一般には信じられている箇所を、人件費が安い中国に一括発注することを目的としています。
日本では労働者が中国の方よりも保護されていると言える為、簡単にその人を首切りできませんが、中国の場合は中国企業が人きりをするため、日本側で仕事が少なくなっても人の流動性を柔軟に出来るという狙いがあります。
そこには、人の教育を云々という事はあまりありません。
日本側が使えるようにするために、ある程度は育てるという行動もありますが、多くの中国企業はある程度日本語ができるなどの人材を確保することも多いです。決して協働ではない点が海外企業と違うところでしょう。

日本のIT企業がオフショアに走る大きな理由は人件費です。つまり、日本人の単価が高い割には日本人のIT技術力がないという結果だと暗に言っています。日本ではプロジェクトマネジメントのみを行います。これは日本がプログラマよりもITについて詳しくはないが、コストに対する危機感がある人間を重要視するのと同じです。
日本企業がアジア圏で活用する人材は実際にはITリテラシは高くないことがあります。つまり、結局教育コストがかかり、現在では人件費抑制という効果はなく、日本人よりも人材流動性の確保が容易というメリットしか語られていません。

日本IT企業のオフショア方針は当初の目的からはずれて失敗しているのです。
もちろん、中国の方にはとても優秀な方も多いです。実際に一緒に仕事した方も優秀な方でした。が、彼らは日本に来て仕事をしていました。
日本企業はもとをとれるまでオフショア開発を行い、ある程度稼げたと感じた段階で撤退する企業もあるでしょう。
おそらく私の会社は数年後には撤退するでしょう。

日本企業がオフショアをうまく活用できない理由にはもう一つあります。日本企業は現在、極度に情報流出を恐れています。
私の会社でもこれ以上の情報を海外に流すと情報流出のリスクを考えて、どこまでなら任せられるかが衝突のポイントになります。
内部的に争いが起きて、結局外に出せない、もしくは出す範囲が絞られ、有効に活用できていません。
結局は費用対効果がないのです。

私は日本企業がオフショアをするのであれば、人件費ではなく教育コストが抑えられる場所に進出すべきだと考えます。多くの人は反対するかもしれませんが、私ならばエストニア、イスラエルなどです。インドも良いと思います。
エストニアはヨーロッパの国々がオフショアとして活用しているようですが、コンピュータスキルの高い人が多いと思います。イスラエルは軍に所属した段階で高度な教育が行われたかと思います。
軍を卒業後に会社を起こす人も多いぐらい技術水準も高いと思います。治安は良くないのかもしれませんが、戦争はないのですがそこは実はあまりアジアの国々と比較してもあまり変らないと思います。

上記はあくまで個人的な意見です。実際には良く知らない人間のたわごととなりますが、会社の社長さんはどうお考えになるか聞いてみたいです。

2008年08月09日

誰がためのシステム開発なのか?

最近は忙しいわけではないのですが、めっきり疲れやすくなってしまい、少し更新の頻度が遅くなってしまっています。
彼女からも少し運動して体力をつけないとと言われていますので、ここら辺でがんばって運動したいなぁと考えています。

つい最近、彼女とディズニーランドに行ってきました。そのときも体力がなくて、最後は体調不良になってしまい、彼女が楽しみにしていたものを見せてあげられず、彼女に申し訳ないことをしてしまいました。ごめんなさい。

今回は、そのディズニーランドに行って感じたことです。

ディズニーランドはまさに夢の国を作っているという事で、従業員は従業員といわず、夢の国をサポートするキャストと言われて存在しています。
彼らはまさに、夢の国に来たお客様達が夢の国に幻滅しないよう、いろいろな趣向を持ってがんばっています。
私はディズニーランドそのものを楽しみつつ、そんなキャストたちの存在に心打たれてしまいました。

彼らは常にごみが落ちていないかをチェックし、ごみがあればすぐに清掃しますし、お客様のサポートを献身的に行います。
体調不良であれば、医務室で休んだり、丁寧に症状を聞いてくれます。
それ以上に、例え夏であっても相当大変なパフォーマンス(とあえて言います)をしています。
それは全て、ディズニーランドに訪れてくださったお客様のためだからだと言えます。それは当然だと思う方も多いでしょう。なぜなら、それがサービス業だからです。
もしかしたら、キャストにも夢があって、自己実現のためにいろいろな練習をしたり、夢を膨らませたりして努力しているのかもしれませんが、それは最終的に、お客様を楽しませる存在になりたいという高みに向っていると結論付けできます。
普段は揚げ足取りばかりを考えてしまう自分であっても、彼らはそれが使命であると考えていると思うぐらい、一生懸命に感じました。
本当は現実を忘れるために行くディズニーランドで、私はふと現実に戻ってしまいました。

果たして自分はどうなんだろうか、と。

夏は比較的涼しい部屋で、ぬくぬくと仕事をこなしています。正直に言ってしまえば、とても簡単な仕事です。
趣味で作っていたソフトウェアの方が、はるかに高スペックを要求し、バグが少なく、実は規模も同じぐらいです。
果たして私は、こんな環境で何のためにシステムを作っては、お客様に提供しているのだろうかと思ってしまいました。

小学校や中学校の頃は、今のような自分がしている仕事に就いて、お客様が喜んでくれて、便利だと言って、そしてすごいねって言われるシステムを作りたくて、そしてそれをお客様に提供していきたいと考えていました。
小学校からずっと大学まで、自分のためにプログラムすると同時に、人のためにもプログラムを作ってきていました。
人から「こういうのは思いつかなかった。便利だね。」って言われるだけで、十分な報酬でした。

今は、、、お恥ずかしい限り、そうではないと思います。
結局は会社の保身のために、必要なバグはこっそり修正し、関係なさそうなバグは無かったことにして、後からばれてしまったり。。。
いつも私は、可能な限りバグはお客様に正直に言って、また認識したバグは常に管理して、必要なタイミングでお客様に説明するべきだと思い、上司にそう言います。が、結局はいつもそんな時間がない等の理由でうやむやになっています。

いつの間にか、何とかバグを無かったことにしたり、気づけば勉強もしなくなったり、お客様に喜んでもらうよりも自分の出世やより良い自分が望む仕事ができるようになることだけを考えている自分がいるように思います。

まだまだ私は下っ端なため、「正論だけどね」で終わってしまうことが多いです。実際にあの時言っておけばよかったと後悔することも多いのですが、コミュニケーションが重要であるとコミュニケーションを履き違えて主張を繰り返す人間が多く、いろいろなことがうやむやになって、忘れ去れていて何も残らない、残していない状況も多いです。


みなさん、自分が使いたいと思わないシステムを、お客様が果たして喜んで使うと思いますか?
私は、お客様は他に選択肢がないという理由だけで、使っているかもしれませんよ。
そして、私は私が仕事で作ったシステムは、新人のときに一度だけ、全て自由にやらせてもらえたB2C向けシステム以外は、仕事で作ったシステムを使いたいとは全く思いません。

私はむしろ、レベルが落ちています。
彼らのような高みへの努力、いつの間にか落としてしまっていたことを認識しました。
同時に、とても悔しかったです。だって、同じ仕事というフィールドで、彼らはまさしくキャストであって、私はまさしく今、一社員でしかないのだから。

2008年07月13日

設計書の長さから考える

ビジネス文書、特にメールでは、忙しい人向けに文章を短めに書くべきだと良く言われます。
しかしながら、文章をうまく要約し、相手に誤解を与えないレベルで短く適切にまとめるのには、非常に技術がいることだと思います。
現段階でそれが本当に出来ていると感じる人は、自分自身も含めて一人もいません。
自分の文章を他の人が見たときに、こうした方が良いと言われて納得することもありますし、逆にその人の文章を読んだときに、こうしたらより良くなるのにと感じることがあります。
自分の文章というものは、自分ではどこまで正しくて、またどこに誤字脱字や分かりにくい表現があるか、すぐには分かりません。
それは当たり前のことです。自分の表現は自分からの主観で書かれている以上、正しいと思い込んでしまう箇所も生れます。
その時、思い込んでいる場合は文章だけでなく、他にもプログラムであったとしても、即座に問題を直すことができないものです。

その上で、人に誤解を与えない文章を短く書くことは、長い文章以上に難しいことが多いです。ここで文章が長いというのは、1文が長いのではなく、ドキュメントやメール全体の長さのことを言っています。
長い文章を書く場合、文章の中に矛盾がある場合もありますが(その場合は、書き手が混乱しているケースがほとんどですが)、基本的によく読めば情報は足りないことは少ないことが多いです。
(何にでも、当てはまらないケースはありますが、傾向としてです)
また、正直なところ、私はよく、文章を読むのにそこまで時間がかかるのでしょうか?と思います。当然、短く、意味も分かる文章を欠けるに越したことはありません。ですが、あまりに短くて理解できなかったり、誤解を生む文章を送られて、これはどういう意味ですかと質問するほうが、トータルの時間は、長い文章をいただくほうがマシであると感じます。

ビジネス文書については、それでも短いほうが美徳という印象は私にもあります。

では、設計書はどうでしょうか?

設計書も短いほうが良いという方がいます。
ですが、私はビジネス文書は短くても、設計書は文章を長くするべきだと考えています。
基本的に短い設計書は、行間を読まなければ作れないことが多いのですが、その行間は人によって様々です。
その様々さをあえて排除するのか、それともあえて書かなくて許容するのかと、文章の長さは関係はありません。
短いことがバグを生んでしまっている、つまりコミュニケーションが無駄に発生し、その上でドキュメント化されず暗黙のうちに記憶にのみ設計が残るために認識ミスが発生する、そのようなケースが多発しています。
それを避ける意味でも、設計書にはあいまいさを可能な限り排除するべきです。未決定な仕様が記述されないのはあいまいではありません。不確定要素ではありますが、そこは正しく未確定である情報を管理するべきです。
しかしながら、あいまいに短く書いた設計書は、個々の開発者の感性に委ねた開発にしかなりません。
その上で、設計者の認識に合わない開発をされた場合、設計者は開発者の行間の読みを責めることが多いです。

私は短い設計書しか書けない設計者は、設計者としての責務を果たしていないと感じます。これは設計者と顧客にも同じ現象が発生するかもしれません。
つまり、私は設計者が責任逃れで書きたがらないように感じられます。
(もちろん、全てが全てではありません。今まで数名、適切な設計書を記述できる方も、3年以上年上の先輩にいました。)

何が良くて何が悪いかは、状況によって違うため、これはとてもナイーブな問題ですが、安易な設計者が多いのもまた事実だと思います。

ただし、一言言っておきますが、これすらも感性の問題になってしまうナイーブなことではありますが、設計書もむやみに長ければよいというものでもありません。
仕様変更が入ったときに、極力ドキュメントの修正範囲に影響が出ないように気をつけて書くべきだと思います。
例えばWordであれば参照を利用するなどし、表現を1箇所に記述し、後は参照して表示するようにするなどの技術的なスキルも設計者は持つべきだと思います。

結局、設計者もいろいろな技術を持たなければならないのです。

設計書を記述する皆さん、どのような技術や工夫を持って自分や人のために設計書を記述していると、あなたはいくつ自信を持っていえますか?

2008年04月26日

ログに対する認識の甘さ

ソフトウェアを開発する方ならば、多くの方はログをプログラムから出力しているかと思います。
ログは例えばリリースした後に客先で動作しないなどの何らかの不具合が発生した際に、原因等を探るとても重要な情報源です。そのため、ログを適切に出力、保存されなければ、そのログはただ要領が大きいだけのゴミにしかなりません。

ただ、ログを出力するということは、
1. 何を出力するべきなのか?
2. いつ、だれが、何に利用するのか?
3. いつ出力するのか?
4. 何を出力してはいけないのか?
等を考えながら出力している方は少ないように思います。

ログを出力するときに、ログに対してもみなさんは設計書を作成していますか?
ばかばかしい、ログなんてメインの業務処理から考えればオプションのような位置づけだと思うかもしれません。
ですが、ログ出力を正しく行わないと、私の周りでは、今までこういった問題が発生してきました。

・実際に不具合が出ても、そもそもどこまで処理が完了したのかも分からない
・通常はエラーが発生するとログ出力するのに、特定のエラーはエラーを握りつぶしてログも出力しない
・DEBUGログ時に、メソッドや関数単位でどこまで処理が完了したのかみたいのに、全て「開始」は出るが「終了」は表示されない
・英語環境に日本語でログを出力し、意味不明
・顧客のパスワード等、直接顧客が管理する情報をマスキングなしでエラー時にログ出力する。そのため、顧客から全てのログ出力の精査を求められた(しかも、修正・リリース後にさらに漏れが発覚し、こっそり再リリース)
・同じログファイルを必要でもないのに2つ出力する
・ログの内容が見た目で美しくないため、見るのに苦労する
・お客様がログを見て、ログメッセージの内容から不信感や不安を感じる(なぜこのメッセージが出ているのか分からないため)
・設計書と出ているエラーコードが違い、問題発覚時に実際には誤りの説明を顧客にしてしまう
・不要なログばかりを出力し、必要な情報が出力されない
・ログのフォーマットが決まっていないため、作成者によって同じエラーが異なる文言で出力されるため、検索しにくい
・ローテーション設定が通常出力される内容との見合いで検討されていないため、ディスクを圧迫したり、必要なログがすぐに消える
・エラーコードは違うが、同じエラーが複数存在し、顧客が混乱した

大きなものでは、こういう事態が今までのプロジェクトで存在したことがあります。
これらは実際には、正しく設計し、かつ、設計書を作成後に内部の開発者や設計者に周知・徹底させれば、ほとんど発生しないはずです。
ログに実装上のバグはあまり含まれませんが、ほとんどのバグは設計バグです。ログ1つで、そのシステムの問題発生時の対応速度が人日レベルで大きく変化します。そして、ログが正しく出力されないことの問題や課題を理解して、開発している人間も少ないのが実情です。

今一度、なぜログを出力するのかから、再度自分自身の答えを見つけてみていただけたらと思います。当然、設計者も開発者にログの内容などを任せたり押し付けたりせず、なぜ出力し、何に利用するのかを定義してみてください。

私の経験上、ログ出力を正しく検討しているシステムは、以外にもログを利用する場面が少なかったりします。ログを正しく出力するシステムは、ログを利用しないことが多いというのも不思議ですよね。しかし、それだけ設計や実装に目が行き届いていて、そもそも根本的にバグがないのです。
ログ出力について、実装時に苦労するべきか、リリース後にバグの原因が分からなくて苦労するか、さて、どちらがよいでしょうか?
私は保守要員ではないと、人事のようにシステムを開発するのは避けてください。その考え方をしている時点で、あなたはバグを容易に埋め込む可能性があります。

ログはそんなに甘いものではありません。


最後に、私が簡単にですが、ログ設計書のテンプレートみたいなものを作成してみました。私は実は設計者ではありませんので、まだまだな面もありますが、だいぶ項目は洗い出せていると思います。
これからも必要な項目を発見し次第、バージョンアップを続けて生きたいと思います。
参考にしたいという方がもしいましたら、是非見てみていただけたらと思います。
ダウンロードは、以下のリンクか、私のメインサイトから可能です。
ダウンロード

2008年04月12日

楽な状態にするために、一時でも手間をかけなさい

すでに確立された手法がある場合、例えば仕事でもこの方法で今までやってきたということがある場合、それに対して保守的にかたくななまでにその方法を維持する人と、別の方法を試みようとする革新的な人の2グループに分かれることが多いと思います。

保守的な考え方の人は、それで今までやってきて、うまくいっているから問題がないというケースがほとんどです。
革新的な考え方の人は、よりもっとメリットのある方法を採用するべきだと考えるケースがほとんどです。
それぞれ、保守的な人からすれば、革新的な行動というのはリスクに感じられます。また、革新的な人から見れば、保守的な行動がリスクに感じられます。
保守的であるのが良いのは、まさに物理的に物を作る技術職の方でしょうし、革新的であるのが良いのは、研究職の方かもしれませんし、どの方がどちらが良いかはケースバイケースでしょう。

「守破離」という言葉もありますけれども、つまり、そのままで良いのか、それとも新しくするべきかということは、実はどちらも言い分は正しいと私は考えています。
タイトルの印象から誤解を与えないようにしておきますが、保守的・革新的どちらも認めたうえでのお話です。


仕事をしていると、あるときふと、これは面倒だ、もっと楽にならないかと感じることが多々あります。
その時、面倒だから"しない"という考え方をする人が多いように思います。それを省略できるのでしたら、そしてする場合と、しない場合で効果に遜色がないのでしたら、しないという選択もありかと思います。

しかしながら、IT系の特にシステム開発で発生するデグレは、この面倒だから"しない"をした結果、発生していることが多いように感じます。つまり、しないがために発生した結果であり、"しない"という選択肢は問題だったといえます。私がよく聞くのは、バグの管理をしていなかったり、その更新を面倒だからという理由でしないケースがほとんどです。そして、面倒でしない理由は、システムが使いにくい、分かりにくいというケースばかりです。
一言で言えば、ただ単に「楽をした」だけであったと言えます。

多くの人は、楽をするための行為をしています。
使っていないということだったので、私はバグ管理ツールを、デグレを発生させたチームに展開したことがありますが、その時言われたことは、「これで楽になるの?」でした。実際は楽にはならないのです。楽にならないツールをなぜ導入することを薦めるのでしょうか?
多くのいわゆる「楽になる」という宣伝文句のシステムは、実際は楽になるという効果はないと思います。

私は、「楽をすること」と、「楽な状態にすること」は違うと思います。

今までのお話は、ずっと自分達がいかに楽をするかに重きを置いて考えているかのお話です。しかし、本来は何か新しいことを入れるなりして、今の作業を楽な状態にすることが重要だと思います。
考えるべきは、今の作業で最も大変なことでしょう。それは、デグレが発生したときの対応なのです。開発する時よりもエネルギーを使います。なぜなら、場合によっては持っているソース全てが本当に正しいのか信用できなくなるケースすらあるからです。
そうならないようにするために、例えばバグ管理ツールを導入し、デグレが発生しない状態にする、これを楽な状態にすることだと私は考えています。

最初のお話に戻りますが、そこで楽をすることにのみ意識が向いている保守的な方は、新しくツールを導入する行為について、導入自体が楽ではなく、嫌がってしまうのです。
革新的な方は、一時の面倒でも、後々楽になる方法を選択しています。
もちろん、どちらもリスクがあります。ですが、この場合は保守的であるよりも、私は革新的であるべきだと思います。

例えば、社員全員が1ヶ月の最後の日にだけ行う1時間の手作業があるとします。すると一人が1年でかける時間は、約12ヶ月*1時間=12時間かかってしまいます。しかし、社員数が3000人いれば、さらに12時間*3000=36000時間です。これは、225人月程度になります。
これを毎年繰り返すことになるわけですが、では、225人月かけてその作業が5分で終わるような簡単なシステムを作ったとします。
そのシステムを10年稼動させたら、1人あたりの1ヶ月の単価を100万円として、システム化する前と後で果たしていくらの差となるでしょうか?
このような考え方をするだけでも、一時の手間をかけるだけで後々がよくなるならば、実施するメリットがあると思いませんか?


このようなお話はシステムの納品先のお客様も同じなのです。しかしIT業界では、お客様にはシステムを導入すると「楽な状態になります」と営業しながらも、システム業界のほとんどの保守的な方は、自分達のシステムやプロセスをより「楽な状態する」ことに対しては反対することが多いのです。
他の業界はシステム業界を利用し、システム化のメリットを活かしていますが、システム業界自体は何年も前からやり方が変っていないのです。未だに開発手法が変らず、逆に昔の方法に戻っていこうとするケースすらあります。

IT系企業はオフショアを積極的に展開しています。私の会社も例に漏れず、オフショアをすすめています。ただし、高気圧から低気圧に空気が流れていくように、いつかオフショア先の人件費も高騰するようになれば、破綻してしまうやり方かもしれません。
日本のIT系企業の現在の進む道は、私はもっと根本的にやり方を考えなければ、今はただの付け焼刃での対応にしか本当にならないと思います。

2008年02月24日

管理していることを周知しなければ、"管理していない"

私はIT業界しか分かりませんが、おそらく、どの業界であっても業務上の何かしらの情報は必ず管理されていると思います。
管理する情報としては、顧客情報であったり、資産情報であったりします。IT業界では他に、ソースコードやドキュメント、設計者、顧客から受領したファイル、質疑応答、果てはプロジェクトメンバーの能力までが管理されることがあります。
また、管理する人はプロジェクトの中でも上位のリーダーや中核メンバーになります。
情報を管理することによるメリットはとても大きいです。ただし、管理することには時間がかかる等のデメリットもあります。

一番のデメリットは、管理されているという状態だけが一人歩きしている状態になりやすいということです。
つまり、管理をしているけれど、それが有効利用されない状態であったり、最新の状態に更新されない状態です。これらのような状態に一度陥ってしまった場合、通常は情報を最新にするのみで良いのですが、
時間が経てば経つほど既存の情報と最新の情報の差異をうまくマッチングしなければならないことが多く、非常に手間がかかります。
最悪な状態は、管理している情報が信用できない状態です。結局は管理している情報を一度破棄し、最新に作り直します。これは今まで作成していたものを無かったことにするので、最も時間効率が悪い結果となります。

このような状態に陥ってしまう原因は、私は今まで管理者が管理を"後追いで更新するスタンス"のため、更新漏れや更新忘れが発生してしまうからのみと認識していました。

しかしながら、そもそも、管理していることが周知されていなければ管理していることになりません。
これは、これまでの話の流れから実は少し論点がずれています。
言いたいことは、「そもそも、管理していることが周知されていなければ最新の情報に更新されません」ではありません。
周知されていなければ、実は管理している情報は信用できない状態に陥るケースがあります。これでは、管理していない状態と何ら変らないのです。

管理を"始める"という行為は、実は結構なエネルギーを必要とします。
よって、管理を"始められる"のはメンバーでも下の者ではなく、上の者がトリガーとなるケースがほとんどです。しかしながら、プロジェクト内での実作業は、下の者が上の者に指示されて行います。ここで、実作業が管理されていない状態では、例え下の者が管理されていないことに気づいたとしても、自らが積極的に管理を開始することはありません。
結局、非管理状態での実作業となります。

この状態は、もともとが管理されていない状態であれば仕方ありません。
なぜなら管理されていないのですから。もし下の者が自ら管理を始めたのであれば、それは下の者には管理者としての意識と自覚と正しい認識があると言えるかもしれません。
新人の場合は、99%は自ら管理することをしませんので、非管理状態であれば非管理状態のままでしょう。


(申し訳ありませんがほとんど伏字に近い状態での説明ですが) 私のこれまでの経験で、例えば、ある端末の状態が管理されていましたが、
その管理しているという情報自体は共有・連携されていませんでした。当然、メールでは通知されていましたが、だれも読んでいませんでした。
あるメンバーがソフトウェアをインストールしましたが、管理されていることを知らず、管理ファイルに何のソフトウェア(と一緒にバージョンも)をインストールしたか
情報を更新しませんでした。そして、インストールしたことを、端末の管理者に通知していませんでした。
後々、そのソフトウェアがすでにインストールされていて、いつの間にか準備完了であると別のメンバーが思い、動作させてみたけれどバージョンの違いで動作しませんでした。
これがシステムテストレベルで起こると悲惨です。

これは管理されていないことが知らなかったことだけが問題ではなく、当然他にも要因はありますが、少なくとも管理されていることを知っていて、かつ、情報を管理していれば防げたと思います。
人は、後追いで情報を更新するほど忙しい人を除けば、管理しているということを知っていると、以外にも管理しているという状態が気になってしまいます。
そのため、管理されていることを知っていれば、たいていの人は情報を更新したり、管理者に質問したりします。まれに、そういうことすらも気にならない人がいます。そのような方には管理は難しいと思います。
他の要因については、また折を見て分析していけたらと思います。

規模の大なり小なりはありますが、このような経験は少なくとも1度や2度のできごとではありません。
最後は、実作業を行う人によって管理情報の精度は左右されますが、信用できない状態まで遷移してしまうことは、間違いや嘘がなければ発生しません。

管理者はまず、何をどういう目的で管理しているのか、よって、どういうときに管理情報を更新しなければならないかを明確にしなくてはいけません。
その上で、だれに影響があるかを特定し、影響範囲に対して管理されていることを明確に通知する必要があります。
近年ではメールがポピュラーではありますが、管理を徹底する際にはメールだけでなく、口頭で先に通知するほうが効果的です。

情報の更新は、結局は実作業後でなければ書けないこともありますので、時間的には後追いになるのはやむを得ません。
よって、実作業を実施し情報を更新する者は、その情報の鮮度を意識することを心がけなければなりません。
なぜなら、あなたが更新する前に、後から作業した人が管理情報を更新した場合、あなたの作業内容は正しく反映できず、かつ、後から作業した人の作業内容が信用できないものになってしまう可能性があるからです。

私自身も反省を踏まえて言わせていただきますが、管理する情報には、鮮度だけでなく、それを管理する人・更新する人によって、信頼度まで大きく変ってしまうという特性があることを認識していきたいものです。

2008年01月20日

結局何のために修正したのかを調べてしまう

どの業界でもおそらく同じだと思いますが、何かしらのプロジェクトがあって、その中でドキュメントを作成することが多いと思います。
そして、そのドキュメントはたいてい多くの人が参照したり、修正するのではないでしょうか。
IT業界では、そのドキュメントとして当てはまるものは設計書であったり、提案書という方もいるかもしれません。人によってはドキュメントではありませんが、プログラムかもしれません。
絵かもしれませんし、楽譜かもしれません。何でも可能性としてありえます。
そのようなドキュメントを自分以外が修正していくことはよくあります。
第一版は私が作成しましたが、その後は別の人にメンテナンスを任せていくこともあります。

私は最近、そのような状況になったとき、つまり、私以外の人が修正を加えたドキュメントがどのような経緯でその修正を実施されたのか分からないことが多くなってきています。
私達は、社内のドキュメントのほとんどをバージョン管理システム上で管理しています。そうすれば、適宜コミットさえすれば過去のドキュメントを参照したり、元に戻したりも出来ます。
コミットが社内の人に対してのリリースに近しい行動になります。
また、ドキュメント自身にも更新履歴ページがあり、記入できる場合もあります。
そして、バージョン管理システムを利用して、ドキュメントの比較を実施します。
そのときのコメントに多いのが、「何を修正したのか」です。

何を修正したのか、これはそのドキュメントを保存する上で重要なものです。要は何を変更したのかの概略が書かれていますので、過去に遡って情報を探す場合に、その手がかりになります。
ただ、何を修正したのかという情報は、人にとってとても静的な情報です。
過去のバージョンのドキュメントを取得して比較さえすれば、どこをどう変更したかは、ある程度分かってしまいます。

ですが、私が知りたい情報は動的な情報です。
つまり、話し合いや思考によって生み出された「修正しようと思い立った理由」、つまり「なぜ修正したのか」。そして、「だれが修正を指示したのか」、つまり「修正のトリガー」は誰なのかです。
こういったドキュメント作成や修正のバックグラウンドの情報は、ドキュメントに記述されません。
どこかログに残さなくては、なぜこのような修正をしたのか分からないという状況が発生します。
むしろ、比較すればよいという意味では静的な情報は必ずしも不要なケースもあります。
メンバー間の作業をよりスムーズに進める上で、この動的な情報をいかに残していくかが重要ですが、その残すという作業自体が実施されていません。

ログを記述する場合、お勧めするのは以下の観点を盛り込むことです。
1. 誰が
2. 何を
3. なぜ
4. 誰の指示で(だれに聞けば良いのか)
5. 備考や関連ドキュメント(併せて修正したもの)について


少しお話がかわります。
『あなたの話はなぜ「通じない」のか』という書籍があります。
この書籍はとてもよく面白いので紹介いたします。
コミュニケーションの現場で、話が通じないということがあります。その状況に一石を投じるためのお手伝いをしてくれるかもしれない書籍です。私も持っています(アフィリエイトさせていただきました)。特に第二章を読んでいただけたらと思います。

私は、コミュニケーション上で相手に伝えられないのに、動的な情報をどうして相手に伝えられるのかと考えます。
動的な情報を残す場合は、口頭よりも簡単そうに見えて、もっとシビアな表現が求められます。
人間の思考や感情はとても複雑なのに対して、その細かい部分を一言で表現可能な言葉は少ないです。言葉は感情を一言で適切に表現するのに、言葉は圧倒的に少ないのです。
感情でもなく思考でもなく、それをさらに論理に落として(もしくは昇華させて)、それを後々の自分以外の人に残す場合、通じない言葉を書いても意味がありません。動的な情報を残す上での多少の参考として、他の方とは違う視点でこの書籍を紹介してみました。
ログの残し方として、分かりやすく表現することも求められます。その行為はとても難しいと思いますので、まずは、長い文章でもしっかりと書いてみて、慣れていかないと身につかないスキルだと思います。


話を戻します。
ドキュメントをして、いつのまにか情報が変っていることが多い上で、大きく内容が変っていた場合、あなたはどうするでしょうか。
まずは、どこに変更が入ったのかと、それ以上に知りたい情報として、なぜ変更が入ったのかを調べるのではないのでしょうか。
もしかしたらドキュメントを読んでみて論理的におかしかったのかを探すのかもしれませんし、修正者に聞くのかもしれませんが。

調べたいというのは、その修正が本当に正しいのかというのもありますし、修正されなくてはいけなかった理由が分からなければ、実は次の行動に進めなくなってしまうのです。
動的な情報をログとして残さないというのは、その修正の理由を知らない人の行動を、大きく停止させてしまうのです。
そして、その人は理由を探すために多大な時間を費やしてしまうかもしれません。
それを何度も何度も繰り返すことを多くの人がしてしまって費やしたトータルの時間と、修正者がコメントを入れる時間、果たしてどちらが少なくなると思いますか?

2008年01月02日

これしかできないを逆手にとる

以前に「見方・考え方を逆転させること」を書いたけれど、それに近いお話をします。

最近、会社ではフリーソフトの利用に対して規制が厳しくなってきています。とはいえ、多くの人はソフトウェアの機能の1割程度しか利用していないことも多いです。ソフトウェアの機能はヘルプやマニュアルを見れば、どんなものがあるのか分かりますが、メニューに出ている機能ですら、平然と知らないというSEもいます。
画面に出ているものを使ったことがないと言ってしまう前に、どんなことができるのか、ある程度実験しておくことをお勧めします。
人によってはそのような前面に出ていることを知らないというと、怒る人もいます。
私はソフトウェアを利用する場合、必ず最初に設定画面を表示させます。そのソフトウェアがどの程度設定できるかで、ソフトウェアの能力をある程度は量る事ができます。また、設定に出ている少しだけ隠し機能に気づいたりすることもあり、大変勉強になります。

今回のお話は、そのようなことではありません。
機能や設定を見ていると、だいたいこのソフトウェアはこういうことができると分かります。その機能を、これしかできないと捉えるかどうかで、ソフトウェアをどこまで活かせるかが変ってくると私は考えています。

たとえ話をします。例えば、ウィンドウズ付属のメモ帳があります。メモ帳の機能をどこまで知っていますか?簡単にまとめますと、

1. テキストエディタであり、装飾も何もない。
2. ファイルサイズが大きいファイルを開くのには向かない。ただし、xp以降では時間はかかっても開くことができる。
3. テキストファイル以外を開くと、文字が化ける。
4. 対応している文字コードは、ShiftJIS。最近では、UnicodeやUTF8にも対応している。
5. 対応している改行コードは、CR+LFというMicrosoft系のOSのもののみである。

ここまで見ると、知っている人にしてみれば、機能は限定的で特定の状況でしか使えないように見えます。

この機能的には小さなソフトウェアも実はおもしろい使い方ができます。
簡単に言えば、文字コードがShiftJISとUnicodeのみであるならば、文字コードがそれであるかどうかをチェックできるということです。
対応している改行コードがCR+LFのみであれば、それ以外は正しく改行できないので、改行コードがCR+LFなのかどうかを判定できます。
これは、Microsoft以外のOSを利用している人には特に利用可能な機能です。

コンピュータに詳しい人ならば、バイナリファイルを見たいという方もいると思います。たとえバイナリエディタがなくても見るだけであればメモ帳でも見ることができます。
他のソフトウェアを使えばと思う方もいますが、さすがに顧客に納入するようなマシンでは、そのようなことができない状況も稀にあります。

これはメモ帳が持っている機能が限定的だからこそできるチェック機能です。これはたとえばでしたが、これしかできないを逆手にとった例です。

パソコンを使う上で、できる・できないを問題にするケースがありますが、できる・できないで物事を考えることはあまり重要なことではありません。
それを使えば何ができるのか、それを想像して、使い方を創造することこそ、重要であり、またパソコン、コンピュータを使う上での醍醐味にもなってくると思います。

使い道のしがらみにとらわれず、何ができるかではなく、どう使いたいかでコンピュータを見てみることも、試してみてはいかがでしょうか?

2007年12月31日

安易なタイプ診断はよろしくない

はじめに。
今回は主にコーチングについて書きますが、私はコーチングについて詳細を知らずに書きます。間違っていたり、認識がおかしいものがあったりするかもしれませんが、コーチング等を否定するつもりはありません。むしろ正しく行われるのであれば、とても良いものかもしれません。
人によっては不快感を覚えるかもしれませんが、ご容赦いただけたらと思います。

少し前からIT業界ではコーチングというものが流行しています。
コーチングとは、そのままコーチするということですが、なかなか奥が深いようです。より分かりやすく自分流に言えば、人をいかに育てるかという技術になります。
メンタル的なコーチングと、技術スキル向上を目指したコーチングがあります。IT業界ではスキル向上のコーチングがメインだと思います。

コーチングを語る上で頻繁に4つのタイプわけが話題に出ます。
要は教える側が、教えられる側を4つのタイプに分けて、それぞれに適した教え方をするというものです。
その4タイプは以下のようになります。

・コントローラ
一言で言えば、何でも制御や支配したい人。管理者タイプ。
・プロモータ
一言で言えば、独創的な人。アイディアマン。
・アナライザ
一言で言えば、完璧な技術的なタイプ。スキル至上主義。
・サポータ
一言で言えば、人のサポートを先にしてしまう人。便利屋さん。

人の特性はだいたいこの4つに大まかに分類できるのでしょうね。
コーチングでは、それぞれのタイプに合わせて、このような場合にどう対応したらよいかが、併せて紹介されています。
アナライザを叱る場合であれば、確かですが、プライドを刺激しないようにその人の作業を認めた上で注意するなどです。

コーチングを受講してきた方は大体、まず後輩や部下をこの4つに無理やり当てはめるところから始めます。
そこでまず、私が必ず言われるのが、「お前はアナライザタイプだね」です。これは皆が口を揃えていい、誰もほかのタイプであることは疑いません。
実際、私はアナライザタイプは結構強く出ているのですが、実際のタイプ診断ではサポータの特性が他よりも高く出ています。
また、実際アナライザタイプに言うべき言動を言われると、少しムッとしてしまいます。
コーチングを受講してきた方は、安易に人のタイプを勝手に判断してしまいます。
その判断が正しければ良いのでしょうが、実際には人は何をどう考えているか分かりません。自分自身でも、「あ、この人自分のことを勘違いしているかも」と思うこともあるでしょう。それぐらい、人からは自分のことをより詳しく知る術はないと分かるはずなのに、多くの方は自分は人を量れると思って、正しくないタイプわけを実施してしまいます。
タイプを事前にアンケートで行ったうえで実施するのであれば良いのでしょうが、それでも例えばアナライザであったとしても、言われたい言葉と言ってほしくない言葉は別のタイプのものかもしれません。

私自身を見ても分かるとおり、人のことを単純に4つのタイプに当てはめても仕方ないと思います。
人の感情って、そんなに簡単ではありません。
当然その4つのタイプわけは、いろいろとコミュニケーション術を向上させる上で知っていて損になることはありません。むしろ、よりコミュニケーションを豊かにすることができるでしょう。
ただ、安易にタイプわけをしてしまうことに危険性があると思います。それよりももっと大切なことがあるように私は思います。
安易にタイプわけをすることで、むしろそういうタイプであると決め付けられる側は、より失望してしまうと思います。
あの人はこういうタイプだと勝手に判断したとしても、たとえ分かりやすい人であっても、最低限「あなたはこういうタイプですね」と言わないほうが良いのではないかと思います。

散々言ってきましたが、実は私は、どのタイプにも共通して言える言葉があるのではないかと思っています。
もちろん、私がそういう言葉があると信じているだけです。
ただ、それは言葉の内容だけでなくて、よりノンバーバルも含めた包括的なコミュニケーションの上で成立することかなと思います。
外国人も含めて、私が試してみたコミュニケーション術について少し紹介します。もちろん、今もいろいろとチャレンジ中のことが多く、わざと良くないことをしたり、まだまだな面も多い人間ですので、あくまで参考でお願いします。まだまだ私も勉強中です。

1. ゆっくり話す
これはとても効果的です。特に技術的なものを早口で言うと、煙に巻いている印象を与えてしまいます。ゆっくり、相手を見ながら言うと良いようです。
2. 紙に書きながら説明する
話が終わった後に、その紙を相手にプレゼントすると、特に喜ばれます。
3. 相手の話を途中で止めない
例えば間違っていることを言っているときに、そうじゃないと話をさえぎらないで、まずは最後まで聞いてみると良いと思います。
相手を論破するときも、途中で話を切って論破すると悪い印象を与えますが、最後まで聞いてあげつつ論破すると、話を聞いてもらえたという風に少しは印象も変わることがあります。
4. 極端な男女差別しない
女性だけに極端に甘いというのは、男性女性両方のモチベーションを大幅に低下させてしまい、成果物の品質に大きな影響を与えます(経験済)。もちろん、女性を早めに帰らせない等と言っているのではありません。
難しいところですが、同じミスをしているのに女性に対しては褒めて、ミスを全て男性に押し付ける上司もいますが、そのようなことはしないようにと言っています。
5. 話の途中で質問があるか聞く
これは特にスキルに自信が無い人に対して有効です。考える猶予を与えます。
6. 人が話しかけてくるとき、同じことを言ってきても気にしない
「前にもそれを言ったよね」って言ってしまう人は、知らず知らずのうちに敬遠されます。忘れてしまうことはよくあります。質問も2回目までは同じことを聞いてきても最低限許しましょう。
7. 間違い等を修正してほしい場合、「それも正しいです」、「そういう方法もありますが」など、何でも良いので先に相手の行動を認める(褒めるとは違います)
これは未だに私も完全に実施できませんが、「違う」と先にいうよりも相手の納得の仕方が違います。

上記の7つは大体、どういう人でも通じるような気がします。
いかがでしょうか?

話も長くなってしまい、不快な話をしてしまい申し訳ありませんでした。参考にもならないお話ですし、私もまだまだ途上です。
彼女に話し方で怒られてしまう始末ですが、それでも少しでも、ほんの少しでも上へという意識さえあれば、人は変わっていけると思っています。たとえ無意識のものであっても。


さて、途中でお話の方向が変化してしまっていますが、修正せずにこのままにしておきます。
結局何が言いたいのかは、ころころ変わっていて分かりにくいですね。
いろいろとごめんなさい。

2007年12月20日

新人や後輩に目指してほしいこと

私もいつの間にか先輩になってしまって早数年がたちました。
後輩も何人か入ってきて、いろいろと将来の目標を語ってくれたりもします。
その中で多い回答が、やはり後輩に頼られる先輩になりたいというのが多いです。
また、実際に後輩に頼られる先輩もいます。私は実は後輩からは頼られることはあまりないのですが。。。

そんな後輩たちに私が送るメッセージは、「先輩に頼られる・質問される後輩になってほしい」です。
後輩からすれば、先輩というのはいろいろとノウハウや裏事情まで何でも知っていて、頼りがいのある存在なのは当然なのです。
その反対に先輩から仕事上の重要な事項に対して、質問をされないというのはどうでしょうか?
先輩から仕事について質問されたり確認してもらえるようになったとき、あなたの発言は先輩に認めてもらえていて、信頼されていると呼べると思います。
ただし、後輩に教えることはもちろん大切ですよ。

私が言いたいことは、良くも悪くも心構えの問題です。
上として後輩を指導することはとても大切ですが、まずは謙虚に学び、質問・信頼される存在になってほしいと思います。

とはいえ、質問されるようになるには大変な苦労があります。
まずは、しっかりと話を聞いているとアピールしてみましょう。アピールの仕方は以外にも簡単で、先輩が話していることをすべてメモしましょう。
決して寝たり、わからない場合はわからないという顔をするのではなく、わからないと言いましょう。

同じミスは、だいたい二度までは許容されます。ここは人によってしまいますが、さすがに同じミスを三度繰り返すと意欲があるのあかな?と思う人が多いようです。ここも何のミスをなぜしてしまったのか、解決策は何かを具体的にメモしておく癖をつけるとよいと思います。

また仕事を頼まれた場合は期限を確認しましょう。その上でできるかどうかを早めに判断して、できそうにない場合はしっかりとできないと言いましょう。もちろん理由と、いつまでならできるかも。

私もまだまだできないことですが、時間をかけてもきっちりと作業をして、無駄をなくしましょう。早くてもミスの多いものより、遅くてもしっかりしているほうが、実は好印象になります。
「彼は手は速いけど、ミスが多い」か「彼は手は遅いけど、ミスが少ないから手戻りがない」のどちらが良いと思うかです。

簡単に3つほど挙げてみましたが、簡単なようで難しいことばかりです。作業はメモを取るなど、心がければ簡単ですが、実は心がけるというのが難しいです。
別の方面でマメな人はいますが、仕事でもマメになってほしいなと後輩に対して思う、今日この頃の私でした。

あくまで私の主観なので、この内容が完璧とは言えませんが、何かの参考になればと(文面も汚いですが)書かせていただきました。
最後まで読んでいただき、ありがとうございました。

2007年10月17日

見方・考え方を逆転させること

大学時代、目から鱗が落ちるお話を先生から聞きました。今日は、そのお話。

研究にはいろいろあるけれど、中には認識率が何%あがったかを見るものもあります(高い方が性能が良い)。
私の研究も認識率が何%あがったかが重要でした。
先生とお話ししていて、先生から「50%から55%に認識率が上がるのと、90%から95%に認識率が上がるのは意味が違う」と言われたことがあります。
(その時、私は両方とも同じ5%の向上と思っていました。)
先生から言われたことは、「エラーで考えると、前者はエラー率が50%から45%になったが、後者は10%から5%になっている。後者はエラー率が半分になっているんだよ」。
その時、目から鱗が落ちました。
人によってはへりくつに思うのかもしれませんが、確かにエラー率で考えると、エラーの減少率は10%から5%の方がエラーを半分にできています。

少し良くない例えですが、分かりやすく考えるならば、1問5点で4択問題の100点満点(20問出題になります)のテストで、50点確実にとれている状況で55点に点数を上げるのと、90点確実にとれている状況で95点に点数を上げるのと、どちらが簡単かです。
50点から55点にあげるのは、要は10問中1問でも正解すればよいのですから、極論、4択問題でしたら全て選択肢の1番を選択すれば、1問は当たる確率があります。
逆に、90点の場合、95点に上げようと考えたら、残り2問の内、1問に正解しないといけないわけです。どれか1つの選択肢に決め打ちしても、確率的には当たらないでしょう。

そう考えれば、50%から55%にあげることより、90%から95%に上げることの大変さが分かります。

今回のように、表面から見たら同じ5%の向上でも、裏面から見たら全然違うということはよくあるのではないかと思います。時には、その裏面から見ることで、問題をうまく解決できることもあるかもしれません。
おや、これは自分から見たらこうだけど、人から見たらどうなのか等、常に裏面から自分を見ることができるようになれたらと思います。
人の視点で言えば、主観の裏面が客観かもしれませんね。

裏面があることを最初から知っていることは、なかなか希なことだと思います。だから気づかなかったという姿勢は、いろいろと考えるチャンスを自ら捨てていることのように感じます。
知るまで待っているのではなく、常に、裏面が実は存在するのではないか、裏面から見たらどうなのかと、見方・考え方を逆転させてみてほしいと思います。

そうすることで、例えば会社の先輩が面倒なことばかり指示するけれど、実は全体的に見たらこういう理由があったとか、そういうことを先輩に聞かなくても分かるようになってくるようになったりします。
まさしく成長のチャンス。
ポジティブになるということではありませんが、常に見方・考え方を表面、裏面、必要に応じて多角的に見ることを心がけてみると良いと思います。

とはいえ、私もできているわけではないので、まだまだ伸びしろはあると信じています。

(読み返してみると、不思議な文章ですね。そのうち、しっかりと主題を明確にして、補足するなり書き直すなりするかもしれません。)