2013年09月05日

ボーイング787被雷

忙しい仕事の合間を縫って、遅い夏季休暇を取り、地元の宮崎に帰省してきました。
台風の影響で雨ばかりの4日間でしたが、暑くもなくそれなりに快適に過ごせました。

帰省する前々日台風15号が発生して、飛行機が飛ぶかどうか心配していましたが、前日の夜に熱帯低気圧に変わって無事宮崎に降り立つ事ができました。
自分が帰省している間、関東では、大雨や竜巻で大荒れの様子が連日ニュースで報道されていたので、自分が休んでいる間に仕事をしている会社のみんなに大変申し訳ないと思いつつ、本心は、宮崎にいて良かったと思っていました...ふらふら

でもそんな私にも不運は巡ってきました。短い休みも終わって東京に戻る日、父親に空港まで車で送ってもらって手荷物を預けて、東京に戻る直前に発生した台風17号も、戻る当日には熱帯低気圧になって定刻通り離陸できることを確認して一安心して、父親と軽くコーヒーを飲んだあと、簡単にお別れを済ませて手荷物検査場を抜けてゆっくりしていたところ。
ANAから「東京行き 11:25発の ANA 608 便が、宮崎空港に来る途中に被雷し点検のため出発が遅れます...」とアナウンスが入りました。
じぇじぇ〜!がく〜(落胆した顔)



自分が搭乗予定の飛行機を出発ロビーの大きな窓から見てみると、最新鋭のボーイング787の機種部分で何やらゴニョゴニョ作業をしていました。
被雷することぐらい考慮して設計していると思うので大丈夫だとは思いますが、現代の飛行機は精密な電子機器の塊ですから少なからず不安はあります。しかも、最近何かと話題の絶えないボーイング787なので余計です。
でもGSユアサとボーイングが完璧に改修してくれていると信じて、点検の終わったボーイング787に1時間遅れてで乗り込みました。
結果的に、こうしてブログを書いているということは何事もなく無事に飛行できたということなのですが、被雷で出発が遅れるなんて初めての事だったのでちょっと動揺してしまいました。
夏に地元に帰ることはあまりないのですが、暑いと積乱雲も発生しやすいし、台風の心配もあるし、不足の自体を想定しておく必要がある事を改めて実感しました。

posted by j.shiozaki at 14:44| Comment(0) | TrackBack(0) | 日記

2013年09月08日

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

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

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月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月29日

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

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

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

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

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

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

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

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

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

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

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

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

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

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