2C 分科会セッション「開発プロセスの評価と改善
　　　　　　　　　　 〜 組込みシステムの開発プロセスを明確にしよう 〜」

　参加者数は、ほぼ40人。全体の1/3であった。
　それぞれの会社の実例の紹介を通した議論がメインとなった。
　非常に意味の広い題であったため、今回は、テーマ選び自体がテーマになって
いた感もある。大きく分類すると、
　　・best practiceと成熟度モデル
　　・CMM
　　・プロジェクトマネージメント
　　・ソースコードレビューを通して考えるマネージメントのありかた
　　・人材の適材適所への配置、管理、生産性
といったところが話題となったように思われる。以下、それぞれについて
の意見を列挙する。

(best practiceと成熟度モデル)
・近年組込みシステムの設計/開発は規模が大きくなり複雑化(形態)してきている。そのため、
　どのようにプロジェクトを管理すればよいのかという問題がある。その解決法として、
　best practice を体系化することが上げられる。そこで組込み開発におけるbest practice
　とはなにかという問題がある。
・成熟度モデルについては、メインフレームの世界では成功、現場でやられていること体系化
　した、アメリカより良いものが出来ている。
　組込みシステムの規模が大きくなってきた(携帯)、組込みシステムのbest practiceを体系化
　して昔の成熟度モデルとマッピングして組込み開発に適用しようとする議論がなされている。
　そこで、組込みシステムの開発のbest practiceについて意見を聞きたい
・OSについては、MULTIXに失敗におけるUNIXがあるがLinuxはオープンソースで
　情報の共有化が旨く行っている。成熟度モデルと同じく構成管理がうまく行われる。
・メインフレームのOSと組込みOSは規模が異なるのでそのまま使えるか疑問がある。
・ISO/IEC15504(成熟度モデルの標準化)
　ソフトウェアライフサイクルプロセスに関する技術文書
　大きなシステムを対象、ピンボック(プロジェクトのマネージメント方法) + ISO9000
　(品質管理)のような形になっている。 
・IEC15504をそのまま持ち込んでも、大規模システム用であるため、組込み開発
　に対して嬉しくない。
　そこで、組込み開発用の成熟度モデルや、開発行程を評価出来るようなモデルを作って
　開発に対する支援や管理を行いたい。特にソースコードレビューに関してどの時点で
　どのようにやれば良いといったことが抜けている。
　そこで、今回は各社のうまくプロジェクトが進んだモデルについて話を聞きたい。
・キーワードの解説
　ピンブック(PMBOK)ISO10006
　建築関係の開発プロジェクト管理の手法(日本が中心)
　例:アルティミス社
　ソフトウェアの開発プロジェクトの知識の体系化についてどのように
　管理すればよいかをコンサルティングしている。
　ツールを販売している
　ピンブックをもとにISO10006として標準化されている。

(CMM)
・段階的に管理モデル(5レベル)を上げるモデル
　モデルの再現性
　モデルの定義とその最適化
　エンパワード
　プロセスデザイン
　オペレーション
　レベル5:最適化段階 (数値より次にどのように繋げるかどう最適化するか)
　レベル4:管理段階 (管理を数値化している)
　レベル3:定義段階 (異なる仕事も出来る)
　レベル2:再現可能段階 (同じ仕事なら出来る)
　レベル1:初期段階　 (やったらうまくいったが、管理は何もしていない)
・世界の状況
　インドのレベルの受注企業のレベルは3
　日本ではゼロックスのみ?
　レベル5の会社は 世の中に20個ほどあり例:モトローラの軍関係
・CMMは役に立っているか?
　ISO9000も含めてISOにした時点でうさんくさいが、現場が分かってい人
　が使うためのモデル。何もないよりましである。
　枠組みだけにあてはめてもいい結果がない
・CMMでソフトウェア開発部隊を評価したところ、
　結果はほとんどレベル2、一部はレベル3である。会社の目標としては
　最低でもレベル4が必要
　大企業はコストが高いためレベル4以上で無ければ価値がない。
　役に立つかは分からないが、活動をしてこの意識をもたせるのが大事である。 

(プロジェクトマネージメント)
・CMMがビジネスになっている一つの理由は、
　管理者層が他人がなにをしているのかが分からないのが原因だと思われる。
　管理の失敗によるプロジェクトの失敗例は?
・マネージャーは年をとった人でありまた昔は技術者でありマネージメント
　教育を受けてない。昔の経験に基づいてマネージメントする。
・携帯の例:昔は少人数でできたが、規模が大きくなったが、無線屋とは関係ない
　技術が必要となってきた(TCP/IP,Java)そのためプロジェクトマネージャー
　(無線プログラムを作っていた)は感覚的にマネージメントできなくなる。
　これからは、自分の知らない分野を含めてマネージメント出来なくてはならない。
　そのため、プロジェクト管理の体系化、定石を身につけなければならない。
　また、人間が作業しているため思わぬ自体が発生するため、その危機管理が必要

(ソースコードレビューを通して考えるマネージメントのありかた)
・日本ではうまく行った事例については余り公表されいないが、うまく行った例はないか?
　(cf. アメリカが調査すると見つかる)
・コーディングのある段階で行っている。
　やくにたっているかと思うのは、デバックの段階。
・適切な時期に適切なレビューをするとうまく行く。
　これはプロセスがうまく行っていると言えるのか?
・ソースコードレビューの前に情報の共有かを行っているか?
・ソースコードが分かる人がマネージャーなのか?
・マネージャは、1つのプロジェクトにはかかりっきりになれない
　毎日は見れない
・外注の管理か仕様書ばかりでソースコードを書いたことがない人もいる。
　レビューはあるが、実体はセレモニーとなっている場合もある。
・コードレビューはこの人数でも人手がたりないため行われていない。
　バグがあった周り、やばい部分に対してはコードレビューを行っている。
・どうにもならない場合は丸1日ソースレビューをするとバグが激減した。
　別のプロジェクトも走らせているので常に見ることは不可能。
・問題が起きたときのみコードレビューを行っている。 
　毎日決められた時間にメンバーで集まる。
　テスト行程 ->バグの収縮曲線を持ってくる。
・ソースコードレビュー はゲリラ的に行なっている。
　なぜなら、マネージャの仕事がオーバーフローしているから。
　話を聞いてやばいなと思うと突っ込む(優先順位をつける)
　体系的な管理はできてない。
　サポートする体制としては情報の共有はBBS,CVSを活用している。
・優先順位をつけるのが大切である
・新しい技術を使うとき担当者がどの程度理解しているかを議論
　品質を求められる分野なので、人の成果のあらを探すが重要
・ソースコードレビューをプロジェクトマネージャーがするのは間違っている。
　主任レベルがすべきだ。
　プロジェクトマネージャは新規にこれから作るところの優先順位をつけて
　売れるためにどうすればいいのかを考えるのが重要
・プロジェクトマネージャの仕事はリスクを早めに判断し、
　適材適所を行うのが大切

(人材の適材適所への配置、管理、生産性)
・オブジェクト指向、プロセス管理は並以下プログラマの人を管理するためのものである。
　ソフトウェアの世界では生産性の違いが10〜100倍ある。
　10倍のひとが並の人を管理して効率を落とすのは、意味があるのか?
　そのトレードオフはどうするのか?
・プロジェクトマネージメントは並以下の人を管理するのではなく、
　どんどん書いていく天才的なプログラマを管理するもの。
　すなわち天才的な人の行った仕事をどのように次の世代に伝えるのかが問題。
　天才的な人が書いたプログラムをどうメンテするかも含め。
・組込みソフトウェアの特徴としてハードが無い時点でソフトウェアを
　書かなければならない。ハードの不都合をソフト(ディバイスドライブ)
　で吸収しなければならない。これを解決するツールはあるが、イマイチ。
　そのため一番優秀なエンジニアにディバイスドライバ開発をまかせている。
・来週までに動かせと言う要求に対する解決が、「人」であることも多い。
　CMM、ISOは綺麗だが、なんか人が見えないところがあまり好きではない。
　人を含めたシステムがほしい。
・優秀な人をモニタしてどのような現象が発生しているか見てそれを体系化
　したい。
・優秀な人の書いたプログラムは、ベストプラクティスになると思う。
・優秀な人の書いたプログラムをレビューすることは長い目で考えると
　人を育てることにつながると思える。
・普通にソースコードレビューしてもスーパープログラムの努力は伝わらない
・思考過程をダンプするのが重要で単にコードレビューではなく
　開発過程のレビューが必要なのではないのか。
・コードよりも設計パターン/思考パターンを残せば有効ではないのか? 
　クリティカルな部分は信頼できる人にまかせる
・平凡な人を使ってプロジェクト管理をするぐらいならスーパープログラマ
　を育てる方が魅力がある。マネージャとしてプロセスのあるべき姿と本心
　が異なってしまう。一人の優秀なのがいれば煩わしい管理は必要ではなく
　なる。これはわがままなのか?
・だめな人はだめで、その意味でやはりソフトウェアは工芸品で
　科学になってないのではないか。
・だめな人に何を割り当てるか
・意識の低いプログラマの書いたコードはお祈りして出荷するしかない。
・大企業で生産性が低いのは当たり前であり、それに対して大きな人数で
　効率を求めるのは間違い。プログラムの規模でやり方を変えた方がいいの
　ではないのか。これは大きな会社で経営のオーバーヘッドが大きいのと同じ。
　その代わり大きなものができるのがメリットである。
　それでも小さい会社のように開発者が楽しめる環境を作るのが大切なのではないか。
・スパープログラマを育てたいが、企業としては普通の人を活性化する
　プロセス管理の両方が必要なのではないだろうか。
　大企業ではスパープログラマを育てるのもCMMを使うのも大切。
　納期/コーディング/レビュー等に追われるだけでなく
　プロセスに興味を持つのが大切なのではないのだろうか。

(2C以上)