ちあき(c_c).6の徒然なるままに

■こんにちは！……お久しぶりです。

　こんにちは！　……と言いましても、前回のコラムが「2010年4月28日」なので、ほぼ2年ぶりでございます。どうもお久しぶりです。はじめましての方、はじめまして！ ちあき(c_c).6と申します。とあるSIer子会社にて銀行様システムを担当しています。

　コラムの自己紹介に、「立場は、リーダー的現場担当者（笑）」とありますが、この2年間のあいだに、PMを経験しました。パッケージのバージョンアップによる制度案件対応でしたが、基盤更改、サイト(ロケーション)変更などの要素も踏まえた16カ月という長丁場のプロジェクトに、これまで経験しなかった立場で参画できました。

プロジェクト期間中、いろいろ感じたり、考えさせられたりしました。感じ過ぎ、考え過ぎがたたったのか、今年に入って、ガス欠です……ガッツがなくなっていましたが、少し復活してきました。

■13年目になりました。

　2000年4月に新卒でシステム屋になりましたので、この仕事に携わり今年で13年目に突入しました。勤務先は13年間同じですが、2回の単身赴任を経験したり、勤務先の出資構成変更に伴い会社の環境が変わったりと、さまざまな変化を経験しています。

　仕事の内容も、1年目の配属先で主要業務だった「機械室の床はがし」「ケーブリング」から、設計、プログラミング、テストはもちろん、お客様との要件調整、提案、そして、夜間・休日のトラブル対応……などなど、褒めて、褒められ、しかって、しかられ……それはもう幅広く経験しています。

■システム屋というお仕事

　最近では「エンジニア」という呼称をよく聞きます。このコラムも「エンジニアライフ」ですしね。笑　エンジニア(技術者)というのを調べてみると……。

日本では「技術者」というのは呼称であり、その名称を定義し、その名称を名乗るための法的規制などは存在しない。フリー百科事典「Wikipedia：技術者（エンジニアから転送）」

とのこと。「エンジニア」だと思えば「エンジニア」を名乗っても何ら問題ない！　しかし、私自身の仕事内容を振り返ると、いわゆる「モノづくり」をしている割合は少なく、「エンジニア」を名乗ることに少し抵抗を感じています。うーん、抵抗というよりは、恥ずかしい……ですね。

　同じように、昔は、「SE」というのが恥ずかしく、「えすい」とごまかしてました。(なんじゃそら)「マネージャー」って響き嫌いだし……「リーダー」にもあまりいい印象がない。そんな私が最近ごまかすために使っている呼称が「システム屋」というものです。

■システム屋として……

　「システム屋」として、やってきたこと、考えたこと、習得したいこと、共有したいこと……そんなこんながいろいろあります。少し期間が空きましたが、気持ちを入れ替え、そんなこんなをコラムに、いろんな現場で頑張る「システム屋」さんとコミュニケーションをしていきたいと思います。と、決意表明です。

■システム屋の結婚相手はシステム屋がオススメ！

　最近、コラムニストの「あずKさん(It’s Party Time!)」と「第3バイオリンさん(オブリガート ～感謝されるテストエンジニアになる～)」がご結婚されました。エンジニアライフがきっかけで出会われたということで、おめでたいことです！

　何を隠そう、私の妻も「システム屋」です。しかも、コラムニストです笑。

　うちの夫婦は、もともと同じ会社の同期でした。私は新卒で入った会社にまだ在籍していますが、妻は、Web企業への転身を目的に転職し、数社経験して、今の会社に 至ります。妻の肩書きは「Webサービス会社のプロデューサー」ですが、フロントだけではなくバックのシステムまでが範疇らしく、広い意味で今でも「システム屋」に入ると思います。

　2000年に入社して付き合い始め、2002年9月に結婚しましたので、今年の9月には結婚10年目を迎えます。早いものですね。この10年、いろいろありました。結婚、新婚旅行、単身赴任、妻の転職、親会社の経営危機、単身赴任、妻の転職、私の病気、妻の転職……などなど。

　この10年、心から思うことがあります。それは、「妻よありがとう」と「同じ業界の人間でよかった」ということです。前者はシステム屋に限らずだと思いますが、後者はシステム屋なら思うはずです。

　少し前ですが、こんなまとめページを見ました。

• プログラマの嫁が知るべき97のこと
• IT系技術者を夫に持つ妻が、普通と思っていたけど実は違った32のコト

　これらのページの前提は「夫＝システム屋、妻＝非システム屋」だと思います。そういった場合、奥様が理解されるまでの努力と忍耐は想像を絶するように思えます。恋人同士のときや、新婚の時は、結構もめたのではないでしょうかね。それを乗り越えた結果だと思います。

　ここらへん、特に泣かせますね……。

「今日は飲んできた」という言葉が安心要素。ああ、お酒の飲む時間確保できて良かったねって。

　しかし、これが、「妻もシステム屋」であれば、壁が低くなります。初めから理解できていますからね。大変なのは、「妻＝システム屋、夫＝非システム屋」でしょうね。結構、システム屋さんは男女平等……と聞こえはいいですが、性別に関係なく過酷勤務なケースが多いですが、非システム屋である夫には、「電話が掛かってきて、女性が夜間出勤する」とか「ごめん、トラブルで帰れない」とか理解できないでしょうね。

　ですから、システム屋さんには特に、男女ともに結婚するなら同業者をオススメします！

追伸

　先日、妻がとある勉強会で「タスク管理」についてプレゼンしたのですが、結婚式までの間、ToDoをWBSで管理したって話をしたら、喝采を浴びていました笑。

　……そんなもの、ありません（笑）。

　あ……

　みなさん、そんな冷たい目で、わたしを見ないで……。そして、他のページへいかないで……（切実）。

　開発に携わっておられる方は「品質向上」について、運用に携わっておられる方は「トラブル削減」について。皆さま、興味を持ち、日々やいやい言われているのではないでしょうか？

　わたしはここ数年、会社のタスク活動として自部門の「QCサークル」をリードしています。

　「QCサークル」とは……

同じ職場内で品質管理活動を自主的に行う小グループのことで、全社的品質管理活動の一環として自己啓発、相互啓発を行い、QC手法を活用して職場の管理、改善を継続的に全員参加で行うもの……
(フリー百科事典「Wikipedia：QCサークル」より抜粋)

　Wikipediaには、後ろ向きな説明が続けられていますが、どんなツールであれ、どんなアプローチであれ、万能なものはないと思っています。

　そう、今回のコラムのタイトルにあるように、品質向上やトラブル削減のための「手っとり早い方法」なんて存在しません。

　でも逆に、

1. ポイントを押さえて
2. きちんと
3. 地道に

進めることができたら、効果が出てくるものだと考えています。

◆ポイントを押さえて

　「現状の把握」と「真の原因の追求」をポイントとして抑える必要があります。

　まず、

• 現状はどのような状態なのか？
• なにが？ どのように？ 悪いのか？
• どのような傾向があるのか？

などについて把握する必要があります。

　次に把握した現状について、そこに至った「真の原因」を探る必要があります。

　「真の原因」とは、現状に至った「表面的な原因」にとどまらず、その「表面的な原因」に至った「原因」、またその原因の原因に至った「原因」……と分析した結果、得られるものです。

　例えば、本番稼動しているシステムにおいて、間違ったデータ更新が行われた場合、

　あるプログラムにおける「仕様の実装漏れ」が「直接の原因」であるとすれば、「仕様の実装漏れ」がなぜ防げなかったのか？ 何があれば防げたのか？ と分析し、突き止めることができるのが「真の原因」です。

　例えば、同時並行で進めた案件が多すぎたのが「真の原因」で、結果として「設計者の多忙により設計に漏れた」のである、と判明するでしょう。

　原因は「限定」するのではなく、広く考えて「特定」することが大切です。

◆きちんと

　ポイントを押さえるためにも、実績のあるアプローチ、ツールを使う必要があります。 例えば 「QCストーリー」　 「QC7つ道具」があります。

　課題解決を進めるためのアプローチが「QCストーリー」、ツールが「特性要因図(フィッシュボーン)」などを含む「QC7つ道具」です。

　もちろん、これらには課題があり、使い方の工夫も必要ですが、使うことによってやみくもに自分たちで考えて進むよりは、はるかにきちんと活動が進むでしょう。

◆地道に

　やはり、品質向上、トラブル削減に「王道はなし」だと思います。

　現状を少しでも変えるという思い、当事者意識など地道な発想が本当に重要だと思います。

　わたしの部門では、今年は「自部門の責任による影響障害数 0」を目標に活動を進めています。

　現在、「QCストーリー」でいうと「解析」「対策の立案」付近です。さらに有効な効果が出るように、PDCAサイクルを回したいと考えていますので、上期と下期にわけて、「QCストーリー」を進めようと考えています。

　このコラムでも、途中の状況や、活動を通して気づいたことや考えたこと、学んだことなどを書いてみたいと思います。

　余談ですが、Wikipediaで「QCストーリー」が「カテゴリ：思考」に分類されていたので、そのカテゴリに分類されているページのラインナップを見てみたのですが、かなり面白い！

　QCストーリーやMECEといった「ツール」に属するものから、呪術的思考、フレゴリの錯覚、ミラーニューロンといったアカデミックなもの、そしてジャイアニズムまで何ともいえない「ごった混ぜ感」があり、かなり好奇心をくすぐられます。

(フリー百科事典「Wikipedia：Category思考」)

　（こちらにもどうぞお越しください。ちあきの場所(ありか)　http://nishi3.info/chiaki99/　）

　見積り、ミツモリ……と、見積りを題材に2回コラムを書きました。

　前回は、「概算見積りと、そのレビューに関して、思ったこと、感じたこと、考えたこと、理解したこと、リマインドしたこと、次回に続きます。なんてことを書きましたが……。

　少し、方向を変えて……今回は「時事争論」に初参戦！ 今月のお題「新人／部下の教育」について書きたいと思います。

　わたしの会社では、新入社員には配属されるまでの半年間、マンツーマンでアドバイザーがアサインされます。

　アドバイザーは、研修のサポートだけではなく、社内プロセスのフォロー、生活態度などの相談を受けたり、指導をしたりします。

　また、新入社員には、入社日に1冊のノートが配られ、「業務日誌」を書くことが伝統になっています。新入社員とアドバイザーは、この業務日誌を介して、コミュニケーションを深めます。

　もちろん、口頭でのコミュニケーションも行うのですが、お互いに「書く」「読む」を繰り返すことで、より深いコミュニケーションが進みます。

　わたしの新入社員のときの業務日誌を引っ張りだしてみました。

　4月初めから9月末までで、5冊のノートを消費しました。

　わたしのアドバイザーが熱心だったためもあり、消費量は同期で一番でした（笑）。

　中身をみると、左半分にわたしが書き、右半分にびっしりと赤ペンでアドバイザーがコメントしてくださってます。

　時には、全面真っ赤っかな時もありました。だれの日誌やねーん！ と突っ込みつつ、さすがにやりすきだろうと思う時もありましたが、今読み直してみると、いいことをいっぱい書いてもらっていることがわかります。

　

　入社初日のアドバイザーコメント

メモ帳と筆記用具は常に携帯すること

→メモ魔になること

　入社2日目のアドバイザーコメント

3年後に一人前のSEになろうと目標を持ったなら実現できるように、考え、工夫すること。

まず第一に、一人前のSEとは何か自分の中で答えを出すこと。すぐに出なくてもいいので、常に考え続けること。

日常の中で、いろいろな先輩、同期と一緒になるので、その中で、直接的に、間接的に意見を交換し、自分のSE像を作り上げること。

　うーん。アツイですね～！

　またある日は……

• 報告のタイミング
• いつか時間があったらやろうという発想はやめること
• できるだけ夜型ではなく朝型に切り替えること
• 問題意識を持ち続けること　

　……などなど。

　新入社員としての業務日誌の基本フォーマットは、

1. 研修内容について
2. 理解度について
3. 感想、学んだこと

　です。

　今となっては当たり前のことも、新入社員のわたしにとって新鮮な出来事は多かったことでしょう。そんなこんなが、この業務日誌にまとめられています。

　また、わたしたちの仕事で、ドキュメントを作成する機会は多いです。わかりやすく伝えることの基礎練習にもなったと思っています。

　特に、紙のノートにこだわる理由はありませんので、メールやテキストファイルで代用もできます。ただ、コメントが挿入しやすかったり、印象に残りやすいなど、紙は紙でいい点がありますので、新入社員に業務日誌を書かせるのであれば、わたしは紙のノートをお薦めします。

　新入社員にとってのメリットと、アドバイザーにとってのメリットもあります。

　わたしは、2年目の時と9年目の時に、新入社員のアドバイザーのアサインを受けました。

　わたしのアドバイザーほど、真っ赤かなコメントは書けませんでしたが、業務日誌を通して、自分がそれまでに教わったことを、たくさん伝えることができました。

　書くことはやはり、思考の整理になります。新入社員に伝えているつもりが、自分のリマインド、戒めになっていることのほうが多かったかもしれません。

　この春、新入社員のアドバイザー役になった方には、ぜひ、業務日誌をお薦めします！　

　（こちらにもどうぞお越しください。ちあきの場所(ありか)　http://nishi3.info/chiaki99/　）

　前回に引き続き、概算見積の話です（まだ終わりません笑）。

　しかも、レビュー自体には出席できませんでした。

　アサインされる予定であるメンバーも参加しようとしていたのですが……厳しいことも言いたいからなのか、レビューアーから「説明する人と、同意者以外はけっこうですよ」と。

　おっと、そう来ましたか。

　前日に、関係者で最終の認識合わせをしておいた甲斐がありました。

　寂しそうな目をするPMを会議室に残し、レビュアー、PM、部長、議事録担当する人以外は、レビューが終わるのを待つだけになりました。

　1時間半の予定だったレビューは、2時間ほどかかり、思った以上に、指摘されることが多かったです。そして、お客様に回答するまでには至っていません。 あー、早く楽になりたい！

　救いの点は、わたしがPMではないこと……人任せにしてはなりませんが、少し気が楽なのは否めません。

　まだ終わっていませんが、QAレビューでの指摘、それから思ったこと、感じたこと、考えたこと、理解したこと、リマインドしたことについて整理したいと思います。

0.　QAレビュー

　わたしの会社では（……というわけでもなく、皆さんの会社でも同様だと思いますが……）、案件の各局面で、品質とリスクに関するレビュー　QA（Quality Assurance）レビューが行われます。

　今回であれば、お客様からの概算見積り依頼に対し、概算レベルでの検討結果を「提案書」の形で回答するため、その提案書に対する品質とリスクを判断することになります。

　準備するものは、実際にお客様へお渡しする提案書に加え、その提案書の根拠となる資料が全て必要になります。

　レビューは、ウォークスルー形式で行われ、主な観点は「Verification（整合性検証）」と「Validation（合目的性確認）」になります。

1.　整合性

　一番言われたのは「整合性」です。

　QAレビューの観点に「Verification（整合性検証）がありますので、大切なのは理解しているつもりですが……結構、やいやい、ねちねち、指摘されました。

　今回の概算見積でお客様には、費用を回答するのはもちろん、ご要望に対する対応内容（概要）、スケジュール、その前提事項・制約事項・依頼事項、も回答する必要があります。

　この項目間の整合性、根拠資料との整合性がレビューの対象です。

　整合性は、内容にはとどまらず、用語の一語一語にまで指摘が及びます。

　同じ意味のところは同じ用語を使う、アルファベット表記とカタカナ表記が混同している用語は、「なんでやねん？」と聞かれることになります。

2.　妥当性

　QAレビューのもうひとつの観点である「Validation（合目的性確認）」によるものです。費用の妥当性、スケジュールの妥当性、リスク認識の妥当性……妥当性、だとうせい、ダトウセイ……。

　例えば、費用算出は、必要なH/W、S/Wに加え、W/Lはもちろん、出張費などの経費まで含める必要があります。

　算出するには、お客様から提示のある要件から、必要な機能を定義し、トップダウンで進める一方、作業項目を積み上げる　ボトムアップでも進める必要があります。

　いずれのアプローチでも、最終的に算出される数値に、きちんと根拠があるか？ ロジックが通っているか？ について検証されます。

　また、もちろん、妥当性を検証するには、それぞれの間の整合性が取れていることが前提になります。

　例えば、「開発局面が1カ月、必要なW/Lが5人月なのに、体制図では、開発局面は2名」なんて見積りは、即却下されます。

　概算見積りと、そのレビューに関して、思ったこと、感じたこと、考えたこと、理解したこと、リマインドしたこと、次回に続きます。

　こちらにもどうぞお越しください。ちあきの場所(ありか)　http://nishi3.info/chiaki99/

　わたしは、某金融機関様のシステム保守を担当しています。立場としては、サブリーダーとして位置づけられています。実装、実作業もしますし、プロジェクトのマネジメント、推進も行っています。

　保守とは言っても、稼動済みシステム、アプリケーションに関するエンドユーザー様からの照会対応、トラブル対応、制度変更に応じた対応、新業務開始に応じた対応、提案が実った対応……等があります。

　わたしの会社自体は、1月から新年度が始まっているのですが、お客様は4月から新年度が始まるため、今ちょうど、新年度のシステム投資案件の「概算見積」が佳境を迎えています。

　「概算」とはいえ、お客様へ提出する正式文書であるため、ここで出す数字はこの後ついて回る数字になるので、気を抜くことはできません。

　お客様サイドでは、さまざまなシステムの「概算」を集計し、新年度予算の総額と照らし合わせながら、新年度のシステム投資案件を絞られます。

　平たい言葉で言うと、後にやってくる「正式見積もり」では、よほどのことがない限り、「概算」を超えた数字を出すことは難しくなります。

　もちろん、決まっていないこともありますし、詳細が不明な要件もありますので、前提・制約を置いて算出することになります。ユーザー様などにヒアリングし、できる限り有効性のある前提・制約を明示するのですが、ユーザー様にとっては「概算」という意識があるため、なかなか要件定義局面のように詳しいお話にまで踏み入ることができない場合が多いです。

　できることなら、案件を、要件定義とそれ以降の局面でわけ、まずは要件定義のみしっかり行い、この間のコストは、投入した人数＊期間で頂き、それを基に算出した以降の局面の工数を「見積」として提示するほうが、案件に関わる人の幸せにつながるのではないかな？ と感じます。

　とはいえ、現実的に、プロセスとしてそうなっていないわけですから、工夫が必要になります。

　概算見積をお客様に提示する前にも、QA（QualityAssurance）評価を受ける必要があるのですが、小規模の案件では部長レビューで済んだり、大・中規模の案件、複雑な案件、新製品を使う案件……等は、QA担当のレビューを受けます。

　わたしは、これまで、今担当させていただいているお客様以外にも、大きな案件に関わることはありましたが、ただ担当者として関わることが多かったため、見積を算出することはあっても、それを取りまとめ、QAを意識する機会は少なかったです。

　今、概算見積をしている案件は、中規模でなかなかQAレビューが通らず、困っています……。

　さまざまな指摘があります、正直「そんな細かいことまで……概算やん……」と思うものもあります。

　しかし、上流工程の「ぶれ」は、下流工程では「大きなぶれ、大きなコスト」として跳ね返ってきますので、概算見積時点でつじつまの合わないことは、案件開始後には、「大きなぶれ、大きなコスト」として跳ね返ってきます。

　「概算」だけど、得られる情報の範囲で「詳細に」「きちんとしたロジックで」が必要だと思っています。

　QAレビューでの指摘、それから思ったこと、感じたこと、考えたこと、理解したこと、それらを次回から整理してみたいと思います。

　こちらにもどうぞお越しください。ちあきの場所(ありか)　http://nishi3.info/chiaki99/