親が発する言葉を、子どもは忠実に真似をする

言葉について以下の記事を読みました。
itmama.jp

普段どうしてる？

子どもには使ってほしくない言葉は、子どもの前では言わないように意識はしています。
片付けをしていて、「そこにいると邪魔だな」と思ったときに「そこ片付けの邪魔だからどいて」と言いそうになります。
「邪魔」と言われたくないので、「そこ片付けしているから、こっちに移動して」と言うようにしています。

それでも、意識できていないときや僕ではない人から聞いて、「邪魔」という言葉を覚えていました。
他にもいろいろ言ってほしくない言葉を覚えていっています。

覚えてもいいのでは？

いつかは覚えるものなのでしょう。
使ってもいい相手に適切に使えればいいと思います。

大人でも言い方を誤って、失敗することがあります。
子どものうちに失敗して学べばという考えもあります。
子どもだからと許してもらえる今だから、失敗してもいいのかもしれません。
相手には親が謝って、子どもには使わないように注意して、学ばせるのも手段かもしれません。

どうするのが最善なのかと考え始めると、答えが出てこず悩んでしまいます。

photo credit: jccchou 121119 via photopin (license)

方言も覚えていく

普段何気なくしゃべっている言葉を子どもは覚えていきます。
「とる」という方言を使ってしゃべるようになりました。
detail.chiebukuro.yahoo.co.jp

子どもが「とる」という方言を使ってしゃべるまで、全く「とる」という方言を使っている意識はありませんでした。
気にしてみると、意外に「とる」という方言を使ってしゃべっています。

子どもが「使っとるね」と言うと、「使ってるね」とこちらから言い直しています。
何度も言い直していれば、「使ってるね」で覚えて直してくれるのではないかと期待しています。
今のところ期待どおりにはならず、「使っとるね」と言い続けています。

子は親を映す鏡という言葉は昔から言われていた気がしますが、そのとおりだと改めて感じる日々です。

適切な設計およびコーディングをすることで、変更がしやすくなる

データをデータベースから取り出してCSV形式で保存するプログラムを作成しています。
データをデータベースに登録されたときに、同時に登録されたファイルも合わせてコピーもしています。

これまでの処理の流れ

特に要望がなかったので、
1.データベースからデータを取り出す。
↓
2.取り出したデータを加工する
↓
3.取り出したデータをチェックする。
↓
4.チェック結果をログに保存する。
↓
5.取り出したデータをCSV形式でファイルに保存する。
↓
6.取り出したデータを元に、ファイルの保存元からファイルの保存先に、ファイルをコピーする。
↓
7.ファイルのコピーに失敗したら結果をログに保存する。
↓
8.最終データを処理するまで繰り返す。
といった流れをしていました。

要望された処理の流れ

お客さんから、ファイルのコピーが正常にできたら、データベースから取り出したデータをCSV形式でファイルに保存するようにという要望がありました。
要望を満たすための方法を考えたところ、以下のような流れに変わりました。
1.データベースからデータを取り出す。
↓
2.取り出したデータを加工する
↓
3.取り出したデータをチェックする。
↓
4.チェック結果をログに保存する。
↓
5.取り出したデータを元に、ファイルの保存元からファイルの保存先に、ファイルをコピーする。
↓
6.ファイルのコピーに失敗したら結果をログに保存する。
↓
7.ファイルのコピーが正常にできたら、取り出したデータをCSV形式でファイルに保存する。
↓
8.最終データを処理するまで繰り返す。

太字の部分が当初と順番が異なり、アンダーラインが要望により追加された機能です。

photo credit: yaph Perl malloc.c extract via photopin (license)

単純な機能の組み合わせなので変更が容易

なるべく単純、なるべく単機能なメソッドを作成するというのを常に考えています。
メソッドを順番に呼び出して、目的の結果を得るようにしています。
今回の要望の反映は、メソッドを呼び出す順番を変更して、判定条件を追加するだけでできました。
時間にして30分もかかっていません。
常に考えていることを実践することで、楽に対応ができました。

コメントを貰うのが、ありがたいときと迷惑なときと両方あります

お客さんが、僕の勤務先の製品から他社の製品に移行することになりました。
僕の勤務先の製品から他社の製品に移行するためには、データを抜き出す必要があります。
標準でデータを抜き出す機能がないので、一からプログラムを作成しなくてはなりません。

なぜかチェックされる

設計書を納品物として出さなくてはならず、お客さんに提出したところ、移行先の他社の担当の方も設計書を確認されました。

移行先の担当として、抜き出すデータについてどのように定義で記述されているか関心があるのかと思っていました。
結果はそうではなくて、抜き出すデータ以外のプログラムの設計部分にも、あれこれコメントがありました。

ありがたいコメント

確かにわかりくい記述をしている部分もありました。
わかりやすくするための意見として、ありがい気づきを得られるコメントがありました。

photo credit: AspirationTech image1 via photopin (license)

迷惑なコメント

曖昧さがあり、多分間違って理解されていると推測され、最後に「修正していただければ幸いです。」というコメントがありました。
このコメントには、曖昧さがなく、間違って理解されてないように説明を書いてメールをしました。
移行先の他社の担当の方からは、丸2日経ってもメールに対して返事がありません。
理解したとか、そうではなくてこういうことが伝えたいんだとか、なにかリアクションがあるべきだと思います。

データを抜き出して、移行先に渡すという目的には、返事の有無は影響をしません。
設計書に対する意見集約ができていない状態で現状止まってしまいます。
お客さんから、移行先の他社の担当の方のコメントを無視するという指示は無い気がするので、催促するしかないのかと予想しています。
できれば、お客さんから移行先の他社の担当の方に対して、移行元がコメントをしたので、コメントを返すように促してほしいところです。

移行先の他社の担当の方は、他社に対して「修正」という「指示」をしたのだから、「結果」まで見届ける責任があると考えます。