2013年09月05日

ボーイング787被雷

忙しい仕事の合間を縫って、遅い夏季休暇を取り、地元の宮崎に帰省してきました。
台風の影響で雨ばかりの4日間でしたが、暑くもなくそれなりに快適に過ごせました。

帰省する前々日台風15号が発生して、飛行機が飛ぶかどうか心配していましたが、前日の夜に熱帯低気圧に変わって無事宮崎に降り立つ事ができました。
自分が帰省している間、関東では、大雨や竜巻で大荒れの様子が連日ニュースで報道されていたので、自分が休んでいる間に仕事をしている会社のみんなに大変申し訳ないと思いつつ、本心は、宮崎にいて良かったと思っていました...ふらふら

でもそんな私にも不運は巡ってきました。短い休みも終わって東京に戻る日、父親に空港まで車で送ってもらって手荷物を預けて、東京に戻る直前に発生した台風17号も、戻る当日には熱帯低気圧になって定刻通り離陸できることを確認して一安心して、父親と軽くコーヒーを飲んだあと、簡単にお別れを済ませて手荷物検査場を抜けてゆっくりしていたところ。
ANAから「東京行き 11:25発の ANA 608 便が、宮崎空港に来る途中に被雷し点検のため出発が遅れます...」とアナウンスが入りました。
じぇじぇ〜!がく〜(落胆した顔)



自分が搭乗予定の飛行機を出発ロビーの大きな窓から見てみると、最新鋭のボーイング787の機種部分で何やらゴニョゴニョ作業をしていました。
被雷することぐらい考慮して設計していると思うので大丈夫だとは思いますが、現代の飛行機は精密な電子機器の塊ですから少なからず不安はあります。しかも、最近何かと話題の絶えないボーイング787なので余計です。
でもGSユアサとボーイングが完璧に改修してくれていると信じて、点検の終わったボーイング787に1時間遅れてで乗り込みました。
結果的に、こうしてブログを書いているということは何事もなく無事に飛行できたということなのですが、被雷で出発が遅れるなんて初めての事だったのでちょっと動揺してしまいました。
夏に地元に帰ることはあまりないのですが、暑いと積乱雲も発生しやすいし、台風の心配もあるし、不足の自体を想定しておく必要がある事を改めて実感しました。

posted by j.shiozaki at 14:44| Comment(0) | TrackBack(0) | 日記

2013年08月25日

ZAMST RK-1 ランニングヒザサポーター

昨日スポーツ用品店で買った ZAMST の ランニングヒザサポーターを、さっそく使ってみました。
まず使ってみた感想は、大変GOODでした、いつも4Kmあたりで、ひざの感覚がなくなって力が入らなくなってしまっていたのですが、今日は4Kmを超えてもしっかりしていて初めて5Kmを走り切りました。



注意点としては、走る直前に装着することです。自分は着替える時にサポーターをシッカリと装着してしまい、そのまま準備運動をしたのですが、このサポータはかなりひざの動きを束縛するため、ふくらはぎのならしが不十分で途中で足がつってしまいました。
着替える時は、ひざ下のふくらはぎあたりにずらしてつけておいて、準備運動をシッカリした後にひざに装着するというのがいいやり方かと思います。
走っている時には、適度に反発力があって、確かにひざのねじれを防いでくれている感覚があります。使い始めはちょっと上につけすげて若干太ももに痛みがあったのですが、ひざ上ギリギリにつけ直したら解消しました。適正サイズを買ったのですが、若干きつめなので、装着には若干神経をつかいます。
走り終わってサポーターをはずすと、若干ひざの痛みがありましたが、5km を走り切った事を考えると上場だといえます。
後は体重を減らしてひざの負担を減らすようにがんばります。
posted by j.shiozaki at 23:18| Comment(1) | TrackBack(0) | 日記

2013年08月24日

ジョギングアイテム

ダイエットのためにジョギングを始めて早3ヵ月た経とうしています。最初は2Kmも走れば息が上がってしまったのですが、今では歩きなしで4Kmを普通に走れるようになりました。
しかし、90Kgを超える体重を支えるにはひざに負担が大きすぎてひざの痛みに耐える日々を過ごしています。
走り始めて1ヵ月が経過して3km 走れるようになった頃に初めてひざに痛みが起きるようになりました。
走っている時はアドレナリンのおかげなのな、あまり痛みを感じないのですが、走り終わって落ち着いてくると不意にズキッときます。
特に、朝起きてベットから起きて立ち上がる瞬間が恐怖ですね。今日は痛くありませんようにと願いながら立ち上がります。

そこで、周りのジョギング愛好家の方々にいろいろ相談にのってもらい、いくつかアイテムを揃えました。
まず始めに買ったのがジョギングシューズです。ジョギングを始めた時は、近所の量販店で4000円程度で売られている安物のシューズを履いていたのですが、そんなシューズではひざを痛めるのは当たり前だとみんなに注意されました。
当初私は、ちょっと走るだけなのに高価なシューズは必要ないと思っていたのですが、とりあえずひざの痛みがおさまるのならばと思いシューズを買い直すことにしました。その時のみんなのアドバイスは、

@日本人の足には国内メーカーのアシックスか、ミズノがいい。
Aネットで買ってはダメ、必ずスポーツ用品店でためし履きすること。
B重くてもクッション性の高い物を選ぶこと。

の3点でした。ネットで調べても同じような事が書かれているので、これはジョギングをやる時の基本中の基本のようです。自分は何も知らずにがむしゃらに走っていただけなので、キチンと下調べをしておくべきでした。ふらふら

で、購入したのはアシックスの GT-2000 です。店員の話では、幅広でクッション性が高く初心者向けだということでこれに決めました。前使っていたシューズの3倍の値段でしたが、その価値はありました。

始めは半信半疑でしたが、翌日のひざの状態がすこぶるよくて、朝起きてひざが痛むということがなくなりました。シューズでこんなに変わるなんてちょっと驚きでした。

そこで、ジョギングのペースも良くなり、距離も少しずつ伸ばせるようになってきたのですが、2ヵ月を経過したころ、距離も4km に届こうという時にまたひざが痛むようになりました。そこで週4回走っていたのを週3回に減らして回復期間をながくして対応しましたが、また最近4kmランが普通になってくると時々ひざが痛むようになってきました。

これ以上ジョギングの回数を減らすのも、距離を短くするのもいやなので何かいい方法がないか考えていたのですが、その時いいサポーターがあるという話を聞いてさっそく購入しました。
ZAMSTというメーカーのもので両ひざで7000円となかなか高価なポーターです。


まだ試していないのですが、明日のジョギングの時にさっそく使ってみようと思います。
いままで膝が痛くなって4kmどまりだった距離が5kmまで伸ばせるようになればうれしいです。
posted by j.shiozaki at 18:10| Comment(0) | TrackBack(0) | 日記

久しぶりにアップデート

超久しぶりに J.S Draw をアップデートしました。おそらくJ.S Draw をいじるのもこれで最後になると思います。
元々 J.S Draw は、自分のスキルアップのために作ったもので、普段の仕事では絶対にやらないような、かなりトリッキーなコーディングをしています。そのため、数行のコーディングに1ヵ月かけたり、難解なバグに悩ませられたりといろいろ楽しませてもらいました。
作成には2年以上かかりましたが、おかげで目的は十分果たしてくれました。

ホームページで J.S Draw のソースを公開していましたが、描画を行う本体である J.S Draw ControlLibrary は dll のみの提供としていたため、数人の方からソースコードを提供してほしいと問い合わせがありました。
そこで、今回は、J.S Draw ControlLibrary のソースコードもダウンロードできるようになっています。
僭越ながら私のスパゲッティ状態のソースコードが何かのお役に立てれば嬉しく思います。

posted by j.shiozaki at 16:27| Comment(0) | TrackBack(0) | J.S Draw

SZJ006 顧客に誠実に対応する事の重要性

顧客の信頼を一度失うと、それを取戻すのは並大抵なことではありません。信頼がないと、ちょっとスケジュールの遅れや、プログラム不具合に対しても敏感に反応し、徹底的に叩かれてしまいます。
では、どのような時に顧客の信頼を失うのでしょうか?

スケジュールが遅れた時?
不具合が発生した時?

いえいえ、こんなことでは信頼は失いません。
この程度のことはシステムを開発する上で当たり前のことなので、顧客も織り込み済みです。
ではどんな時かというと、

スケジュールが遅れた時の対応。
不具合が発生した時の対応

です。
つまり、スケジュールの遅れや、不具合などの、問題が発生した時に適当な対応をすると顧客の信頼を失ってしまうということです。
信頼を失った後に、いくら頑張って挽回しても一度失った信頼は決して元の状態には戻りません。そこで、顧客の信頼を失わないように普段から発生した問題への対応には最大限の注意を払う必要があります。

では次に、問題が発生した時にどのような対応をすればよいでしょうか?

<問題が発生した時>
問題が発生したらすぐに回答します。問題を放置することは絶対にやってはいけないことです。
できれば問題が発生した翌日に回答を返すのがいいでしょう。
すぐに解決策が見つからないものは、何時までに調査して回答しますと期限を提示しておきます。
また、問題の内容が不明瞭で顧客と調整が必要な場合は、時間を空けずにすぐにレビューの依頼を出します。

<問題への対応>
問題の原因が、開発側にあるのか、顧客側にあるのか明確にしておく事は重要です。
追加要件など、顧客の都合による物は、工数をしっかり出して、顧客に提示して承認をもらう必要があります。開発側の問題でないものはきちんと顧客から追加の工数のコストを負担してもらって下さい。

開発側の問題の場合には、しっかりと原因を調査して顧客に報告し、対策方法を提示します。その時に、類似箇所もしっかりと洗い出して同様の問題が他の箇所で発生しないようにするのが大変重要です。一度指摘した問題が他で発生することを顧客は大変嫌います。これを繰り返すと信頼関係は崩壊します。
また、問題が発生した場合の管理体制を明確にしておくと顧客は安心します。顧客との問題管理に専属の担当者を割り当て、常に顧客とステータスを共有して、問題の取りこぼしがないように目を光らせておきます。


最後に問題発生時の対応手順をまとめておきます。
全てがこのケースに当てはまるわけではないですが、問題に対応する際の基本的なプロセスを理解するのには役立つと思います。

1.問題発生
   ↓
2.問題点をまとめて、台帳で管理する。
   ↓
3.問題の発生元が顧客側にあるのか、開発側にあるのかを明確にする。
   ↓
4.問題の対応策を考え即時対応可能な物から着手する。
   ↓
5.対応に時間がかかる物は、期限を決めて顧客に提示する。
  また、追加要件の場合には、工数を出して顧客の承認をもらう。
   ↓
6.問題が大量に発生した場合には、体制の強化を図る。
   ↓
7.体制の強化だけではどうにもならない場合には、リスケジュールする。

問題の責任が、開発側にある場合には、それに伴うコストは当然開発側負担する必要がありますが、、追加要件などに伴うコストは顧客に負担してもらうのが筋です。
ただし、顧客との信頼を失っている場合には、追加コストの請求もままならなくなり、本来顧客に払ってもらえるはずのコストも自腹を切らざるを得ない状況に追い込まれる事もあるので、顧客に誠実に対応して、良い信頼関係を築くことは大変重要です。
posted by j.shiozaki at 16:10| Comment(0) | TrackBack(0) | 3分メモ

2013年08月19日

SZJ005 リスケジュールについて考える

リスケジュールと聞くと、ネガティブな印象を受けます。それは、ほとんどの人が「リスケジュール=トラブル」という概念を持っているからです。なので、多少作業が遅れていても、何だかんだと理由をつけてスケジュール通り完了しますと顧客に説明するのが常です。
しかし、よく考えてみてください。

作業が遅れているのになぜスケジュール通り完了しますと言い切れますか?

よく言い訳に使われるのが「人を増やします」とか「作業に慣れて後半は早くなる」とかですが、実際こんな事はスケジューを作成する際に考慮しておくべきで、人が足りないのは自分の見積もりが甘かっということなので、この時点ですでにスケジュールは破たんしています。
進捗が50%ぐらいまでは、こんな言い訳でも顧客にはなんとか納得してもらえますが、進捗が50%を超えるあたりからこの言い訳も通用しなくなってきて、最終的に顧客からリスケジュールを指示されてしまいます。
顧客からリスケジュールを指示されたということは、開発側がスケジュールが遅れているのに適切な対応を怠ったと顧客に判断されたということなので、顧客からの信頼は失われています。

だからといって、安易なリスケジュールを推奨しているわけではないです!!!

あまり頻繁にリスケジュールを行うと、何を前提にして作業を見積もっているのか不明瞭になり、結果、顧客が不安になりこの場合も顧客からの信頼を失う結果となりかねません。
あくまでも、リスケジュールは、スケジュールが破たんしている場合の話で、スケジュール通りに作業を進められる余地が残されているのであれば、体制の強化などを行いスケジュール通り作業をこなす努力をしなければいけません。

リスケジュールを考慮しなければ行けない状況はいろいろあるとは思いますが、いつくか例を上げておきます。

<顧客起因>
@仕様追加や、仕様変更の要望が出た場合。

<開発起因>
@想定外の問題が大量に発生して調査に時間がかかる場合。
A見積もりが甘くて、体制の強化だけでは対応しきれない場合。


リスケジュールの判断はとても繊細であり、開発者としての技量が試されるポイントでもあります。
そして、決して忘れてはいけない重要な事は

『顧客も開発者も良いシステムを作ろうという気持ちは同じ』

ということです。進捗会議などで厳しい事を言われると時々このこのことを忘れてしまい感情的になってしまったりしますが、顧客と開発者の根本にある物は同じだという事を決して忘れないでください。
そして、リスケジュールが必要と判断した場合は積極的に顧客に提案してください。私たちが良いシステムを作ろうと誠意ある対応をすれば必ずきっと顧客もそれに答えてくれるはずです。ただし、リスケジュールにかかるコストの話については別ですが...
posted by j.shiozaki at 01:49| Comment(0) | TrackBack(0) | 3分メモ

2013年08月09日

SZJ004 設計書の書き方@〜読み物としての設計書〜

設計書を書く時に、文章の表現に気を付けていますか?
ユーザーは、開発者とは違った視点で設計書を見るので、開発する側からすると当たり前のことでも、文章の表現の仕方一つで理解できなかったり、違う意味で受け取ったりします。
誤解のないように気を付けて書いているつもりでも、ユーザーに指摘されて設計書を修正するといったことは普通にある事なので、できるだけユーザーに負担をかけないように、設計者は読み物だという意識をもって、文章の書き方に気を付けてみましょう。

■受動的、能動的

日本語は主語を省略しても意味が通じるため、書き方によってはユーザーが混乱してしまいます。例えば下の例で考えてみてください。

「選択した従業員を検索して画面に表示する。」

設計書を見慣れている私たちには、従業員を選択するのはユーザーで、検索して画面に表示するのはプログラムだと感覚的に理解できるのですが、設計書を見慣れていないユーザーは、この区別がつかない場合があります。

「ユーザーが選択した従業員を、プログラムが検索して画面に表示する。」

上記のように主語をつけて書けば誤解はなくなりますが、実際このような書き方はあまりしないです。
もっとシンプルにわかりやすく書くには、操作をするユーザーと、処理を提供するプログラムのどちらかの視点から書いて、受動的、能動的な表現を使います。

@ユーザー視点
「選択した従業員が検索されて画面に表示される。」

Aプログラム視点
「選択された従業員を検索して画面に表示する」

設計書はプログラム視点で書くのが一般的ですので、特別なことがない限りはAの書き方で問題ないです。また、能動的な表現で統一したい場合もあるので、その場合は下記のような書き方もあります。

「ユーザーが選択した従業員を、検索して画面に表示する。」

肝心なのは、ユーザーが混乱しないように操作する側と、処理する側が明確になっていることです。


■体言止め、用言止め

文章を名詞で終わらせる表現を体言止め、動詞・形容詞で終わらせる表現を用言止めと言いますが、この体言止め、用言止めをきちんと使い分けることで設計書が読みやすくなります。

<体言止めを使う箇所>
@処理の見出し

 1.従業員一覧表示処理
  1.1.入力チェック
  1.2.従業員の検索

A注釈
 「※詳細は○○を参照。」

B処理の条件
 「入社年月日がシステム日付以下であること。」

<体言止めを使う箇所>
@処理の説明

 「以下の条件に一致する従業員を従業員マスタより検索する。」
 「取得した従業員を一覧に表示する。」

自分が試した限りでは、処理の説明に関する部分は用言止めで、見出しや注釈など、処理の説明に直接関係ない部分や、処理の条件など動作を制限する部分を体言止めで表現すると全体がすっきりして読みやすくなるようです。


■句読点

句読点の使い方に、初歩的・基本的なミスのある文章は、それだけで読むのが嫌になってしまいますので気をつけなければいけない重要なポイントです。
句読点についてユーザーに指摘されるような恥ずかしい思いをしたくはないので、たかが句読点となどってはいけません。

特に目につきやすいのが、句点「。」の使い方です。句点をつける箇所と、つけない箇所を明確に区別しておかないと設計書がとても読みにくくなります。
基本的に文章の終わりには句点「。」をつけますが、一覧形式で処理を説明したりすると句点「。」をつけ忘れてしまいます。




あと、カッコつきの文章に句点「。」をつけるかどうかですが、一般的にはつけないそうなのですが、コンピュータシステムの設計書では文字列をカッコで表現することが多いので自分は句点「。」をつけてもいいと思っています。

文章のお作法で句点「。」をつけないの一般的
 「従業員番号が入力されていません」

エラーメッセージなどを記載する場合などには句点「。」を付けてもよい。
 「従業員番号が入力されていません。」


<参考文献>
 よい文章の書き方
  http://www.h3.dion.ne.jp/~urutora/bunshoupeji.htm

 ちょっとおかしな文例
  http://www.h3.dion.ne.jp/~urutora/bunreipeji.htm
posted by j.shiozaki at 00:27| Comment(0) | TrackBack(0) | 3分メモ

2013年08月02日

SZJ003 「あいつよりましだ」は思考停止のはじまり

今回は3分メモを始めるきっかけとなったネットの記事を紹介します。

http://www.sinkan.jp/news/index_1792.html

内容は大前研一氏の「洞察力の原点 プロフェッショナルに贈る言葉」という本の抜粋なのですが、身につまされることばかりで、これまでの自分の行動をすぐに改めようと気になります。

私が特にグサッときたのが「そのうちに」というやつです。

「そのうちに」やりたいことがあるなら、今やりなさい。というのが大前氏のアドバイス。時が経つにつれて情熱は薄れるもの。「やりたい」と思った時こそが旬であることを忘れないようにしましょう。

この記事から私は、他人や、結果を意識しすぎてグズグズしていてはいけない、とりあえず行動しなくてはと思い。3分メモを始めました。
結果として、形にならなかったとしても、行動することに価値を見出し、次に繋げる原動力として行きたいと思っています。

また、「あいつよりましだ」や「おれもいいと思ってた」も自分的にはかなりグサッときました。
「あいつよりましだ」と自分の方が優れていると慰めてみてもみじめなだけです。人と比較するのであれば一生懸命頑張っている人を目標にして「あいつを超えてやる」みたいな意気込みが必要だと思います。
「おれもいいと思ってた」は、他人の意見に便乗して、自分で考えることをしない人の言葉です。何かを成し遂げたいと思うのならば、しっかり自分で考えて発言すべきです。

まだ3分メモを始めたばかりですが、今後3分メモをどうすべきか、自分の長期的なテーマとして取り組み、少しずつ改善して行こうと考えていますのでどうか長い目で見守っていてください。
よろしくお願いいたします。
posted by j.shiozaki at 00:46| Comment(0) | TrackBack(0) | 3分メモ

2013年07月28日

SZJ002 メッセージで開発者のセンスが問われる

システムを開発する上で必ず必要となるメッセージですが、そのメッセージの文章について深く考えた事がありますか?
メッセージの目的は、システムからユーザーに必要な情報を伝えることですが、間違えなく正確に伝えようとして、システマチックで分かりにくいメッセージになっていませんか?
メッセージに求められる要素は、「分かりやすく」「正確に」「簡潔に」といったところですが、これらの要素をいかにうまくまとめられるかは開発者のセンスに依るところが大きいです。

たとえば必須チェックのエラーメッセージを例にしてみると、

@「必須項目が入力されていません。」
A「個人番号を入力してください。」
B「必須項目が入力されていません。個人番号を入力してください。」
C「個人番号は必ず入力してください。」

上記の4つで私が一番センスが良いと思うのはCです。@は何をすればエラーを解決できるかが不明で、Aはなぜ個人番号を入力しなければいけないのかが不明。Bは原因と解決方法の両方が盛り込まれていて、一見良さそうですが、システム的な表現でユーザーに優しいとは言えません。
その点Cは、「必ず入力してください」という言葉で、個人番号が必須項目である事をユーザーに認識させ、なおかつ個人番号を入力すればエラーが解消できることも伝わります。
BとCのどちらのメッセージでも、ユーザーに伝えようとしている内容は同じですが、Cの方が自然で読みやすくすんなり理解できることに気づくはずです。

次に確認メッセージについて、編集した内容を保存せずに画面を閉じた場合などに、表示される保存の確認メッセージを例にして説明します。

@「変更した内容を保存しますか?」
A「変更した内容を保存しなくてよろしいですか?」
B「変更した内容を保存せずに画面を閉じてもよろしいですか?」

上記の3つの内、@Bは特に問題ないですが、Aはセンスが悪いです。Aの場合、「はい」「いいえ」の2択の確認メッセージの場合で、

 「はい」…保存しない
 「いいえ」…保存する

という処理になりますが、通常「はい」は肯定の意味で使われるので「はい」を選択した時の保存される方法がしっくりきます。
確認メッセージには非定形の文章はユーザーに誤解を招きやすいので使うべきではありません。確認メッセージはシステムが行いたい処理に対して同意をもらうといった感じの方がユーザーに優しくてセンスが良いと私は思います。

以上、エラーメッセージと確認メッセージについて例を上げて説明しましたが、場合によっては、どうしてもシステマチックな表現しかできない場合もあるとは思いますが、できるだけユーザー視点で読みやすく、理解しやすいメッセージを心がけてください。
最後に、いくつかメッセージの例を上げておきますので、ちょっと自分なりに考えてみてください。

電話番号のフォーマットチェック
1-@「電話番号は数字で入力してください。」
1-A「電話番号のフォーマットが不正です。数字で入力してください。」
1-B「電話番号に数字以外が入力されています。」

開始日、終了日の大小チェック
2-@「開始日が終了日より後です。」
2-A「開始日が不正です。開始日<終了日で入力してください。」
2-B「開始日には、終了日より前の日付を入力してください。」

検索条件に合う従業員が検索できなかった場合
3-@「検索条件に一致する従業員は存在しません。」
3-A「従業員が存在しません。検索条件を変えて再度検索してください。」

内容を変更したのに保存せずに終了しようとした場合
4-@「変更内容を保存しますか?」
4-A「変更内容が保存されていません。変更内容を保存してから終了しますか?」

※センスが良いと思うもの※
1-@「電話番号は数字で入力してください。」
2-B「開始日には、終了日より前の日付を入力してください。」
3-@「検索条件に一致する従業員は存在しません。」
4-@「変更内容を保存しますか?」
posted by j.shiozaki at 00:58| Comment(2) | TrackBack(0) | 3分メモ

SZJ001 顧客の理解度を高める5つのコツ

【なぜ?を明確にする】
処理の目的をしっかりと顧客に理解してもらうためにも、なぜこのような仕様になったのかを明記しておく。
時が経つと書いた本人もなぜこうしたのか忘れてしまうので、処理の目的を明記しておくことで、仕様変更や、不具合で設計を見直す場合に、デグレの発生を抑制することに役立つ。
また、他の担当者が仕様を理解する際にも役立つ。

 悪い例:「△△を□□に設定する。」
 良い例:「○○のため、△△を□□に設定する。」

【比較する】
既存システムや、類似した機能が存在する場合には、比較して説明する事で顧客がイメージしやすくなる。
顧客が既に知っている事と関連づけることで、打ち合わせの時間を大幅に短縮できるし、仕様の深い部分まで議論できるようになるので、過去の情報は最大限に活用する。

【全体を見せる】
顧客に説明を行う際に、対象とする機能だけでなく、全体から説明する。
全体図を見せてこれから説明する部分はここですと示すことで、これから説明する機能のイメージがつかみやすくなる。
仕様の打ち合わせをする場合などには、共通で使える全体図を用意しておくのも良い。

【流れをつくる】
顧客に説明を行う際に、関連性のある機能をまとめて流れを作って説明する。
例えば、設計書の説明をする場合などには、処理の流れに沿って説明すると顧客に理解してもらいやすくなる。

【繰り返す】
システム上重要な処理は、打ち合わせの要所要所で繰り返し説明する。
得に複雑な処理などは、一度の説明では完全には理解してもらえないため、繰り返し説明することで顧客の理解度を高めることができるし、その都度ブラッシュアップできる。
posted by j.shiozaki at 00:55| Comment(0) | TrackBack(0) | 3分メモ