********************************************************************** セッションS1-b 分科会テーマ：プロセス改善〜実践編〜ツール vs チームワーク勝つのはどちらだコーディネータ: 江口亨(富士通コンピュータテクノロジーズ) 間瀬順一(アイシン・コムクルーズ) 日時：9/1 21:00-22:30 参加人数：約30人 ********************************************************************** M氏:根性派チーム(チームワーク派)とテクノロジー派チーム(ツール派)に分かれてロールプレイによる議論を行います。ただし信条と関係なくチームを選んで良いです。プロジェクターを用いつつ討論を進めます。はじめにそれぞれのチームのリーダーからチームワーク又はツールを擁護する理由の説明をします。 ---------------------------------------------------------------------- テーマ：ソフトウェア開発の効率はツール解析によって上がるべきか、チームでの協力により上がるべきか・E氏率いるチーム(ツール派)とM氏率いるチーム(チームワーク派)に分かれて討論・気持ちが変われば相手チームへ移動可能・ロールプレイングにより行う ---------------------------------------------------------------------- 9:10 ---------------------------------------------------------------------- ツール派の主張(E氏が事前に準備したスライドを元に説明) ---------------------------------------------------------------------- E氏：まずは会社宣伝から、富士通コンピュータテクノロジーズで働いています。本社は川崎、事業所は長野、豊橋にあります。事業内容は組み込みシステムの開発です。ツール擁護以前に、モノの作り方を業界を超えて考えたい。ところで、建築業界をご存知ですか？・自宅の大規模リフォームのため興味があった・建築費の5%が設計料、工期監督料が5%、合計10% - つまり、紙を書いて監督して商売でき、設計図が全ての生産物⇒こんなおいしい商売はない！建築業界における設計図・顧客の要望を設計士がアーキテクチャで形にしたもの - 顧客と設計士の合意文書 - 建築確認・許可申請の資料・使う部材・数量・加工方法から人工・材料費を算出・相見積りで適切な工務店の選定 - 一番高い業者と一番低い業者は除外 - 高い業者⇒その工事をやりたくないので高くしている可能性 - 低い業者⇒何が何でも取りたいので無理をしている可能性・工事は設計士から業者への意思を伝え、工程・工事に特化した図面を用意 UMLとの出会い・建築業界の仕事の進み方 - 現場にくる業者はクライアントを知らないが工事は進む - 工事が終わると別の現場に移る - 設計図は上流工程から下流工程への意思伝達手段・ソフトウェア業界にも建築設計図相当はないのだろうか - 当時、中国へ実装発注がトレンド - 中国の単価は日本の1/10、翻訳した仕様書でやり取り - コミュニケーションがうまく取れずに失敗するプロジェクト続出・キャノンの友人が米国HPとUML図で設計やり取りしていた⇒これだ！ソフトウェアの設計図開発手法の切り替え・ウォーターフォールからスパイラルへ - 一発で完成させるのは難しい - アーキテクチャ設計・確認→機能拡張・各種問題 - 工程と納品物の不一致⇒やり方、生産物が変わる - 文書主体からUML主体へ⇒お客さんが読めないという問題が生じる - 進行・遅延が分かりにくい・新しいことを始めるリスクは高いのでポイントを決めて行う。・新手法がうまくいかないとき、従来に切り替えて間に合う限界点の設定は重要・うまくやるためのコツ - 少人数 - 小規模 - 顧客との合意オブジェクト指向開発の普及・社内にオブジェクト指向開発を展開 - アーキテクチャ部発足 - アーキテクトが開発チームに参加、開発チームリーダーと共にアーキテクチャ設計 - アーキテクチャに基づくFW開発、開発チームが肉付け・オブジェクト指向開発の実践度 - 新規開発ほぼ100%、既存製品は少数、全体では30％・アーキテクトの意図通りに開発が進まない - アーキテクチャを理解できない - FWの間違った使い方をする - 既存コードを取り込めない・原因は何か？ - 言語やソフトウェア理論だけを持ち込み、業務に即した開発プロセスまで踏み込んでいない - 既存資産を活かす具体的方法を示していない・現場に対してうまく浸透する手段を考えなければ無駄な手段となる AUTOSARとの出会い・良いアーキテクチャは難しいことが多い - 「複雑」ではなく、洗練された「抽象化」が理解できない・現場の開発メンバに「抽象化」を理解してもらうのが困難 - 開発規模増加⇒開発メンバ増加 - アーキテクチャを全員が理解できない - 新しいことに意欲的でない・AUTOSARで実現したいこと - アーキテクチャをツールで開発メンバに守らせる - ツールの部品を組み合わせて製品開発 - 実装スキルを属人的にしないコードを生成する・コンピュータ業界にTPSが入ってきたように10年後にAUTOSARがソフト版TPSとしてやってくる DSL TOOLでロボット開発環境・バージョンアップもされているロボット開発に適用して判明したこと・反復しやすい開発プロセスの導入が必要・コード生成に適したアーキテクチャをフレームワークに取り込むブロック組立型ツールBricRoboを開発・ハードウェアのように部品を組み合わせて、ソフトウェアを開発できるコード生成ツールとランタイム環境の開発ツール・開発例:バーコード読み取り装置 - LEGO Mindstorm NXTで実現 - ARM7 - ROM＋RAM 64KB まとめ・チームワークはとても大切 - しかし規模が大きくなり、開発メンバが20、50人になってもチームワークで乗り切れるか?⇒ツールが必要・誰でもどんなものを設計していいのか？ - 原発のシステム設計に免許がいるのか？・実は我々のこの業界では自由だが、法律的な縛りがある - もしかしたら新しい法律やルールが増えると良いかもしれない・建築業界と比較して - ソフトウェア設計にはなぜ免許が必要ないか - ハードウェア設計には、クリアするべき基準あり - 建築には工法がある・組み込み業界のために - 分業体制にできないか - 良い工法の確立⇒業界に厚みが増し発展 - 工法を確立するのはツール - アーキテクチャ＋ツール = 仕組みが必要である 9:40 --------------------------------------------------------------------- チームワーク派の主張(M氏がその場で書いたスライドを元に説明) --------------------------------------------------------------------- M氏：夜の分科会なので、出来るだけダメ出しを行った方が楽しい。ツール派は事前に準備してきましたが、チームワーク派はその場で書きます。ツール＋プロセスについて・建築業界を見習うべき・ソフトウェアには設計図はないだろうか？・うまくやるコツはある。・アーキテクチャは困難やっぱりチームワーク・システム記述は多くの人が分からないといけない - 難しい記述では、理解できない人が多数いる。・書ける仕様に限界がある - 書ける範囲が狭い・多能工が結局、日本の強みでは？ - 設計を考える人が仕様も考えている - 他の人のことまで考えられるのが日本人の強みである・モデリングとプログラミングの境界は？ - E氏は大規模な時に困るという問題の答えに触れていない 9:50 -------------------------------------------------------------------- 討論開始(発言は双方自由に行う) -------------------------------------------------------------------- ツール派：M氏のテンションが高すぎてついて行けない人が多いのではないか？フィルターをかけて、ある制限内で受け入れられる人がいっぱい出てくるのがツールの良いところではないか？ M氏答えられず。ツール派：やっぱりチームワークとあるが、特定の人だけが多能工であるのが今の現状ではないか？ M氏：仕様を作っている人が仕様のことを理解していません。ツール派：それは多能工ではないと言えるのではないか？ツール派：仕様とは何か？こうしよう、ああしようということが仕様。仕様がないことをしょうがないという。ツール派：ツールを狭く思い過ぎてはいけない。分割統治もツールである。 M氏：すぐれた設計の原則を言っているだけである。それはツールではない！チーム派：リーダーにはついていけない。ツール派：(チームワーク派の)隊長自身がチームになっていない。 M氏：その批判は受け入れます。チーム派：UMLについて、誰が理解できるのか？新しいツールを年を召したおじ様たちはどうやって学ぶのでしょうか？つまりツールを学ぶにもチームワークが不可欠ではないか？ツール派：チームワーク派にチームワークがない。ツール派：チームワークでは何が大事か？例えば5人の人間がいて、A君は何が得意、B君は何が得意だと言っているときにまわりもそれに納得し合える。つまり、お互いの特徴を納得しあえるということがチームワークではないか。 M氏:答えを言ってしまってはダメ。チーム派：M氏は隊長失格。ツール派：物を作ってる立場からは、チームワークについてお互い何ができるか重要だが、力強いリーダーは必要。これは自分、あれは他人とすると役割の境界が希薄になってしまう。ツール派：わからない人間に教えるよりもツールに任せた方がよいのではないか？チーム派：仕様書を書くということはお客様に理解してもらわないといけないということ。ツールにできるか？ツール派：確かにUMLがお客様を満たせるとは限らない。ツール派：LEGOのパッケージを開いたことがあるか? 数字と絵しか描いていないが、どこの国に出荷しても設計書は一種類しかない。表現の仕方を考えたら物は伝わる。 DSLツールでも伝わることもあるのではないか？チーム派：M氏対ツール派ではないか？チーム派にはチームワークがない。 M氏：モチベーションがないとツールは導入できない。ツールは手段であって目的はチームワークである。ツール派：組み込みでUMLはダメ。ステークホルダーが分かるモデルが必要チーム派：DSLは良い仕組み。設計する人には10倍能力が求められ階級社会向き。日本のようなフラットな国には向かないかもしれない。ツール派：ツールにできることはパターンが見つけられたこと。これができるということはスペシャリスト。皆で一気にまとめてやろうっていうものがツールである。ツール派:ツールには二つの目的がある。コミュニケーションと品質のため。例えばインドリソースとのコミュニケーションにはツールが必要。ツールがないとコミュニケーションが取れない。ツールがあるから一定の品質がある。人間系だけでこれを確保することができるのか。ツールはやはり必要である。チーム派：ツールは冷たさが見え隠れする。頼める人が見当たらないとき、頼りになるのは人ではないか？ツールだけでは成り立たない。ツール派：良い大工さんでなくても同じ品質を出せるのがツールである。チーム派：ツールは一般解でしかない。それ以上のものを作るのはチームワークからのみ。ツール派：設計図が一つのツールだとすると、設計図入札を考えるとき、一番高いものと低いものは削り、真中から選ぶ。チーム派：そんなに完璧なツールの仕様書は書けますか？ツール派：実際、施工はどうなるのか電話がかかってくることもある。仕様に見えない部分がある。これは設計料に入っている。ツール派：日本人は中国やインドから仕事を任されて苦労している状況か？チーム派：そんなことはない。中国やインドから仕事取ることができれば優秀。ツール派:この仕事は力技ではできない。もっとスマートにやらなければならない。完璧な要求は書けるか？チームワークで補えるわけはない。ツールは技術に裏付けがある。それを手に入れて強くなる。チーム派：ツールを使うというのはエンジニアの差を埋めること。ツールを使って標準化。チームワークは一緒に仕事をして互いの領域を補うことによって、互いの能力を引き上げられる。ツール派：それはない。何千行書こうが、出来ない人は成長しない。若い人材の面倒を見ながら仕事をできる人は何人いるか？ツール派：チーム作りにはバランスが必要。モチベーションを育てる事が大切。そのためには監督のような存在が必要。ツール派：ベテランと中堅と若手の比率の理想はどれほどだろうか？ツール派：リーダーが一人、3人くらいの中堅、2、3人の若手で6〜7人がひとチームとなるのがよい。ツール派：ツールベンダーですが、チーム力は確かに大切だがツールはもっと大切。 M氏:良いチームが良いツールを持つのが最高。チーム派:良いチームとは何ですか？ツール派：リーダーシップがあってそれぞれの人に責任感がある。ツール派：良いリーダーシップとは何ですか？ツール派:リーダーシップが重要かツールを選ぶ力が重要か？チーム派：多数決を取りましょう。 --------------------------------------------------------------------- 多数決をとり、ツールを選ぶ力が過半数を占める。 --------------------------------------------------------------------- ツール派：ドイツの学会とSWESTと比べてどうか？ツール派：ドイツと日本のビールに違いはない。しかし、半ズボンで議論に参加して、床に座るスタイルはない。日本では密なコミュニケーションが取られている。ここで乾杯。 --------------------------------------------------------------------- ○まとめチーム（M氏）：この問題に解答はないです！ツール（E氏）：初めから解答はないと思ってました。時間になりましたのでこれでセッションを終わらせていただきます。 ---------------------------------------------------------------------