ソフト開発とビジネス その論理思考のちがい [ソフト開発者の視点]
さて、気付けばだいぶ間があいてしまいました。
このブロブの記事はEverNote上で書いているのですが今回の記事を作成したのが4/2になっているので２ヶ月も熟成させたことになります。なにぶん背伸びをしながら書いているので自分でも腑に落ちるまで時間がかかるんですよね。では、お待たせしました。（待ってた人がいるかはわかりませんが）
--------
「わかりやすく説明してください。」
ビジネスシーンで時折耳にする言葉です。特に事前配布した資料が難解だと、まず間違いなく誰かにいわれるでしょう。話が細切れだと「論理的にわかりやすく」という条件がさらに加わるのですが、今回のネタはその「ビジネスの文脈で、わかりやすく説明するための論理」と、「ソフトウェア開発で使う論理」の違いについてです。
私もソフトウェア開発で論理思考に慣れてますし、「理屈っぽい」と揶揄される人間なので（笑）「論理的」というのをわかった気でいたんですが、コンサル系や知財系の人からは「開発者（プログラマー）なら分かるかもしれないけど....」と、作った資料にNGを食らうことも多いし、....どうも非プログラマーの言う「論理的」ってやつを良くわかっていない様です。
でもねぇ、ソフト開発と他分野の「論理思考」の違いを上手く説明してくれているドキュメントって見た事無いんですよね。仕方ないんで自分の脳みそを使ってみましょうか。まずはソフトウェア技術者に取っては一番、違和感を覚える「フレームワーク」から行きましょう。
フレームワークという異物
「経営」とか「マーケティング」といった、いわゆるビジネスの世界の「論理思考（＝ロジカル・シンキング）」についての書籍で、昨今は「フレームワーク」という言葉が踊ってます。この「フレームワーク」がクセモノです。非IT系ビジネスパーソンは「思考の枠組み」という意味でこのフレームワークという言葉を使いますが、ソフトウェア技術者はこの言葉を別の意味で使います。それにビジネスの文脈での「フレームワーク」というのはソフトウェア技術者から見ると「パターン化された分析手法」に見えるんですよね。正直言って「分析パターン」と呼んでほしいところです。（ビジネスパーソンも個々のフレームワークを「SWOT分析」とか「４P分析」とかいう言い方もしますが、それでも全体ではフレームワークと言い切ってます。）さらに困った事に、この分析パターンを用いる事を「論理思考」と言い切っているフシもあります。これがソフトウェア技術者としては不思議なんです。
ソフトウェア開発者にとってフレームワークというのは、それに細かいソフトウェア部品を組込めばソフトウェアを完成させることができるものです。そうした意味ではビジネスの文脈でのフレームワークとは「思考のピースをはめ込んで思考を完成させるもの」ということになります。ロジック（論理）は「思考フレームワーク」のなかに折り込み済みって訳ですかね？こう考えるとビジネスパーソンの思考パターンがおぼろげに見えてきます。でもやっぱり、やってることは「分析パターン」を使って考えたり、説明したりですので、そもそも分析パターンと呼ばない理由がわかりません。
ここで私なりに「分析パターンとは何か」を説明すると、対象を観察・分析する際によく使われる分類・分析手法のことです。ビジネスパーソンのフレームワークは論理より「高度なモノの見方」が重要な部分占めています。これって「分析パターン」です。しかもそこで働く力は論理と言うより自然の理（ことわり）と言った方が腑に落ちるものです。この感覚はおそらくソフトウェア技術者だけでなくエンジニアや科学者全般に共通するものではないでしょうか？百歩譲って「論理思考をするための「材料の切出し」も論理思考の一部」って発想は理解できるとしても、そもそもソフト業界では同様のことをやっている「ドメイン（領域）分析」や「オブジェクト指向思考」をわざわざ論理思考とは言わないですよねぇ。そんなことしたらソフトウェア工学全体が論理思考になっちゃうから。........「論理」が工学の中心であるソフトウェア工学の方が特殊なのかもしれませんが..........これもギャップを生む原因でしょう。それから彼らは「思考の枠組み」を単なる分析に使うのではなく、自分の主張を通すための道具として使います。現実を知るために枠組みを使うのではなく、ブッチャケた話、我を通すための理論武装に利用するのですから分析パターンという受動的な呼称を使わないのは、まあ、納得ですね。
このように用語の使い方からだいぶ違うのですが、扱う対象もちがうので、IT技術者が彼らの「フレームワーク（＝分析パターン）」を使うのには、かなりの慣れが必要です。ソフト開発って「現場レベル」っていうか、具体的な仕事について扱うことがメインですが、ビジネスの世界って売込みとか提案とか、商売や経営に絡む内容がメインなんですよね。（勿論、技術系プレゼンもたくさん行われていますが、マイナーというか、視野外というか....）
で、彼らの「3C」とか「4P」とかのフレームワークを実際に使ってみるとやっぱり違和感を覚えます。はっきり言えばリアリティを感じないんです。これも多分、ソフト開発者が見ている部分と経済専門家が見ている部分が違うからでしょう。一人一人のユーザーや、個々の操作状況を思い浮かべる比重が高いソフトウェア技術者に対して、経済の専門家は「どれぐらいのユーザーが喜ぶか？」といった大きな反応に意識が集中します。売上とか利益とかを気にする立場だからリアルに感じるものが違うんでしょうね。（それとも私が彼らより馬鹿なだけ？）
論理思考と抽象思考
話はそれますが、じつは同じIT系でもインテグレータ（統括者）系のコンサルタントでは似たようなギャップが見受けられます。彼らは情報工学の高度な教育を受けていますので一流のソフトウェア開発者ということになるのですが、じつは現場での開発経験に乏しいので総じて概念的な思考に走りがちです。プログラマー出身の開発者は驚くでしょうが、彼らは所謂「手続き型」の思考が得意ではありません。ロースペックなプログラマーだと手続き型の思考しかできないのと対照的です。
「手続き型」の思考で一般にも馴染みがあるのは業務マニュアルの作成でしょう。つまり、仕事の手順を作業内容（＝手続き）ごとに分割して考える、その思考活動をソフトウェア業界では「手続き型」の発想とか思考と呼びます。これは初歩的なものなら人間なら誰でもできます。プログラマーがやっている「手続き型思考」はこれをそのままプログラムに落とし込むだけです。ただし手順や事実関係が入り組んでくると熟練したソフトウェア技術者でも理解が難しくなります。現場のユーザーは日々細かい判断を求められますから、手続き型の論理思考に結構ついて来れるのですが、日頃、概念的な事しか扱い慣れていないインテグレータ系コンサルは複雑な手続き型論理思考について来れない様です。彼らはそうしたケースにぶつかると「もっと、わかりやすい切り口があるはずだ」と考えてしまうのです。大抵の場合、その判断は正しかったりしますが、それが彼らの論理思考力の高さを証明する事にはなりません。どちらかというと「抽象的な思考力」の高さの証明と言えるでしょう。彼らが「プログラマーなら分かるかもしれないけど我々にはわかりにくい」とクレームを付けてきたら、そうした抽象的な切り口での整理を望んでいるサインでしょうね。
これとは逆にプログラマーや現場の開発者は具体的な設計とか実装レベルで考えるのに慣れているので、「何でそんな概念的な話をするのか！」と抽象思考に付合ってくれないこともあります。彼らにとって概念的なものは思考を刺激しないのです。それどころか拒絶反応さえ起こすこともあります。IT業界と言うのは何とも業の深い世界です。そしておそらく、こうした状況を見ているから私にはビジネスパーソンが言う「論理思考」が「抽象思考」にしか思えないのでしょう。
強過ぎる武器は封印すべし
さて、ビジネスの論理思考に話を戻しましょう。
先ほどビジネスパーソンのフレームワークは「論理より「高度なモノの見方」が重要な部分占める」という話が出ましたが、これは言換えると「論理は極力シンプルに抑える」ということでもあります。まずはその話からしましょうか。色々調べたんですが実際、ビジネスで使われる論理というのはそれほど多くありません。
1.「AだからBである」と理由をはっきり述べること
2.三段論法とも呼ばれる理由の組み合わせから結論を導く演繹法
3.反対事例を述べて逆説を否定する帰納法
4.論理を組み合わせる時は「真か偽か」の2値論理が基本だが、曖昧さや重複を避けること（つまり集合論）の方が重要であること
5.文章間の接続詞を的確に使って、話の流れを明確にすること
これぐらいしかありません。（これでも多いと感じる人も多いでしょうが、笑）間違っても四段論法とか五段論法とか使っちゃいけません。「かつ」とか「または」を使って複雑にし過ぎてもいけません。場合分けも1、2回が基本です。ましてや論理パズルを仕込むなんて論外です。
例えばSE上がりの起業家がビジネスプレゼンをするとしましょう。その時に「事業内容」や「製品の原理」について馬鹿正直に「論理的に、」秩序立ててプレゼンしてもまず話が通じないでしょう。元々ソフトウェア技術者が扱っているのはコンピュータに処理させるための非常に高度な論理体系です。ちょっとぐらい簡略化しても一般人の手には負えません。それに、ITコンサルタントと違い、投資家などの非IT系ビジネスパーソンは専門知識がありませんし、抽象的な思考を共有するための土台がありませんから、彼らに高度に抽象化された概念を理解してもらうのは不可能です。学生が相手でも然り。ソフトウェア技術者の最強の武器は、プレゼンでは強力すぎて相手を沈黙させる効果しか持たないんです。
逆に、目の着けどころさえ間違えなければ、プレゼンで要求される論理思考なんてソフトウェア技術者にとっては朝飯前のはずです。でも、「目の着けどころ」が以外に難しいんですよね。もともと超難解なものを超簡単にしたら突っ込みどころ満載になるのは目に見えています。それでもやれって言うのは、私らに言わせれば「だましてください」って言ってるのと同じです。でもまあ、お望みならダマして差し上げましょう。こう言うと聞こえが悪いのですが、要はソフトウエア技術者にとって「真実」と等価な「論理の積上げ」を全部端折ります。（これを端折ることは技術者にとってダマしていることとほぼ同義です）その代わりに述べるのは「問題」と「解決策」と「効果」の３つについてです。解決策や効果には理由の説明が必要ですが、先ほど述べた様に演繹法か帰納法をいくつか並べる程度に抑えましょう。そして、あまり抽象的な概念を使ってはいけません。どうしても話が抽象的になるなら具体例を挙げましょう。
え？何か違う？いやいや、そもそもソフトウェア開発とビジネスは全く粒度が違うんです。フラクタル図形の２、３階層ちがうところを見ているようなもんです。この説明もわかり難いのかな？ともかく気持ちと視点を切換える必要があります。
以上、強引にまとめると「論理的に」という言葉に惑わされるな！ってことです。
蛇足
こんなところにも論理思考
そういえば論理思考の使い方の一つにプレゼンテーションの「ストーリー」として使うというのがあります。日本ではプレゼンテーションのストーリーにも物語のストーリーと同様に「起承転結」を適用することが多いようですが、マッキンゼーとか米国の経営コンサル系では「論理思考」がプレゼンのストーリーなんです。なんか、いかにも知能レベルの高い人たちが考えそうなことですね。.......でもねぇ、今更ですが、わかりやすくする工夫が「論理思考」と言うと矛盾しているような.....確かに工夫というのは、工夫する側にとっては難しいものですが........というか論理思考は難しいだろ！（怒）
これで本当にわかりやすくなるのか
ビジネスにおける論理は「視点」が大事だと何度も述べてきました。それを使えばプレゼンがわかりやすくなるかと言えば、目が覚めるような明確な視点を打ち出せたなら、もちろんわかりやすくなるでしょう。ですが論理そのものはそれが苦手な人にとって難解な物だし、論理思考が得意な人でも今まで考えたことも無かった観点から物事を考えるのはやはり難しいものです。それでも自分の頭の整理ができるなら論理思考すべきだし、プレゼンでは伝える情報を整理するために論理を使うし、相手に論理構造そのものを伝えるためにも論理が必要です。プレゼンテーションのストーリーを論理構造にするのが常にベストとは限りませんが、元々難しいものを少しでもわかりやすく整理するために論理を使うことはできます。
ただし多少わかりやすくなったとして、それで伝わりやすくなるかどうかはまた別問題です。論理は聞き手も頭を使う必要があるので、上手く伝わらないケースも出てきます。そう、プレゼン等のコミュニケーションでは「わかりやすく」という意識設定は副次的なもので、本当は「伝わりやすく」というのが一次命題のはずです。ですが、この話は今回のテーマから外れるので別の機会にしましょう。
さて、そろそろ終りです。
私自身まだ戦い始めたばかりですから、上記の内容がどれほど役に立つかはわかりません。ご意見をお待ちしております。
このブロブの記事はEverNote上で書いているのですが今回の記事を作成したのが4/2になっているので２ヶ月も熟成させたことになります。なにぶん背伸びをしながら書いているので自分でも腑に落ちるまで時間がかかるんですよね。では、お待たせしました。（待ってた人がいるかはわかりませんが）
--------
「わかりやすく説明してください。」
ビジネスシーンで時折耳にする言葉です。特に事前配布した資料が難解だと、まず間違いなく誰かにいわれるでしょう。話が細切れだと「論理的にわかりやすく」という条件がさらに加わるのですが、今回のネタはその「ビジネスの文脈で、わかりやすく説明するための論理」と、「ソフトウェア開発で使う論理」の違いについてです。
私もソフトウェア開発で論理思考に慣れてますし、「理屈っぽい」と揶揄される人間なので（笑）「論理的」というのをわかった気でいたんですが、コンサル系や知財系の人からは「開発者（プログラマー）なら分かるかもしれないけど....」と、作った資料にNGを食らうことも多いし、....どうも非プログラマーの言う「論理的」ってやつを良くわかっていない様です。
でもねぇ、ソフト開発と他分野の「論理思考」の違いを上手く説明してくれているドキュメントって見た事無いんですよね。仕方ないんで自分の脳みそを使ってみましょうか。まずはソフトウェア技術者に取っては一番、違和感を覚える「フレームワーク」から行きましょう。
フレームワークという異物
「経営」とか「マーケティング」といった、いわゆるビジネスの世界の「論理思考（＝ロジカル・シンキング）」についての書籍で、昨今は「フレームワーク」という言葉が踊ってます。この「フレームワーク」がクセモノです。非IT系ビジネスパーソンは「思考の枠組み」という意味でこのフレームワークという言葉を使いますが、ソフトウェア技術者はこの言葉を別の意味で使います。それにビジネスの文脈での「フレームワーク」というのはソフトウェア技術者から見ると「パターン化された分析手法」に見えるんですよね。正直言って「分析パターン」と呼んでほしいところです。（ビジネスパーソンも個々のフレームワークを「SWOT分析」とか「４P分析」とかいう言い方もしますが、それでも全体ではフレームワークと言い切ってます。）さらに困った事に、この分析パターンを用いる事を「論理思考」と言い切っているフシもあります。これがソフトウェア技術者としては不思議なんです。
ソフトウェア開発者にとってフレームワークというのは、それに細かいソフトウェア部品を組込めばソフトウェアを完成させることができるものです。そうした意味ではビジネスの文脈でのフレームワークとは「思考のピースをはめ込んで思考を完成させるもの」ということになります。ロジック（論理）は「思考フレームワーク」のなかに折り込み済みって訳ですかね？こう考えるとビジネスパーソンの思考パターンがおぼろげに見えてきます。でもやっぱり、やってることは「分析パターン」を使って考えたり、説明したりですので、そもそも分析パターンと呼ばない理由がわかりません。
ここで私なりに「分析パターンとは何か」を説明すると、対象を観察・分析する際によく使われる分類・分析手法のことです。ビジネスパーソンのフレームワークは論理より「高度なモノの見方」が重要な部分占めています。これって「分析パターン」です。しかもそこで働く力は論理と言うより自然の理（ことわり）と言った方が腑に落ちるものです。この感覚はおそらくソフトウェア技術者だけでなくエンジニアや科学者全般に共通するものではないでしょうか？百歩譲って「論理思考をするための「材料の切出し」も論理思考の一部」って発想は理解できるとしても、そもそもソフト業界では同様のことをやっている「ドメイン（領域）分析」や「オブジェクト指向思考」をわざわざ論理思考とは言わないですよねぇ。そんなことしたらソフトウェア工学全体が論理思考になっちゃうから。........「論理」が工学の中心であるソフトウェア工学の方が特殊なのかもしれませんが..........これもギャップを生む原因でしょう。それから彼らは「思考の枠組み」を単なる分析に使うのではなく、自分の主張を通すための道具として使います。現実を知るために枠組みを使うのではなく、ブッチャケた話、我を通すための理論武装に利用するのですから分析パターンという受動的な呼称を使わないのは、まあ、納得ですね。
このように用語の使い方からだいぶ違うのですが、扱う対象もちがうので、IT技術者が彼らの「フレームワーク（＝分析パターン）」を使うのには、かなりの慣れが必要です。ソフト開発って「現場レベル」っていうか、具体的な仕事について扱うことがメインですが、ビジネスの世界って売込みとか提案とか、商売や経営に絡む内容がメインなんですよね。（勿論、技術系プレゼンもたくさん行われていますが、マイナーというか、視野外というか....）
で、彼らの「3C」とか「4P」とかのフレームワークを実際に使ってみるとやっぱり違和感を覚えます。はっきり言えばリアリティを感じないんです。これも多分、ソフト開発者が見ている部分と経済専門家が見ている部分が違うからでしょう。一人一人のユーザーや、個々の操作状況を思い浮かべる比重が高いソフトウェア技術者に対して、経済の専門家は「どれぐらいのユーザーが喜ぶか？」といった大きな反応に意識が集中します。売上とか利益とかを気にする立場だからリアルに感じるものが違うんでしょうね。（それとも私が彼らより馬鹿なだけ？）
論理思考と抽象思考
話はそれますが、じつは同じIT系でもインテグレータ（統括者）系のコンサルタントでは似たようなギャップが見受けられます。彼らは情報工学の高度な教育を受けていますので一流のソフトウェア開発者ということになるのですが、じつは現場での開発経験に乏しいので総じて概念的な思考に走りがちです。プログラマー出身の開発者は驚くでしょうが、彼らは所謂「手続き型」の思考が得意ではありません。ロースペックなプログラマーだと手続き型の思考しかできないのと対照的です。
「手続き型」の思考で一般にも馴染みがあるのは業務マニュアルの作成でしょう。つまり、仕事の手順を作業内容（＝手続き）ごとに分割して考える、その思考活動をソフトウェア業界では「手続き型」の発想とか思考と呼びます。これは初歩的なものなら人間なら誰でもできます。プログラマーがやっている「手続き型思考」はこれをそのままプログラムに落とし込むだけです。ただし手順や事実関係が入り組んでくると熟練したソフトウェア技術者でも理解が難しくなります。現場のユーザーは日々細かい判断を求められますから、手続き型の論理思考に結構ついて来れるのですが、日頃、概念的な事しか扱い慣れていないインテグレータ系コンサルは複雑な手続き型論理思考について来れない様です。彼らはそうしたケースにぶつかると「もっと、わかりやすい切り口があるはずだ」と考えてしまうのです。大抵の場合、その判断は正しかったりしますが、それが彼らの論理思考力の高さを証明する事にはなりません。どちらかというと「抽象的な思考力」の高さの証明と言えるでしょう。彼らが「プログラマーなら分かるかもしれないけど我々にはわかりにくい」とクレームを付けてきたら、そうした抽象的な切り口での整理を望んでいるサインでしょうね。
これとは逆にプログラマーや現場の開発者は具体的な設計とか実装レベルで考えるのに慣れているので、「何でそんな概念的な話をするのか！」と抽象思考に付合ってくれないこともあります。彼らにとって概念的なものは思考を刺激しないのです。それどころか拒絶反応さえ起こすこともあります。IT業界と言うのは何とも業の深い世界です。そしておそらく、こうした状況を見ているから私にはビジネスパーソンが言う「論理思考」が「抽象思考」にしか思えないのでしょう。
強過ぎる武器は封印すべし
さて、ビジネスの論理思考に話を戻しましょう。
先ほどビジネスパーソンのフレームワークは「論理より「高度なモノの見方」が重要な部分占める」という話が出ましたが、これは言換えると「論理は極力シンプルに抑える」ということでもあります。まずはその話からしましょうか。色々調べたんですが実際、ビジネスで使われる論理というのはそれほど多くありません。
1.「AだからBである」と理由をはっきり述べること
2.三段論法とも呼ばれる理由の組み合わせから結論を導く演繹法
3.反対事例を述べて逆説を否定する帰納法
4.論理を組み合わせる時は「真か偽か」の2値論理が基本だが、曖昧さや重複を避けること（つまり集合論）の方が重要であること
5.文章間の接続詞を的確に使って、話の流れを明確にすること
これぐらいしかありません。（これでも多いと感じる人も多いでしょうが、笑）間違っても四段論法とか五段論法とか使っちゃいけません。「かつ」とか「または」を使って複雑にし過ぎてもいけません。場合分けも1、2回が基本です。ましてや論理パズルを仕込むなんて論外です。
例えばSE上がりの起業家がビジネスプレゼンをするとしましょう。その時に「事業内容」や「製品の原理」について馬鹿正直に「論理的に、」秩序立ててプレゼンしてもまず話が通じないでしょう。元々ソフトウェア技術者が扱っているのはコンピュータに処理させるための非常に高度な論理体系です。ちょっとぐらい簡略化しても一般人の手には負えません。それに、ITコンサルタントと違い、投資家などの非IT系ビジネスパーソンは専門知識がありませんし、抽象的な思考を共有するための土台がありませんから、彼らに高度に抽象化された概念を理解してもらうのは不可能です。学生が相手でも然り。ソフトウェア技術者の最強の武器は、プレゼンでは強力すぎて相手を沈黙させる効果しか持たないんです。
逆に、目の着けどころさえ間違えなければ、プレゼンで要求される論理思考なんてソフトウェア技術者にとっては朝飯前のはずです。でも、「目の着けどころ」が以外に難しいんですよね。もともと超難解なものを超簡単にしたら突っ込みどころ満載になるのは目に見えています。それでもやれって言うのは、私らに言わせれば「だましてください」って言ってるのと同じです。でもまあ、お望みならダマして差し上げましょう。こう言うと聞こえが悪いのですが、要はソフトウエア技術者にとって「真実」と等価な「論理の積上げ」を全部端折ります。（これを端折ることは技術者にとってダマしていることとほぼ同義です）その代わりに述べるのは「問題」と「解決策」と「効果」の３つについてです。解決策や効果には理由の説明が必要ですが、先ほど述べた様に演繹法か帰納法をいくつか並べる程度に抑えましょう。そして、あまり抽象的な概念を使ってはいけません。どうしても話が抽象的になるなら具体例を挙げましょう。
え？何か違う？いやいや、そもそもソフトウェア開発とビジネスは全く粒度が違うんです。フラクタル図形の２、３階層ちがうところを見ているようなもんです。この説明もわかり難いのかな？ともかく気持ちと視点を切換える必要があります。
以上、強引にまとめると「論理的に」という言葉に惑わされるな！ってことです。
蛇足
こんなところにも論理思考
そういえば論理思考の使い方の一つにプレゼンテーションの「ストーリー」として使うというのがあります。日本ではプレゼンテーションのストーリーにも物語のストーリーと同様に「起承転結」を適用することが多いようですが、マッキンゼーとか米国の経営コンサル系では「論理思考」がプレゼンのストーリーなんです。なんか、いかにも知能レベルの高い人たちが考えそうなことですね。.......でもねぇ、今更ですが、わかりやすくする工夫が「論理思考」と言うと矛盾しているような.....確かに工夫というのは、工夫する側にとっては難しいものですが........というか論理思考は難しいだろ！（怒）
これで本当にわかりやすくなるのか
ビジネスにおける論理は「視点」が大事だと何度も述べてきました。それを使えばプレゼンがわかりやすくなるかと言えば、目が覚めるような明確な視点を打ち出せたなら、もちろんわかりやすくなるでしょう。ですが論理そのものはそれが苦手な人にとって難解な物だし、論理思考が得意な人でも今まで考えたことも無かった観点から物事を考えるのはやはり難しいものです。それでも自分の頭の整理ができるなら論理思考すべきだし、プレゼンでは伝える情報を整理するために論理を使うし、相手に論理構造そのものを伝えるためにも論理が必要です。プレゼンテーションのストーリーを論理構造にするのが常にベストとは限りませんが、元々難しいものを少しでもわかりやすく整理するために論理を使うことはできます。
ただし多少わかりやすくなったとして、それで伝わりやすくなるかどうかはまた別問題です。論理は聞き手も頭を使う必要があるので、上手く伝わらないケースも出てきます。そう、プレゼン等のコミュニケーションでは「わかりやすく」という意識設定は副次的なもので、本当は「伝わりやすく」というのが一次命題のはずです。ですが、この話は今回のテーマから外れるので別の機会にしましょう。
さて、そろそろ終りです。
私自身まだ戦い始めたばかりですから、上記の内容がどれほど役に立つかはわかりません。ご意見をお待ちしております。
コメント 0