設計とデバッグの相関関係
スケジュールが遅延するプロジェクトとゆうのは、往々にしてテストフェーズがなかなか納まらなく、バグが収束しないために、リリースが後ろにずるずると延びてしまうことが原因であることが多い。ソフトウェアには、バグは必ず存在する。だが、許容範囲以上のバグは、バグがバグを呼びバグの修正が、またバグを呼ぶとゆう最悪のループにはまり込んでしまう。テストフェーズは、全体工程の１／２を占めるといわれているが、このようなトラブルを抱えたプロジェクトは、それ以上にテストフェーズが占める割合が、高くなる。では、なにがテストフェーズを、こんなにも混乱させる要因になっているのだろうか。
テストフェーズを賑わす原因は、やはり、仕様策定・設計工程に起因する。バグを許容範囲内に収めるには、コンセプトの統一性を意識した、仕様策定を行うことである。コンセプトが明確であると、リーダーのビジョンと相まって、進むべき方向性が明確になる。なにか、曖昧な仕様が存在したときには、おのずと、コンセプトに則った方向性に、仕様が落ち着く。また、テストを行う際にも、際どいバグが存在した場合、コンセプトに照らし合わせて、検証が可能となる。このように、コンセプトの統一性が、プロジェクトに与える影響は、非常に大きい。
さらに重要なのは、設計工程の完成度である。「どうせ、バグは出るんだから、適当に設計をして、細かいところはテストフェーズで直せばよい」、などと思っている設計者がいるとしたら、論外である。上記したように、許容範囲以上のバグは、収束のつかないループを生んでしまう。テストフェーズが、予想以上に多くの時間がかかる理由として、デ
バッグ作業が、困難なことにある。デバッグ作業は、問題の表面的な現象から、本質的なロジックの問題を解明する作業である。この作業は、高いスキルを必要とし、複雑な問題であれば、数週間や１ヶ月かかってしまうこともある。デバッグは、進捗度を予想できないため、スケジュールを立てにくい。このため、テストフェーズは、のびのびになってし
まうのだ。そのような、問題の根本であるデバッグ作業を減らすためには、おのずと、バグを減らすことになる。バグを減らすためには、完璧な一貫性のある設計を、心がけるべきである。特に、サブシステム間でのインターフェースや、シーケンスなど影響範囲が大きく、複雑な処理は、問題が起きた場合の解析作業や、手戻り作業が非常に大きいため、念入りに行う必要がある。
スケジュールを焦るあまり、設計を疎かにして製造工程に入るのではなく、「急がば回れ」の精神で、スケジュールが厳しいからこそ、さらに念入りに設計を行い、下流工程での組込みを抑え、大半の期間を要するテストフェーズを圧縮することこそ、最短リリースへの近道である。
vol.42
最近はモデルベースの設計がずいぶん浸透してきました。一部では設計からテストまでの全工程に適用した（ソースファイルをいじらない）開発プロセスを確立したところもあると聞きます。
モデルベース設計の利点はなんと言っても可視化できて記述を標準化できることです。ソースコードは人それぞれ。文章のようなものです。それを図式化することによってデバッグの速度も速くなるしそれを前工程（フロントローディング）で行うことで上記の問題が少しは改善されるでしょう。ですがモデルベースを開発全般で行うには自動コード生成においてＨＷ、プラットフォームとの対応をどうとっていくかが今後の課題でしょう。そろそろソフト開発も変えて行かなければならないですね。
蕃山
蕃山は仙台近郊にある「蕃山」「西風蕃山」「蛇台蕃山」の三つの峰からなる里山です。古い言い伝えなどもあり歴史のある山です。ふつうは大梅寺から登るのが普通ですがここではマイナーな白瀧不動尊側から登った記録です。
■登山口
白瀧不動尊は錦ヶ丘の１丁目と２丁目の間にある雨水用水路沿いに上っていくと小さな祠があります。登山口はそこから少し先にある橋とその先の下りの石階段が目印になります（表示は何もありません）
■白瀧不動
階段を下りていくとうっそうとした森の中に小さな滝が見えてきます。その小さな滝に不動尊が祭られています。左手の道なき川上を登っていくとかなり急な上りが延々とつづきます。ロープが付いているので雨の後でもなんとか登れますが大人でもかなりしんどいです。途中急斜面にブナや杉、赤松の巨木を多く見ることが出来るのでそれがせめてもの骨休めになります。環境の影響なのか立ち枯れしている木が目立ちました。20分ほど登ると「白瀧不動」の看板がある分岐点にたどりつきます。
■菅ヶ崎分岐
最初の分岐路を左に5分ほど進むと立ち枯れの巨木が目印の「菅ヶ崎山」と「白瀧不動」と書かれた分岐点にたどりつきます。基本は蕃山側から来る人向けの表示になっていますので表示の無い方の道を進みます。
■巨木の原生林
さらに進んでいくとブナや杉の巨木が目に付くようになってきて倒木などが多くなり原生林の風景になっていきます（蕃山のなかではここが一番のおすすめです）。巨木が生い茂る広場のようなところをさらに進むと「←蛇台蕃山」と書かれた看板があります。ここを過ぎるとめっきり巨木はみられなくなります。
■無線中継所
蛇台蕃山分岐点を右の方向に進みます。少し進むと無線中継所が木の隙間から見えてきます。ここでも菅ヶ崎山との分岐がありますが西風蕃山のほうに進みます。ここから先は栗生などの登山口に降りる分岐があるだけでひたすらまっすぐ進みます。途中異様な音のする送電線の下をくぐり（ここからの眺めもいいです）、結構なアップダウンを経て蕃山山頂の開山堂に到着します。登山口から大人の足で約１時間くらいかかりました。朝はこのあたりをジョギングする人もいるとか・・
■蕃山山頂
山頂からは人来田や長町(だと思う)のほうがよく見えました。開山堂の扉は開けることが出来て、中には木像が三体（雲居禅師・蕃二郎・蕃三郎）あります。雲居禅師は江戸時代に日本に数人しかいない国師になられたお偉いお坊さんだそうです。ちなみに蕃二・蕃三郎とは山に住む猟師のようなひとたちのことをそう総称したのだそうです。
■菅ヶ崎山
ちなみに、一つ目の菅ヶ崎山分岐を左に行くと10分ほどで菅ヶ崎山頂に着きます。ちょうど送電線のところになります。途中の道はなだらかな雑木道で快適です。山頂からの眺めはよくて蔵王連峰がよく見えます。その先を進むと茂庭にまでつながっています。
白瀧不動尊側は原生林ものこっていて仙台の近郊とは決して思えない雰囲気を味わえますので一度来てみることをお勧めします。
コミュニケーションについて考える
コミュニケーションは、プロジェクトにおいて見落としがちな作業である。コミュニケーションとは、具体的に、どのような作業なのであろうか。コミュニケーションとは、チーム内に発生する、情報の共有のための話し合いである。それは、打合せのような公的な場であるかもしれないし、ふとした疑問でメンバーに相談に行く個人的なケースなども考えられる。それ以外にも、趣味などのプライベートな情報や天気などの井戸端的な会話などもある。コミュニケーションの無いチームは、得てして情報共有が出来ていないケースが多く設計に多くのミスが見られることが多い。
vol.41
コミュニケーションは最近の企業が採用する際に筆頭にあげている能力(?)です。
辞書でコミュニケーションをひくと「意思や感情、思考を伝達し合うこと」とあります。情報の伝達だけでなく意見の交換なども含まれるってことです。もっと言えば世間話をしながら「今日なんか疲れてるね？？」なんて感じるのも立派なコミュニケーションなんです。
チーム規模について
ひとつの作業単位のチーム（ワークパッケージ・レベル）は、出来るだけ大きくないほうがよい。それはチーム内でのコミュニケーションが多くなり、情報収集が困難になってしまうからである。そうならないために、作業単位のチームで閉じ、チーム間のコミュニケーションを持つことにより、コミュニケーション経路を減らす意味合いがある。また、リーダーが、直接メンバーの状況を把握できる人数が１０名ぐらいと考える。リーダーは、現場の空気を感じながら臨機応変に対応できなければ、よりよいプロジェクト管理は出来ない。その限界となるのが個人差はあれどそのくらいの人数であろう。機能を作業単位に分離し、各チームの影響を極力切り離すことにより、チームごとの、自発的な行動を可能とし、リーダーの管轄の下、情報を共有しあい、サポートしあえるチームを構成できるのだと考える。
vol.40
チームを多くしてしまうとその分優秀なサブリーダーが必要となり、そのリーダー群のなかでも同様にコミュニケーションロスが発生した場合、その影響はチーム内のコミュニケーションロスに比べて大きなものになります。チームの規模はリーダー人材の頭数や各チーム間に関連度などを見ながら慎重に決めるべきでしょう。
人日計算の危険性
作業量を見積もる場合、ソフトウェアでは、ソフトウェア規模から工数に換算した値を用いることが多い。ソフトウェア規模は、Step 数や、Function Point など、いろいろな測定方法があるが、それらは、専門の書籍を確認いただきたい。ここで述べたいのは、工数＝人日or 人月を用いて算出することの難しさである。この工数の値は、要員計画に用いられることになるが、そのままの値では、実質的な値ではないと考える。人がチームを組とゆうことは、おのずとコミュニケーションが生まれる。コミュニケーションは、人数が多くなれば多くなるほど、そのコミュニケーションの経路が増えることは、下記の図から理解してもらえると思う。
要するに、少人数のチームであればコミュニケーションに要する影響は少ないが、大きなチームになればなるほど、コミュニケーションに要する時間の影響度は、見捨てて置けなくなる。それを、そのまま、作業量を一人当たりの作業量で割ることにより、工数を算出してしまうと、大きく作業量の差分が生じることになる。大規模プロジェクトになると、進捗遅れが生じるのは、作業工数の見積もりに、このような問題があるからと考えられる。このことを考慮し、適切な工数の見積もりを行うべきである。
また、ソフトウェア規模による点も見逃せない。ソフトウェアは、近年さらに肥大化し、現在では、考えられないくらいのサイズにまで拡張してきている。規模が増大するとゆうことは、機能が増え、機能の内容が複雑化してくる。このことは、単にステップ数が、倍加するだけではなく、複雑な関係が多く発生し、難易度も高くなり、検証作業にも多くの時間を要するようになる。要するに、ソフトウェア規模が増えるとゆうことは、指数倍的に作業量・工数が増加していくことに、注意しなければならない。このことを考慮せず、過去の実績から算出すると、大きな間違いを犯すことになる。
上記のことから、ソフトウェアの巨大化、チームの巨大化は、プロジェクト運営の弊害になる。よりシンプルに、効率的な分割を行った少数精鋭のチームで、開発できるようなスケジュールの確保が、よりよい製品を作るうえで必要となるであろう。
vol.39
チームが大きくなってくるとおのずと出てくるのが「そんなの聞いてないよ！」という情報の共有の問題です。人はチームで活動することにより連帯感が生まれ責任感を持つようになって人数以上のパワーを発揮しますが、大所帯になると先のようなマイナス面が出てきます。これらの問題はプロジェクトマネジメントのコミュニケーションマネジメントで扱うものですが、それ以前に最適なチームサイズは大事だと思います。
プロジェクトの失敗要因
「スケジュールに、時間的余裕の無いことが原因で、うまくいかなかったソフトウェアプロジェクトは、それ以外の原因で、失敗したプロジェクト全部を合わせたものよりも多い」、とゆう現状が物語るように、タイムマネジメントスケジューリング）の重要性は、疑いの無いものである。だが、このことに気づいていながら、誰も真剣に取り組まない。その結果、スケジュールの遅延が生じ、結局毎回、同じ道を歩む。この原因となるのは、次に説明する、見積もりの不透明さからくる、自信の無さが、上層部や営業からの戦略的なスケジュールの圧力に負けてしまい、プロジェクトチームを不当な状況に追いやってしまっていることにある。
前に記述したように、途中からの体制変更は、スケジュールの延長を認めたようなものであり、スケジュールの遅延から立ち直るすべは、無いと考えたほうがよい。だが、ほとんどのリーダーは、状況に応じて補強をすればよいと考えている。それでは、最初から、スケジュールの遅延を、容認しているようなものである。このことの、大きな間違いを認識し、リスクを考慮した、余裕のあるスケジュール（その時は余裕があるが、実際にはよい感じにはまることが多い）は、プロジェクトを最短で終了させるための、必須条件であることを強く心に刻んで、ステークホルダーに対して説明するべきである。
vol.38
毎年経済産業省が発行している2008年度の組込みソフトウェア産業実態調査
（プロジェクト責任者）によると、「プロジェクトの結果」について「機能」「品質」については８割もの人が「計画通り」もしくは「計画より良い」と応えているのに対し、「費用」「期間」に関しては４割に留まる結果が出ています。プロジェクト評価の詳細を見てみても「開発期間」が一番悪く、約８割が「やや不足」「大幅に不足」となっています。
最短のスケジュール目標に向けて現状の開発は邁進しているわけですが、最終的には諸々の理由で開発が遅延している状況が上記のデータからも出ています。今週まで、来週まで、、とめども無く締め切りが設定されるわけですが、それによって起こる技術的、人為的影響は計り知れないものがあります。コンティジェンシー計画（リスク要因）を含んだスケジュールで余裕があれば品質の向上や機能強化などのプラス思考の開発にしたいものです。早い分には誰も文句言わないわけですから・・
Windows Embedded CE6.0
Windows Embedded CE6.0の開発ツールパッケージにVisual Studio 2005 Proが同梱されていることは意外に知られていないようです（危うく二つ買う人もいるかもしれません）
開発パッケージに含まれるものとしては
- Windows Embedded CE6.0(Platform Builder)
- Windows Embedded CE6.0 R2
- Visual Studio 2005 Professional Edition
- Intel Framework 2.0 SDK
- MSDN Library
- SQL Server 2005
価格も$995でこれだけついてきます。VS2005とたいして変わりません。
最近はVS2005もなかなか手に入らないようなので訳ありでお探しの人はCE6.0を購入するのも手かと思います。
ついでにCEの開発もはじめてもらえるとうれしいのですが・・
