ゆずのコンサート

行ってきましたよ、ゆずのFURUSATOコンサート！

初めての経験（うふふ）
親子で行ったのですが最高でした～。

FURUSATOのアルバムの中では一番好きなYesterday and Tommorowでは涙がだぁだぁでした。
40前の坊主オヤジがｗ

残念ながら知らない曲が何曲かあったので今度レンタル（ケチっ）してコンサートと同じセットリスト作って繰り返し聴きたいですね。

みなさんも興味が沸いたらぜひどーぞ！

親子サイクリング（岐阜駅）～前篇～

①号と行ってきました。

じゃっくは名古屋市在住なんですが、記念すべき第一回親子サイクリングの目的地は『岐阜駅』です。

サイクリングなのに、目的地が電車の駅なのは①号のたっての希望なわけですが、なんのことはない、


「ポケモンスタンプラリーのチェックポイントだから」

ってのがお目当てみたいです。
まぁ、私にとってはどこだろうが行って帰ってこられるか、が問題なのであまり深くはつっこまないことにします。


距離にすると片道３０km、往復で６０km。
時速１０kmなら６時間で走破できる計算です。
実際にどの程度のペースで走れるかは未知の領域ですが、まぁ時間的なリミットを設けて最悪の場合、
途中で引き返すことにします。



さて、サイクリング当日です。
（前夜、①号が興奮して寝られず泣いて起きてきたのは内緒です。）


朝８時に出発の予定でしたが、あれやこれやと準備しているうちに３０分遅延です。

ずんどこずんどこ走ることにします。
まぁ、６時間も走る計画なので最初の１時間ぐらいでひーこら言ってはいられません。
もっとも、特に最初の１、２時間は街中なので、たいしたペースもだせないので、
①号と初めての親子サイクリングを楽しむことにします。

が、往路の半分もこなさないうちから昼ご飯を連発しはじめる①号。
一応、がんばるエサとして昼食と帰り休憩でのアイスクリームをあらかじめぶら下げてあったんですが、
早くもその効果が威力を発揮しはじめました。

数度の休憩を入れながら、２時間半ほどしてようやく木曽川到着です。
今回のコースはとにかく濃尾平野の真っただ中なので、坂道らしい坂道はほとんどないのですが、
唯一、この木曽川を渡る橋のみが難関でした。
この頃には①号の体力もかなり尽きかけてたようですが、頭の中は昼ご飯とポケモンのスタンプだけで
ペダルを漕いでました。

なんとか坂を登りきって岐阜県に突入です。

なかなか感慨深いものがあります。
じゃっくは中学生の頃、悪友と二人で三重のナガシマスパーランドに自転車で行ったことがあるのですが、
その時以来のサイクリング越県です。
この時も自動車専用道の国道２３号を自転車で走るなどかなりヤヴァイことしましたが、その辺はおいといて。

実は、ここまで走ってくる間、

『そもそも、往復で６０kmって、小学２年生の走る距離としてどうなんだろう？』

みたいな今更な考えが何度も浮かんできましたが、まぁイイヤと考えないようにします。

さて、この非常識なサイクリング、①号とじゃっくは目的地にたどり着き、無事帰宅することができるのでしょーか！？


後編に続く～

はだか祭

先週の土曜日（２／７）に国府宮神社のはだか祭に参加してきました。

あまり知られていませんが正確には、「尾張大国霊神社の儺追神事」といいます。
今年は土曜日＆好天とあって非常にはだか男の数が多かったようです。


このお祭りは、いくつかのパートで構成されていますが、メインは、はだか男（報道によると１万人以上）の待ち受ける神社の参道に神男がでてきて、もみくちゃに儺追殿という神社の中の建物に引き上げられるところかと思います。

参道への出たては人が集まっていないので一番さわりやすいチャンスなのですが、でてくる場所と時間がわからないのでみんなあちこちきょろきょろして探すことになるわけです。


今年は神男が義弟の知り合いだったそうで、義弟は顔を知っていたのでカツラをかぶった神男が出てきたのがすぐわかったそうで、無事さわってきたようです。

私といえば、寒さを紛らわせるために日本酒をガブ飲みしたせいか、無事家に帰りついて風呂から上がった後でブッ倒れてしまいましたとさ。

毎年、はだか祭が終わると暖かくなってくるので、春ももうすぐといったところでしょうか。


噂によると来年は金曜だそうです。
皆さん、午後休とってはだか祭にでましょ～！

var_tempよりpr

こんな便利な関数が用意されているなんて知りませんでした・・・。（cakePHP）


pr()


配列の階層が分かりやすいように改行、インデントがされます。
今までhtmlソース見てた（アホでしょうか）のでかなり楽になります。

らーめん臺大の新年会

近所のらーめん屋「らーめん臺大」の新年会に行ってきました。

店主夫妻と店の常連、および、その知り合いで総勢２７名（！）でした。

初参加の方も３分の１ほどいて、なかなか新鮮でした。
年齢の幅も広く、下は２１歳から上は４０うん歳と、コンパのような同窓会のような上司部下の慰安と説教のような、いつもながらなんだかよく分からない飲み会でしたｗ

店主夫妻の老婆心から（だと思う）、毎回、独身男女を優先して招待するのですが、今回めでたく１組カップルが成立しそうな予感です。

会を重ねるごとに人数が増えてきており、そろそろ収拾がつかなくなってますがそれもまた楽しといったところでしょうか。


締めは店主の

「不景気の中ですが皆さん、らーめん食べに来てくださいTT」

という切実な営業トークで幕を閉じました。（笑）





全然行けなくって、すんませーん！！


次回は花見かな～？
楽しみでっす。
興味のある方はぜひお店に行って大将と仲良くなりましょうっていうか、２回も行けば絶対大将に話しかけられてると思いますケド！

インフルエンザ来襲

①号②号とも撃沈です。

小学校ではインフルエンザにかかった児童は出校停止となり、自宅で休養しなければなりません。
知らなかったのですが、この時の休みは「欠席」にはならないとのことです。

皆勤狙いの児童が無理やり出校するのを防ぐためでしょうか。

でも、そもそも「皆勤賞」って、健康に気を配り風邪などひかないようにし勉学によく励んだことを賞するもののような気がしますが・・・。



インフルエンザの話題ついでに、社会人の風邪ひきマナーについて。


大事なことは、１にも２にも、

「人に伝染さない」

です。

ただの風邪でもマスクは当然、手洗いうがいも子供以上にしっかりやるべきです。
38度以上の熱が出た場合は、インフルエンザとの診断があるなしにかかわらず、職場に出るべきではありません。

ただし、欠勤する間の業務については、様々な対応が必要です。


自分しかできない業務（あまりそういう業務が多いのは問題ですが）については、

「延期し、その連絡と予定変更手配やリスケジュールを行う」


自分以外でも対応可能な業務は、

「上司、部下、同僚に対応依頼または対応の調整を依頼する」

この時、部下や同僚に直接指示や依頼を行ったら、必ず、上長にその旨を報告することが大切です。


当たり前のことになりますが、欠勤し自宅で過ごす場合は、しっかり休養することが一番大事です。

万が一にも、

「ひゃっほう！久しぶりの休みだぜ。たっぷりゲームしよう。」

などといたずらに睡眠時間を浪費してはいけませんｗ

会議をコントロールする～その５

今回は「双方で何かを決定する」会議についてです。



当然ですが、前回までの内容がこのタイプの会議ではすべて必要になります。

例えば、

「事前準備」（その２参照）
「最重要ステークホルダーは誰か」（その３参照）
「攻守のフェーズの切り替え」（その４参照）
「聞き出した内容は、必ずその場で自分で整理して、参加者全員に確認する」（その３参照）
「締め方（会議の終わり方）」（その４参照）

などです。


ですので、ここではこれまで触れなかった部分を中心にまとめていこうと思います。




当たり前ですが、このタイプの会議の開始時点では「結論」が合意できておらず、会議の目的は「結論を出す」ことになります。

ですので、大きく会議の行方を握るのは「自分なりの結論を持った人」になるでしょう。



この観点で会議を見てみると、いろんなパターンが見えてくると思います。
例えば、


「結論（＝落とし所）を持った人がいない場合」

発言がなかったり、逆に議論が拡散したりして、結果的に意味のない会議になりがちです。



「結論を持った人が１人の場合」

必要な議論が行われずその人の都合のよいその場の結論が出され、後々問題となったりします。



「自分なりの結論を持った人が多すぎる場合」

会議が紛糾したり、利害の絡み合った綱引きになったりして結論がでにくい会議となります。




まず、会議の前半で、参加者の考えている落とし所を聞き出しましょう。

いわゆる「腹の探り合い」です。

まぁ、エンジニアリングの世界ではあまりコソコソせす、どーんと聞いてしまうのが手っとりばやいと思いますが、契約や費用などナーバスな問題がからむ場合は、より「政治的な」駆け引きが必要となるでしょう。
が、そのあたりはまた別の機会に。


参加者の思惑や、会議のパターンが見えてきたところで、実際のコントロールの話に入るわけですが、その際に、自分がどの立場で会議に臨むのかで必要なテクニックは変わってきます。


次回から、自分が落とし所を持っている場合と持っていない場合のコントロールテクニックを書いていこうと思います。

スキーで骨折！入院！？

じゃっくです。

実は昨年末の大みそかに家族でスキーになぞ行ったりしたのですが・・・。


場所はチャオおんたけ。

あんな激遠くて、激寒いスキー場、ゴンドラ・リフト券が1000円じゃなきゃいきませんよ。
（思いっきり誘惑に負けたｗ）


20年近いスキー歴の中で、今回初めてやった失敗が、

「靴下二重に履くのを忘れた！」

です。

やっちまいました。

おんたけの寒さは半端ぢゃありません。
下界‐10度、てっぺん-15度です！

そもそも皮下脂肪による防御がないに等しいじゃっく。

生まれつき心臓に欠陥があって低血圧（上が8、90台）なじゃっく。

あっと言う間に足は凍え、血流０到達です。


ちび①号とゴンドラ一本降りた後、今度はちび②号とクワッドリフトです。

ゴンドラやリフトに乗るたびにブーツのロックを外し、リアをエントリーモードに緩めていたのが運のつき。

まだおもちゃスキーの②号は基本的には滑れないので「だっこ」なのですが、ここでやっちまいました。

だっこしてアイスバーンに差し掛かり、あっと思った瞬間には後ろ荷重→しりもちをついてました。


「しりもち」なんてもんじゃありません。


ブーツのリアを緩めたままだったので、まったくリアのエッジをかけることができず、両足とも前にすっ飛びました。

あーんど、体重20kgの重りを両手で抱えていたので手をつくこともできず・・・。


どう考えても、およそ50cmは落下したでしょう、わたしのおケツTT


こけた瞬間、目がちかちかしました。
多分、衝撃が脊椎をつたって、脳を揺さぶったせいと思われ、頭痛もしてきました。

その後、もだえながら②号を抱えて気合でセンターハウスまで降り、家族と合流しましたが、①号の「まだ滑りたい！」に勝てず、②号③号をキッズエリアで子守させられマスタTT


結局4時近くにようやく出発。

雪道の運転を、じゃこに任せるわけにもいかず、片シリ浮かせながらここも気合いで下山。
ここでもおんたけのイヤなところに苦しみます。

大きい国道まで遠いんだもんTT


帰宅してもケツの痛みはひかず、頭痛も治まりません。


が、時は大みそか。

結局、病院へは正月明けに行きました。

結果。


「多分、尾てい骨骨折だね。」



ひゃっほう！！骨折～！！

私は骨折ったことなかったので、骨折→入院に憧れてたんですぅ～！



が、しかし！

「え？何にも治療なんてできないから入院なんてしないよ。」

先生の無情の宣告にがっかり・・・。


「なんならシップでもだそか？気休めだけどｗ」


いらんわ～い！！

で、痛み止めにロッキー（ロキソニン）しこたまもらって帰りました。

でも耐えられない痛みじゃないので、片頭痛用の常備薬にしよ～っと！


ちぇ、白衣の天使に看病してもらおうと思ったのに！！

会議をコントロールする～その４

前回に引き続いて、今回は、

「相手から何かを聞かれる会議」

の進め方です。


なにやら尋問や査問のような表現ですが、実際にはいろいろな会議がこのタイプに当てはまります。

「（発注者として参加する）要件、要求仕様のヒアリング」
「（チーム内の統括されるメンバーとして参加する）進捗会議」

他にも、

「プレゼンテーション後の質問タイム」
「（被レビューアとして参加する）各種レビュー」

なども変則的ではありますが、この「聞かれる」タイプの会議と言えます。



このタイプの会議は、「聞く会議」以上に、事前準備が大切となります。


会議の議題に関する下調べはもちろん、会議の中で関連する事柄にまで質問が及ぶことも珍しくないので準備はしっかりしておきます。

ただし、準備に費やす時間は、自分の抱える他の作業とのバランスには注意が必要です。
なぜなら、準備とは基本的に成果物がない作業だからです。
上司は少ない準備で最大の成果（会議がスマートに終わること）を望むので、こっそりしっかりが基本となります。


さて、実際に会議が始まります。

会議の最中に意識したいのが、

「攻守のフェーズ」

です。

会議の参加者の力関係というのはどうしても、お金を払う側や役職の高い側が強くなります。

ですが、ここで言う「攻め」と「守り」は、そういった立場上の強弱ではなく、

「自身を持って何かを説明している時は『攻め』」
「記憶があやふやだったり、後ろめたいことを隠したり避けたりしながら答えている時は『守り』」

といった、会議で説明している時の自分の状態をあらわしたものを指しています。

これを、客観的に把握できるように努めることが第一です。
会議の経験の浅い人や会議が苦手という人は、この自分を含めた会議の参加者を客観的に把握するのが苦手なことが多いようです。

自分が『攻め』ているのか、『守り』ながら説明しているのかが分かるようになると、次は、

「『守り』から『攻め』への転換」

が重要になってきます。
『攻め』続けて会議が終了できるのであれば、それはコントロールされた状態、または、コントロールが不要な状態といえるからです。

この、転換に有効なテクニックがいくつかあります。

「ズバっと謝る」
「（事前に準備した得意な、自信を持って説明できる内容に）話を切り替える」
「質問を切り返す」

一つ目が一番王道で一番有効です。
非を認めた時は、善後策や再発防止策まで打ち合わせることができれば、かなりカッチリした印象を与えることができると思います。
また、時には謝るついでにそれらについて教えを請うのもいいでしょう。
相手は得意になってしゃべりはじめ、いつしか追及の手は緩む、なんてこともあるかもしれません。

二つ目と三つ目はちょっと上級テクニックとなりますが、あまりやりすぎると「誤魔化し」と見なされます。
これらをクセでやってしまっている人も多いですが、そういう人は絶対周りから信用されないので注意が必要です。


また、『攻め』にも注意が必要です。

まず、

「誰かを攻撃しない」

参加者であろうとなかろうと、人を責めて得られるのはその場を制したという達成感だけで、必ず、最終的には自分自身を貶めることになります。
例えば進捗が芳しくない責任を他のメンバーに押し付けたとしても、結局上司はよい評価をしてくれず、「言い訳が多い、次回も改善が見込めない」などといった、マイナスのイメージを持ってしまいます。

他にも、

「『攻め』続けすぎると参加者は辟易してくる」

どんなしっかりとした説明や答弁も、過ぎたれば何とやらです。
これには、適度なタイミングで「～ですよね？」「ここまで何か疑問はありますか？」など、相手に対する問いかけを挟むのが有効です。


最後に「終わり方」に関するコツを。

この「終わり方」については後日別途書きますので、ここでは「聞かれる会議」で役に立つものを一つだけ。
それは、

「必ず『攻め』で終わり、締めの言葉をはっきり言う」

です。
途中どれだけ『守り』ばかりだったとしても、しっかり誤ってから、次ちゃんとやります！と『攻め』て『以上です！』と締めれば、会議はすんなり終わることが多いものです。

この、締めの言葉をうまく使って、会議をうまくコントロールしましょう。

会議をコントロールする～その３

まず、３種類の会議のうち一番コントロールしやすい、

「相手に何かを聞く会議」

から。


このタイプの会議は実は始まる前にうまく進められるか半分以上は決まってしまっています。
なぜなら、

「誰が知っているのか？」
「誰が決定できる権限を持っているのか？」

を、事前に押さえることができているかにかかっているからです。
これらには、前回もふれました。

とにかく、この２点が最重要です。
もし、会議前にこの最重要キーパーソンが判明していない場合は、

「会議の前半は捨てて、参加者をなるべく自由に泳がせてキーパーソンを発見する」

といいでしょう。


聞きたい事柄に関する情報を持っている参加者から引き出す時のポイントは、

「しゃべりたい人は放っておいてもしゃべるが、それが正しいかどうかは実はわからない」
「しゃべりたい人がいても、なるべく独壇場にはさせず、常に他の参加者に意見を求める」

しゃべりたい人に好きにさせるのは楽かもしれませんが、実はコントロールできていない状態とも言えます。
また、逆のタイプの参加者には、

「口べたな人がいたら、指名してインタビューする」
「他の参加者の説明に対するコメントを聞く」

などが有効です。


あと、当たり前ですが、

「分からないキーワードが出てきたら、説明に割り込んででもその場で教えてもらう」（あまり都度だと不勉強と思われますが）

ことは、非常に大事です。
頻度にもよりますが、１つずつしっかり用語、語句を押さえていく様子を見せることは、真剣さと、内容をより深く理解しようとする姿勢を相手に印象付けることにつながります。


次に、時間配分ですが、相手のペースで説明をさせるのは予定の半分ぐらいと考えましょう。
一通り聞き終えたら、

「聞き出した内容は、必ずその場で自分で整理して、参加者全員に確認する」

これをしっかりやることが、会議が始まってからの最大にして唯一の目的になります。
あと、不明点や、後日回答などの宿題が出た場合は、それらについて、「誰が、いつまでに」回答するかも必ず確認します。


また、情報を持っているキーパーソンが参加者にいないことがわかったら、会議の目的を変更しなければならないでしょう。

「本当のキーパーソンから、いつ、どのように情報を得られるかを聞く」または「それを双方で決める」
「今回の参加者から、仮の情報を聞いて」、「それで正しいかを本当のキーパーソンに聞く」

このように、場合によっては当初の会議の目的にこだわらず、臨機応変に対処することが、無駄に長引かせないコツにもなります。


まずはこの「相手に何かを聞く」会議をスムーズに進められるようになることが、会議上手への第一歩となるでしょう。

某回転寿司屋のモニター

じゃこ（カミさん）がネットで応募した各種モニター調査がちょくちょく当たります。

で、今回は某回転寿司チェーンの最寄の店舗の調査。

まず、最初の指令は、と。

「店舗までの道順を聞け！」

ふむふむ。
じゃこが電話してきました。

「電話担当って人が出て、ちゃんと教えてくれたよ～。」

ほほう、なかなか好感が持てますな。
何々、次の指令は、と。

「１８～２０時に入店しろ。そして待ち時間を計れ！」

むぅ、いつもは１７時より前にしか行かないから、混むのやだなぁ・・・。
ま、指令なので仕方ありません。
ど真ん中１９時到着です。

「お、駐車場、割と空いてるね。」
「２０分待ちだって。」

結局席に通されるまで２５分ほど。
メモメモ。

いよいよ本格的な店内での指令が。

「汁物とすしを大人１人あたり１０００円分オーダーしろ！」
「お勧めの品を尋ねろ！」
「店員を捕まえて何か聞け！」

次々と指令をこなし、胃袋に調査結果を詰め込んでいく２人。

さらなる、指令。

「トイレの様子を調べてこい！」

えぇ～、便意も尿意もないのにぃ・・・。
が、指令には逆らえないので、ぱぱっと調査。

いよいよ、最後のミッション、脱出。

「レシートを貰え！」

あっさり貰う。
敵の何人かは我々をスパイと怪しんだかもしれませんが、無事国外じゃなかった店外に脱出。

実はこの店舗、これまでもわりと贔屓にしていた店だったのですが、この日に限ってイマイチいろいろマイナス点が目立ってしいました。
残念、今後よりよいお店になることを希望して正直に報告させていただきます。


ちーーーん。




今回のモニター謝礼はというと、飲食代金×０．９。

「うし、計算通り！！」

会議をコントロールする～その2

それぞれのタイプの会議攻略に入る前に。

「敵を知り、己を・・・」

そう、会議に入る前の準備です。

・資料
・事前調査

これらはしっかりとやってください。

で、ここからが会議をうまく動かすためのコツ。
重要なのは、

「最重要ステークホルダーは誰なのか？」

参加者と面識がある場合はもちろん、ない場合でも関係者（上司や親しい顧客担当者など）から可能な限り情報を引き出して、人物と役職、立場を把握しておきます。
誰が最終決定権を持っているのか、はもちろん、性格的に誰が誰に強いのか、なども重要な判断基準になります。

その上で、会議の内容についてのステークホルダーとしての重要度、つまり優先順位を自分なりに整理しておくことが大切です。
この優先順位が決まっているということが、会議をスムーズに動かす時に非常に役に立ちます。
また、後でも触れますが、この順位は会議の最中でも臨機応変に並べなおすことも大事です。

会議をコントロールする～その１

私はSEですが、ちょくちょく会議というものに招集されます。
SEに限らず、というか、他の職業ではより多くの会議に参加することがあるかと思います。

で、私なりの会議の動かし方を。

まず、会議にはいくつかの種類があります。
これまでSEとして参加してきた範囲では、すべての会議は以下の3種類に分類できます。

１．相手に何かを聞く（尋ねる）
２．相手から何かを聞かれる（尋ねられる）
３．双方で何かを決定する

例えば、

「進捗報告」　→　顧客や上司から「進捗はどうか？」と聞かれる会議
「システム仕様の打合せ」　→　顧客に要件を聞き、仕様を決定する会議

このように2種類の属性を持つ会議も多い、というかほとんどがそうかと思います。

それぞれのタイプの会議の動かし方は次回。

cakePHPで詰まったところ

componentからmodelにアクセスする方法。



１．呼び出し元contorollerの参照を取得し、そのcontrollerにて$userとして定義しておく。こんな感じ。



２．componentの最初でloadModule('モデル名')しておき、$モデル名_dao = new モデル名()でインスタンス化する。こんな感じ
。でもこんな話も。





個人的には１はないでしょ、と。



componentからcomponentって作りが必要になるまでは２でよし、かと。

cakePHPの$this->data

最近、cakePHPやってます。

RoRなどの他のフレームワークもさわったことのない初心者ですが。



で、悩んでるのが「cakePHPで$this->dataに初期値を突っ込んでよいか？」です。



私の出した結論は「全然OK」。



ここやここで更新画面の変更前データ表示用に$this->dataにDBデータを突っ込んでます。



フレームワークはセオリーとかうまいやり方を常に意識しないと、ね。

SEに必要な資質

結論から言うと、



「技術半分、口半分」



というのが私の持論です。



技術力のないエンジニアは信用されません。

コミュニケーションがとれなければどんなスーパー技術者もまったくの役立たずと同じです。