入園式に参加しました

子どもの保育園入園式に参加しました。

入園式までは
・組分けは事前にわかっているので、組の部屋の子どもの名前が書かれた棚に今後必要になる荷物を持っていく。
・書類を提出する。
・荷物を置いたら、講堂に移動し、組毎の列があるので、座って待機する。
という流れでした。

入園式は、
・園長先生の挨拶。
・職員の方の挨拶。
・年長さんの歓迎の歌と鍵盤ハーモニカ演奏。
・職員の方の手遊びと人形劇。
・担任の先生が組ごとに子どもの名前を全員を呼ぶ。
という内容でした。

入園式が終わった後は、園庭で遊べるようになっていたので、子どもは当然のように遊んでいました。

photo credit: MIKI Yoshihito. (#mikiyoshihito) SAKURAKO attended entrance ceremony. via photopin (license)

入園式の感想など

• 晴れて風もないおかげで寒くもなく、いい天気に恵まれました。
• 子どもがまだ小さいからなにかするわけでもないので、これは撮り逃してはいけないという場面もなく、予想通りビデオカメラは使うタイミングが難しかったです。
  職員の方の挨拶や子どもの様子など、断片的に撮っていました。
  三脚持ち込んでいる方がいたのには驚きました。
• 親はスリッパ、子どもはバレーシューズを指定されて持って行きましたが、必要性を感じませんでした。
  確かにスリッパがあった方がいいところを歩きましたが、気にならなかったので、入園式が終わってからは使いませんでした。
• 子どもは入園式が始まる前、終わってからも、ネット状の登れる遊具を数段あがって遊びたがっていました。
  遊びたくて仕方ないとはいえ、今日はダメだよと降ろしていました。
• 入園式の看板(？)の前で写真を撮りましたが、奥まったところにあったので、入園式が終わってから写真を撮っていました。
  手前に出すと撮影待ちの列ができて、園の外に列が出ると危ないからという配慮はありそうです。

今後1週間は慣らし保育の期間で午前中だけですが、泣いてばかりいないか心配しながら過ごすことになりそうです。

予定通り作業が進まない理由を推察

システムの修正の依頼がありました。
2時間くらいで終わると思って、合間合間に他の作業をしながら修正していましたが、合計2時間では終わりませんでした。

なぜ2時間くらいで終わると思った内容ができなかったのかを考えてみると、

1. そもそも2時間くらいという見積が正しくない。
2. 修正の依頼の元データが、Wordで取り消し線を使って、文章の修正前後を比較しやすいようにされている。そのため、修正後の文章を自力で作成しないと比較できない。

という2点を思いつきました。

photo credit: Dave Wilson Cumbria Psalm 34 via photopin (license)

より考えてみる

見積自体が正しくないのは、修正の依頼の元データを見て、文章の修正だったら2時間くらいとしか考えられず、過去の経験から導いているので、結果としての時間がかかりすぎているという印象です。
合間合間に他の作業を行わず、連続で行えば2時間で終わっていたのかもしれません。

修正の依頼の元データが、Wordで取り消し線を使って、文章の修正前後を比較しやすいようにされているのは、確かにわかりやすいです。
わかりやすいのはありがたいのですが、そのために、修正後の文章が正しく修正できているのかを、WinMergeなどの比較ツールを使って比較するため用の文章を用意しなければならなくなり、そこで時間を使っていました。
WinMerge 日本語版

修正部分がわからないのも面倒そうな感じがしますが、比較ツールを使えばどこが変わったのかはすぐに把握できます。
修正後の文章が貰えれば、どこが修正されたのか比較ツールで比較しながら、システムに修正を反映することができます。

修正を依頼してきたお客さんは良かれと思って作成されているだけに、指示の仕方をこうして欲しいとは言いだしづらいです。

思い込みで無駄な時間を使ってしまうか慌ててしまう

先日、既存のプログラムを再利用する機会がありました。
再利用にあたり、CASEが使われているクエリを修正しなければいけないことに気がつきました。

データベースの値が1なら5000、0なら0を検索結果として戻るためにCASEは使われています。
再利用後は、CASEを止めてJOINした別のテーブルの値を用いて、検索結果を戻すようにしなければなりません。

思い込みで無駄な時間を使ってしまう

クエリの修正をしなくてはならないことは覚えていたので、該当のクエリを修正し始める前に、こんなクエリにしなければならないと考え、既存のプログラムのクエリを元にしないで、新たなクエリを考えだしました。

CASEを止めてJOINした別のテーブルの値を用いる部分ができたので、既存のクエリのCASE以外の部分を反映しようと、既存のクエリを改めて確認しました。

確認した結果、新たにJOINしなければいけないと考えたテーブルは、既存のクエリでもJOINしていました。
JOINした後のテーブルの別名を指定して、値をデータベースから取得するようにするだけで目的を果たせるようになっていました。

既存のクエリは修正後にはあまり使えないと思い込んでしまったために、無駄な時間を使ってしまいました。
既存のクエリを元に、修正できるのか、新たなクエリを考えた方が早いのかという判断が必要でした。

photo credit: World Economic Forum Davos Insights: Addressing Identity through Positive Narratives via photopin (license)

思い込みで慌ててしまう

システムの作成が終ったのでお客さんに連絡しようと思い、ふと最近のメールを読み返すと、選択肢の変更依頼がありました。
読み返すまで変更をしたつもりでいて、念のためと表示を確認すると変更前の状態です。

変更したつもりになっていました。
お客さんへの連絡をしなければいけない期限も迫っています。
慌てて選択肢を変更し動作確認を行って、お客さんへの連絡の期限に間に合いました。

思い込みがないか、連絡の前日に再確認を行う時間を確保して、確認の結果翌日に連絡できるように余裕を持たせたいです。