提案書は客観性と主観性の両方を含めよ

今回は、提案書を書く時のポイントについてです。
提案書には複数の提案を記載します。1つだけしか記述しないと、その案が相手に認められなかった場合、それでその話は終了してしまいますし、第一真剣にその内容について検討した のかと、こちらの姿勢そのものを疑われかねません。だから、3つは提案を記載します。多すぎても相手を混乱させるし、少ないとアイディアが無いと評価される。難しいですが、そういうものだと 割り切りましょう。
提案書には、提案内容の他にその案のメリットとデメリット、制約等を記載します。よくメリットだけを表現しデメリットについては触れる事もしない提案書を見掛ける事がありますが、そのいうもの 印象は「フェアでない」です。デメリットについて相手から質問を受け、回答しても、デメリット部分を隠していたのかと相手に疑われる結果にもなりかねません。全てを客観的にオープンにする事 で、こちらの隠し事をしていない誠実さも伝わりますし、誰にでも理解しやすいものになります。
しかし、客観的に表現しさえすれば良いのかというと、そういうものでもありません。相手が情報を与えられても物事を決められない人だと、必ずこう言い返してくるからです。
「それで、結局何を薦めているの?」
客観的に評価した上で、自分が一つ選ぶとしたら○○の理由でこれを選択する、という意志を伝えます。もちろん、「○○の理由」は相手もそれを選ぶものでなければ、相手の心を 揺さぶる事はできません。一つに選ぶことができない場合は、「A案もB案もどちらも有りだと思います。後は、お客様のお好みかと思います」と二択ぐらいに絞って、相手に委ねましょう。 提案全てを相手に委ねると、相手と自分の距離を作る事になりますから、気を付けましょう。
(2011.08.21)

メッセージの送信責任と受信責任

今回はコミュニケーションの、情報の伝達について話をします。
コミュニケーションとは、適切なタイミングで、複数人の間で情報を共有しあう事を言います。情報は、直接会って口頭で伝えたり、電話で伝えたり、メールで伝えたり、書面にして直接 会って説明したりと様々な手段によって伝えます。PMBOKには、伝えたい情報を「メッセージ」と定義しています。ここでは、以降メッセージと表現します。
メッセージは、発信者から受信者へと伝わります。受信者は場合によって複数の場合もあります。(発信者が複数の場合でも、一つのメッセージは一人が発言しますから、発信者は 一人と考えます)
コミュニケーションについて、PMBOKでは次の様に記述しています。

「発信者には、受信者が正しく受け取れるように情報を明確かつ完全なものとする責任、および、それが正しく理解されていることを確認する責任がある。受信者には、情報を完全な 形で受け取ること、正しく理解すること、受け取りを通知すること等を確認に行う責任がある」(PMBOKガイド 第4版 255ページから転記)

つまり、発信者は受信者に分かりやすく、かつ漏れなくダブり無く(MECE)メッセージを伝え、受信者がきちんと理解している事を確認するまでが仕事であり、受信者は受け取った メッセージが何を言っているか分からなければ発信者に確認してでもきちんと理解し、理解した事を発信者に伝えるまでが仕事である、という事を言っています。身の引き締まる思いに なります。特に、怠りがちなのが、受信者が理解したのを発信者に伝える事、受信者が理解したのを発信者が確認する事です。特に、最近では、口頭での説明をしないでメールで 伝えっぱなしが良くある事です。簡単なメッセージでの理解確認は、反って付き合いを悪化させてしまう可能性もありますが、伝わりにくいメッセージの場合は、文書やメールだけでなく、 口頭でも説明をし、相手に理解してもらった事を直接確認することが必要であると意識しましょう。
メッセージは分かりやすいに超した事はありませんが、相手にきちんと伝われば、その役割は果たしていると捉えましょう。逆に、いくら時間を掛けて頑張って作成したメッセージでも、相手 に伝わっていなければ、役割を果たしていないとなります。限りある時間を有効に活用する為にも、コミュニケーションを行う上で、自分に何が不足しているかを、この機会に見つめ直して みて下さい。
(2011.08.14)

まだ昼休みまで10分ある!

一般的に、SEは常に遅くまで働いているという印象が強いと思います。私も以前はそれに該当していました。今日は時間の使い方について話します。

この文章を読んでいる方の中にも、普段遅くまで働いている人がいるでしょう。そんな方は、なぜ遅いのかと、自分を振り返った事はありますか? 仕事が一杯あるからと、 簡単な答えとしないで、時間が掛かっている作業は何であるか、自分の働きを客観的に分析してみて下さい。
文書やメールを作成するのに多くの時間を掛けていないか、長電話が多くないか、休憩ばかりとっていないか、そもそも無駄な作業は発生していないか、過去の自分の 作業の質が問題でその後処理に時間が取られていないか、集中して仕事はしているか、一つ一つの作業を全力で行っているか・・・

以前の私を顧(かえり)みると、その全てに該当していました。今の私が過去の自分を見たら、「何をちんたら仕事をしているんだ、さっさとしろ」「言いたい事がまとまって いないから、文書を何度も書き直すんだ、話が長いんだ、ミスが多いんだ」「インターネットばかり見ているな、無駄な動作が多すぎる」「遅くまで働いている事を自慢にするな、 恥ずかしいと思え」と言いたくなってしまいます。そんな私がなぜ変わったのか。きっかけは2つの事に気付いたからです。

・事務職の女性は定時に帰る為に、必死で作業をしている時がある。
・SEは自分を分析しない。

この2つは、全く関係の無い事ですが、自分の仕事の仕方を変える大きなきっかけになりました。
「事務職の~」は別に事務職に限定している訳でも、女性に限定している訳でもありません、また全ての事務職の女性がそうであると言う訳でもありません。私に気付きを 与えてくれたのが、事務職の女性達であったというだけです。私はお客様先に常駐していた事があり、お客様先の事務職の人達と同じ場所で働いていました。その女性達は 普段の忙しくない時期はちんたらと仕事をしているのですが、忙しい時期になると無駄話もしないで必死に仕事をこなしていました。その人達は、会社から残業を最小限に する様にと言われていた為、そんな仕事っぷりだったのですが、私はそれを見て「集中して仕事をすれば早く帰る事ができるんだ、自分も集中して仕事をすれば早く帰れるのでは?」 と思ったのです。それから徐々に自分を変えていきました。キーボードを打つスピードをもっと上げられないか?、プリンターから出力される印刷物を取りに行くのも早歩きで、と 些細な事でもできるだけ短時間で行う様に努力しました。ある程度改善はできましたが、まだまだ充分ではありませんでした。
次に気付いたのが、「SEは自分を分析しない」という点です。普段は、お客様のところに出向き、改善を提案するSEも、何故か自分の仕事に関しては改善をしようとしません。
改善には二つの側面があると思います。一つはやり方の工夫、もう一つは能力を上げる事です。
やり方に無駄がないか、自分の仕事を見直してみましょう。組織が持つ制約上どうしようもない事もありますが、自分の工夫で仕事を改善できる事もあるはずです。例えば、 文書のテンプレートを作成するとか、段取りをギリギリで行わない為にスケジュールの管理を毎日確認し、期限の少し前に関係者に連絡をするとか、作業品質を高める為に 作業時間をきちんと確保するとかです。少しの手間を掛ける事で、多くの時間を無駄にしない様になります。
能力を上げるとは、完成度の高い成果物をより短時間に作成できるようになるという事です。これには、ロジカルシンキングの能力を上げるしかありません。

今回は色々な面について書きましたが、いずれにしても「少しの時間も無駄にしない様にするべき」という事です。昼休み10分前に仕事が一段落しても、いきなり休憩モード にならないで、他にまだ出来る仕事がないか考えるとか、午後の仕事の手順を再確認するとか、何かできるはずです。皆さんも是非実施してみてください。
(2011.07.30)

ラベル付けを上手になろう

文書を提出した際に、相手が何を言いたいのか分からないとか、部分的に勘違いされたとかといった経験はありませんか?
「その様な人はロジカルシンキングができていない」、一言で表現すると、この様になってしまうのですが、ここでは、その様な人を傷付けるのが目的ではなく、そんな人に 訓練のきっかけになると思う話を今回はします。

偉そうな事を言っていますが、大した事ではありません。言いたい事を分類し、分類したものにラベルを付けるだけです。なぁんだとお思いの方も多いでしょう。そうです。 なぁんだ、という程度のものです。でも、実際には、なかなか思う様に出来ないと思います。「言うは易く行うは難し」です。

経験がないと、まず、ラベルが変な物にしがちです。なので、全体構成が分かりにくいものになってしまいます。また、ラベルに適さない文章を含めがちです。上の文章に 関係していると思って、ラベルを無視して一緒に書いてしまうのです。結果、ラベルがラベルとして機能しません。

具体的に話をしましょう。例えば、トラブルの報告書を提出するという場面です。この場合のラベルは何になりますか?
大体、「状況」「原因」「対処」「今後の対策」になります。簡単過ぎましたかね? でも、実際に作成する場面では、慣れていない人は「状況」「今後の対策」だけで、 「状況」に「状況」「原因」「対処」が混ざって記述していたりって事は良く見掛けます。ラベルは細か過ぎず大まか過ぎずの粒度のものとするべきです。

また、肝心な事を記述していない事も良くあります。提出文書を口頭で説明する際に、肝心な部分を口頭で補って説明する場面です。よく見掛けるでしょ? では、 なぜ一番大事な事を書き忘れるのでしょうか? 自分の中では当たり前だと思っているからです。当たり前と思っている事を表現する事に慣れていないからです。

経験を踏むと、どの様なラベルを付けるべきかが、作成する文書によって決まってくる事を分かっています。また、ラベルの中にはラベルから外れる事は記述しません。 だから、作成する時間も、推敲する時間がかなり少なく済む為、短時間で終わります。書く順番も、大事な事から記述していきます。だから、微細な部分を書き漏らす事は あっても、一番肝心な部分は絶対に書き漏らしません。もっと経験を踏むと、MECEを意識しますので、漏らす事もありません。文書を読む相手を意識して、微細な部分は 意識的に記述しない事もあります。

ロジカルシンキングができる人は、何でもはっきりくっきりしている訳でもありません。「何となくそんな感じ」と捉えている事も少なくないはずです。しかし、ぼんやりとしている 事柄を明確にしなければならない事態になった時は、本気で取り組み、ロジカルシンキングが出来ない人より短時間にまとめ上げる事ができるでしょう。やり方は簡単です。 片っ端から思いつく事を書き記し、それを分類するだけです。

ロジカルシンキングができていない人は、結局、自分が何を言いたいのか簡潔に表現するのが苦手です。片っ端から思いつく事を書き記すのが面倒と感じているはずです。 だから、ラベルを付ける事もいつまで経っても上達しません。

自分が言いたい事を明確にする技術は、一朝一夕に身に付くものではありません。それ故に、自分を変える第一歩は、手を動かす事を億劫に感じない、そんな姿勢だと 私は思います。
(2011.07.24)

アイディアは最初は出す事に専念しろ

以前に書いた「手を動かせ! 文字化しろ!」の続きです。
アイディアを列挙する時に、出す度に評価をしてしまう人がいます。その度に議論が始まり効率的ではありません。アイディア出しの時は評価はしないで アイディアを出す事に専念しましょう。出したアイディアは全て書き留め、文字にします。文字にすれば勝手に消える事はありません。評価は後で充分にしましょう。
なぜアイディア出しに専念するかというと、限られた時間の中で充分に議論ができるからです。
打合せの時間と議論の質には密接な関係があります。打合せ時間は限られています。その時間の中で議論をしようと努力をするのですが、多くの人は疲れてくると、 「これだけ時間を掛けて議論したのだから充分だろう。もう、これで良いよ」と結論を出しがちです。つまり、時間切れまたは疲れ時が完成時という事です。
でも議論とはそういうものではありません。
最初にアイディアを全て列挙しておけば、残った時間をどれぐらいのペースで評価していけばいいか計画も立てられます。アイディア出しの時点できちんとした評価を していなくても、どのアイディアが優れているか直感的に分かるものもあります。全てのアイディアを評価するのに時間が足らない事が予想される場合は、優れていると思うもの から評価する事も可能です。この様に時間を活用すると、前述の「疲れ時が完成時」のやり方とはかなり違った議論になるとご理解頂けると思います。

評価をしている最中に、新たな優れたアイディアが生まれる事は良くありますが、この場合は注意が必要です。一方的な見方だけで評価し「優れている」と判断しがちだから です。結論とする場合は必ず、多角的に評価しましょう。最終的に結論付けたアイディアの優れた部分と弱い部分を理解しておきましょう。
(2011.07.10)

失敗から学べ

SEに限らない事ですが、仕事には失敗が付きものです。失敗する事はできるだけ避けたいものですが、失敗を恐れてはいけません。新しい事にチャレンジできなく なってしまいますから。失敗から原因に気付き、次回はそれを避ければ良いのです。
失敗しても何も学ばなければ、発展はありません。反省は落ち込む為に行うのではなく、自分を強くする為に行うのです。
同じ過ちを繰り返してしまう場合は、反省すべき点がずれているかもしれません。継続が出来ないという自分の性格が起因している場合も少なくありません。 では、どうすれば良いか? 永遠のテーマとしても良いと思いますが、自分だけで解決しようとしないで、上司やきちんとできる部下にチェックを依頼してしまうというのも手です。 色んな意見が出てきます。そんな時は、あまり重く考えず、素直な気持ちでその意見に半分でもいいので、拒絶しないで触れてみましょう。自分を変えるきっかけになると 思います。
(2011.07.30訂正) (2011.07.03)

期限を守らせる

SEはお客様(または社内の別部署)と長い付き合いをし続けます。お客様には様々なタイプがいます。今回は、約束を守らないお客様との付き合い方について書き ます。
約束を守らないとは、お客様のやるべき課題について期限を守らないであったり、打合せ時間にルーズだったりする事を指しています。何度も約束を守られない事が 続くと、期限を守らない事がどういう事態を引き起こすか、その影響度合いに関係なく、腹が立ってくるものです。

一番やってはいけないのは、相手の行為に腹を立てて相手と同じ行動をしてしまう事です。この手の相手は、自分の事は棚に上げて他人に厳しいタイプが多い からです。苦情を言われて、余計に腹を立てることになります。そもそも、自分の質を下げてまで行う事なんて全く意味を持ちませんし、後で振り返ってみた時に後悔 する事になります。
再スケジュールや費用追加の要求をする事も、容易に持ち出すべきではありません。こちらが悪者になるのがオチです。最後の手段として取っておきましょう。
抗議もあまりお勧めできません。相手はなんだかんだと理由を付けて課題をやらなくなったり、お互いのコミュニケーションを悪くするだけです。

私のお勧めは、約束を守らないことの影響が然程大きくない場合は許してあげる、影響が大きい場合はそれによって引き起こる事態を説明する事です。説明の 際には、困った感情は出しても良いですが、怒った感情を出さない事です。相手も冷静に聴いてくれるでしょう。

もっとも、期限厳守の課題は事前に影響を説明しておき、約束を守らない事態を起こさない事です。なかなか思う様に行かない場合でも、腐らず頑張りましょう。
(2011.06.26)

まずはスケジュール感の認識合わせ

新たな要件が出た時の話です。まずは、大まかで良いのでお互いのスケジュール感を話し合い、認識の統一を図ります。
大事なのは、分かりきった事でも口にして、後になってから「~だと思った」という状態を作り出さない事です。

当たり前すぎて詰まらないとお思いですか? では、相手が大まかでもスケジュールを何も考えていなかった時、あなたはどうしますか? スケジュールがMUST要件で 無いと捉え、聞かないなんて事もあるのではないでしょうか。また、絶対にできない期間の要件を相手から伝えられる時も同様です。
それでは、「お互いのスケジュール感の認識統一」は図れません。自分の考えているスケジュールを大まかに相手に説明しましょう。

もう一つの大事なポイントは、こちらが考えているスケジュールが妥当なものである事。プロとして抜け漏れがないものでなければなりません。
 ・調査のタスクが必要か
 ・仕様打合せの回数、相手と自分の打合せ可能な頻度から仕様打合せの期間を求める
 ・内部設計(詳細設計)以降の開発期間の決定時期
無理をしたスケジュールを作り上げる必要はありません。無理をした物は、結局無理となるのですから。

スケジュール感の認識合わせが大事なのは、プロジェクトの完了時期が決まるからです。ぼんやりとでもエンドの時期が決まっていると、人はそれに向けて頑張ります。 頑張らざるを得なくなります。これが良いのです。最後までお互いが「まじめ」に取り組む様になります。エンドが決まっていない、または実現できないエンドでは、人は なる様にしかならないと考え、頑張る努力をしなくなります。そんな状態は、健全でないですよね。

お互いが気持ちよく仕事をする為の第一歩が、妥当なスケジュール作成なのです。
(2011.06.19)

ご用聞きにならない

開発の依頼元(お客様)から要求された通りに開発したのに、依頼元が望む様な運用ができず、文句を言われた経験は少なからず誰でもあるでしょう。要求内容 をきちんと稼働させる為に、開発後に多額の費用が発生したり、開発した機能を使用しないでお蔵入りさせた事もあったのではないでしょうか。この時に皆さんはどう 思いましたか。
「何だよ、こっちは言われた通りに開発したのに... 自分が変な依頼をしたんだろ?」なんて思いましたか? 私も以前はそれに似た気持ちになった事があります。 でも、暫くしてから次の事に気付き、考えが少し変わりました。

依頼元は私たちに、「要求内容が問題なく機能するか判断してもらい、問題ないのであれば開発をできるだけ安価にしたい」と期待している。

特に重要なのが、「要求内容が問題なく機能するか判断してもらい」の部分です。依頼元にしてみれば当たり前の事なので口にもしません。だからこそ、この事を 私たちは意識しなければならないのです。私たちは、依頼元が要求している事を実現する為の最善の方法を考えます。その上で生じる問題点は、依頼元に 通知しなければなりません。問題点を解消する代替案も同時に提示します。そして、依頼元に最終判断をしてもらうのです。

依頼元は、きちんとした情報を私たちから受け取れば、それを理解し判断できます。そこから先は依頼元の責任です。依頼元が私たちを責める事もありません。 それ故に、私たちの提供する情報は網羅したものでなければなりません。私たちはプロなのですから。

冒頭の問題は、私たちがきちんした情報を提供しなかった事が原因なのです。私たちはご用聞きであってはならないのです。
(2011.06.12)

自分だけの仕事は後回し

他の人への指示、連絡が遅い人がいます。自分の作業を優先して、指示、連絡を後回しにする人です。他の人に指示、連絡を 優先すれば、自分と指示、連絡を受けた人が並列で作業が進行します。だから、他の人に指示、連絡を先に行えば、プロジェクト 全体の効率が上がるのは明らかです。恐らく、自分の作業を優先している人も頭では分かっているでしょう。では、なぜ分かって いても、自分の作業を優先しているのでしょう。

それは、自分の作業を先に終わらせれば、自分がすっきりするから。他の人の事は二の次と考えているからです。

どうですか? 改めて言葉にすると、自分勝手な考えである事が分かりますよね。気を付けましょう。
勿論、何でもかんでも、自分の仕事を後回しするのは良くありません。仕事には優先度があるからです。特急の仕事があるのに、 他の人への指示、連絡を行うのは間違っています。多少の優先度の違いなら、自分の仕事を後回しにする、といった感じに留め ましょう。機械的に判断しては危険です。また、自分勝手に優先度を決める事も危険です。第三者から見て適切と思える優先度 でなければなりません。

もうひとつ、他の人への指示、連絡を遅らせる理由があります。それは、指示、連絡する相手が苦手な場合です。苦手な人との 会話を避けがちなのは、誰にでもあります。そんな時は、こんな風に考えたらどうでしょう。

苦手な人への指示、連絡を遅らせれば、遅らせるだけ、そのあいだはずっと苦手な人の事を頭の隅で気にし続ける事になります。 だから、さっさと指示、連絡をしてしまって、頭からその人の事を消し去りましょう。会話をした際に多少嫌なことがあっても、ずっと 「指示、連絡をしなきゃいけないけど、するのが嫌だなぁ」と思い続けているより、すっきりしますよ。
また、自分が不必要に情報の伝達を遅らせた事で、より関係が悪化する事も避けられます。もしかしたら、そういった行動が両者 の関係を良くしていくかもしれません。

要は、自分のちょっとした考え方と行動なのです。
(2011.02.19)

理解している範囲としていない範囲の境界線を意識する

曖昧な話ばかりするSEが、時々います。こういうSEの共通点は、自分が理解している範囲を理解していない事です。

人はある内容について、「知らない」「知っている」「理解している」の3つの状態のどれかをとります。「知らない」は説明が不要です よね。では、「知っている」と「理解している」の違いは? 自分の言葉で、その内容をきちんと説明できる事が「理解している」です。 概要しか語る事ができない場合は、「知っている」状態です。
言い換えれば、「知らない」「理解していない」「理解している」とも表現できます。

上記の曖昧な話ばかりするSEは、この「知っている」状態を「理解している」と勘違いしている事が多いのです。だから、理解して いない事まで話し始め、途中から話が混沌としてきて、ぼや~っとした話で終わってしまうのです。
話しをする内容について、良く分かっているか? 知っているだけの状態か? 知りもしない内容か? これらを意識して話す事で 聴き手は、安心して話を続けることができます。また、お互いの時間の無駄にもなりません。

よく、実力以上に自分を周りに見せる人がいます。2、3の質問ですぐに実力がばれるのですから、止めておきましょう。却って 自分を小さく見せているだけですから。しかし、この様な人も、多くは、無意識で自分を大きく見せているのです。そして、その多くが 今回のトピックである、「知らない」「知っている」「理解している」の状態を意識していない事から起きているのです。

さぁ、皆さんはどうですか? 自分を見つめ直してみて下さい。
(2011.02.12)

衝突しても逃げない

SEは利用者と深く、長く関わります。だから、利用者と衝突する事も少なくありません。今回はその時の話です。

衝突の原因は様々でしょう。利用者が勝手な事を言っている場合もあれば、自分の明らかなミスもあります。自分の考慮が足り なかった事もあるでしょう。自分も人間なら、相手も人間。些細な事でぶつかる事もあります。でも、どんな理由で衝突しても、 SEと利用者の関係は終わりません。今後もずっと続いていくのです。まずは、その事を認識しましょう。

衝突を当事者間だけの問題にしてはいけません。上司に報告する事で、第三者の視点で、どちらに問題があったのかを判断 してもらう事もできます。ただ、上司も人間。人によっては偏った見方をしてしまう場合もあるでしょう。そんな時は別の上司や先輩 の意見を聴くようにしてみましょう。
一番良くないのは、相手を避ける事です。溝を深めるだけです。自分に問題があったのであれば、その問題部分を直していくしか ありません。また、相手に問題があった場合は、許してあげましょう。相手に、人間的に問題がある場合は、相手の上司や自分の 上司に相談しながら、会社間(社内の場合は部署間)の問題にして解決していく様にしましょう。また、相手がトップの立場であれば、 相手に合わせてあげる事も考えてみましょう。自分の気持ちを一旦取り払い、大きな視点で相手の意見を見つめ、多少の事で あれば、相手の意見に合わせてあげましょう。

相手が関係をリセットしたがる人でなければ、時間を掛ければ必ず解決します。前よりも強い関係になる事も少なくありません。 だから、逃げる気持ちにならない、これが大事なのです。
(2011.04.23訂正)
(2011.01.01)

定形フォーマットは埋める為のものではない

会社には、様々な書類の定形フォーマットが存在しているでしょう。これらを利用する場合の話です。

あなたは定形フォーマットを埋める為の枠と思っていませんか? もちろん、定形フォーマットにはその様な目的もありますが、 埋める為の枠だけと捉えてしまうと、書き手の思考を狭めてしまいます。あくまで、書き漏れがないようにする為に存在している と考えるようにしましょう。小さな違いのように感じるかもしれませんが、大きな違いです。定形フォーマットを操っているつもりが逆に 操られているのではないですか?
自分が記述したいものが何であるかを意識した上で、定形フォーマットを利用します。この様に、定形フォーマットと向き合う事で まず自分が表現したいものを押さえ、その内容が定形フォーマット上どこに存在していて、かつ、自分が書きたいものに漏れが なかったかを確認する事ができます。
記述したい内容が定形フォーマットに適さない場合は、どの様に表現したら、分かりやすいかをよく考えて、定形フォーマットを 拡張するか、フリーのフォーマットで添付するのかを決めます。間違っても、定形フォーマットを無理に利用するのは止めましょう。 無理に利用しても、何だか良くわからない書類を作成するだけになってしまいますから。
書類を書き始める場合は、定形フォーマットの事は取り敢えず考えないで、何を記述しなければならないかをメモしておき、 その上で定形フォーマットを利用すると、自分の記述したかった事を漏らさない様になりますし、定形フォーマットを使いこなして いる事になります。

上記の話は、空の枠の定形フォーマットにだけ言える事でなく、情報が埋まっているテンプレートにも同様の事が言えます。 会社での過去の経験を元に作成されたテンプレートは、かなりの情報を含んでいます。中には、自分の作成したいものと ぴったりとは一致しないが全く離れていないといった類のものも多いでしょう。二つ三つその様なものを見ると、殆どを残そう という意識に変わり、中には、全てを確認することすらしなくなる人もいるでしょう。
テンプレートを使用する場合は、自分に適している順に並び替えると、いい結果になる事が多いです。並び替えた上で、 下の順位にしたものが適しているか判断し、削除するかどうかを決めます。並び替える事で、テンプレートに記載されている 内容を自分のものになります。
(2010.12.19訂正)
(2010.12.12)

話が噛み合わない時

相手と話をしていて、話が噛み合わない時があります。理由は、
  ・お互いの目標が違う
  ・お互いの前提が違う
のどちらかの場合が多いでしょう。

目標は、何を目指しているのか確認すれば良いので、あまり問題が発生しない様に感じますが、実際には、目標を 実現する為の手段の話に終始し、利用者が思い描いている目標とは別の像を、SEが勝手に思い込んでしまうケース は少なくありません。
また、利用者の目標がブレる時もこれに該当します。
「何を実現させたいのですか?」とストレートに聴いてみた方が、ブレていることを当の本人も認識する事ができ、話を整理 する方向に持っていくことが可能になり、物事をスムーズに進められるでしょう。

前提とは、お互いに言葉にしていない当たり前の事です。その当たり前の事が、双方で食い違うと、当然話が まとまりません。前提が違うのは厄介です。なぜなら、言わなくても当たり前とそれぞれが思っている為、言葉で表現する 事が慣れていないとできないからです。
では、どうしたら良いでしょうか? 答えは簡単です。
相手が話しているのは、いつ、どこで、誰が、使用するものは何で、どうする話なのかを確認するだけです
冷静になれば、これらを確認するのは当たり前であると思うのですが、人はどうしてもまどろこしい部分を省略しがちです。 その際に、重要なキーワードまで省略してしまい、相手に伝わらない状況を生んでしまうのです。
明らかな物も一々言葉にするのは冗長的で避けなければなりません。一杯の失敗を経て、慣れていきましょう。

相手は、「どういう風にしたい」の話ばかりをしがちです。相手がいきなり、手段の話を始めた時は、こちらは冷静に なってまず5Wを確認する様にしましょう。

恐いのは、要求を定義する粒度が粗いと、目標も前提も双方で一致していないのに、話が成立してしまう事です。
外部設計(基本設計)も粒度が粗いと最悪で、この場合はユーザー受入テストの際に話のズレが発覚し、多くの改修 工数(コスト、時間)を必要とする事になるでしょう。
業務フローをきちんと記述すれば、そうした問題は発生する事は殆どありません。
(2010.12.07訂正)
(2010.10.30)

手を動かせ! 文字化しろ!

複雑なものを考える場合の話です。
人は頭だけで考えられるパターンは、せいぜい4つ~6つぐらいです。それ以上は、抜けが発生したり、または同じこと ばかりを繰り返し考えてしまいます。
そんな時は、うじうじ考えてばかりいないで、手を動かし、思いついた事を片っ端から文字にしましょう。文字にすることで その情報を基に、次の4つ~6つを考える事ができます。
書けるだけ書きましょう。膨大だと思っていたものも、10個にも満たない程度であった事に気付かされるのも少なくありま せん。

パターンの漏れを無くすには、マトリックスを利用する事も重要です。

書き出したら、次に、それを整理しましょう。グループ化したり、順番を考えたり。最初から正解は分からないものです。 失敗する事を恐れず、何度もトライする事を覚悟して、整理をしてみましょう。30分~1時間もあれば、あぁでもない、 こうでもないとやっているうちに正解なのか正解に近いものが見えてくるはずです。
この整理する作業の時に、ロジカル思考のスキルがあるとより早く正しく整理することができます。

情報が整理されると、かなり気分がすっきりします。今までうじうじ考えていたあの時間は何だったのだろうという気持ちに なると同時に、かなりの達成感に包まれます。
(2010.10.24訂正)
(2010.08.15)

目標と夢は大違い

大きな目標を持つ事は良いことだと思います。
しかし、その大きな目標があまりにもぼんやりとしたものだとしたら、それは目標になっていない事に気付くべきです。
目標と夢。これらは似ているようで、全く別ものです。

目標とは、夢を現実化する為に、何を行うべきか、その過程が把握できている状態のことです。過程が単なる手順だけ でなく、日程計画まで作成できていれば、よりすばらしいですね。
言い換えれば、実現化プロセスが見えていない様であれば、目標と思っていても、それは夢なのです。
実現させる為に何を行えばよいのか、課題が何であるのかを詳細に洗い出し、一つ一つを消化していくのです。最初から 全てが見えている必要はありません。途中で課題が増えるのは、システム開発の手順と同様で、良くあることです。 ローリング・ウェーブ計画法で良いので、アウトラインから目標までのプロセスを「見える化」させましょう。
(2009.03.08)

日程計画はプロジェクト・メンバ全員で共有を

プロジェクト・メンバに、担当させる仕事内容とスケジュールのみを知らせ、全体の状況を知らせないプロジェクト・リーダー がよくいます。
でも、これは間違いです。

全体の状況は、プロジェクト・メンバ全員が知っている必要があります。計画通りに進捗していない場合は、尚更です。
週に一回、30分だけでも、プロジェクト・メンバ全員で集まり、進捗の状況、遅れの原因、遅れの対応策、遅れている 担当者の別作業の再割り当て等を行い、全体の調整を行います。
遅れの解消のアイディアがメンバから出る事も少なくありません。また、プロジェクト・メンバの一体感が強まり、チーム 連携も良くなります。
(2009.03.05)

技術的な学習は継続的に

仕事のやり方・姿勢は、ある「気付き」によって格段に成長します。一瞬で変化するといっても過言ではありません。
ところが、コンピュータ技術や、ロジカル思考やコミュニケーション、交渉術といったビジネス・スキルは、一瞬では成長しません。
私は、これを「人は船」と例えます。発進するにも、方向を変更するにも時間が掛かるのが船と似ているからです。
日々の努力が大事ということです。
(2008.09.21)

入力書を元に画面の構成を考える

当り前のことでも、これができていないSEをよく目にします。
システムを新たに作成する場合に発生しがちです。元の画面構成を独自で変更し、インプットである入力書の構成と 全く違う画面を作成してしまうのです。入力書と入力画面が一致していないと、非常に入力しづらいのです。SE自身が 実際に行ってみる事を勧めます。
入力書と入力画面はワンセット。入力画面が大きく変わるのであれば、それに合わせて入力書のレイアウトを変更しま しょう。入力書のレイアウト作成もSEの大事な仕事の一つです。
(2008.09.14)

SEはコンピュータと人とをつなげる仕事

SEには、コンピュータの知識を多く求められます。コンピュータ技術者だからです。
だからといって、コンピュータの知識だけで良いかと言えば違います。一般的なビジネス・ルールを身に付けるのは当然です が、もっと大事なのは、システムを利用するユーザーの気持ちを理解できることです。
利用者やそのシステム担当者から、システム化の課題の解決提案を要求されることは多々あります。そんな時、人を 見ていないSEから出てくるのは、現実的でない解決方法ばかりです。

「あんた、本当にそんなので良くなると思っているのか? 実際に運用してみろ!」

コンピュータばかり見ていて人を見ていないと、利用者からそんな言葉で叱られても、相手が何を怒っているのか良く分か らず、不満だけが残り、解決策は一向に出てこないでしょう。

大事なのは、システム化したプログラムを利用するのは「人」であるということ。自分が面倒だと思うものは、他の人も面倒 だと感じることが殆どです。だからこそ、自分なら利用しないと思えるようなものは提案してはいけないし、他人が面倒と 思えるものと自分が面倒と思えるものの感覚をできるだけ一致させる努力をするべきなのです。
(2008.07.16)

SEはコンピュータ・システム・エンジニアではない

SEは、システム・エンジニアの略です。つまり、システムに精通した技術者ということです。
では、「システム」とは何でしょうか?
システムとは、「あるまとまりがうまく動く仕組み」のことです。生態系システムや社会経済システム、ネットワークビジネスの システム、ビリヤードのバンクシステムなど、誰しも一つは聞いたことがあるでしょう。

SEが担当するのは、売上管理、在庫管理、勤怠管理、経費精算などの特定の業務をシステム化することです。つまり、 特定の業務がうまく機能するように、必要なプログラムを考えたり、業務の流れを考えだし、構築するのです。しかし、 コンピュータを使用する部分だけに留まらず、システム化する業務全体がうまく機能できることを設計することが大事なの です。
コンピュータを利用することで問題の多くを解決することが多いですが、必ずしもコンピュータが常に問題を解消できるとは 限りません。手作業も、業務を処理する重要な手段です。
残念な事に、こういった考えを持っているSEは結構少ないのです。
コンピュータ技術者だからという理由で、コンピュータ処理ばかりに目を向けていてはダメです。

手書きの方が処理しやすい業務もコンピュータを利用したりする、コンピュータ至上主義は良くありません。また、手作業 を軽視し、手作業の処理手順や書類の移動を分析すらしないでシステムを構築し、総合テスト時に実運用ができない ことが発覚するなんてのは、恥ずかしい限りです。
だから、手作業や書類の移動が記述された「業務フロー」を作成するのが大事なのです。手作業や書類の移動を軽視 しても、今まできちんとしたシステムを構築できていたのは、対象の業務規模が小さいか、たまたまラッキーであったかの どちらかでしょう。次のシステム開発ではどうなるかは分かりません。
(2008.07.16)