2014年01月05日

SZJ015 人月について考える

ソフトウェア業界では、作業量を表す単位として「人月」がよく用いられます。
今さら説明するまでもないとは思いますが、1人月とは1人が1ヵ月(20日)に行える作業量を表し、2人月の作業ならば1人で2ヵ月、もしくは、2人で1ヵ月という解釈になります。

作業内容に関わらず、だれでもその作業量を把握できるという点ではこの人月という単位は大変便利だとは思いますが、
ただ、人月の求め方そのものに問題があることはみなさん気付いるでしょうか。
普段、工数を見積もるときにこのぐらいの作業なら1人月かな、これはちょっと難しいから2人月にしようかなとか、自分の過去の経験に基づいて感覚的に決めていると思いますが、こんなアバウトな方法で本当に良いのでしょうか?

一般的に工数を求める時は、「難易度」「数量」「生産効率」「生産能力」等の要素を参考にすると思います。

 <工数を求める時に必要な要素>
 ・難易度 … 難しい作業ほど工数が増える。
 ・数量  … 作業を行う数が多いほど工数は増える。
 ・生産効率 … フレームワークや開発ツールなどにより効率が上がれ工数は減る。
 ・生産能力 … 会社の技術力や、担当者のスキルが高ければ工数は減る。

難易度や、数量という要素は比較的数値化しやすいですが、一番ネックとなるのは「生産効率」と「生産能力」です。
今の自分の環境における「生産効率」と「生産能力」をしかりと見極めないと見積もりで大失敗してしまうことになります。
「生産効率」と「生産能力」を数値化する手法は、私も現在勉強中ですが、直近のプロジェクトから実績値を求めて、次はこれぐらいでやれるだろうという理論値を元に工数を求めていくのが一番いいやり方ではないかと私は考えます。

ただし、私が頭まを悩ませている事が一つあります。それは協力会社の存在です。
これからは、当社も社内のメンバーだけではなく、社外のから積極的人を雇い入れて効率的に作業をこなして行かなければいけない状況になってきています。
社内のメンバーであれば個々の能力を把握するのにそれほど労力を必要とはしませんが、社外の人の能力を判断するのはそうたやすい事ではありません。
学校の成績が良くても仕事はできないなんて事はよくある話で、実際に一緒に仕事をやってみないと本当の能力は判断できません。
その不確定要素をどう工数に盛り込んでいくかが今後の課題になると思います。

実際私も過去のプロジェクトでは、たくさんの協力会社の人達と仕事をして、個々の能力差に振り回されて大変な思いをした1人ですので、この件については今後しっかり考えていきたいと思っております。

人月の話からだいぶそれてしまった気もしますが、「生産効率」と「生産能力」について、私がもっと勉強したらまた3分メモで御託を並べたいと思います。
posted by j.shiozaki at 16:26| Comment(0) | TrackBack(0) | 3分メモ

SZJ014 意識の共有について考える

10人以下の小規模な開発でも、4人以上集まるようになると、なかなか意思の疎通が難しくなってくるものです。
私は、その原因の一つに、各個人の考えを共有しない事にあると思います。

以前担当していたプロジェクトでは、私の考えの甘さから複数の人間で同じ作業を行った際に、その成果物の品質のバラツキに悩まされ続けてきました。
ある人は、高度なスキルを有しており、想定される例外をうまく処理して設計してプログラムを作成していたのに対して、別の人は、正常系しかまともに動かないような物を作っていたり。
はたまたテスト工程では、インプット、アウトプットのデータの中身まで正確にチェックしてくれる人もいれば、ただひたすらテストを実施するだけで、仕様が分からないと言って結果をまったく確認してくれない人とか...
自分1人でやっている分には容易な事でも、複数の人が関わるようになると途端に難しくなります。

このような状況でも、高いレベルの製品を均等な品質で大量生産するには、各人の考え方を尊重しつつ、チーム全体での「意識の共有」が必要です。
そこで、私なりに「意識の共有」についていろいろ考えてみたところ、「見える化」「仕分け」「積極性」の3点が重要なのではないかという結論に行きつきました。


●見える化

各個人が考えている作業内容や、問題点を全て書き出してチーム全体で共有する。

●仕分け

見える化で表面化した課題を、仕様や、作業状況に合わせて優先順位を付けて対応する。

・顧客に確認が必要なものは、速やかに確認して仕様をフィックスさせる。
・重要度が低いものは後に回し、影響範囲広かったり、解決手段の見つかっていないような、重要度の高いものから優先して対応する。
ただし、簡単な課題を先に対応して、後で難しい課題にじっくり対応するというやり方もあるので、必ずしも重要度と優先順位は一致するものではない。
・担当者の思いこみで必要のない作業を行っている場合は、ただちに中止させ無駄を省く。

●積極性

問題がありそうでも、自分の担当外だから黙っているといった、了見の狭い考えを捨てて、チーム全体で取り組むといった積極性を持たせる。
ただ、口で言うほど容易いことではないので、「積極性」に関しては、おいおい考えていきます。


複数の人で一気に大量生産するのですから、ひとつのミスがとてつもない規模になって跳ね返ってきます。
作業に携わる人は、その立場や役割に関係なく、常に全体を意識して、問題が表面化して大事になる前に対策するといった事が、チームで作業する上で絶対不可欠ではないかと私は考えます。
posted by j.shiozaki at 16:24| Comment(0) | TrackBack(0) | 3分メモ

2013年11月24日

SZJ013 プロセスイノベーション

成功した時よりも、失敗した時の方が多くを学べる事は周知の事実だとは思いますが、できれば失敗したくないというのも人間の本心ではあります。
それゆえ、ある時試した方法が成功すると、失敗を恐れてずっとその方法をやり続けてしまいます。
でも失敗しないやり方が一番いい方法ですか?と問われるとどうですか?
あなたはその問いに対して自身をもって「YES」と答えられますか?

過去に成功した方法は、無数にある選択肢の1つにすぎません、他の方法を試しもせずに答えは出せないはずです。
確かに実績を重ねるたびにリスクは減り、ベストな方法に近づくかもしれませんが、もっと良い方法というものは必ずあるものです。
時にはリスクをとってチャレンジする勇気も必要だと思います。

しかし... ここからが本題ですが、

趣味でやっているのであればいざ知らず、仕事で果敢にチャレンジして玉砕しては元も子もないです。
飯の食い上げです。
新しい事に挑戦しつつも、いかにリスクを減らすか、私はこれからの時代を生き残っていく上で必ずぶつかる壁だと思っています。
まだこの壁を一気ぶち破るほどのインパクトを持った解決方法は発見できていませんが、とりあえず覗き穴ぐらいは開けられそうです。
そのために以下の3点を提案します。

@過去に実績のあるやり方をベースにしつつ、いくつかの工程で新しい方法を試す。
A新しい方法を試しつつ、実績のあるやり方で保険をかけておく。
B社内では試した事はないが、社外で実績を上げている方法を取り入れる。

もし、これらの方法を試して失敗したとしても、実績のあるやり方でリカバリできるので、致命的なダメージとなる可能性は低いです。
失敗したからといって、その方法が悪いわけではなく、やり方が悪いといった事も考えられるので、失敗のダメージが極小ならば、他のプロジェクトでも試してみてから結論を出すといった事も可能かと思います。
そうやって、少しずつ今までのやり方を「改善」していって、最終的には全プロセスにおいて過去を超える生産性を達成するのが目標です。

そして、それが私の目標とする「プロセスイノベーション」です。
posted by j.shiozaki at 17:42| Comment(0) | TrackBack(0) | 3分メモ

SZJ012 「イノベーション」にはまず気付くことから

システム開発において「気付く」という事は大変重要だと私は思っています。問題が潜在しているにも関わらず、それに気づかずに作業を進めてしまい、後になって問題が表面化してから気付く。
すぐに有効な対策を打てればいいですが、根が深い場合には致命的なダメージを被ることだってあり得ます。
納期を守り、コストを抑えて作業を行うには、問題となり得るポイントをしっかりと押さえてその発生を未然に防止する事が肝心です。
問題が発生してから対策を考える「後手後手」の対応ではなく、問題が発生する前に対策する「先手先手」の対応を行う。
ある種、システム開発の理想とする形ですが、この「先手先手」の対応を行うために必要な事とは一体何でしょうか?
私は次のような事を考えました。

●一歩踏み込んで考える
例えば、画面レイアウトを考える時、要求仕様を満たしているか、技術的に可能かといった点を重要視すると思いますが、そこで一歩踏み込んでユーザがこの画面を見てどう感じるかを考えてみてください。
ユーザが必要としている情報を表示しているか、ユーザの使い勝手が悪くないか、直観的に操作できるか等、実際そのような事はあまり考慮しなくてもユーザ承認は得られます。なぜならユーザは机上だけで判断しているからです。でも実際にプログラムが完成していざユーザが触ってみると、いろいろ問題が発生するものです。
いくらユーザビリティを考慮した設計をしても少なからず問題は発生しますが、設計時に何も考えなかったものと、その時想定される最大限の対策を盛り込んだものでは、問題の数やレベルに雲泥の差があることは想像に難くないと思います。

●「たら」「れば」結構
世間一般的には「あの時…していたら」「もし…していたら」とクヨクヨ考える事は良くないと事として知られていますが、私は「たら」「れば」は大変結構だと思います。
「たら」「れば」を考えれるということは、そこに問題があった事に気付いているということで、とてもポジティブな事だと思います。
今回失敗したのなら、次回は同じ失敗を繰り返さないように必要な対策を事前に講じればいいのです。
ただ、現在進行形のプロジェクトでは、「たら」「れば」を考える前に、今ある問題を解決する事が最優先ですので注意してください。「たら」「れば」を考えるのはプロジェクトが終わってからの方がよいでしょう。

成功したプロジェクトでは、苦労が少ない分問題点に気づく事も少ないでしょう。でも、気付くポイントというものは無数に存在していると私は思います。要はそのポイントを見つける「気付く力」をどれだけ持っているかだと思います。常にアンテナをピンと張って一瞬のすきも見逃さず問題の予兆に気付く努力することが重要だと思います。
イノベーションの糸口はまず気付く事、全てはそこから始まります。
posted by j.shiozaki at 17:41| Comment(0) | TrackBack(0) | 3分メモ

2013年09月29日

SZJ011 「できません」と言う前にその理由をよく考えよう

誰しも仕事で何か頼まれ事をされて「できません」と答えた事があると思います。
「技術的に無理だからできません」「時間がないからできません」「コストがかかり過ぎるからできません」といった具合に。

不具合など、避けられない絶対的な理由がある場合は別ですが、大部分の人は、何か頼まれ毎をされたら少なからずやらなくていい理由を探すはずです。
そこで、筋の通った理由が見つかると「できません」と答えて面倒事を避けようとします。

でも、ちょっと考えてみてください。
「できません」と答えてしまうとその後の選択肢が限定されてしまう事を。

「できません」と答えると、その後選択肢は「やらない」です。依頼主がいくらその作業をやってほしくても「できません」と答えられるとその後はどう転んでも「やらない」ということになります。逆に「できます」と答えると、最低でも「やる」「やらない」の2つの選択肢ができます。

●「できません」の後の選択肢は1つ
 ・「できません」⇒「やらない」

●「できます」の後の選択肢は最低でも2つ
 ・「できます」⇒「やる」
        ⇒「やらない」

どんな場合でもそうですが、選択肢は少ないより多いほうがよいです。複数の選択肢があることで状況に合わせて柔軟に立ちまわれるようになります。
そうゆう点で「できます」の後の選択肢は無限です。

●「できます」の後の選択肢は無限に広がる
 ・「できます」⇒「やる」⇒「全部やる」
             ⇒「一部だけやる」⇒「Aをやる」
                      ⇒「Bをやる」
             ⇒「段階的にやる」⇒「Aからやる」
                      ⇒「Bからやる」
             ⇒「複数の方法を試す」
             ⇒「やって状況をみる」
             ⇒「試しにやってみる」

では、リスクを無視して何でも「できます」と答えるべきなのかというと、それも違います。
要は「できない理由を探すのではなく、できる方法を探す」ということです。
どんなに頑張っても、できる方法が見つからない場合は、本当に「できません」ですが、どんな難しい事でも条件を付ければ何かしら方法は見つかるものです。
最初に上げた3つの「できません」を例にして上げると、

「技術的に無理だからできません」
 ⇒実現可能な技術を組み合わせて代替案を提示する。
 ⇒サポートセンターに問い合わせてみる。

「時間がないからできません」
 ⇒時間が限られているので、優先度の高い物だけ先にやる。
 ⇒今やっている作業を後にずらして、依頼された作業をやる。
 ⇒スケジュールを伸ばしてやる。
 ⇒増員してやる。

「コストがかかり過ぎるからできません」
 ⇒必要のない機能を削ってやる
 ⇒現在の予算内でどうしても必要な物だけをやる
 ⇒必要性を顧客に訴えて、予算を増やしてもらう。

実際の現場でも、いろいろ条件をつけてできる方法を探すと以外見つかるものです。
これからは「できません」と答える前に、できる方法をしっかり考えてみるようにしてください。必ずよい方法が見つかるはずです。
そうすれば、自然にプロジェクトがうまく回るようになります。
posted by j.shiozaki at 16:35| Comment(2) | TrackBack(0) | 3分メモ

2013年09月22日

SZJ010 究極の選択

システム開発を行っていると、いろいろ決断に迫られる事があると思います。例えば、会議の時、設計している時、コーディングしている時、時には数十人規模の作業に影響するような決断を迫られる事もあり、そのストレスは半端ではありません。
決断を誤れば、莫大な工数をかけた作業が全て無駄になってしまうことだってあり得ます。
そこで、自分が決断を迫られた時、どう判断すればよいか、実際の現場で起こり得るケースを想定してシミュレーションしてみることにします。

シミュレーションでは、現実に起こる複雑な状況までは想定しきれないので、実際はケースバイケースで決断する必要があるとは思いますが、基本的な考えを自分の中に持っていることで、いざという時の決断の助けになります。
グダグダ考えて貴重な時間を無駄使いすることのないように、自分はこうするんだという信念を持って一貫性のある決断ができるように、ぜひこのシミュレーションで自分の考えをまとめてみてください。


■自己解決できるささいな問題でも、報告するか

大規模プロジェクトに限らず、どのような開発でも問題点を共有するために定例会議などを開きますが、その時に、自分の管理範囲に収まる限定的な問題でも、メンバー全員に報告すべきでしょうか?
周知徹底のため、必ず報告すべきという考えもあるし、他のメンバーに関係ないことは、時間の節約のために報告しないという考えもあります。さて、あなたはどうしますか?

※あくまでも 100% 自分の管理範囲内での問題である場合のみの話です。1%でも他に影響する疑いがある場合には、なにがあろうと報告するのが義務です※

<必ず報告する>
長所:自分の考えが正しいか、他のメンバーの意見を聴ける。(逆に考えがまとまらなくなる危険性もありますが...)
短所:全体に関係ない事で、みんなの貴重な時間を浪費してしまう。

<報告しない>
長所:全体に関係することだけに集中して議論できて効率が良い。
短所:対策した本人しか詳細を知らないので、ブラックボックス化してしまう。


■自分の考えに合わないといって、他人が考えた仕様に口出しするか

これはプロジェクトの人間関係に影響する問題です。大規模プロジェクトになると、いろいろな知識や経験を持った人が集まります。当然そのような人達は自分の考えや作業のやりかたといった物があります。
そのため、機能間の仕様の打ち合わせを行ったりすると、意見が衝突するといった事が、日常茶飯事に起きます。お互いプロなので、ある程度は融通し合えますが、超えてはいけない一線というものがあります。
それを超えるとその担当者と良い関係を築けなくなる可能性があります。あなたはそれが分かっていても、良いシステムを作るために他人の仕様に口出ししますか?

<口出しする>
長所:自分の考えに沿ったまとまりのある仕様に統一できる。
短所:どんなに気を使っていても、口出しされた人の尊厳は少なからず傷ついてしまう。
   人間関係が悪化して、仕様を融通しあ合える幅が狭まる。

<口出しない>
長所:プロジェクト内で、良い人間関係が築けることで、仕様を融通し合える幅が広がる。
短所:システム全体でまとまりのない仕様になってしまう可能性がある。


■STで、不具合でもないのに他チームに影響するような仕様変更を行うか

不具合ではなく性能や、操作性に問題がある場合、PT、CTであれば、迷いなく仕様変更できても、STでは躊躇してしまうものです。
PT、CTレベルならば、自分のチーム内で完結できますが、STレベルになると、他チームとの連携も絡んでくるのでより問題が複雑になってきます。
それでもあなたは、仕様変更を強行しますか?

<仕様変更する>
長所:システムが改善されて顧客に喜ばれる。
短所:想定外の仕様変更でコスト増になる。
短所:STをやりなおす必要があり、他チームも含めてスケジュールの調整が大変。

<仕様変更しない>
長所:スケジュール通り作業をこなせる。
短所:問題があるのが分かっているのに、無視するのは倫理的に問題がある。


■リスク回避 or ダメージコントロール

どの工程でもいえる事ですが、リスクが高いと思われるポイントを回避して、問題の発生を未然に防ぐか、あるいは、リスクがあるのは承知で、問題が発生した場合に備えて被害を最小限に抑える処置を施しておくか、あなたはどちらを選択しますか?

<リスク回避>
長所:問題になりそうな部分を排除することで、開発がスムーズに行える。
長所:既存の実績のあるシステムを流用して、不具合のリスクを軽減できる。
短所:コンサバなシステムになってしまう。

<ダメージコントロール>
長所:新しい技術や考えを取り入れて、最先端のシステムを構築できる。
長所:既存のシステムを流用した場合でも、どうせテストし直すのだから思い切って改良できる。
短所:ダメージコントロールのために余計なコスト(調査やテスト)が必要。
posted by j.shiozaki at 15:33| Comment(0) | TrackBack(0) | 3分メモ

2013年09月16日

SZJ009 knowledge transfer を行うべし

ここ2年あまり、大規模プロジェクトに携わってきましたが、その間つねに頭を悩ませてきた事があります。
それは、自分の考えを他人に伝える事です。何度テレパシーで自分の考えを転送できればいいかと思った事か。

特に苦労したのがプログラムの製造を行うプログラマに、自分の設計した機能を理解してもらう事です。
私が作成するのは、基本設計まででしたので、そこからブレイクダウンして製品に仕上げるのがプログラマの作業です。当然プログラムを作成するのに必要な情報は基本設計書に記載していますが、立場が変われば設計書の見方も変わります。
顧客に分かりやすくするために若干端折った記述もあり、プログラマに詳細設計を行ってもらうには端折った部分を別途補足する必要があります。

例えば、この処理は区分によって設定する値が変わるとか、テーブルAのフラグBがONの場合はこの処理行わない等々。
顧客に対しては、処理の概要だけを説明すればよいですが、プログラマに対しては、詳細まで説明する必要があります。それを怠ると自分が想定していた通りにプログラムが仕上がってきません。

設計から製造工程へシフトする際に、プログラマへ仕様説明を行いますが、その理解度はプログラマのスキルに依存する部分が大きいです。
基本設計書の記載レベルは、どの機能も同じなのですが、軽く説明したただけで完璧に作りこんでくれる人もいれば、いくら説明しても正常ケースも動作しないグダグダなプログラムを作る人もいます。
では、どのようにすればプログラマのスキルによる品質のバラツキを防ぐ事が出来るのでしょうか。

私が重要と考えるのがKT(knowledge transfer)です。
大規模案件を扱う上で、難しいというか、もどかしいポイントは、「自分が設計した機能を自分でプログラミングできない」ということです。
効率的に利益を出すためには、全ての工程を社内で行うのではなく、下流工程を積極的に外部に出すことが求められます。

そこで、作業を下流工程に受け渡す際に、設計書の内容をただ説明だけでなく、対象とする機能を設計する際に得た知識や、このような設計になった経緯も合わせて説明します。
そうすることでプログラマは、これから自分が担当する機能の役割や、処理の流れを理解でき、効率的にプログラミングが行えます。

前に書いた「いくら説明しても正常ケースも動作しないグダグダなプログラムを作る人もいます」のような状況は、プログラマが自身の担当する機能の役割を理解していない場合によく発生します。
KTを行って、設計者からの知識を受け継いだプログラマは、その知識を活用して、上位の機能からどのようなデータ降りてくるのか、どのようなパターンがあるのか、次の機能にはどのようなデータを渡す必要があるのか等、基本設計書だけでは網羅しきれないような情報を自分で分析してプログラムに反映することが可能になります。

でも、いくら必死にKTを行ってもダメなプログラマはいるもので、特に相手がオフショアの場合には言葉の壁という大きな障害もあります。
そのような場合は、速やかにプログラマを変更することをお勧めします。
社内の人間なら教育的観点から、がんばってやらせるという選択肢もありますが、自分の時間も無駄にしますし、品質も保証できなくなるので、社外の人でしたらビジネスライクにビシッとケジメを付けさせるべきです。

KTは、社内、社外を問わず担当者レベルで、工程間や、機能間で積極的に行い、知識を共有することが大規模案件では重要になってきます。
自分が担当する部分だけの知識さえあれば良いという考えでは良いシステムは作れません。
完璧に理解する必要はありませんが、担当外の機能でも基本的な知識は身につけておく必要はあると私は考えます。
posted by j.shiozaki at 12:31| Comment(0) | TrackBack(0) | 3分メモ

2013年09月08日

SZJ008 デグレードと闘う

システム開発を行う上で、決して避けては通れないデグレード(以下デグレ)ですが、その予防について真剣に考えたことがありますか?
主なデグレの要因は、仕様変更時の修正の取りこぼしや、バグ対応のミスなどが上げられます。
開発の深度が浅い段階でのデグレはそれほど致命的になりませんが、工程が進むにつれてデグレによるダメージは深刻度を増します。
そのレベルは単純なバグの比ではありません。
なぜなら、デグレは想定外の事象だからです。

仕様変更や、不具合が発生した場合の対応の基本的なプロセス以下の通りですが、

1.影響範囲を調べる。
2.1.で調査した内容を元に、プログラムを修正する。
3.2.で修正した箇所をテストする。

デグレはこれらのプロセスをすり抜けてきた場合に発生します。つまり、開発者が発生した不具合の影響範囲を把握していなかったということになります。
これはかなり危険な状態です。どこに影響するかわからないような修正を行うと、今まで長い時間とコストをかけてテストして信頼性を上げてきたことをすべて台無しにしかねません。
もっとも危険なのは、デグレとは気づかずに、正しく動作していた機能を不具合として修正してしまうことです。いわゆる「デグレのシーソー現象」や「デグレの連鎖」と言われるものです。

<デグレのシーソー現象の例>
1.A機能の不具合を修正
2.A機能の不具合が直るのと同時にB機能に不具合が発生した。
3.B機能の不具合を修正
4.直したはずのA機能がまた正常に動作しなくなった。

<デグレの連鎖の例>
1.A機能の不具合を修正
2.A機能の不具合が直るのと同時にB機能に不具合が発生した。
3.B機能の不具合が直るのと同時にC機能に不具合が発生した。

小規模なプロジェクトでは、開発メンバーが限られるため、不正な修正にすぐ気付きこのような状況に陥るのを未然に防ぐことも可能かもしれませんが、機能ごとに担当者が分かれるような大規模プロジェクトでは以外と気づきにくいものです。
実際私も、これらの現象に悩まされた一人です。

では、どのようにすればデグレは防ぐことが可能でしょうか?
これはある意味究極のテーマです。

デグレの発生を完璧に検知するには、すべてのテストをやり直すしかありませんが、これは非現実的です。
また、不具合の影響範囲を1つの漏れもなく完璧に洗い出すことも、可能だとは言い切れません。

今私が思いつくことは、設計、または、製造を開発当初から担当していたメンバーが、不具合の対応を行うということぐらいです。そうすることで、少なくとも影響範囲の洗い出しの精度が増し、デグレのリスクを軽減することが可能になります。

どうやら、ここは発想を変えて、大規模プロジェクトでは、デグレは避けては通れない物と割り切って、デグレが発生した際のダメージを最小限に抑えるような方法を考えるしか無さそうです。
この件については、まだいいアイデアが思いつかないので、今後の課題として継続して取り組んでいきたいと思います。
posted by j.shiozaki at 16:55| Comment(0) | TrackBack(0) | 3分メモ

SZJ007 会議で発言するということ

まずはじめに次の事を考えてきてください。

「あなたは会議で発言していますか?」

良かれ悪しかれ会議で発言する事は非常に重要です。
人を集めて会議をするということは、参加者の知恵を借りて思考の幅を広げるということです。
そうすることで、自分一人では気づかなかったような問題点を早期に発見したり、難解な問題の解決の糸口を見つけたりすることができます。
「会議では広く意見を集めるために、積極的に発言すべきだ」なんてということは、私に言われるまでもなくみなさん周知の事だとは思いますが...

それでは、次に「理想的な発言とは?」について考えてみてください。

以下は、スケジュールについての会議の発言例です。

@「そんなスケジュールでは無理です」
A「A機能はそんなんじゃ無理ですよ。そんなの当たり前の事が分からないんですか」
B「私の担当分は難しいので、スケジュールを後ろにずらしてください」
C「B機能がないとC機能が作れないので、B機能を先にした方がよいのでは?」

みなさんはどう感じましたか?
私の考えはこうです。

@全否定タイプ
あまりいませんが、周りの状況も考慮せずに全否定するタイプです。無理だ!無理だと!と言うばかりで、どうすればできるかを考えようともしないタイプ。

A上から目線タイプ
自分は知識も経験も豊富だから、知識の浅い人が考えた事にとりあえず難癖をつけて自分はクールだぜ!と思われたがるタイプ。
このような人に意見を求めても、ただ文句を言いたいだけで自分では何も考えていないので、いい答えは期待できない。

B自分だけタイプ
自分のスケジュールが遅れて迷惑をかけてしまう恐れがあるような場合であれば、そんなに悪い発言ではないと思います。自分だけ楽しようなんて考えている人はそうはいませんから。

C気がきくタイプ
まさしくこれが自分が考える理想的な会議での発言だと思います。問題点をズバリ指摘して、解決方法まで提案しています。


会議では、「無理だ」とか「ダメだ」とか否定的な事ばかり言う人が結構います。問題点を見つけて黙っているのに比べればまだましですが、否定するだけでは、何も解決しません。
否定するのであれば、それに代わる代替案を提示するか、一緒に問題解決をしようという姿勢を見せるべきです。
上記の@Aがその悪い例だったのですが、@は救いようがありませんが、Aは「A機能は特殊な処理が必要なのでもっと工数が必要です」みたいに、自分の知識と経験に基づいて客観的にA機能にどれぐらい工数が必要かを説明すれば、会議に参加している人たちに共感してもらえると思います。

会議の人数が多いと、発言するのに勇気がいりますが、ここは一つ頑張って発言するように努力してみてください。
かく言う私も、偉そうに書いていますが、SAPの知識に乏しくて、会議でほとんど発言できなかったという経緯があります。的外れな事を言って笑われたりしないかとか、馬鹿にされないかとかいろいろ考えて口がすぼんでしまいました。
しかし、今では、プロジェクトが事故った事もあり、積極的に発言するようにしています。いつもしどろもどろになりながらグダグダな発言になってしまうのですが、カッコよくクールに発言できなくてもいいんです。肝心なのは自分の考えを伝えようと努力するということです。自分が必死になれば周りの人も分かってくれます。世の中そんなに意地悪な人はいないですから。

なんだかうまく話しがまとまりませんが、自分が言いたい事は「会議では積極的に発言しよう、ただし、否定的な発言はNG」ということです。
社内でも、社外でもいいですので、今度会議に参加するときに、このことについてちょっと考えてみてください。
posted by j.shiozaki at 16:53| Comment(0) | TrackBack(0) | 3分メモ

2013年08月24日

SZJ006 顧客に誠実に対応する事の重要性

顧客の信頼を一度失うと、それを取戻すのは並大抵なことではありません。信頼がないと、ちょっとスケジュールの遅れや、プログラム不具合に対しても敏感に反応し、徹底的に叩かれてしまいます。
では、どのような時に顧客の信頼を失うのでしょうか?

スケジュールが遅れた時?
不具合が発生した時?

いえいえ、こんなことでは信頼は失いません。
この程度のことはシステムを開発する上で当たり前のことなので、顧客も織り込み済みです。
ではどんな時かというと、

スケジュールが遅れた時の対応。
不具合が発生した時の対応

です。
つまり、スケジュールの遅れや、不具合などの、問題が発生した時に適当な対応をすると顧客の信頼を失ってしまうということです。
信頼を失った後に、いくら頑張って挽回しても一度失った信頼は決して元の状態には戻りません。そこで、顧客の信頼を失わないように普段から発生した問題への対応には最大限の注意を払う必要があります。

では次に、問題が発生した時にどのような対応をすればよいでしょうか?

<問題が発生した時>
問題が発生したらすぐに回答します。問題を放置することは絶対にやってはいけないことです。
できれば問題が発生した翌日に回答を返すのがいいでしょう。
すぐに解決策が見つからないものは、何時までに調査して回答しますと期限を提示しておきます。
また、問題の内容が不明瞭で顧客と調整が必要な場合は、時間を空けずにすぐにレビューの依頼を出します。

<問題への対応>
問題の原因が、開発側にあるのか、顧客側にあるのか明確にしておく事は重要です。
追加要件など、顧客の都合による物は、工数をしっかり出して、顧客に提示して承認をもらう必要があります。開発側の問題でないものはきちんと顧客から追加の工数のコストを負担してもらって下さい。

開発側の問題の場合には、しっかりと原因を調査して顧客に報告し、対策方法を提示します。その時に、類似箇所もしっかりと洗い出して同様の問題が他の箇所で発生しないようにするのが大変重要です。一度指摘した問題が他で発生することを顧客は大変嫌います。これを繰り返すと信頼関係は崩壊します。
また、問題が発生した場合の管理体制を明確にしておくと顧客は安心します。顧客との問題管理に専属の担当者を割り当て、常に顧客とステータスを共有して、問題の取りこぼしがないように目を光らせておきます。


最後に問題発生時の対応手順をまとめておきます。
全てがこのケースに当てはまるわけではないですが、問題に対応する際の基本的なプロセスを理解するのには役立つと思います。

1.問題発生
   ↓
2.問題点をまとめて、台帳で管理する。
   ↓
3.問題の発生元が顧客側にあるのか、開発側にあるのかを明確にする。
   ↓
4.問題の対応策を考え即時対応可能な物から着手する。
   ↓
5.対応に時間がかかる物は、期限を決めて顧客に提示する。
  また、追加要件の場合には、工数を出して顧客の承認をもらう。
   ↓
6.問題が大量に発生した場合には、体制の強化を図る。
   ↓
7.体制の強化だけではどうにもならない場合には、リスケジュールする。

問題の責任が、開発側にある場合には、それに伴うコストは当然開発側負担する必要がありますが、、追加要件などに伴うコストは顧客に負担してもらうのが筋です。
ただし、顧客との信頼を失っている場合には、追加コストの請求もままならなくなり、本来顧客に払ってもらえるはずのコストも自腹を切らざるを得ない状況に追い込まれる事もあるので、顧客に誠実に対応して、良い信頼関係を築くことは大変重要です。
posted by j.shiozaki at 16:10| Comment(0) | TrackBack(0) | 3分メモ

2013年08月19日

SZJ005 リスケジュールについて考える

リスケジュールと聞くと、ネガティブな印象を受けます。それは、ほとんどの人が「リスケジュール=トラブル」という概念を持っているからです。なので、多少作業が遅れていても、何だかんだと理由をつけてスケジュール通り完了しますと顧客に説明するのが常です。
しかし、よく考えてみてください。

作業が遅れているのになぜスケジュール通り完了しますと言い切れますか?

よく言い訳に使われるのが「人を増やします」とか「作業に慣れて後半は早くなる」とかですが、実際こんな事はスケジューを作成する際に考慮しておくべきで、人が足りないのは自分の見積もりが甘かっということなので、この時点ですでにスケジュールは破たんしています。
進捗が50%ぐらいまでは、こんな言い訳でも顧客にはなんとか納得してもらえますが、進捗が50%を超えるあたりからこの言い訳も通用しなくなってきて、最終的に顧客からリスケジュールを指示されてしまいます。
顧客からリスケジュールを指示されたということは、開発側がスケジュールが遅れているのに適切な対応を怠ったと顧客に判断されたということなので、顧客からの信頼は失われています。

だからといって、安易なリスケジュールを推奨しているわけではないです!!!

あまり頻繁にリスケジュールを行うと、何を前提にして作業を見積もっているのか不明瞭になり、結果、顧客が不安になりこの場合も顧客からの信頼を失う結果となりかねません。
あくまでも、リスケジュールは、スケジュールが破たんしている場合の話で、スケジュール通りに作業を進められる余地が残されているのであれば、体制の強化などを行いスケジュール通り作業をこなす努力をしなければいけません。

リスケジュールを考慮しなければ行けない状況はいろいろあるとは思いますが、いつくか例を上げておきます。

<顧客起因>
@仕様追加や、仕様変更の要望が出た場合。

<開発起因>
@想定外の問題が大量に発生して調査に時間がかかる場合。
A見積もりが甘くて、体制の強化だけでは対応しきれない場合。


リスケジュールの判断はとても繊細であり、開発者としての技量が試されるポイントでもあります。
そして、決して忘れてはいけない重要な事は

『顧客も開発者も良いシステムを作ろうという気持ちは同じ』

ということです。進捗会議などで厳しい事を言われると時々このこのことを忘れてしまい感情的になってしまったりしますが、顧客と開発者の根本にある物は同じだという事を決して忘れないでください。
そして、リスケジュールが必要と判断した場合は積極的に顧客に提案してください。私たちが良いシステムを作ろうと誠意ある対応をすれば必ずきっと顧客もそれに答えてくれるはずです。ただし、リスケジュールにかかるコストの話については別ですが...
posted by j.shiozaki at 01:49| Comment(0) | TrackBack(0) | 3分メモ

2013年08月09日

SZJ004 設計書の書き方@〜読み物としての設計書〜

設計書を書く時に、文章の表現に気を付けていますか?
ユーザーは、開発者とは違った視点で設計書を見るので、開発する側からすると当たり前のことでも、文章の表現の仕方一つで理解できなかったり、違う意味で受け取ったりします。
誤解のないように気を付けて書いているつもりでも、ユーザーに指摘されて設計書を修正するといったことは普通にある事なので、できるだけユーザーに負担をかけないように、設計者は読み物だという意識をもって、文章の書き方に気を付けてみましょう。

■受動的、能動的

日本語は主語を省略しても意味が通じるため、書き方によってはユーザーが混乱してしまいます。例えば下の例で考えてみてください。

「選択した従業員を検索して画面に表示する。」

設計書を見慣れている私たちには、従業員を選択するのはユーザーで、検索して画面に表示するのはプログラムだと感覚的に理解できるのですが、設計書を見慣れていないユーザーは、この区別がつかない場合があります。

「ユーザーが選択した従業員を、プログラムが検索して画面に表示する。」

上記のように主語をつけて書けば誤解はなくなりますが、実際このような書き方はあまりしないです。
もっとシンプルにわかりやすく書くには、操作をするユーザーと、処理を提供するプログラムのどちらかの視点から書いて、受動的、能動的な表現を使います。

@ユーザー視点
「選択した従業員が検索されて画面に表示される。」

Aプログラム視点
「選択された従業員を検索して画面に表示する」

設計書はプログラム視点で書くのが一般的ですので、特別なことがない限りはAの書き方で問題ないです。また、能動的な表現で統一したい場合もあるので、その場合は下記のような書き方もあります。

「ユーザーが選択した従業員を、検索して画面に表示する。」

肝心なのは、ユーザーが混乱しないように操作する側と、処理する側が明確になっていることです。


■体言止め、用言止め

文章を名詞で終わらせる表現を体言止め、動詞・形容詞で終わらせる表現を用言止めと言いますが、この体言止め、用言止めをきちんと使い分けることで設計書が読みやすくなります。

<体言止めを使う箇所>
@処理の見出し

 1.従業員一覧表示処理
  1.1.入力チェック
  1.2.従業員の検索

A注釈
 「※詳細は○○を参照。」

B処理の条件
 「入社年月日がシステム日付以下であること。」

<体言止めを使う箇所>
@処理の説明

 「以下の条件に一致する従業員を従業員マスタより検索する。」
 「取得した従業員を一覧に表示する。」

自分が試した限りでは、処理の説明に関する部分は用言止めで、見出しや注釈など、処理の説明に直接関係ない部分や、処理の条件など動作を制限する部分を体言止めで表現すると全体がすっきりして読みやすくなるようです。


■句読点

句読点の使い方に、初歩的・基本的なミスのある文章は、それだけで読むのが嫌になってしまいますので気をつけなければいけない重要なポイントです。
句読点についてユーザーに指摘されるような恥ずかしい思いをしたくはないので、たかが句読点となどってはいけません。

特に目につきやすいのが、句点「。」の使い方です。句点をつける箇所と、つけない箇所を明確に区別しておかないと設計書がとても読みにくくなります。
基本的に文章の終わりには句点「。」をつけますが、一覧形式で処理を説明したりすると句点「。」をつけ忘れてしまいます。




あと、カッコつきの文章に句点「。」をつけるかどうかですが、一般的にはつけないそうなのですが、コンピュータシステムの設計書では文字列をカッコで表現することが多いので自分は句点「。」をつけてもいいと思っています。

文章のお作法で句点「。」をつけないの一般的
 「従業員番号が入力されていません」

エラーメッセージなどを記載する場合などには句点「。」を付けてもよい。
 「従業員番号が入力されていません。」


<参考文献>
 よい文章の書き方
  http://www.h3.dion.ne.jp/~urutora/bunshoupeji.htm

 ちょっとおかしな文例
  http://www.h3.dion.ne.jp/~urutora/bunreipeji.htm
posted by j.shiozaki at 00:27| Comment(0) | TrackBack(0) | 3分メモ

2013年08月02日

SZJ003 「あいつよりましだ」は思考停止のはじまり

今回は3分メモを始めるきっかけとなったネットの記事を紹介します。

http://www.sinkan.jp/news/index_1792.html

内容は大前研一氏の「洞察力の原点 プロフェッショナルに贈る言葉」という本の抜粋なのですが、身につまされることばかりで、これまでの自分の行動をすぐに改めようと気になります。

私が特にグサッときたのが「そのうちに」というやつです。

「そのうちに」やりたいことがあるなら、今やりなさい。というのが大前氏のアドバイス。時が経つにつれて情熱は薄れるもの。「やりたい」と思った時こそが旬であることを忘れないようにしましょう。

この記事から私は、他人や、結果を意識しすぎてグズグズしていてはいけない、とりあえず行動しなくてはと思い。3分メモを始めました。
結果として、形にならなかったとしても、行動することに価値を見出し、次に繋げる原動力として行きたいと思っています。

また、「あいつよりましだ」や「おれもいいと思ってた」も自分的にはかなりグサッときました。
「あいつよりましだ」と自分の方が優れていると慰めてみてもみじめなだけです。人と比較するのであれば一生懸命頑張っている人を目標にして「あいつを超えてやる」みたいな意気込みが必要だと思います。
「おれもいいと思ってた」は、他人の意見に便乗して、自分で考えることをしない人の言葉です。何かを成し遂げたいと思うのならば、しっかり自分で考えて発言すべきです。

まだ3分メモを始めたばかりですが、今後3分メモをどうすべきか、自分の長期的なテーマとして取り組み、少しずつ改善して行こうと考えていますのでどうか長い目で見守っていてください。
よろしくお願いいたします。
posted by j.shiozaki at 00:46| Comment(0) | TrackBack(0) | 3分メモ

2013年07月28日

SZJ002 メッセージで開発者のセンスが問われる

システムを開発する上で必ず必要となるメッセージですが、そのメッセージの文章について深く考えた事がありますか?
メッセージの目的は、システムからユーザーに必要な情報を伝えることですが、間違えなく正確に伝えようとして、システマチックで分かりにくいメッセージになっていませんか?
メッセージに求められる要素は、「分かりやすく」「正確に」「簡潔に」といったところですが、これらの要素をいかにうまくまとめられるかは開発者のセンスに依るところが大きいです。

たとえば必須チェックのエラーメッセージを例にしてみると、

@「必須項目が入力されていません。」
A「個人番号を入力してください。」
B「必須項目が入力されていません。個人番号を入力してください。」
C「個人番号は必ず入力してください。」

上記の4つで私が一番センスが良いと思うのはCです。@は何をすればエラーを解決できるかが不明で、Aはなぜ個人番号を入力しなければいけないのかが不明。Bは原因と解決方法の両方が盛り込まれていて、一見良さそうですが、システム的な表現でユーザーに優しいとは言えません。
その点Cは、「必ず入力してください」という言葉で、個人番号が必須項目である事をユーザーに認識させ、なおかつ個人番号を入力すればエラーが解消できることも伝わります。
BとCのどちらのメッセージでも、ユーザーに伝えようとしている内容は同じですが、Cの方が自然で読みやすくすんなり理解できることに気づくはずです。

次に確認メッセージについて、編集した内容を保存せずに画面を閉じた場合などに、表示される保存の確認メッセージを例にして説明します。

@「変更した内容を保存しますか?」
A「変更した内容を保存しなくてよろしいですか?」
B「変更した内容を保存せずに画面を閉じてもよろしいですか?」

上記の3つの内、@Bは特に問題ないですが、Aはセンスが悪いです。Aの場合、「はい」「いいえ」の2択の確認メッセージの場合で、

 「はい」…保存しない
 「いいえ」…保存する

という処理になりますが、通常「はい」は肯定の意味で使われるので「はい」を選択した時の保存される方法がしっくりきます。
確認メッセージには非定形の文章はユーザーに誤解を招きやすいので使うべきではありません。確認メッセージはシステムが行いたい処理に対して同意をもらうといった感じの方がユーザーに優しくてセンスが良いと私は思います。

以上、エラーメッセージと確認メッセージについて例を上げて説明しましたが、場合によっては、どうしてもシステマチックな表現しかできない場合もあるとは思いますが、できるだけユーザー視点で読みやすく、理解しやすいメッセージを心がけてください。
最後に、いくつかメッセージの例を上げておきますので、ちょっと自分なりに考えてみてください。

電話番号のフォーマットチェック
1-@「電話番号は数字で入力してください。」
1-A「電話番号のフォーマットが不正です。数字で入力してください。」
1-B「電話番号に数字以外が入力されています。」

開始日、終了日の大小チェック
2-@「開始日が終了日より後です。」
2-A「開始日が不正です。開始日<終了日で入力してください。」
2-B「開始日には、終了日より前の日付を入力してください。」

検索条件に合う従業員が検索できなかった場合
3-@「検索条件に一致する従業員は存在しません。」
3-A「従業員が存在しません。検索条件を変えて再度検索してください。」

内容を変更したのに保存せずに終了しようとした場合
4-@「変更内容を保存しますか?」
4-A「変更内容が保存されていません。変更内容を保存してから終了しますか?」

※センスが良いと思うもの※
1-@「電話番号は数字で入力してください。」
2-B「開始日には、終了日より前の日付を入力してください。」
3-@「検索条件に一致する従業員は存在しません。」
4-@「変更内容を保存しますか?」
posted by j.shiozaki at 00:58| Comment(2) | TrackBack(0) | 3分メモ

SZJ001 顧客の理解度を高める5つのコツ

【なぜ?を明確にする】
処理の目的をしっかりと顧客に理解してもらうためにも、なぜこのような仕様になったのかを明記しておく。
時が経つと書いた本人もなぜこうしたのか忘れてしまうので、処理の目的を明記しておくことで、仕様変更や、不具合で設計を見直す場合に、デグレの発生を抑制することに役立つ。
また、他の担当者が仕様を理解する際にも役立つ。

 悪い例:「△△を□□に設定する。」
 良い例:「○○のため、△△を□□に設定する。」

【比較する】
既存システムや、類似した機能が存在する場合には、比較して説明する事で顧客がイメージしやすくなる。
顧客が既に知っている事と関連づけることで、打ち合わせの時間を大幅に短縮できるし、仕様の深い部分まで議論できるようになるので、過去の情報は最大限に活用する。

【全体を見せる】
顧客に説明を行う際に、対象とする機能だけでなく、全体から説明する。
全体図を見せてこれから説明する部分はここですと示すことで、これから説明する機能のイメージがつかみやすくなる。
仕様の打ち合わせをする場合などには、共通で使える全体図を用意しておくのも良い。

【流れをつくる】
顧客に説明を行う際に、関連性のある機能をまとめて流れを作って説明する。
例えば、設計書の説明をする場合などには、処理の流れに沿って説明すると顧客に理解してもらいやすくなる。

【繰り返す】
システム上重要な処理は、打ち合わせの要所要所で繰り返し説明する。
得に複雑な処理などは、一度の説明では完全には理解してもらえないため、繰り返し説明することで顧客の理解度を高めることができるし、その都度ブラッシュアップできる。
posted by j.shiozaki at 00:55| Comment(0) | TrackBack(0) | 3分メモ