プロジェクトのゆとり。

新しく本を読み始めました。

 その本はこれです。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

これまで仕事や私生活の中でプロジェクトの管理について考えることが多かったんですよね。

それは、私がプロジェクト管理をしているかどうかにかかわらず、「これってプロジェクトだよな？」と思うことが多いことが関係しているのだと思います。

私は、基本的に、プロジェクトに関わる人数が何人であれ、目標を達成するまでにある程度の期間とある程度の作業工程が必要になるものは全てプロジェクトとして考えています。

私は、そのプロジェクトが、どういうふうに進んでいけば、どうなるのかを知りたかったんですよね。プロジェクトに関わる限り、できるならば成功させたいと思うので。

何でもそうだと思いますが、基本的に、本を読むよりも１回経験するのが理解は早いと思っています。百聞は一見にしかず。というように、１００回聞くより１回経験できるのであれば、それが良いと思います。

そうはいっても、１００回プロジェクトを経験できるかといえば、それは難しいと思います。それに１００のアンチパターンを自分で全て潰して行くのは少しばかり心が辛いです。当然のことかもしれないですが、失敗するためにプロジェクトをやることは少ないですし、最初から失敗するためにやるのはモチベーションも上がらないです。とはいえ、絶対に成功するプロジェクトってなんなんだろうと思うようなところもあります。

そして、私はプロジェクトをどうやって成功に導くのかを考えるのがプロジェクト管理であると考えています。

だからプロジェクト管理について勉強してみようと思っています。

まだ、３章しか読んでいないが、すでに経験のあることが書かれています。

効率化を進めようとすると、複数のことを並列で作業しようとする。とのこと。

なぜ複数のことを並列で作業しようとするかといいいますと、仮に一つのことだけを作業してして、それな１日の５０％くらいの時間で終わるとき、同じくらいの仕事を２つ同時にできるよね？という話です。

ただ、それは実際のところ難しくて、複数のことを並列でやろうとすると作業の切り替えが必要になるので、無駄な時間が発生しますよ。とのことに言及されていました。

それはわかります。確かに、複数のことを並列でこなそうとすると、それぞれのタスクや情報を管理するコストがかかります。私も同じ状況になったことがあります。情報の管理のためにコストが爆発して、全然前に進まなくて困ります。そして、すごいフラストレーションが溜まります。

とはいえ、これについて少し対策としてこうならないか、と思っていることがありました。

今の所、複数の作業をやるときに、作業の切り替えで時間がかかるなら、切り替えなければいいのではないか？と思っていたりします。

切り替えないとはどういうことかというと、作業は一つ一つ完了させてクローズして行くということです。

複数の作業をやるなかで一番キツいのは、途中まで物事を進めた後に、別のことに着手することです。そして、その後に途中まで進めた物事に戻ってくる時に時間がかかります。

戻ってきた後は、自分が何をするのかをサイド考え直すことになります。それが結構な時間かかるし、タイムロスになります。

じゃあどうするか、別のことに行った後に戻ってこなきゃいいと思ってます。片道切符しか持たないのではないかと。

そうは言っても、自分のやっている作業が完了していなければ、戻ってこざるを得ないように思います。じゃあどうするか、というのを考えて、今の所は、「タスクひとつひとつをできるだけ小さい単位に分割する。」という方法で試行錯誤をしています。

何かを思い出すときは、自分の行動の軌跡を確認すると楽になります。だから、タスクの一つ一つの履歴を確認すれば、何をしているのかを追跡できるようになります。

ふむ。

そうすると次は、「タスクひとつひとつを小さい単位に分割するか」「小さい単位とは何か。」という疑問が湧き出ます。

これについては、現在、試行錯誤中です。何がいいのかわわからないのですが、とりあえずは、小さい行動と、小さい成果物単位の集合体として、最終的な成果物を定義すると、うまく行くように思っています。

ただし、最終的な成果物が小さい行動と小さい成果物の集合になっている場合、最終的な成果物を構成する行動や成果物を自分で洗い出すことになります。

そこでミスが起きると、時間的な見積もりに狂いが出ます。狂うことが悪いと言っているのはないのではですが、少なくとも狂っているのが現在です。

じゃあどうするか、というと、とりあえず余分に見積もっています。１日にできることを全体の７０％くらいしかつめない。後の３０％は、不要なほどクオリティを上げたり、遊んでみたり、別のことを考えたり、と十分条件に対応するような情報をここでやる。僕にとっての「ゆとり」は、そういう部分と思ってます。

僕が今考えていることは、今読んでいる本で考えている「ゆとり」という考え方とは、少し違うのかもしれません。でも、この本がこれから、どういう風に発展して話が進んで行くのか楽しみになっています。

思考のリハビリ活動

この二週間のひとり旅で少し思考は整理されたのですが、まだまだ、私の頭の中は、気になることや考えたいことで、いっぱいです。頭の中が、たくさんの気になることで埋まっているなと思います。

今の私は、自分の話したいことや、自分が考えたいことが絶え間なく湧いてくる状態です。今の私の状態は、1人で一つのことについて考えている時に、別のことも浮かんでくる状態です。

別のことが浮かんでくると、そっちが気になって仕方がなくなります。そして、浮かんできた別のことを考えていると、また新しいことが気になり始めます。そうして、私の思考の対象は、どんどん入れ替わっていきます。

思考の対象がどんどん入れ替わって行くと、累積的な思考時間としては、どんどん蓄積されて行くけど、一つ一つのなかなか話の進展具合としては、芳しくないという状況になります。

あんまりよくないと思います。

以前はもっと頭がすっきりとしていました。もっと頭がすっきりしていた際は、自分の言いたいことを自分の頭の中で整理することができました。

私はそういう状態になりたいです。頭がすっきりしていて、それをどうしたらいいのかを、頭の中で、考えがまとまる状態です。

こうやってブログなどのために、文章を打っていると気付くことがあります。それは、自分が書いている文章には、結構な頻度で接続詞や助詞が抜けて書いていたり、間違えて書いているということです。主語が抜けているときもあります。

何にしても、私は、正確に日本語を喋れないようになっていると思います。例えば、主語がないまま言葉にして行くのが癖になっていることもあります。

前は、最初はそういうの好きじゃなかったのに、気がついたらこういうふうに、主語がないまま喋り出す癖がついていました。

おそらく、３年前は、自分で考えて、大量の文章を書いていました。

しかし、この三年間は、自分で考えて文章を書くことがかなり少なくなっていました。

そのことによって、自分は正確な日本語を喋れないようになくなったと思います。

とはいえ、それでいいとは思っていません。

ですので、少しずつリハビリを進めていきたいと思っています。リハビリの中で、一つ一つの文章の精度を上げて、きちんと主語を意識して、文章を書くことができると思う。

だから、私は、今、こうやって考えていることを文字にして行くことで、再度リハビリに励んでいます。

ひとり旅に行ってきました。

こんにちは。

会社からゆっくりと休暇をいただきましたので、ひとり旅に行ってきました。

先々週は、４泊５日で、北海道に行ってきました。 

先週は、４泊６日で、バリ島に行ってきました。

久しぶりにひとり旅に行ってきたんですが、だいぶ落ち着くことができました。

私は、普段は東京で生活をしているのですが、今回、北海道やバリ島に行って、改めて、東京って恵まれてる環境だなあと改めて確認しました。

なぜかといいますと、東京って基本的に情報やイベントへのアクセスがすごく容易ですし、治安も良くて安全な街だと思います。

北海道は、安全とは思いますが、「あれ？ここ大丈夫なの？冬とか大変じゃない？」というような場所はちょくちょくありました。

バリ島でも、時折、生死に関わりそうな、話を聞いたり、バイクをヘルメットなしで乗っている人がたくさんいるのをみて、安全じゃないなあと思うことがありました。

まあ、旅行について、今回は、詳しく書くつもりはありません。

今回は、何かしらブログを更新したいなと思いまして、こうしてブログを更新しています。

今、仕事を一旦休憩にして、色々考え事をしている時期になります。

普段の私は、気になることはひたすらメモにとっています。その気になることについて、一つ一つ、時間のある時にひたすら詳しく考えてみるということをしています。

ただ、それがこの３年くらいは、溜まりに溜まってしまって、全然消化できていませんでした。ただ、この二週間ほどで、結構消化することができました。よかった。

とはいえ、気になることを考えると、新しく気になることが出てくるというものです。ですので、数としては、そんなに減ってはいないのですが、それでも、頭の中が整理されたようで、少し気持ちいい気分ですね。

それとは同時に、読みたくて溜まっている本も少しずつ読み進めています。

GWあたりに読みたいと行っていた本で、「パーフェクトソフトウェア」という本がありました。この本は読み終えました。

システムとかソフトウェア開発がうまく行っているのかうまく行っていないのか、という判断は難しい、ということについて学ばせてくれる本でした。

読んでよかったですね。ソフトウェア開発に詳しいベテランにたくさんの経験談を聞いたような気分になりました。実際にこれから、この知識が活かせるのかわからないですが、そのような話があると認識していきたいですね。

はい。

旅行の中で、他にも本を読んでいました。

例えばこの本です。

愛するということ

エーリッヒ・フロムが書いた哲学の本ですね。愛って何だろう。という話を書いてます。

そう、めんどくさい話なのです。私は結構めんどくさい話をモゴモゴと考えたりします。

この本でもそうなのですが、基本的に本に書いてあることって、本を読まなくても自分で経験して、自分で考えて、自分の考えを整理すると、同じことに到達することがあると思います。

この本も、まだ読んでいる途中ですが、私が1人でモゴモゴと考えていたことに近いことが書いてあったりと、なるほどなるほど。と思うところがありました。

それは本を読んでいて面白いことだと思っています。

さて、とりあえず、今回のブログはここまで。

何が言いたいかよくわからない感じになっていますが、まあ文章を書くリハビリと思って、少しずつ書いていきます。

タスクが大きすぎて困る

はじめに

以前、日記で「ソフトウェア開発の一つ一つのタスクが大きすぎることについて悩んでいる」と書いた。

mtb-beta.hatenablog.com

 

作業量を見積もりたい

今回は、その話について、少し書いてみようと思う。例えば、ソフトウェア開発って、ある機能を開発する、ってタスクがあったときに、それがどれくらいで終わるか？というのがなかなか見積もりにくい。

 

例えば、「A機能の開発」とか「デバッグする」と言ったとき、その中に何が含まれているかわからないとき、３時間と見積もるかもしれないし５時間と見積もるかもしれない。３日と見積もるかもしれない。３ヶ月かかるかもしれない。ソフトウェア開発を生業としていくには、それがどれくらいでできるかどうか、という見積もりはすごく大切な気がする。

 

というか、作業見積もりができないと、色々困ることがある。

 

 見積もれないと困ること

とにかく見積もりができないということは、その作業がいつ終わるのかよくわからない。作業がいつ終わるかわからないということは、また色々困ることがある。

 

それが終わった後に、別のことをやろうとしていたとしてもいつ終わるかわからないから、いつ着手できるのかわからない。

 

それに、そもそも来週までに終わらないと意味がないこととかって結構あるんだけど、作業量が見積もれないということは、そこまでに終わるのかどうかもわからないということ。

 

そこまでに終わらないんだとしたら最初からやらないほうがいい感じがすることって結構ある。というか、最初からできないんだったら、別の人にやってもらうとか、他の人に手伝ってもらうとか、そういう話も色々ある。

だから作業量を見積もりたいという話になる。

逆になになら見積れるの？

何でもかんでも時間を見積れないわけじゃなくて、時間が見積れる時もある。日常的な話で言えば、自宅から、最寄駅までの道のりにかかる時間は見積もることができる。

 

ソフトウェア開発にかかる部分で、見積れることもある。例えば、指定されたファイルを指定されたフォルダリストにコピーするとか。でも、ソフトウェア開発の時間で見積もることができないことは多い。

 

なんでだろう。

見積れることと見積もれないこと

今のところ、僕の考えているイメージでは、見積れることって今までやったことがあること。今までに全く同じことをやったことがある場合は、見積れる。

自宅から駅まで歩いて行くとかは、そのイメージ。

 

でもソフトウェア開発って、基本的に新しいことばかり。

というか、新しいことをしないとどんどん後ろに下がって行く気がする。

（新しいことをしない人もいるけどね）

本当に見積もる必要あるんだろうか

こんなことを考えていると、そもそも本当にソフトウェア開発って、時間を見積もる必要があったっけ、と思う。

 

なんで、そもそも時間を見積もっていたんだっけ？

時間を見積もろうとした理由

時間を見積もろうとしたのは、以下のような点が困ったから。

• 次のことがいつ着手できるかわからない。
• いつ完成するかわからない。
• その人がやるべきなのか他の人がやるべきなのかわからない
• 人を増やすべきなのかどうかわからない。 

そこで次のようなイメージが浮かんだ。

•  次のことにいつ着手できるかわからなかったら、終わったら着手したらいいのでは？
• いつ完成かわからなかったら、いつ完成するかわからないという話にすればいいのでは？
• 誰がやるべきかとか考えずに、やりたい人がやればいいのでは？
• そもそも人を増やすべきかどうかを考えるのがなんかおかしいのでは？

うーん。

なんか色々ずれているようなずれていないような、なんなんだろうか。

 

 

どういうことかというと、行動を管理するためには、一つ一つのアクションアイテムが、少なくとも３０分、短ければ５分、で終わるようなレベル感になっていないといけないと思っている。でもソフトウェア開発のタスクは３０分で終わらないようなことがたくさんある。

 

３０分で終わらないと行動の管理が難しい。というか、基本的に僕は、いくら集中力が続いたとしても３０分以上集中できない。だから、３０分以上、例えば１時間のアクションアイテムは、あんまり管理している意味がない。それはアクションアイテムというより、消化すべきタスクリストになっている。それじゃあ、行動を管理している意味がないような気がする。

 

 

まあ、確かに、今の僕が３時間かかるようなタスクも５時間かかるようなタスクも３時間かかるようなタスクも、全て１０分で終わるようになれば、いいのかもしれないし、そのようにスキルを磨いていくのは大切な気がする。

 

とはいえ、自分がやっていることにあとどれくらいの時間がかかるのかわからなければ、行き当たりばったりのクオリティのものしかできないし、それって仕事としてどうなんだろうなあと思う。

 

じゃあそのでっかいタスクの中でやることを、プロセス化して、取捨選択すれば、もう少しクオリティの高い仕事ができるようになるんじゃないかなあと思っていたりもする。

 

とはいえ、プロセス化して、それしかやらなくていいという話になるとかなりおかしい話になるから、自分のためにプロセス化するだけなんだけど。

読みたい本がたくさんありすぎて困る状況

こんにちは。みなさん、楽しいGWをお過ごしでしょうか

僕は、まああいかわらずの生活を送っています。

少々、実家に帰省したりもしましたが、今は自宅に帰ってきて、いつも通り本を読んだり、黙々と勉強したりなんかやってます。

Youtubeで適当に音楽を流していて、最近はこういう音楽が流行ってるんだね。みたいな感じでやってます。

いきなりですが、最近、読みたい本がたくさんありすぎて、やばいことになっています。

買うスピードと本を読むスピードが一致していなくてすごい勢いで本が溜まっていっています。

困った。

まあ勉強したいという意欲があるだけ、今は幸せと思って、マイペースに勉強しようかなと思っています。

とはいえ、全然消化できないと心のモチベーションも下がっていくのでどうにかしたいなと思っています。

なんとかできないものかと思って、とりあえず、読む本をリスト化してみました。

リスト化してみたものの、一つ一つが大きくて、全て読書中の状態から進まず、それもなかなかモチベーションに影響があるなあと思っています。

というわけで、全ての本に対して、目次の章単位で、AIに追加しました。

AIというのはアクションアイテムね。人工知能とかそういうやつじゃないですよ。

こうやって、一つの章を読むたびに、一つの章をOK！ってチェック入れていくと、多少なりモチベーションを保って、読書できるかなあとか思ってます。

なんか、やってもやっても終わってないというか、何もやっていない気分になると、自分は何をやってるんだろうな、って思っちゃいますしね。

こんな感じで、読書をたくさんしたいなあとか思っていたりします。

ソフトウェア開発のテストに含まれていること

何かしら文章を書きたい気分なので、文章を書こうと思います。

とはいえ、今のところブログに書きたい話も特にないので、今日読んでいた本の話をしようと思います。

 

今日もパーフェクトソフトウェアっていう本を読んでいました。

パーフェクトソフトウエア

パーフェクトソフトウェアという本は、ジェラルド・ワインバーグ（1933～）の著書の一つです。

ソフトウェア開発の世界では、有名な人だと思うので、知らない人は調べてみてもいいと思います。簡単にいうと、ソフトウェア開発仙人みたいな人です。

 

そして、パーフェクトソフトウェアは、ソフトウェア開発が大好きなジェラルド・ワインバーグがソフトウェア開発のテストについて書いた本です。まだ、少ししか読んでいないけど、話の密度が濃いと思います。まあ、ワインバーグの本は、全部そんな感じなのですが・・・。

 

で、話の密度が濃すぎるので、とりあえず、SEやプログラマになりたての人に誰でもオススメできないと思っていますし、ソフトウェア開発が好きじゃない人にもオススメできないと思っています。でも、ソフトウェア開発をより良くしたいと思っている人なら、一読する価値はあると思います。

 

今回は、パーフェクトソフトウェアの４章「テストとデバッグはどう違う？」を読みました。そこでは、一般的にテスト、と言われているものが、どういうもので何を含んでいるかを話していました。個人的にすごく興味のあるはなしです。

 

なぜかというと、最近、ソフトウェア開発の一つ一つのタスクが大きすぎることについて悩んでいて、それを整理したいと思っていたからです。これについては、詳しく書くことがあったので、また今度書くことにします。

 

そんなことを考えながら、ソフトウェア開発の中にやることって何が含まれているんだろうとか考えていました。それで本を読んでいたら、パーフェクトソフトウェア、という本に出会って、その中で、テストがどういうもので、何をやるべきなのかについて書いていました。

 

この本によると、テストには、次のような工程が入り乱れています。

• 発見のためのテスト
• 絞り込み
• 特定
• 重要度の決定
• 修正
• トラブルシューティング
• 学習のためのテスト

発見のためのテスト・・・新しい情報が見つけようとする。

絞り込み・・・バグが発生する条件を特定しようとする。

特定・・・バグを修正できるようにコードの中のバグの位置を探す。

重要度の決定・・・修正したことによるリスクと、バグを修正しないことの影響を天秤にかける

修正・・・コードを修正する

トラブルシューティング・・・ソフトウェアの動作の障害を取り除いたり回避したりする。

学習のためのテスト・・・ソフトを使うために試行錯誤する。または遊ぶ。

1人でやっているときは、これらを好きな時間にスイッチすればいいものの、複数人でやっていたり、組織的にやっているときは、これの役割分担がしっかりしていないと揉め事が起きるよ、という話をワインバーグはしています。

これまで、ソフトウェアを開発しているときに、自分がやっていたことをこういう風に可視化されると、もう少し管理しやすくなるような気がしました。

とはいえ、これをどうやって管理しよう？という部分までは今のところ考えが及んでいないんだけど・・・。

今年のGWでやりたいこと

挨拶

みなさんこんにちは。mtbです。GWに入りましたね。

みなさんは、GWに何をする予定でしょうか？まだ、予定が決まっていない人もいれば、予定がたくさん決まっていることもいるのかなと思います。

私は、連休が始まりましたので、ひとまず田舎の方に帰ってきました。

私は連休があると田舎の方に帰ってくることが多いんですが、特に田舎の方で何かをやるという話でもありません。まあ都会にいてもできることをやってるケースが多いです。（例えば、プログラム作ってるとか、音楽作ってるとか、本読んでるとか・・・）

とはいえ、連休中にこんなことやりたいなーと思っていることがあります。

連休中にやりたいこと

こんなことが連休中にやりたいと思っています。 

• GitとGithubを勉強したい
• Pythonでプログラミングしたい
• Pythonの開発環境を整備したい
• 「パーフェクトソフトウェア」を読みたい
• 「Pythonプロフェッショナルプログラミング」を読みたい
• 「データ解析のための統計モデリング入門」を読みたい
• 「ソフトウェア開発者の人生マニュアル」を読みたい
• 「ストレスフリーの整理術 実践編」を読みたい

まあ、他にもあるし、これが全部できるのか、、、というとなかなか怪しい部分ですが・・・。 

一つ一つ軽く触れようと思います。

GitとGithubを勉強したい

お恥ずかしながら、私、ほとんどgitとgithubを使ったことがないんですよね。

「git？あー、バージョン管理システムの分散型のやつね」とかなんか知ってる風のことを言いますが、実際はよくわかっていません。

ただ単に、gitとかgithubのことを本とかで軽く読んだだけです。

実際に使うってところになった時に、どういう風に使うのとか、どんなことができるのとか、どんな風にやるといい感じなのか、とか、全然よくわかっていません。

まあそういうのは、「個人的に追々やっていけばいいかな？」と思っているところがあったり、「最初はわからないのはしょうがない。」的な考えはあるのですが、しょうがないと言いながら、個人的には早くわかるようになりたいという気持ちもあるので、ちょっとこの機会に詳しく勉強したいなあと思っています。

Pythonでプログラミングしたい

まあこれはあれです、Pythonでプログラミングしたい。って話です。

ちょうど、今、Pythonのプログラム課題があるので、それやろうと思っています。

Pythonプログラミング、というかプログラミング自体に少々ブランクがあるので、早く慣れて、もっとスピードアップしたりクオリティ高いプログラムかけるようになりたいなあと思ってます。

とりあえず、Pythonでプログラム書くのは気分がいいし、かけるようになっていくと、なんか気持ちがいいです

Pythonの開発環境を整備したい

Pythonのプログラムを開発する開発環境をもっと整備したいなあと思っています。

今のところ、

iTerm2 + vim + pyenvになっています。

もうちょいソースチェックツール入れたり、テストフレームワーク入れたり、色々やりたいことがあります。まあ何をやれるのかよくわからんので、調べるところですかね。

「パーフェクトソフトウェア」を読みたい

これです。 

パーフェクトソフトウエア

ソフトウェアのテストとはなんぞや？って話について書いてます。

個人的に気になるので読み進めているところです。GWに読み終えなくてもいいですが、ちょっとは読みたいなあと思っています。

「Pythonプロフェッショナルプログラミング」を読みたい

これです。 

Pythonプロフェッショナルプログラミング

私のPythonプログラミングは独学なので、Pythonでのプログラミングってどんな風にやるのがいいんだろう？というのを知りたくて買っていました。

前に３〜４年くらい前にざっと読んだんですが、当時は「へー、こんなことがあるんだ」くらいしか理解することができませんでした。というか、当時は、仕事でソフトウェアの開発に関わってもなかったので、何を言ってるのか、いまいちしっくりこなかったという感じです。これも、また改めて読み返したいなあと思っています。

「データ解析のための統計モデリング入門」を読みたい

 これです。

データ解析のための統計モデリング入門――一般化線形モデル・階層ベイズモデル・MCMC (確率と情報の科学)

いわゆる統計の有名な入門書です。緑本とか言われていますね。

これも2年くらい前に読んだんですけど、再度読み返そうと思っています。

なんでかというと、またそのうち、データ解析の話に関わりそうなんですよね。

ここ1年2年は、データ解析の話をほとんどしていないと言っても過言ではないので、ちょっといろんな知識を復活させていかないと、色々問題がありそうだなあ。と思ってます。まあこれもぼちぼち読み進めたいですね。

久しぶりにざっくり見ると、楽しそう。

「ソフトウェア開発者の人生マニュアル」を読みたい

 これです。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

いわゆる自己啓発本です。今のところ、はじめの方だけ見ました。

読んでて「あーそうそう、僕も1人で同じこと考えた」みたいなことを思います。

多分、基本的に複数の選択肢があった時にどちらかを選ぶということはどういう意味を持つのだろう？という話について、考えたことを書いている流れの本だと思っています。

私も、多くの人と同じように複数の選択肢があった時、両方とも考えて見て、どうするか考えるので、読んでおくとそのうち楽になることがあるかも。と思って読みたいと思っています。

「ストレスフリーの整理術 実践編」を読みたい

 これです。 

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

私は自分のタスク管理をGTDでやろうと思って、色々モゴモゴしているのですが、なんかいまいちしっくりきていない部分がちょいちょいあるので、もっといい感じにGTDを回していきたいなあと思っています。

そのために、色々考えたり試行錯誤してますが、試行錯誤した後に、この本を読むとなるほどなるほど、と思うことがたくさんあるんですよね。

そんなこんなで、ちょいちょいこの本は読み進めていきたいと思っています。

終わり

まあ、とりあえず、私は相変わらずです。GWでも普段の生活とそんなに差がなくて、ただ単に場所が変わっただけみたいな感じですかね。

５月２日くらいまでは、実家周辺にいるので、時間がある人は声かけてください。飲みにいきましょう。