テレワーク 〈コミュニケーション/コラボレーション〉

残念ながら新型コロナウィルス感染まだ落ち着きませんね。2月から3月にかけて気温は上昇しましたが関連性は薄いようでした。感染予防の在宅、テレワークという働き方が広がりつつあり、これを契機に仕事上のコミュニケーション、コラボレーションのあり方も変わっていきそうです。

都内の最新感染動向 （東京都の新型コロナウィルス感染症対策サイト）によると 3/26の

検査陽性者数は50人前後です。普通の風邪症状で終わってしまう人は検査にかからないので東京都トータルでの感染者数、感染率はわかりません。検査は2182人に行われており陽性率は12% 、 8人に1人です（8人に7人は予防的検査か、症状はあるものの別のウィルス・細菌感染の可能性）。検査陽性者の状況をみると累計259人中、死亡5人となっており死亡率は 約 2% となるのですが、そもそも市中肺炎で入院した場合の死亡率は 9% 前後と高いものです。肺炎は日本の死因の第4位で年間約12万人が肺炎で死亡します（東京都健康安全研究センター年報 69巻 ）。重症者15人＋死亡者5人との割合で、死亡率は  5 / (15+5) = 25% ですが、重症の市中肺炎の死亡率が 22% 前後なので特別な数字でありません（市中肺炎患者死亡率ー全日本民医連）。感染率、重症化率が謎のまま不安が広がっています。肺炎について高齢者と喫煙者は要注意ということで、これは新型コロナに限りません。私は幸い気管支炎までで済みましたが、かって子供にとって肺炎は死の病でした。

今回の新型コロナは試練ですが、救いは乳児・小児の症例が少ないことです。もしもインフルエンザのようにも乳児・小児にも重症例をもたらすものであったら、騒ぎは想像を絶するものであったと思います。世間の騒ぎの割には医療現場は静かなもので、この時期にしては内科・小児科の患者さんが非常に少ないのです。インフルエンザの早期終息により日本全体で今シーズン500人以上の命が救われました（前回の投稿）。全国的な予防衛生対策の副次的な成果として小児疾患の川崎病と赤ちゃんに影響を及ぼす風疹が減少することを願っています。

人口1400万人の東京で新型コロナ肺炎の死亡者は現時点で5人です。これを、常態化している通勤過密等から既に高いレベルにあった衛生マナーが一層高められた結果と考えることは楽観的過ぎるでしょうか。あと１ヶ月が勝負のようです。過労厳禁、人混みでは口を閉じていましょう。あと手洗いを忘れずに。接触感染防止に手袋を。

話は変わりますが、テレワークご多分に漏れず私も経験しました。通勤および職場での新型コロナ感染予防を目的としたものですが、通勤がなくなった途端、仕事場として会社は副で、自宅が主という感覚になります。不便を感じつつもこれはこれでいけるとなると、この流れ元に戻せないかもしれません。

不便というのはコミュニケーションです。テレワークは仕事のコミュニケーション、コラボレーションのスタイルを疎結合スタイルに変えますね。いくらツールを使っても同じ職場で近い距離に同僚がいることと同じにはなりませんし、あえて同じようにしなくても良いかと思いました。メリットとデメリットを踏まえスタイルを変えていけば良いと思います。

（テレワークが成立する前提）

・職務能力を持ち社会で自律している人

・人に頼らずこなすことができるタスク

（メリット）

・人の目や雑音、つきあいたくもない雑談もない。人間関係のストレスが減る。

　チャットができるといっても仕事ですからハードルができます。リアルタイムに応じる必要もありません。

・休憩やちょっとした家事をはさむみことで仕事に対する集中力が回復する。

　集中とリラックス、頭を使うことと体を使うことを織り交ぜるのが集中力持続のポイントだといわれます。結果的にテレワークはバランスのとれた時間の使い方ができます。

　個人中心、他人は他人という感じです。

（デメリット）

・自律できないと無為に時間が過ぎるだけになる（人の目がないのでさぼりやすい）

　他人依存的な人には不向きです。

・ライバルや手本となる人を見ることが出来ない。組織ならではの成長圧力がない

　先輩が様子をみて助けることができません。指導には限界があります。
　自律前提＝他律不向きです。またチーム一体で瞬発力発揮も難しいかもしれません。

仕事にもよると思いますが、ITプロジェクトでテレワーク、疎結合型組織で働けるようにようになるのは30代からでしょうか。社会人としてある程度成熟し、専門能力をもち、それを裏付ける経験を語れるレベルでないと難しいと感じました。新型コロナ対策を契機に過密社会の是正に加えて、自律した個人が能力を発揮しやすい世界、他律組織から自律組織への変化が進めばと思います。ティール組織というのでしたっけ？

永島志津夫

失敗できないプロジェクト 〈急所〉

プロジェクトの “急所” 、一つ挙げるとしたらどこでしょうか？　プロジェクト計画、要件定義、設計、開発、テスト

どれも大切ですが、問題が表に出てくるのは “テスト” ですよね。結合テスト、システムテストでこんな問題が起きることがあります。

１．テストに入れない（プログラム がない！、ファイル、テーブル がない）

２．テストに入れない（テスト仕様書がない！）

３．テストに入れない（環境がない！、時間枠がない）

１番目のケース、まさかそんな！と思われますよね。でも開発の遅れで一部プログラムが揃っていないということは経験があると思います。影響のないところからテストをはじめます。またテストを始めた途端、仕様の取り違えが判明しテストにならない、ということもあるでしょう。結合テスト段階で単体テストのバグが出るというケースです。そもそも取りこぼしでプログラムを作っていなかった、リリース期日の間違え、もあるでしょう。

規模が大きくなる程、この手の初歩的なミスが増えます。

プログラムができるまでは、ドキュメントベースで確認するしかありません。要件定義書、設計書など何百ページもあるドキュメントを目検していく訳なので、ベテランであっても一定割合で、ある、なしレベルのミスが発生します。

発生割合ですが、さすがに全体の10%ということはありませんが、0.1%ということもありません。感覚的に１%はありますね。２%前後はあってもおかしくないと考えておくのが相場です。

結合テストからシステムテストと進むにつれ、ある、なし レベルのミスは全体の足を引っ張ります。影響のおよぶ範囲のテストを止めてしまいます。ミスは避けられません。早い段階で露見させるのが賢い対策です。PM（プロジェクトマネージャ）、PMOの真価は課題対策にあります。

“仮組み”

そこで開発中であっても、週の最後に、出来ている分だけ、ある分だけのプログラムを集め、中途半端なデータベースにつないでしまうのですね。私はよくやりました。ポイントは集めるにあります。

ビルドエラーも出ます。マスターのコード定義もありません。初めは動きません。それでも無いものが分かるので

「来週これは作る予定だよね？」

と確認できます。そこでドキッとします。

「忘れるところでした（本当は、忘れていました）」

というふうに。

アジャイルだと、頻繁にビルドをしているので、ある、なしレベルのミスは防止できますね。限られた時間と集中力を設計開発に回せるのは利点です。

“仮組み” はウォータフォール開発や基幹系システムでもおすすめです。「忘れている」というと、担当者に対する落ち度の指摘です。指摘された方は気分のいいものではありません。指摘する側も、言いたくて言っている訳ではありません（言いづらいです）。人間同士お互いの負の感情はコミュニケーションを阻害します。できれば避けたいものです。

 “仮組み” は「ある」「なし」を見えるようにしています。担当者が「忘れていた」ことに違いはありませんが、指摘は、仮組み環境を経由した間接的なものになります。同じことでも人から直接指摘された時のような負の感情は生じないか弱いものになります。

「見える化」とか「可視化」は問題発見の効率化と合わせて、担当者の前向きな行動や、グループのコミュニケーションを維持する効用があるのではないでしょうか。

“仮組み” 試してみてはいかがでしょうか。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その４ 〈議事録 テンプレート〉

失敗しない要件定義その４ は 議事録のテンプレート、書式です。ワードとPDFファイル版をアップしておきます。

シンプルですが、構成と大事なポイントは私がフューチャーアーキテクトにいた頃から20年以上変わっていないのでご安心を。

こちらです。議事録（MSワード、PDF）研修も以前ご紹介しました

あまりにシンプルなのでガッカリされたでしょうか？でも、シンプルなほうが書きやすいです。この書式を見ながら、要件検討会の運営も含め大事なことを列挙していきます（検討会は毎週開かれる前提とします）。

要件検討会で一番大事なことは重要な論点を効率良く、徹底的に議論、検討することです。システム設計プロジェクトの最初の段階、要件定義では検討結果、検討状況の確認ツールとして議事録があります。従って議事録の内容、品質、デリバリータイムが重要です。その分、体裁など他のことは端折ります。検討資料と議事録がしっかりしていれば要件定義書はできたも同然です。

失敗しない要件定義のポイント

• 要件定義フェーズのプロジェクト設計（仮説、重要論点出し、推進体制作り、検討会スケジュールの事前調整など）
• 検討会での意思疎通、コミュニケーション
• 検討資料と議事録作り（ドキュメンテーション）

1. 検討会の論点は２週前からアナウンスしておく。業務部門内での検討に２週かかるのが相場。その上で必要な資料準備や予習をしてきてもらう。１週前の検討会では進み具合を確認する。
2. 検討会の１週前には議論の材料となる資料を用意し、問題がないか予習してきてもらう（検討会資料、業務フロー、データ定義、画面構成・遷移図など）。
3. 検討会はスケジュール表で今日の位置付け、論点や、前回の振り返り、宿題状況の確認から入る。1週ぶりなので参加者の準備ができないと、いい議論に入れない。
4. 検討会では議論となる論点が絞られているので、各部門の立場で、大胆に見直す案、現状との親和性を維持する案、その間の妥協案、その案をとった場合の盲点などをじっくり議論できる。ただし積み残し、宿題が出るので２週など期限を設けてもちかえってもらう。重要な論点を要件定義前半にカバーしておく。それでも時間がきつくなることがあるので、毎回検討会スケジュールを見ながら善後策を考えていく（検討会スケジュールには問題がなかったことを納得してもらいながら）。
5. 検討会では議論の中で別の論点に言及することがあるが、議事録は論点別に再構成し、箇条書き形式とする。言葉を補い要件定義書のインプットになるレベルに仕立てる。確認が必要な言葉にはアンダーラインを引くか、目立つ記号★★を付けるなどして、参加者に議事確認をしてもらう。誰が言ったかよりも、ドキュメントが優先される。曖昧さ、考慮漏れを排除していく(MECEという言葉があったりします)。
6. 概ね時間順になるが、それにとらわれず構成の分かりやすさを重視する（論点の階層、議論の粒度など）。
7. 発言者の記載は必要に応じて。質問－回答は一文にまとめて構わない。細かい発言、同じ内容はカットする。本線に関わらないが記録に残したいものは、「その他」として最後にまとめておく。
8. 決定事項、未決宿題の確認を検討会の最後に行っておく。時間切れの場合、メールでの議事確認を必ず伝えておく。
9. 議事は必ずレビュワーがチェックする。書き始める前に重要ポイントをおさらい、確認しておくと早く正確に作ることが出来る。
10. 議事送付は当日か翌日までに行う。

ヘビーですよね。要件検討会２時間やるとヘトヘトなります。１日３コマやるとやせます。でも、要件定義しっかりしていれば、その後がうまくいきますからね。頑張りがいがあります。何事も備えあれば憂いなし、先手先手です。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その２ 〈コミュニケーション〉

コミュニケーションについてのエピソードをご紹介します。

あるお客様から課題要望事項をまとめた一覧表がEメールで届きました。課題と思われること、課題ではないが実現できればなお良いと思われる要望があれば、ご連絡くださいと、前回の打ち合わせで私がお話したことを受けて送っていただいたものです。 

ただ一覧表を見ると担当のスタッフは驚いてしまいました。そこにはとてもご契約期間内（1ヶ月）で完了できないほど多くの事項、初めて聞く内容などがあったからです。これを一つ一つ実使用に耐える品質で実現することなど到底できません。担当者は途方に暮れかけていました。少し時間をおいてから私もそのメールと課題要望事項の一覧表を確認しました。 “まずは電話で課題要望事項として挙げた背景、理由であるとか、是非とも必要なことなのか、きいてみてはどうだろう？” と担当スタッフに話しました。幸いすぐ電話で連絡がつきました。30分程お話した内容は以下のようなものでした。  

“社内から色々と要望、課題が出てきており、その量を認識、把握する意味合いもあり一旦全て表にまとめた。要望として挙げているものも、すぐ実現が必要という認識ではなく、これから数ヶ月の中での改善を考えていく上での検討材料という位置付けである。もちろん要望を実現できるに越したことはないが、なかには相矛盾する要件も存在している。要するに、表に挙げたような要望は現在もあるし今後も出てくるであろう、そのような状況にあることをまず共有、理解してもらいたかった。”  

また、課題とされているものも一つ一つに対応するというよりは、業務に与える影響、代替手段（人手で回避、工夫できないか）、そもそも課題として挙げていることの理由、妥当性などの検討を一緒にしたい。それから現実対応できるものを絞り込んで、順次対応していくプランを作ることができたら、と考えられていることが理解できました。 

いかがでしょうか？電話でのコミュニケーション。リアルタイム、インタラクティブですから効率がいいですね。テキストよりもはるかに情報量が多い分、相互理解に有利ですし、お互いの時間を共有したこと自体が価値になります。逆に、お客様から時間をとるに値しないと思われたら要件定義失敗です。電話が苦手なスタッフが増えていると聞きます。ボイスコミュニケーション、もっと活用して欲しいと思います。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その１

IT / システム部門の方とお話をするのですが、苦労が絶えないのは相変わらず要件定義のようです。開発になるとパソコンに向かうことが多くなるので技術者という感じですが、要件定義は対人業務です。ストレス解消法も良く話題になります・・

要件定義には、コミュニケーション能力とドキュメンテーション能力（とストレス耐性）が求められます。業務要件を言われた通りに丸写しすればいいというものではなく、システム化、シンプル化のインタラクティブな現場対応が必要です。コンピュータは賢くありません。だからといって闇雲に要望を切り捨てたら使えないシステムになります。実現性、工数などを勘案して、賢くないコンピュータを不便でない程度にブラッシュアップして、費用対効果に見合うようにするのですが、実は要件定義で大方結果が出てしまいます。*

設計フェーズで見直すという考え方もあるのですが、予算が決まっている以上、要件を膨らます訳にはいかないのです。要件精査でもたついたら設計フェーズの時間が削られてしまいますし、そもそも忙しい業務の合間をぬって検討会に参加してもらった業務部門のキーメンバーとの関係にひびが入るなど、デメリットばかりです。

すべては無理にしても要件検討会のその場その場で問題処理をしてしまわないと時間切れになります。データもあいまいでは困るので定義を明らかにしていきます。データ間の依存関係、上下関係も大事です。幹をクリアにしないと例外要件なんかまず出てきません。

プロジェクトは要件定義開始2週間が勝負です。最初の2週間でセッションをリードできれば要件定義をスケジュール通りに進めることが出来ます。失敗するプロジェクトは、要件定義が終わっていないのに時間切れで次のフェーズに進めている場合が多いです。設計フェーズで吸収しよう、ということですが、設計フェーズの方が投入工数は増えるので進捗の遅れのインパクトが大きくなります（工事進行基準廃止！）。要件定義が終了しているモジュールから五月雨式に設計に入ろう、としますが、データモデルを共有している以上、影響が伝播します。結局、設計修正、手戻りが発生し二重コストになります。データモデルが確立していない段階でのアジャイル開発が失敗するのはこの点にあります。MVC ( Model, View, Controler ) のModelについてはウォータフォールに利があります。データモデルを精査するためにはユースケース（システム利用、操作仕様）の理解が必要で、業務シーンではその重要なインプットの一つに業務フロー（業務フロー）があります。

業務フロー図にやり取りされるデータは定義されているでしょうか？失敗しない要件定義の分かりやすい Howto を一つアドバイスさせて頂くとしたら、

業務フロー上のデータを精査

することです。あまりうるさく言われていないようですが、成功のカギの一つです。
大変かもしれませんが、必ず報われる苦労ですので。是非一度レビューしてみて下さい。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

* 顧客サービスですから、ここをうまくお話ししないと仕事が終わってしまいます。状況をフェアに説明し理解を得て、妥協点に落ち着かせる交渉事でもあります。

失敗できないプロジェクト 〈成功の秘訣〉

システムプロジェクト成功のポイントは要件定義にあります。では要件定義の成功のポイントは？　プロジェクト開始前の事前ヒアリングです。規模の大小、期間の長短問わず、1,2回の事前ヒアリングの有無が、プロジェクトの運命を決めます。全体の費用対効果、QCDを大きく左右します。

“ 事前ヒアリング ” 、うちでもやっているよ、と思われるでしょう。それがプロジェクト成功のポイントになるのか？

事前ヒアリングの断片的な情報から、必要とされるもの・ことを具体的に想像して、仮説レベルの全体像をイメージ。要件定義の限られた時間で、検討すべき課題を具体化し、キーメンバーのアサインを決める。

これが、事前ヒアリングからのアウトプットです。

要件定義の重要検討テーマ、セッション・スケジュール、そして仮説レベルですがシステムの全体像、おおまかなデータモデルまでイメージします。要件定義はその仮説検証となります。一般的には要件定義フェーズの計画書ですが、この段階で高い品質を目指し、ゴールに近づいています。

成功しますよね。だから事前ヒアリングが重要です。仮説作りです。

プロジェクトリーダには業務知識、システム設計経験もですが、コミュニケーション能力、ドキュメンテーション能力が重要です。仮説作りは、インプットからロジカルにアウトプットするという思考法ではありません。課題解決型の非日常的な思考法です。プロジェクトの初期段階はお客様、ベンダー共にお互いのことが分かっていない、情報不足した状態ですから、仮説作りの思考法が効果的です。

事前ヒアリングもう一つの利点はベンダーの実力が、早い段階でお客様にはっきり分かることです。不幸にも実力のないベンダーを選んでしまったら、お客様側がそれに合わせるしかありません。
初めて要件定義をするリーダーがアサインされているかもしれません。業界、業務知識ゼロかもしれません。お金を払っているのはお客様。でも、ほとんどお客様がベンダーに仕事を教えて、チグハグなドキュメントをもらって、真っ赤になるほど赤入れをしているかもしれません（アジャイルとかスプリントがどうとか言って、ドキュメントを出さないベンダーもいるかもしれません）。事情はともかく、あいみつ（相見積もり）なり、コンペなりをして、事情了解の上で、契約、注文書を発行してしまったのですから、元には戻れません。

泣くのはお客様側、特に業務の現場のみなさんです。こうならないように、事前ヒアリングでベンダーの実力をみてください。コミュニケーション能力、ドキュメンテーション能力も伺い知ることができるでしょう。人柄、第一印象も重要です。そういう相談の仕方、提案依頼をしてみてください。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。

オフィスエヌ ショートレビュー5万円から。

連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）