ソフトウェア開発

そんなことばっかりやっていたら、ソフトウェア開発がどんどん面白くなくなってしまうよ。本当はもっと楽しいもののはずなのに。

こんな話を聞いた。
//
ソフトウェアを開発している組織が守るべき規則を決めて、
その組織が規則を守っているかどうかを検証するのが、
ソフトウェア品質保証だという人がいる。

その人がどんな規則を決めているのかを聞いてみると、
それは、CMMIの焼き直しで、「車輪の再発明もどき」だ。
CMMIというのは、カーネギーメロン大学が作ったソフトウェア開発プロセスモデルだ。
それはとてもきちんとしている。

今、CMMIの真似をして、その人が作った規則を「スーパー革命ルール」と呼ぼう。
スーパー革命ルールは、所詮「もどき」なので、CMMIには劣る。

スーパー革命ルールの作者を「革命君」と呼ぶことにすると、

革命君は声を大きくして、
「ソフトウェア開発に関わっている人すべてが、この素晴らしいスーパー革命ルールを知らないといけない!」と叫ぶのだという。

もちろん、多くの人は、スーパー革命ルールは自分の仕事には関係ないし、革命君はなんだか胡散臭いと感じるので、軽く無視する。
少し過激な人だと、「スーパー革命ルールなんて自分たちには必要ない!!」と公言してしまう。

すると、それを聞きつけた革命君は、
「こんなに素晴らしいものが必要ないなんて、けしからん!」
「そんなことをいう人が組織のリーダーをやっているなんて、その組織も終わりだ!」
と、まわりにいる人たちに当り散らす。

それから革命君の自画自賛の演説が30分以上続くのだが、まわりの人も忙しいので、適当に聞き流す。

すると革命君は、「そういえば、この間、あの人にあったけど、その人の自分に賛同してくれた」と自己弁護を開始して、さらに30分以上、自分の言いたいことだけいうと、気がすんだのか、どこかにふらっと消えていくのだという。

ちなみに、革命君は仕事をほったらかして、いろいろな業界の集まりに出かけることが多いので、そこそこ名の知れた有名人とも面識があるらしい。もっとも相手が革命君のことをどう思っているかまでは分からないらしい。
//
どうだろう。
こんな話は、どこの会社や学校にでもよくあることではないだろうか。

僕がとくに気になったのは、革命君が「車輪の再発明」をしてCMMIもどきの「スーパー革命ルール」を作ってしまう件だ。
実は「スーパー革命ルール」の教育とルール自体の見直し作業が、継続して行われており、一部の集団に利益をもたらしている。
しかも「スーパー革命ルール」は実際には使われていないのは、上の話の通りだ。

一部の集団が、自分たちに利益を誘導するために、多くの人には必要のないものをつくっている。
そして、一度その利益誘導システムが出来上がると、あとは必死に守ろうとする。

国政レベルで良くみる構図だが、ソフトウェア開発に関わる組織でも同じことが起こっていることに気づいてビックリした。
//
今回聞いた話はここまで。

「革命君に革命は起こせないと思う」


| | コメント (0) | トラックバック (0)

品質保証の見学会は、思いつきだけで催された。

世の中には、一見無意味に見えることでも、
見方を変えればそれなりに意味がでてくることがある。

先日、あるソフトウェア開発企業の、品質保証の状況を見に行ったのだが、
そこで見聞きしたことも、
そんな、一見無意味に見えるわりには、そこそこ面白かったことの一つだ。

もともと、その見学話は、ある管理職の思いつきから始まった、
本当に誰の得にもならないような、
いやむしろ、準備のために、いろいろな人たちの手を煩わせるだけの、
本当につまらないことだったのだ。
よくこんなつまらないことを思いつくものだと、つくづく感心する。

実際、見学会(審査会という名前がついているのだが)で配られた資料や、
その場での説明は、特に目新しいことはなく、通り一遍のものだったのだが、
思いのほか沢山の人が出てきてくれて、大げさにしてくれて、
こんな会に、そこまで準備してくれて申し訳ない、というものだった。

いくらつまらない会でも、誰も発言しないと気まずいし、
いろいろ準備してくれている、相手の会社の人々にも失礼なので、

とりあえず、日頃自分の組織のソフトウェア開発部門に聞いていることや、
調べていることや、気になっていることを、いくつか聞いてみたりした。

そんな見学会は、他にもいくつかの会社で催されたのだが、
会に出席していると、いくつか面白いことに気がついた。

まず、当たり前だが、どこの会社も問題があるという話はしない。
どこも「上手くいきました」としか言わない。
こちらが、失敗したことも知っているのは明白な場合でも、「上手くいきました」という。

つぎに、ちょっと専門的な話をした場合に、
こちらの意図をくんできちんと答えられる人が、どこの会社にも一人はいる。
もしかしたら二人いるかもしれないが、三人はいない。

また、つっこまれると、ムキになって否定したり、
「どこの会社でもやっている」というような無茶な言い訳を必死にする人がいる。
そんなのは、中間管理職に多い。

あと、緊張しているのか、説明するときに声がうわずってしまう人もいる。
開発リーダクラスか。
その緊張している人を横からサポートするサブリーダはなぜか落ち着いている。
良いコンビなのだろう。

それから、雰囲気がわるくなったときに場を和ませる役の人や、
話題を変える役の人もいて、
会議進行システムとして、そういう人たちも必要なんだろうな、と思う。

まぁ!

そんな感じで、結構楽しめた。

ソフトウェア開発に携わっている人には、
いつも真面目に仕事をこなしている人が多いと思うけれど、

たまには誰かの思いつきに乗っかって、

その思いつきを楽しんでみるのも、

良いのかもしれない。

| | コメント (0) | トラックバック (0)

現代的なソフトウェア開発には、現代的な組織が必要だ

現代のソフトウェア開発は分業化が進んでおり、要求分析からリリースまでの全てを、一人で担当することは少なくなっている。
また、それに合わせて、要求分析の専門家、コーディングの専門家、テストの専門家といったように、ソフトウェアの専門職化も進んでいる。
とくに大きなメーカーでは、それぞれの専門分野ごとに部や課を分けており、その部門に配属されると、その部門の担当する種類の仕事だけをやっていくことになるというのが一般的だ。

例えば、開発課が要求分析を担当して、方式設計からソフトウェア結合までは専門のソフトウェアメーカーに外注し、納品されたソフトウェアの適格性確認テストを開発課が行い、機能と性能を確認した後は、テスト部門が検証を行い、ソフトウェア製品の品質を確認するといった具合だ。

このように分業化が進むのは、ソフトウェアエンジニアの専門性を高めることにつながり、好ましいことだと思うが、その一方で、要求分析からリリースまでを俯瞰的に見渡して、適切なマネジメントができる人材が少なくなっているのも事実だ。

実際にプロジェクト崩れを起こしているチームの状況を調べてみると、どのチームも、進捗管理、構成管理、リスク管理ができていないことが共通している。

それらのマネジメントに関わる仕事は、要求分析、方式設計、詳細設計、コーディング、、、といった個別のフェーズを実行するための技術やスキルとは別の技術でありスキルなのだが、失敗しているチームを管理する組織の長が、そのことを理解していないのだ。
つまり、彼らは、個別の開発フェーズを実行する担当を割り当てた時点で、計画を立て終わったと思いこみ、その計画を実現していくための方法を考えることや、その計画実現の担当者の割り当てや、計画の進捗状況に気を配ることを忘れてしまうのだ。

なぜそんなことになるのか?

実は、彼らは忘れているのではなくて、マネジメントを意識していないからだと思う。

多くの会社では、開発部門の組織の長、つまり部長や課長は、ほぼ全員、エンジニアから昇進した人々であり、もともとマネジメントの教育を受けていない。
さらに悪いことに、彼らは共通して、力任せに仕事を片づけてきたり、顧客との間でなんとなく仕事が片付いていく運の良い仕事を担当したりして、そして結果的にはうまくいったという「成功体験」」を持っている。

そんな人たちなら、マネジメントの重要性を意識できなくても、仕方がないだろう。

問題は、そんな彼らにでも、会社の中間管理職の仕事ができているように見えるということであり、さらに、その中間管理職の仕事ができることが、ソフトウェア開発を管理できるという国民的誤解につながっていることだ。

これは大問題だ。
実際に、ソフトウェア開発がとん挫し、ソフトウェアエンジニアが疲弊していく原因は、彼ら中間管理職が作り出しているのだから。

今後、世界はより多くのソフトウェアによって動かされていくし、そのソフトウェアを作り、支えるソフトウェアエンジニアは膨大な人数が必要になるだろう。

そんな世界を、古い体制に組み込まれているだけの中間管理職や、彼らを構成要素とする古い会社が、生き抜いていけるのだろうか?

それは不可能だ。

しかし、今あるものを一切捨てて、新しく作り直すのは、多くの会社にとって、不可能とは言えないまでも、非常な困難を伴うことだろう。

会社の昇進の仕組みを、根本的に変えることが、多くの会社にとって困難であるのなら、既存の中間管理職からなる構造とは別に、ソフトウェア開発のマネジメント構造を作ればよい。そして、徐々に、重点を新しい組織に移していけば良い。

古い価値観から新しい価値観への連続的な変化。

それこそが、今、すぐに取り掛かれなければならない、テーマだ。

| | コメント (1) | トラックバック (0)

評論家と定量データオタクなんて、いらない

■日々の疑問

最近のソフトウェア開発を見ていると、

・プロセス通りにやっていない
・品質データがよくない
・そもそも品質データをとってない

というようなことを、アセスメントや品質保証を業とするソフトウェアの品質向上に関わる人々が、盛んに強調しているのを見かけることが多い。

そしてその後、彼らが、状況を改善するための具体的な何かをするのだろうかと見ていると、何もせずに言いっぱなしになっていることも多い。

自分たちが「問題がある」と評価して、それを改善するように指摘したのなら、言いっぱなしは無責任ではないだろうか?

そして、実際にソフトウェアを作っている人々が、指摘されていることはわかるが、実際に何をしたら良いのかをもっと具体的に教えてほしいと訴えても、アセッサたち(アセスメントをする人々)は抽象的な指摘をするのが仕事で、その指摘を具体化するのは、あなたたちの仕事だといって突き放す。

なるほど。アセッサの言い分もよくわかる。

彼らが言うように、仕事の分担は明確にするべきだし、具体的な指摘をするのはアセスメントの範囲ではないし、そこまでの報酬ももらっていないのだから仕方がない。

しかし、実際のところ、具体的な改善方法がわからないと言っている相手に、そんな正論を唱えても、なんら効果はないし、わざわざ費用をかけて、彼らにアセスメントをしてもらった組織は、まったくの無駄金を使ってしまったことになる。なにしろ、効果がないのだから。

しかし、そもそも、アセッサや彼らにアセスメントを依頼する組織のマネージャ達は、上のような、ソフトウェア開発に本当に必要かどうかわからないことばかりに注目し、とにかくやれ!と開発部隊に強要することに、疑いを持っていないのだろうか?

プロセスがそれほど重要なのだろうか?
品質データをとって、数字の上で議論することが重要なのだろうか?

そんな疑問は浮かばないのだろうか?

評論ばかりで実際に改善効果に結びつかないアセスメントが、本当に費用に見合うものだと信じているのだろうか?

そんな話をソフトウェア開発を業とする友達に話してみたところ、彼は、アセッサも品質保証担当者も、組織のマネージャも、現実のソフトウェア開発に直接には携わっていない人々なので、そういう疑問は浮かばないのだろうと言っていた。

なるほど。

■ソフトウェア開発技術の進歩に管理手法も追いつくべき

確かに、昔のソフトウェア開発には、そういった管理の仕方が適切だった時代があったのだろうし、いまでも特定のドメインではそれが適切かもしれないが、現代的で先進的なソフトウェア開発ではプロセスが最重要ではないし、設計書のレビューに何時間かけたかとか、文書の欠陥をどれだけ見つけたかとか、そんなことは重要ではなくて、どれだけ早く、動くソフトウェアを作るかがクオリティーではないだろうか?

正直なところ、CMMIやSPICEのモデルは時代遅れに感じる。
そして、そのモデルを使って、訳知り顔で評論するアセッサには嫌悪感を感じる。

そして、SQA(ソフトウェア品質保証)を名乗って品質データを集めることを目的化している連中はソフトウェア開発の阻害要因にも感じる。

もちろん、中には、ソフトウェア開発に有益なアセスメントやSQAもあるのだろうが、実際に目にすることが多いのは、最新のソフトウェア開発や技術の進歩に無頓着で、時代遅れな、評論家や定量データオタクだ。

ソフトウェアは常に進歩しているのに、彼らはずっと過去に止まったままだ。

なぜもっとソフトウェア開発技術自体の進歩に気づこうとしないのか?

先の友達いわく。

「だから。彼らは直接、ソフトウェア開発に携わっていないのだから、その進歩に気づかなくて当然なんだよ。」

なるほど。

| | コメント (0) | トラックバック (0)

アセスメントサービスの弊害

ソフトウェア業界では、しばらく前から、開発組織の成熟度を診断するというふれこみで、CMMIやSPICEという名前の付いたアセスメントサービスを業とする人々が出てきている。

そういうアセスメントサービスでは、それぞれの流派で診断につかうモデルがあり、ソフトウェアを開発するために必要な事柄が定義されている。

そのモデル自体は良い。経験に基づいてよく整理されているので、実際にソフトウェアを作っている人々が自分たちの問題点を見つけだして、開発にともなう苦労を少なくするのに有効に使える。

しかし、アセスメントサービスには問題も多い。

まず、ソフトウエア開発自体の役には立たない。
つまり、アセスメントを受けたからといって、その組織のソフトウェア開発能力が高まるわけではない。これは当たり前だ。

また、アセッサ(アセスメントを行う人)の説明が抽象的すぎて、組織の問題点に直接言及していないことが多く、アサッセが言っていることは一般論としてはわかるが、さて実際に自分たちのことに置き換えようとすると、何をして良いのかわからないということが非常に多い。

この2点だけでも、ソフトウェア開発組織の目的には、直接には役に立たないサービスだと言える。

さらに別の問題がある。
それは、アセスメントで「成熟度が高い」と評価されると、その組織の作るソフトウェアの品質が高い、という誤解を、他の組織に与えてしまうことだ。
これは、日本の会社が、中国やインドの会社にソフトウエアを外注する場合などに問題になる。日本の会社にしてみれば、アセスメントサービス会社が与えた「成熟度が高い」というレッテルを信じて発注するのだが、実際はそのレッテルは「高品質のソフトウェア」を意味していないので、納入されたソフトウェアはバグだらけ、ということが起こっても不思議ではないということだ。

これに至っては、受注したい会社が、アセスメントサービス会社を利用して作為的に誤解を生じさせるといったことも可能であるため、さきの問題よりも大きな弊害かもしれない。

最後に、アセスメントサービスは非常に高額だ。
一回の診断(1~数週間)で500万円という値をつけてくる会社もある。
余程、資金に余裕のある会社以外は、おいそれと出せる金額ではないだろう。
さらに悪いことに、ヨーロッパの自動車業界ではAutomotiveSPICE(SPICEの一種)の一定の成熟度であることを、部品の調達先企業の選定条件にしているし、日本でもSPICEを選定条件にしようとしている組織も出てきている。
そうすると、力はあるが資金力に乏しいソフトウェアハウスが、飛躍のチャンスを逃すことにつながり兼ねない。
これも、アセスメントサービスがもたらす弊害と言える。

以上から、日本のソフトウェア業界は、最近広がりつつあるアセスメントサービスについては、何も考えず受け入れるのではなく、弊害をとくに重視して、関わり方を決めていく必要があると思う。

| | コメント (0) | トラックバック (0)

忙しいには理由がある

最近のシステム開発やソフトウェア開発は、規模が大きくなっている一方で、開発期間も短くなっているため、忙しくて働きすぎになりすぎな仕事だ。

また、忙しい忙しいと言っている人の働きっぷりを見ていると、確かに尋常でない忙しさであるように見える。しかし、そんな人に限って、「自分でより一層忙しくしてしまっている」傾向にあることも多い。

それは一体どういうことなのか?

■設計しないので、さらに忙しくなる
忙しいので設計している暇がない。
そんな声をよくきく。
しかし、設計しないまま、ソフトウェアを作ったり、ハードウェアを作ったりすると、それらを組み合わせたときに、正しく動くはずがない。
結局、作り直しになり、仕事が増える。
忙しい。

■計画を立てないので、さらに忙しくなる
忙しいので計画を立てている暇がない。
そんな声をよくきく。
しかし、計画を立てずにソフトウェアを作ったり、ハードウェアを作ったりすると、
・いつまでに何をつくれば納期に間にあうのか?
・今何をやっているのか?
・次に何をやれば良いのか?
・今、どこまで進んでいるのか?
・一体、自分は何をしているのか?
が、分からなくなり、道に迷ってしまう。
迷っているうちに納期が迫ってくる。
忙しい。

■構成管理をしないので、忙しくなる
忙しいので構成管理をしている暇がない。
そんな声をよくきく。
しかし、構成管理をしていないと、
・あのファイルはどこにあるんだっけ?
・最新のファイルはどれだっけ?
・あの人に渡したファイルはどこだっけ?
・こないだもらったファイルはどこに置いたっけ?
・リリースしたファイルはどれだっけ?
と、あれこれファイルを探し出さなければならなくなる。
そうこうしているうちに、ビルドできなくなってしまったり、
昔のバグがまた出てきてしまったり、
お客さんに怒られて謝りにいったり、
忙しい。

と、まぁ、こんな「忙しいには理由がある」という話は枚挙に暇がない。
最初にきちんとしておけば、忙しさはかなり軽減することができる。

ソフトウェア工学の原則にD.R.Yというものがある。
「同じことを2度繰り返さない(Don't Repeat Yourself)」という意味だ。

先のような忙しい人の悪い習慣とはまさに対極にある考え方だ。
一度身についた習慣から抜け出すのは難しいので、最初からきちんと正しい習慣を身につけたいものだ。それこそ、まさにD.R.Yと言える。


| | コメント (0) | トラックバック (0)

餅は餅屋

■単一スキルのソフトウェアエンジニア
とあるソフトウェアエンジニアの考えによると、最近の開発案件がうまくいかないことが多いのは、ソフトウェア開発企業がプログラマ候補ばかりを採用することと、入社後もプログラマ養成教育ばかりを行っていることが原因だと言う。

その結果、現代的なソフトウェア開発で重要性を増しているプロジェクトマネジメント、設計、テスト、プロセス設計などのプログラミング以外の部分が非常に弱くなっているというのだ。

■責任分担
これには、歴史的経緯というものが関係していると思う。
つまり、ソフトウェア開発企業の多くは、もともと機械メーカーや電機メーカーのソフトウェア製造部門だったものが子会社として独立した会社が多いため、設計、テスト、開発管理を親会社が行い、ソフトウェアの製造の部分だけを子会社が担当するという関係が固定化してしまったのだろうと思われる。

■失敗しないという思い込み

また、設計を徹底的に行って仕様化すれば、その仕様を実装したソフトウェアは完璧に動作するという思い込みと、苦労して作った仕様書やソフトウェアには欠陥が含まれないという思い込みが、そのような責任分担による開発を偏重する組織の思考の背後にあるのだろう。

■ソフトウェアの特殊事情
もちろん、そういった関係は機械部品や電気部品や金型でなら、うまく責任分担ができて良いのかもしれないし、そのような分野であれば、上の思い込みは正しいのかもしれない。

しかし、ソフトウェアは設計書通りに作れば良いとか、大量生産の歩留まりがどのくらいとか、そういう工業製品とは違う。設計はコーディングそのものと考え られるし、設計の最初の段階からテストを考える必要がある。その意味ではテストもコーディングそのものと言えるかもしれない。

さらには、ソフトウェアはいつも一品生産であり、工業製品と言えるのは、完成したソフトウェアをCD-ROMなどのメディアに焼くところだけであることを考えると、ソフ トウェアは工業製品ではなく、むしろ工芸品や芸術品に近い存在だと言うこともできるのではないだろうか。

■餅は餅屋

このように、機械部品や電気部品などのハードウェアとソフトウェアとは全く違うものなので、ハードウェアしか作ってことのない機械メーカーや電機メーカーにソフトウェアがうまく作れないのはむしろ当然だ。彼らが、自分たちの専門分野の枠組みでソフトウェアをとらえようとする限り、彼らがソフトウェアという概念を正しく形成することさえも困難かもしれない。

もしそうであるとするならば、彼らが自分たちで中途半端に設計やテスト、あるいは開発管理するのをやめて、ソフトウェア開発はソフトウェア専門メーカーに任せてしまうというやり方について検討を始めても良いのかもしれない。

■苦手なことを知る

企業は利益をあげるのが仕事だ。自分の知らない分野や苦手な分野に無理に入っていくことは、経済的には必ずしも良いことではないと気づくことも大切だ。

WOZ

| | コメント (0) | トラックバック (0)

ソフトウェア品質保証の仕事

ソフトウェア品質保証の仕事を、北風と太陽の寓話に例えて、開発部門に規則を強制するのではなく、規則を守るメリットを伝えて納得してもらう「太陽」のようなやり方をした方が良いという人がいる。

しかし、それは間違った考え方だ。

最初の間違いは、北風と太陽の寓話は「状況によって手段を臨機応変に変えるのが良い」という話であり、必ずしも「太陽」のやり方が良いという話ではない。

次に、規則は守っても守らなくても良いものではなく、守らなくてはならないものだ。開発部門が納得しているかどうかは関係ない。

例えば「飲酒運転はしてはいけない」という規則に納得できなければ、規則を無視して飲酒運転しても良いのか?

あるいは「人のものを盗んではいけない」という規則に納得できなければ、規則を無視して窃盗しても良いのか?

規則が存在する社会で、そんなことはありえない。

それらと同様に、ある組織がソフトウェア開発の規則を定めていれば、開発部門がそれに従うのは当然だ。

品質保証部門は、開発部門が規則を守っているかどうかをチェックし、守っていなければ強制的に守らせなければならない。

証拠調べを徹底して行い、開発部門の間違いを探し出して、その間違いを正す。

それはちょうど、会計監査部門の仕事と同じだ。

会計監査部門の仕事なら、冒頭の「北風と太陽」になぞらえる人はいないだろう。

ソフトウェア品質保証も会計監査と同様、組織が規則違反を犯すことで破綻するのを、未然に防ぐ仕事だ。

今一度、品質保証部門の責任と権限をきちんと考えたい。

★WOZ★

| | コメント (0) | トラックバック (0)

質も量も大事

とある設計書のレビュー会が、予定時間の半分で終わった。

設計書の出来がいつもより良かったのと、参加者がレビューポイントを明確に意識していたのが良かったのだろう。

質的に、とても良いレビュー会だったと思う。

しかし残念ながら、こういう質的な部分は定量データにしてしまうと見えなくなってしまう。

定量的には、いつもより時間が短いので不十分だ、と評価される可能性が大きい。

そして、結果的にレビュー指摘密度が高くなっていると、設計書の質が悪いと評価されるかもしれない。

しかし、実際には設計書の質は良かったのだ。

そして、参加者の質も心構えも十分に良かったのだ。

だから、この場合、定量的評価は実態を表してはいないことになる。

ソフトウェア業界は、全体的に、定量的な評価を重視しがちな風潮があるが、同時に質を考えることの重要性を忘れてはならない。

★WOZ★

| | コメント (0) | トラックバック (0)

設計書を作るのに”遅すぎる”ということはない

ソフトウェア開発では、

  • 開発期間が短い
  • 開発メンバーが少ない
  • いつの間にか納期が迫っている
  • 忘れていた
  • 最初から作るつもりがなかった

など、様々な理由で設計書が作られていないことが多い。
それは、設計書をつくらなくても、プログラミングさえすれば動作するソフトウェアが出来上がってしまうためだ。

実際、僕自身も仕事や勉強で使う”ちょっとしたツール”をつくるのに、わざわざ設計書を作ったことがない。機能を試しながら作ったプロトタイプが、そのまま普段使うツールになることが多い。

しかし、ソフトウェア製品となると話が別だ。
規模も大きいし、リリースした後も長く保守しつづける必要がある。
設計書がないと、検証や妥当性確認ができないし、移植や保守も非常に困難になる。

もうリリース間近になって、あるいはリリースしてしまって、いまさら設計書なんて作っても意味がないと、開発チームの人々は考えるかもしれない。

この先、その製品がバージョンアップしたり、バグを修正する必要に迫られないのなら、それは事実だ。設計はいらない。

しかし、その可能性が少しでもあるのなら、リリースしてからでも良いので、ソースコードから設計書を書き起こしておきたい。
わかりやすいところからソースコードを読み解くのが基本だが、EnterpriseArchitectなどのリバースエンジニアリングツールを用いれば、ソースコードからクラス図やシーケンス図を自動生成することができるので、設計書作成の強力な助けになるはずだ。

★WOZ★



| | コメント (0) | トラックバック (0)