ObjectSquare [2006 年 1 月号]

[レポート]



プロジェクトを成功させる7つのカギ

〜2005年 オブジェクト倶楽部クリスマスイベント 参加レポート〜



株式会社 オージス総研
オブジェクトテクノロジーソリューション第2部
樋口純一




はじめに

2005年12月16日、オブジェクト倶楽部(株式会社永和システムマネジメント)主催によるイベントが行われました。オブジェクト倶楽部では、日々進化するソフトウェア開発の中で、「現実的なオブジェクト指向」の実践を目指して、技術ドキュメントの公開やメーリングリスト、無料セミナーなどの普及、啓蒙活動を行っています。今回のイベントもその活動の一環であり、オブジェクト指向技術者同士の密な情報交換や、新たなインスピレーションのきっかけの場を提供することを目的としているものです。

5回目を迎える今回のオブジェクト倶楽部イベントのテーマは『プロジェクトを成功させる7つのカギ』です。プロジェクトを成功させるためにはいくつかの「カギ」が必要になるはずです。それは、「プロジェクトマネジメント」、「チーム内のコミュニケーション」、「開発プロセス」、「見積り」、「技術者教育」などなど、おそらく個々人で異なるかもしれません。本イベントでは個々人が持つそのプロジェクト成功の「カギ」を参加者全員で共有し、成功へのカギ束をポケットに持ち帰る、そんなイベントを目指し開催されました。その「カギ」の共有を促進するため、今回のイベントでは「ワールドカフェ」という手法を用いて、参加者間でお互いの持つ情報を共有するという、初の試みも行われました。「ワールドカフェ」の説明については後述します。

午前、午後ともにセッションが行われますが、午後のセッションは同時に複数開催されるものもあるため、1つだけ選んで受講することになります。
 私はプロジェクトの失敗原因の多くは工数や期間の見積りの甘さにあると思っています。そのため、13時00分からのセッションでは、「納得の見積り」に参加することにしました。また、UMLで描いたモデルに対してのディスカッションがどのように、どんな感じで行われるのかということに興味があったため、14時10分からのセッションでは「モデリングバトル」に参加しました。
 午後セッションに関しては、これらのセッションについてご報告します。


目次

※タイトルが太字、背景色付で示されているものが、今回私が参加したセッションです。
時間 プログラム
9:45 〜 10:00 開始挨拶
10:00 〜 11:00 オープニング with 全員参加型ワークショップ(オブLOVEワールドカフェ)
『プロジェクト成功のカギ〜現場からの声に耳をすませ〜』
11:00 〜 12:00 『ソフトウェアの生産性と品質を向上させる鍵は何か』
12:00 〜 13:00 昼休み
13:00 〜 14:00 失敗しないオブジェクト指向教育とは Javaアーキテクチャ 納得の見積り マインドマップUMLによる要求分析
14:10 〜 15:10 理屈(大脳皮質)では出来ないチームビルディング アジャイルと言語〜Is Ruby Agile? モデリングバトル フリースペース
15:20 〜 16:05 全員参加型ワークショップ
(オブLOVEワールドカフェ)
16:15 〜 16:55 ライトニングトークス
16:55 〜 17:10 終了挨拶

さいごに

開始挨拶

受付では、サンタの帽子を被ったスタッフが笑顔で出迎えていただき、和やかな雰囲気の印象を受けました。イベント会場に入ると、50〜60台くらいテーブルと1テーブルごとに5つのイスがテーブルを囲むような形で配置されていました。さらに、テーブルの上には右図(→)のように配布物として、イベントパンフレット、首掛けの名札ケース、2006年度オブジェクト倶楽部カレンダー、お茶、単語帳が用意されていました。この中でも単語帳は重要なもので、これから先に受講するセッションで持ち歩き、関心をもったことや勉強になったことをメモって行くためなどに活用してして頂きたいとのことでした。

参加者の方々は、関東圏からの参加の方が多く、半数以上が初参加でした。例年のイベントの傾向では、リピータ参加者が多いらしいのですが、今回はそれが逆転。オブジェクト倶楽部の知名度が向上したことの表れでしょうか。



プロジェクト成功のカギ 〜現場からの声に耳をすませ〜   平鍋健児氏

いよいよ1つ目のセッションが始まりました。このセッションでは、本イベントの目玉でもあります「ワールドカフェ」を用いて参加者間で情報共有を行うというもの。
「ワールドカフェ」のルールは、3〜5人でグループを組み、ある「お題」に対して5分間で会話を行い、その内容を大きな模造紙に書き込んで行きます。この5分を1ラウンドとし、計3ラウンド行います。1ラウンドが終了すると、各グループで1人だけホストを決めてその場に残し、それ以外のメンバーはバラバラに別のグループに移動します。次ラウンドの最初で、ホストが前ラウンドの会話の内容を新しいメンバー に共有し、さらに会話を深めます。その後、そのラウンドの新しい「お題」について会話を行う・・・ ということを繰り返すものです。

3ラウンドの各「お題」と、私の参加したグループで出された回答について記しておきます。

1ラウンド目:お題「なぜこのイベントに参加したのか?」

2ラウンド目:お題「今まで参加したプロジェクトの中で大変だったプロジェクトは何か?」

3ラウンド目:お題「失敗したプロジェクトの原因は何だったか?

本イベント初の試みとは思えないほど、参加者のほとんどが積極的に会話に参加できており、別グループへの移動もスムーズに行われている印象を受けました。私が参加したグループの会話の進め方は、出てきた回答をマインドマップを積極的に用いて記述していき、それに基づいて話しを展開させるというやり方が多かったです。さらに、私自身も感じたことですが、参加者の中には「5分では短すぎる」との意見もあちこちでありました。この「ワールドカフェ」形式による情報共有では、主催者の想像を超える効果を参加者に与えることが出来たのではないでしょうか。


ソフトウェアの生産性と品質を向上させる鍵は何か   前川徹氏

現在、インドや中国などの国がソフトウェア産業の育成に力を入れている中、日本のソフトウェア産業の国際競争力はますます低下しています。では、日本のソフトウェアの競争力を高め、ソフトウェア産業を発展させるためにはどのようにすべきか、開発手法、人材の処遇、業界の構造などの多角的な視点から考えるという内容。

背景
 現在、世界はソフトウェアに依存しており、ソフトウェアの重要性はますます高まっていますが、日本のソフトウェアの競争力は極めて低いのです。まず、日本のソフトウェア輸出額と輸入額を比べてみると、輸出額は輸入額と比べて1%程度しかないのです(図1)。また、各国におけるプログラムの生産性と品質比較(表1)によると、日本は他国に比べて1人のプログラマが1ヶ月に書くプログラムの行数も多く、バグの数も少ないため、数値だけ見ると、日本は他国に比べ、生産性と品質は共に高いと判断できそうです。しかし、日本では残業が恒常化しており1日の労働時間は長いのが現状です。さらに、日本で開発されたシステムは他国に比べて利用者や利用頻度少ないためにバグが発見される機会が少ないという意見もあります。このような点が含まれていない「各国の生産性と品質の比較(表1)」からは、日本が生産性と品質に優れているとは言えなくなります。

図1:日本のソフトウェア輸出輸入額
表1:各国の生産性と品質の比較

ウォーターフォールモデルは間違いだ!
 現在では、規模の大小に関わらず、ウォーターフォールモデルの開発が主流となっています。しかし、ウォーターフォールモデルで開発を行った場合、発見が遅れるほど修復に要するコストは増加してしまいます(図2)。特に要求定義での欠陥は最悪の手戻りを招いてしまいます。さらに、トラブルが起こった場合、その原因を追求してみると4割強が要求仕様にあるのです(図3)。以上から、ソフトウェア開発にウォーターフォールモデルを用いることは間違いであると言うことが出来ます。動くソフトウェアが一番重要なのです。
  • 完璧な仕様書は求めない。早く作ってエンドユーザに見せる。
  • 何をしたいのかをユーザに書いてもらう。動くソフトウェアでユーザの確認をとる。
  • 動くソフトウェアで進捗確認を行う。遅延も予算超過もないプロジェクト管理ができる。


図2:各工程時における要求定義の誤りがもたらすコスト

図3:トラブルの原因どこにあったか?

個人の能力をより重視すること
 個人の能力に大きな差があるという考え方が様々な文献で言われています。
  • 優れた人が優れたソフトウェアを作る、というのは昔からの考えだ(エドワード・ヨードン「プログラマーの復権」)
  • プログラマの世界は、10%の優秀な人と、40%の普通の人と、50%の足を引っ張る人からなっています。プログラムは10%の優秀な人が作ります。(新・戦わないプログラマ No,17 プログラマという人種)
  • プログラミングマネージャーは、できるプログラマとできないプログラマの間に、大きな生産性の相違があることに、前々から気がついていた。(フレデリック・P・ブルックス「人月の神話」)

 また、個人の能力差に関することが、具体的な数値で証明されています。
  • プログラミング(デバッグ作業を含む)における個人の能力差は、最大で28対1
  • 個人の生産性の差は5対1
  • 個人の能力比は2から7最大で7.3:1

 さらに、生産性に差があるというだけでなく、生産性がマイナスのプログラマもいることも報告されています。
 デマルコ(Tom DeMarco)とリスター(Tim Lister)の研究では、「166人中13人が作業を終えることが出来なかった。」と報告されています。そして、カーチス(Bill Curtis)の研究では、「60人中6人が単純なデバッグ作業を終えられなかった。」と報告されているのです。つまり、メンバーのうち足を引っ張っている人間が1割くらいいるということになります。
 ではいったい誰が「彼ら」の代わりにプログラムを書いたり「彼ら」の作りこんだバグを取り除くのでしょうか。それは、言うまでもなく、優秀なプログラマなのです。
 さらに、日本では、残業が恒常的になっており、残業すればするほど給料も高くなります。そのため、以下のことが言われています。
  • プログラムにかかる時間は、下手ほど長くなる。そして、労働意欲が高いと評価される。(藤原博文「コの業界のオキテ!!」技術評論者(1995) )
 以上のことから、優秀な技術者が辞めて行き、ソフトウェアの生産性や品質の悪化を招く結果になっています。 現在の日本では、図4のような悪循環が起こっており、日本のソフトウェア産業のレベルを下げているのです。図5のような好循環を目標とすべきです。


図4:ソフトウェア産業における悪循環


図5:ソフトウェア産業が目標とすべき好循環

ユーザー側の問題と責任
 もっとも効率のよいソフトウェア開発方法は、自分でつくらず、出来合いのものを利用するのが一番です。日米のパッケージソフトの利用状況(図6)を見てみると、日本の企業ではパッケージソフトを利用して開発を行うよりも、オーダーメイドで構築する方が多いことが分ります。このパッケージソフトが普及しなかった理由として以下のことが挙げられます。
  • 日本企業は細部にこだわり、独自性を好む
  • エンドユーザのリテラシーが低く、パッケージソフトが使えない
  • 日本の情報システムがメーカー毎に細分化されていたために、パッケージソフト市場が小さかった
  • リスクの大きなパッケージソフト開発よりも受託開発型のビジネスを好む会社が多かった
 また、ユーザ(顧客)の問題点を指摘する声も多々あります。
  • プロジェクト開始時点で仕様を確定できない
  • プロジェクトの途中で仕様変更を強要してくる
  • 仕様の書き方が曖昧で、工数が見積もれない
  • 重要な制約条件が仕様書に書かれていなかった
  • 見積もった工数を無視した低い金額を提示された
 これらのユーザのソフトウェア開発に対する理解不足が原因となり、結果として、ソフトウェアの生産性と品質の悪化を引き起こしているのです。


図6:日米の企業におけるパッケージソフトの利用状況

図7:ユーザのソフトウェアに対する理解不足がもたらすもの


このセッションでは、普段、みんなが感じているであろうが、なかなか言い出せないようなことを堂々と発表されていました。しかも、様々な書籍や論文で述べられていることを参考や裏づけとして示されてあったため、とても説得力のある内容で良い刺激になりました。そして、私たち参加者の考えに、自信や勇気を与えてくれる内容でした。

このセッションで講演された株式会社富士通総研の前川徹氏は『ソフトウェア最前線―日本の情報サービス産業界に革新をもたらす7つの真実』の書籍の著者であり、今回のセッションの内容はこの書籍の一部のようです。この書籍も是非読んでみたいです。


*なお、本記事で取り扱った図や表は全て、講演者である前川徹氏の講演資料からの引用です。


納得の見積り   三河淳一氏

このセッションでは、「見積りとは何か」ということに対する講演を行うと共に、その中で参加者に対して挙手によるアンケート調査を何度か行いながら進めていました。参加者は50〜60人で、会場がほぼ埋まるほどでした。現在、「見積り」というテーマが注目されている証拠でしょうか。その参加者の多くはSEやプログラマーの作り手側の方でした。

何を見積もる
 「見積り」とは、作り上げたいモノを予定通りに完成させるための計画に必要な情報のことです。そして、「良い見積り」とは、作業に入る前に算出した見積りと作業が完了したときの実績が同値となった場合の見積りのことをいいます。
 情報システムの構築やパッケージソフトウェアの開発の場合、以下のモノを見積もることがあります。
  • 価値効果
  • コスト(単位:「円」)や総工数(単位:「人日」や「人月」)
  • 期間(単位:「月」、「週」、「日」)
  • 品質(単位:欠陥は「MTTD」、信頼性は「MTTF」)
  • リスク(単位:ほとんどが確率)
  • 規模(単位:LOC、FP、UCP)
  • 生産性
 そして、見積もるモノによって、そのアプローチが変わってきます。「規模」を見積もる場合はアルゴリズム算出(COCOMO法、FP法、UCP法)、デルファイ法、類推法を、また、「コスト」や「総工数」を見積もる場合はCOCOMO法、モンテカルロ法、デルファイ法、統計的手法、WBS(Work Breakdown Structure)法を用いることができます。

見積りに必要な情報とは
 Sierが行う見積りでは、新しいシステムの稼動を検討しているユーザ企業から、『要求仕様の決定からシステムの稼動まで』に必要な一連の作業と成果物の納品を依頼されると、見積書(開発計画書)を提示することになります。
 このときの見積り項目には、価格(工数)、期間、体制、プロセス、品質などがあります。

 これらの見積りを行うにあたって、依頼者側からのRFPから要求仕様、期間、予算、アーキテクト、ドキュメント、プロセスなどの情報を考慮し、さらに、開発実績から生産性を考慮します。
 そのため、「RFP + 開発実績 +リスク = 見積り」となります。
 また、要求仕様を見積り要素として考慮する際は、ISO/IEC9126の品質特性(表2)を分類要素として利用することもできます。

 要求仕様から定量化を行う手法には以下のものがあります。
 ・ユースケースポイント法(UCP)
ユースケース分析後のアクターとユースケースの数と特性を元に規模を算出する。
 ・機能数、画面数、テーブル数
外部設計後に確立されるユーザインターフェースやデータベース・テーブルの数と特性を元に規模を算出する。
 ・ファンクションポイント法(FP)
IFPUGが提示しているCPM4.1で規定される算出方法が本家。NESMAと呼ばれる概算算出法もある。
 ・プログラム行数(LOC:Line Of Code)
現在でももっとも多く利用される、歴史ある規模算出方法
 これらの手法が用いられるタイミングを表3にまとめました。

表2:ISO/IEC9126による品質特性
表3:システム規模を算出するタイミング


 見積りを行った後、その見積りを元に期間や人員の配置を行うが、その際に抑えておくべきポイントを以下に示します。
 ・ 期間には現実的な範囲がある
期間を多くとれば、「人月」を単位とする工数は減るが、あるときを境にその変化量は次第に小さくなります。(図8)
 ・ 体制は小さいほうが効率的
プロジェクトの人員が多ければ多いほど、「人月」を単位とする工数は大きくなっています。(図9)
 ・ 規模が大きくなると生産性が落ちる
規模が大きければ大きいほど、1人月あたりのFP数は小さくなり、生産性が落ちることになります。(図10)


図8:工数と期間の関係

図9:工数と人数の関係

図10:規模と生産性の関係

ワークショップ
 ここで、実際に見積りを行うというワークショップを行いました。

 図11、表4の仕様から見積りを行い、表5のシートを作成するというものです。


図11:要求機能仕様1
表4:機能処理仕様1


表5:見積りシート



 見積りの解答例を表6、表7に示します。
 表7の「規模」の88FPは誤りで、84FPが正しい値であると訂正していました。
表6:機能処理仕様1から見積り
表7:見積りシート作成例1


 さらに、図12、表8に示すような仕様が追加されたとき、どのように見積もりはどのようになるか。
 再度、見積りシートを作成します。


図12:要求機能仕様2
表8:機能処理仕様2(追加分のみ)


 この追加要求を含めた見積りの例を表9、表10に示します。

表9:機能処理仕様2から見積り

表10:見積りシート作成例2


 今回の講演では、見積りに対する基礎的な内容が多く、三河氏自身の経験や研究に基づいた「見積り」のお話しがなかったことが残念でした。持ち時間はたった1時間だけでしたので、仕方ないのかもしれません。次にこのような講演がある際には、是非、お聞きしたいものです。

最後に、少し話しが変わりますが、
 ザ・プロジェクトマネージャーズ(HPはこちら)というMLがあるのですが、その中の「プロマネへの道」というコーナーで、次回の対談のお相手として三河淳一氏が招かれる予定となっています。この対談の内容は、第55号のML(2006年1月24日ごろ発行?)に掲載されるそうです。
 「プロマネへの道」のコーナーでは、今回のイベント主催者の1人でもある、平鍋健児氏も対談のお相手として招かれており、とても参考になる内容です。
 是非、ご覧になってはいかがでしょうか。


*なお、本記事で取り扱った図や表は全て、講演者である三河淳一氏の講演資料からの引用です。


モデリングバトル

モデリング道場のメーリングリストで討論されるモデリングコンテストを会場内で行おうという企画です。今回のモデリングバトルのお題は『イベント受付業務』です。各チーム、これをモデル化し、どのモデルが優れているかを競うという内容です。どのモデルが良いモデルの判断は、視聴者の多数決により決定します。詳しい内容はこちら

今回の参加チームは以下の3チーム、視聴者は26人でした。

まず、各チームが自分達の作成したモデルについて視聴者に対して説明を行いました。次に、約10分くらい、ポスターセッションのような感じで、視聴者に各モデルに対して質問する機会が与えられました。なお、各チームが発表した図は本イベント(モデリングバトル)のHPで紹介されています。
ここでは、視聴者はみんな積極的にモデルとモデル作成者の前に集まり、討論を繰り広げいました。この討論は設けられていた時間では、終わらず、数分だけ延長することになりました。それでも、時間が短く、全てのモデルに対して質問できた視聴者は少なかったと思います。

その後、26人の視聴者の方々にどのモデルがより優れていたかの判断をしてもらい、挙手による投票を行いました。その結果、

本多さん 池下さん 大菅さん、田中さん、高木さん、庄司さん
8人 8人 10人

僅差で、「(株)NEC情報システムズ 大菅さん、田中さん、高木さん、庄司さん」チームの勝利が決定しました。勝利したチームにはUMLモデリングツール“JUDE”のライセンスが1つ与えられました。また、参加チームには1冊ずつ専門書籍が参加賞として贈られました。

最後に各モデルに師範のMr.Xおよび師範代からの講評が発表されました。

私は、今回、モデルに対する討論の場に始めて参加させていただきました。視聴者の方々はみんな、言いたいこと、感じたことを率直にモデル作成者にぶつけ、まさに弱肉強食といった感じの雰囲気でした。この雰囲気の中、堂々と戦っていた参加チームの方々の素晴らしさに感動いたしました。


全員参加型ワークショップ

再び、午前に行われたようなワールドカフェ形式の情報共有会です。ルールは午前のワールドカフェと同様ですが、4ラウンド行いました。そして、今回は1ラウンドの時間を7分で行うと始めに伝えられましたが、時間の都合上、午前同様に5分と訂正されました。ちょっと残念です。

4ラウンドの各「お題」と、各ラウンドにおいて、私の参加したグループで出された回答について述べます。

1ラウンド目:お題「午後のセミナーは何を受け、どんな感想を持ったのか」

2ラウンド目:お題「単語帳に記録したこと」

3ラウンド目:お題「プロジェクトの問題点とそれを改善させるための手掛かり」

4ラウンド目:お題「今回のイベントを通して、持ち帰りたいこと」

午後は複数のセッションが同時に行われるため、全てを受講することは出来ません。この場で他セッションの参加者から受講できなかった午後セッションのお話を伺えたのはとても良かったです。
 また、4ラウンド目の最後のお題のときに同じグループの方々とマインドマップの話しをしたのですが、このときに、マインドマップを作成するための使い易いフリーソフトがあることを聞くことが出来ました。そのフリーソフトの名前は“FreeMind(日本語版のサイトはこちら)”という名前のツールです。“JUDE”ではマインドマップ作成は無償版では利用できないため、諦めていたのですが、今回、マインドマップ作成のフリーソフトの存在を知ったことは私にとってとても有益な情報でした。まさに、ワールドカフェがもたらしてくれた成果の1つです。

午前と同様、他の参加者の方と会話するきっかけとなったことや、他の参加者の考えや価値観などを感じることが出来たことは参加者の方々にとってとてもよい刺激になったはずです。是非、今後のオブジェクト倶楽部イベントでもワールドカフェ形式による情報共有の場を与えて頂きたいものです。


ライトニングトークス

毎回恒例となっているライトニングトークスは一般で発表希望者を募り、テーマは自由、持ち時間5分、延長なしの1本勝負で熱く語ってもらおうというものです。今回のライトニングトークスでは、例年に無いほどの多くの応募があり、希望者全員が発表できたわけではないそうです。以下8名のトーカーの方が発表されていました。

1. 坂田 晶紀 さん :「ニコニコカレンダーとメトリクスとSM」
2. 佐藤 竜一 さん :「形から入る『見栄っ張り』アジャイル開発講座」
3. 寺田 雄一郎 さん :「技術屋生活の会計学」
4. 侍塊s featuring 侍RED さん :「困った上司とのつきあいかた教えます」
5. あしざー さん :「XPairChangeのご紹介」
6. 我戸 真澄 :「仏像に学ぶ笑顔の効果」
7. くまたけ さん :「マジカで楽しく業務分析」
8. 牛尾 剛 さん :「オブジェクト指向の営業の営業テクニック」

いずれの内容も愉快で会場内を沸かせるものや参考になるものでした。
私が特に気に入ったものを2つほど紹介しておきます。

1つ目は、坂田晶紀さんの「ニコニコカレンダーとメトリクスとSM」です。このプレゼンテーションの内容は、プロジェクトメンバー1人1人の精神状態を「見える化」させるために、メンバーに自分自身のその日1日の精神状態示すシールを帰る前に毎日貼っていってもらうニコニコカレンダー(通称:ニコカレ)の紹介です。これを利用することで、普段は見え難いメンバー達の精神状態を共有でき、互いにフォローし合うきっかけになるというものです。

2つ目は、侍塊s featuring 侍RED さん「困った上司とのつきあいかた教えます」です。このプレゼンテーションでは、考え方の異なる付き合い難い上司とどのように接して行くべきかということの前向きなアイデアやプロジェクト管理について紹介してくれていました。特に、「見える化」、「振り返り」、「お客様との接し方」などの行い方にはとても共感できるものが多く、参考になりました。

また、トーカーの中には「高橋メソッド」(大きな文字のみが書かれたスライドを用いてプレゼンを行う手法)を利用していた方も数人いました。前々からこのプレゼンテーション手法について知ってはいたのですが、目の当たりにしたのは初めてで、その効果を身をもって体験でき、とても参考になりました。自分でも機会があれば実践してみたい気になりました。

各プレゼンテーションで利用された資料がオブジェクト倶楽部で公開しております。是非、1度ご覧になってはいかがでしょうか。


さいごに

オブジェクト倶楽部で毎年開催されているイベントは、堅苦しいものでなく、スタッフや他の参加者の方々はとても良心的な方ばかりです。そのため、初心者の方でも気軽に参加できるものだと思います。私自身、オブジェクト倶楽部のイベントに参加したのは初めてであり、しかも、オージス総研入社1年目の新人ですが、本イベントに参加し、ワールドカフェなどを通して、初めてお会いする参加者の方々ともそれほど緊張することなく会話することが出来たと思います。本イベントに参加した私自身のふりかえりをKPT(Keep Problem Try)で書いてみました(→)。

オブジェクト倶楽部のイベントにまだ一度も参加されたことのないという方、是非、次の機会に参加してみてはいかがでしょうか?

Keep

・オブジェクト倶楽部イベントへの参加
・会場に余裕を持って着いた

Try

・次イベントでは、懇親会やフリースペースにも参加
・モデリング道場のメーリングリスト登録

・マインドマップを積極的に利用
・前川徹さんの『ソフトウェア最前線』を読む

・「高橋メソッド」を実践
Problem

・懇親会に参加しなかった

・フリースペースで何が行われたのか気になる



記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  

© 2006 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP