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年12月15日

大変お待たせしました。

長らくお待たせしました。
ようやく「SPモードメール監視」がドコモメールに対応して「ドコモメール監視」に進化しました。

ドコモメールに対応するにあたり、ターゲットを Android 4.0.3 以上にしました。
前の「SPモードメール監視」は Android 4.2 で動作しなかったのですが、今回SDKのバージョンを上げた事により動作するようになっています。

ドコモメールに対応する作業事自体はさして大変ではなかったのですが、今までなかなか対応できなかった理由は私が使っているダメスマフォ(T-01D)が12月にならないとドコモメールに対応されないためでした。
しかし、世の中の主流は Androkd 4.X 系なのに、いまだに古臭い 2.X系で開発していてはちゃんとしたものは作れないし、ドコモメールを使えるようにするにはT-01D の OS のバージョンアップが必要ようだし、もともとこのダメスマフォには嫌気がさしていたので思い切ってスマフォを新しくしました。

新しいスマフォは今年の冬モデル AQUOS PHONE SH-01F です。
いやはやめちゃくちゃ快適で、画面なんかサクサク切り替わります。これでまた新しいアプリでも開発したいですね。
posted by j.shiozaki at 02:15| Comment(3) | TrackBack(0) | SPモードメール監視

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分メモ