忙しさに紛れて告知が遅くなってしまいました...。
先日(2016年10月22日)発売のWEB+DB PRESS Vol.95に、大場光一郎氏と一緒に RubyKaigi2016 Special Report を寄稿しておりますので、良かったらお手にとってみてください。大変ありがたいことに、主催者の松田明さんにインタビューさせていただいた上で書くことができたので、イベントの心意識がより感じられるものになったのではないか、そうだったら良いな、と思っています!
ひさびさの夫婦仕事でしたが、以前の執筆と比べて平和裏に(笑)終わりました。娘ちゃん氏も控えめに写真デビューしていたりします。
]]>私が社長をしている (株)万葉が、RubyKaigi2016のNursery Sponsor(ナーサリースポンサー)になりました。
https://www.everyleaf.com/articles/8
Nursery Sponsor って何? っていう方も多いと思うのですが、Nursery(ナーサリー)っていうのは、幼稚園、保育園、託児所、というような意味の言葉で、要は、RubyKaigiというカンファレンスの参加者が、会場でお子様を預けることのできる託児サービスを提供するスポンサーです。
カンファレンスに託児サービス、というのは素晴らしい企画だと思います。
というのは、もしカンファレンスに子どもを連れていく選択肢がなければ、男女を問わず、みるべき子どものいる人は、自分がカンファレンスに行くのをあきらめるか、誰か/どこかにみてもらうことをお願いするしかありません。事情によっては、子どもをみてもらうコストはとても高い場合もあり、カンファレンスへの参加を諦めざるをえないことも多いかと思います。「連れていく」という選択肢が加わることは、多くの人・多くの家族の自由度を上げてくれるはずです。とても素晴らしい事だと思います。
結果として、より多様な人たちがカンファレンスに参加しやすくなり、カンファレンスがより良いものになると思うのです。
この企画が実現したのは、Rails Girls や、絵本『ルビィのぼうけん こんにちは! プログラミング』の翻訳で知られる、万葉社員の鳥井雪さんの頑張りと、それに賛同し推進されたRubyKaigi 運営のみなさまの勇気と尽力によるものです。鳥井さんが以前から暖めていた構想が、こうして実現されるということは、本当に凄いと思います。『ルビィのぼうけん こんにちは! プログラミング』の一節「さいしょは、やってみるのが大事だよね」のように、今回はじめの一歩を踏み出したことは画期的であると思いますし、会社として、心から応援したい挑戦といえます。
そして、託児サービスの提供をRubyKaigiではじめて実現するというときに、万葉がそのスポンサーを務められることは、ものすごく名誉なことであると思っています。
2007年にはじめて当時の日本Ruby会議2007に参加したときの私は、万葉という会社を作ったばかりではありましたが、会社はまだ本格稼動前の状態だったので、意識としては「最近Javaからやってきた新参の孤独なRubyユーザー」といったところでした。物珍しく楽しい気持ちで、ちょこりとカンファレンスに参加していました。
それから9年、Rubyのお仕事はもちろん、Rubyコミュニティ、RubyKaigiへのスポンサーシップ、Rubyアソシエーションとの関わり、RubyWorld Conferenceへのスポンサーシップなど、Rubyに関わる活動を継続的に行ってきました。また、会社の個性として、男女のエンジニアがどちらもプライベートや家族を大事にしながら働ける環境作りを目指し、試行錯誤をしてきました。その延長線上で、今回、RubyKaigi初の Nursery Sponsor を務めさせていただけることは、非常に感慨深く、とてもとてもありがたいことだと思っています。
このような動きを通じて、様々なカンファレンスに子どもを伴うという選択肢が増えると良いなと思いますし、そのためにできることを、これからもやっていきたいと思っています。
私と主人の間には三歳の娘がいます。私たち夫婦はともにRubyistなので、子どもができる前は、当たり前に二人ともカンファレンスに参加していました。しかし、子どもが生まれてからは、特に遠方で宿泊必須のカンファレンスともなれば、片方が東京の自宅で留守番をするか、家族で行きつつも片方はカンファレンスをあきらめてホテルを拠点に子守りをするしかありません。二人とも会場でリアルタイムにセッション内容を聞くといったことは非常に難しいのです。今回は託児サービスがあるので、このあたりの事情は一変します。カンファレンス参加の新しい形を試せることにわくわくしています。
RubyKaigi2016の成功と、託児サービスが無事に役目を果たせることを願っています。
]]>20代から30代前半にかけて、お酒は、楽しくなれる手軽な手段だった。いわゆる「なにか楽しいことなァい?」という気分に対して「そうだ!お酒を飲もう」と考えることで、ワクワクと、特別なひと時を感じられそうな期待感が得られたものだ。
しかし、30代後半くらいからだと思うが、だんだん、その手は通用しなくなった。お酒を飲もうと考えることに、幾ばくかの、高揚した気分の残滓のようなものは感じられたが、それを信じることはもうできなくなっていた。あれ、おかしいな。以前はこれで幸せになれたのに、どうしてしまったんだ?
たぶん、私の環境や、お酒を飲むシチュエーションが変化してしまって、お酒を飲むことはもはや特別なことではなく、お酒を飲むシチュエーションだからといって特別に嬉しいこと、高揚することが起きるわけでもないからなのだろう。ペットボトルのお茶を飲むシチュエーションに取り立てて特別な感情が起きないのと同じように。
そして最近、ある事実に気がつくようになった。私はもう10年くらい日常的に目覚ましを使っていない朝型人間で、代わりに夜はすぐ眠くなってしまう。だから、夜のうちに夕食の食器の片付けをしたり、子供とお風呂に入ったりすることも、ちゃんとできるのかどうかいつも心もとない感じだし、実際、できなくて寝てしまうこともままある。気づいたことというのは、この、夜のうちにしたいこと・すべきことをできるかどうかと、お酒の量が、きっちり関連しているということなのだ。要するに、ある程度以上にお酒を飲むと何もできずに寝る確率が高まり、そうでなければ、案外、色々できるということだ。
お酒が以前のような幸福を運んでくれないばかりか、夜の活動時間を奪い、生活負債を増やすものであると認識できたので、自然と、行動も変わってきはじめた。我慢して飲まないようにするつもりはまったくないけれど、無駄にポンコツとなる夜を増やさないよう、必要を感じないときは飲まなかったり、少量にするということができるようになった気がする。
]]>前々から気になっていたのだが、就職・転職活動をしている人の中には、採用されるために必要な大事なポイントに気づいていない人が一定割合いるような気がする。
これは大変に勿体ないことだ。おそらくそのポイントを抑えているかどうかで、勝率も大きく違うことだろう。特に、年齢が上がれば上がるほど、この点の違いは顕著に響いてくるはずだ。
そのポイントとは、「誰の視点で自己PRをするか」である。
典型的な「わかっていない人」の応募資料に書かれているのは、次のようなことである。
一見、何が悪いの?というような感じがするかもしれない。 そこまで悪くはないようにも見える。 しかし、このような応募資料を書いてくる人は、いわば「自分の視点」で就職/転職活動をしているといえる。
企業が採用したいのは、「相手の視点」で自己PRをしてくる応募者のほうである。 「相手の視点」で応募資料を書くと、次のような内容になる。
特に、それぞれの最初の項目についての差は致命的なまでに大きい。
これは視点の差であるので、扱う題材自体は実は同じでも構わない。 例えば、「部活をがんばりました。辛いこともがんばれば乗り越えられると信じています。」を「部活で集団をまとめる苦労をしたので仕事でも複数の人と働くときに役立つと思います。」に変えるだけで印象は良くなる。 「前職で○×に打ち込みました。」を「前職の○×の経験は、御社でも〜の場面で役立つと考えております。」にすればよい。
なぜ企業は「相手の視点」で活動できる人をとりたいのか。それには次のような理由がある。
ここまで読んで、合点がいった人は、ぜひ必要な際に実践してみてほしい。
しかし、ここまで読んでも、やはり相手の視点で書類を書けそうもない、という人もいるかもしれない。その場合の理由として私が思い浮かべるのは次の2つだ。
まず1について。自分がその会社にとって本当に価値がないと思うなら、応募をあきらめるべきである。相手に提供できる価値はないけれど、自分はそこから給料をもらいたい、というのは筋が通らないからだ。しかしながら、大抵の場合は、よく探せば、なにかしらアピールできる材料が見つかる。そこに光を当てるべきだ。
例えば、次に挙げるようなロジックの例は、メインの仕事についていまは大した価値を提供できないといった場合にも役に立つ。
ちなみに、性格はどんな性格でもそれなりにアピールをすることができる。
次に、2の、相手の会社や業界を知らないために相手視点になれない場合について。
これに関しては、その人の年齢や社会人経験の度合いで状況が違ってくる。例えば、新卒の場合は、会社について具体的な想像ができなくてもある程度仕方がない。採用するほうも仕方がないと思って選考するので、あまり気に病まなくても、出来る範囲で会社とは、社員とはといった想像をすれば間に合うことが多いだろう。
社会人経験がある人で、転職先の会社や業界で働くことについてまったく想像がつかないのであれば、それは準備不足だ。採用されたいのであれば、応募するまえに、情報を集めよう。業界にいる知人にごはんでもおごって、イメージできるように情報を仕入れよう。人脈がなければ、本を読むのもよいだろう。
]]>第一回に参加していたご縁でお声かけいただいて、7/5に行われた Tokyo Girl Geek Dinners 第五回でお話しさせてもらいました。
女性の多い場ということで、日頃あまり公に話さないネタなども交えつつ。
色々な人と交流できて、とても楽しいイベントでした! ありがとうございました。
資料をslideshareにあげておきました。
http://www.slideshare.net/nay/girlgeekdinner0705
こちらの記事でも取り上げられています。
http://itpro.nikkeibp.co.jp/article/NEWS/20130708/489803/?top_tl1
]]>2007年4月に会社(万葉)を作って社長になった。2008年に本格的に従業員を(知人ではなかった人たちを)採用した。
前働いていたベンチャーで、社長たちが期末の面談を重視していないのが嫌だったので、当初から"きまじめに"面談をやるように仕組み作りをした。
で、面談をしてみて驚いたことがある。
というのは、突如として私の面談スキルが飛躍的にあがっていたのである。自分でも驚くほど上手にできたのだ!
ここでいう上手というのは比較の問題で、比較対象は昔ベンチャーで開発本部長として働いていた頃の自分だ。そこそこの期間働いていたし、自分が面談が下手だという意識もなかったのだが、2008年に社長としてやった面談とは、全然質が違っていた。それはもう、衝撃的だった。
面談を終えた私は相棒の専務に、すごい勢いで話し始めた。「ねえねえ、私面談うまくなったよねー?!」もちろん、専務は「うんうん、すごく」と肯定してくれた。その後、どうして面談が急に上手になったのかを私はゆっくり考えた。ベンチャー時代にやっていた面談とはどこが違うのだろう?
すると、違いが思い浮かんできた。社長になってのぞむ面談では、私は目の前の従業員(部下)に対して、「会社にとって望ましい職業人になってもらうための指導と、本人の希望と会社の方向感をあわせる調整」をしていたのである。一方、ベンチャー時代にやっていたのは「従業員が機嫌を損ねないで、会社をやめないでくれそうな情報収集と、自分が得意な領域での多少の"一般的な"指導」だったのである。前者にあって、後者にないものがある。それは「会社の行きたい方向や、会社にとって望ましい社員のイメージを知っていること」であり、そして「そちらの方向を目指してもらうという意思」である。
ベンチャー時代の私は、会社がどんな従業員を望んでいるのか、明確に言葉にすることはできなかった。もちろん、そういう上からの指導がなかったということを言うこともできる(が、なんでもかんでも指導がなかったと言えばいいというものでもなかろう)。一応、思い浮かべてみるならば、「全員社長になったつもりで」とか「営業もやれ」とか「一人一人がビジネスをつくれるように」というようなことをおそらく社長は望んでいただろうと想像はついた。しかし、これらは<なるべくコードを書いていたい>という私自身の指向性とかけ離れているため、仮に明示されていたとしてもそちらにむけて部下を指導する気持ちにはなれなかっただろう。
そんなふうに、会社の望みと自分の望みが乖離しているとどうなるか。会社にとって望ましい像に向けて指導することはできないので、自分が比較的できる分野、たとえばコーディングならコーディング、についてはアドバイスができるということになる。あとは、部下が辞めるのはやはりつらいので、とりあえずご用聞きをして、問題があれば上と調整しようと考える。無理はないのだが、本当に寂しい中間管理職像といえる。
要点を整理すると、つまり、中間管理職がうまく部下を面談できるためには、
ということがとても重要なのだと思う。これらがあってはじめて、部下から困っていることや会社の方向性と違う部分を聞き出して調整するという役割も意味を持ってくる。これらがなければ、ある種の根無し草で、「価値観は人それぞれで、私が何かを押し付けることはできません。まあ、私は個人的にこれがいいと思いますよ。さて、何か困っていることはないですか?」ということになってしまう。これでは、上司による面談が多少でも効果があるかどうかは上司の個人的な資質に100%依存し、効果があればラッキーくらいなもので、組織を意味のある方向にまとめ育てていくという機能を期待することは無理だろう。
というようなことを経験してからは、会社の中間管理層に、積極的にそういうことが面談に必要だと思うということを伝えるようになった。
]]>弊社(株式会社万葉)6周年イベントということで万葉.rbが開催され、基調講演その2をつとめさせていただきました。はるばる札幌からいらしてくださった島田さんはじめ、たくさんのスピーカーの皆様、お越しいただいたお客様、会場をお貸しいただいたIIJさま、社内外のスタッフのみなさま、そして海外から素敵なビデオメッセージをお寄せくださったまつもとゆきひろさま、本当にありがとうございました。天候が嵐ということでどうなる事かと思いましたが、思ったよりはひどくなくてほっとしました。
私のスピーチ(「世界を描く Drawing the world」)の資料をこちらにあげました。
http://www.slideshare.net/nay/nay-rb
資料をつくる過程で、2010年の仙台RubyKaigi02で話した時の資料(「Rubyの教えてくれたこと」)をアップしていなかったことに気づいたのでそれも数日前にアップしておきました。大変遅くなってすみません...(^^;)
http://www.slideshare.net/nay/sendai-ruby02
万葉.rbは、6周年のお祝いシャワーでした。大変ありがとうございます。なんというか、終わってみると私にとっては「各方面に盛大に借りを作ることによってこの後も会社を頑張らざるをえなくする」装置となっておりました。折しも、この日記を書いている4/8の翌日から正式に育休明けで職場へ復帰しますので、キリキリがんばっていきたいとおもいます。
]]>非常にご無沙汰しておりましたが...。
多くの方に助けていただいて、1月に無事に娘が生まれました。ありがとうございます。
はやいもので娘も2ヶ月を過ぎ、目線をあわせて笑うように。めちゃくちゃ可愛い生き物ですね、これは...。
]]>7/7に開催された岡山Ruby会議01に参加してきました。
基調講演的な位置づけで招待していただいて発表してきました。が、詰め込みすぎた...。ごめんなさい(><) テーマ的に入門をという意識が強かったのですが、実際に会場に来ている人たちは8割がRails経験者だったので、ちょっとミスマッチもあった気がします。ごめんなさい(><) 掲示板飽きたとかいって作りたいものをライブコーディングしようと思ったものの20分ではあんまり進めませんでした。(_o_;) 重ね重ねごめんなさい...。
資料はこちら
http://www.slideshare.net/nay/good-names-in-right-places-on-rails
とはいえ、全体的にとても良い感じのしっかりした会議だったと思います。スタッフのみなさんの赤いTシャツと桃をアレンジしたロゴもいい感じでした。あとマスコットるびこちゃんも気になりました!
二次会も含めて、興味深い情報が色々あり、参加できてよかったです。
ちなみに、テーマがかぶるので「リーダブルコード」を事前に読破する予定でしたが、6割くらいしか読めませんでした。とてもいい本なのでここで改めておすすめしておきます。
]]>みなとRubyKaigi01に参加してひさしぶりに話をしてきました。大盛況でとても良いKaigiでした。毎月活動を継続した上でああいうのを開けるというのは本当に素晴らしいですね。 懇親会行けなくて残念&申し訳ないです。
ところで、女子多いって声があったけど、まだまだ、うちの会社からみると男子校みたいでしたよっと… :p
お話しした資料はこちらです。
]]>今のところ、私たちの会社(万葉)は受託開発がメインになっている。
世の中には、受託開発 VS 自社プロダクト/サービス提供 という対立軸もあって、それについての私の見解は、こんな感じになる。
まず、純粋に「自社プロダクト/サービス楽しそう。やりたい!」という思いがある。自分たちの作りたいものを自分たちで作るというのはとても明快であり、齟齬が生まれにくい。作る立場として、とても気持ちが良いのはわかっている。
一方で、会社として次のどちらに力点を置くかというテーマがある。
前者の場合、自社プロダクトやサービスの開発というのは目的達成の一部であるので、話の展開によってはソフトウェア開発から離れることもありえる。また、基本的に、プロダクト/サービスを開発するのにもっとも経済的な、効率のよい形を求めることになる。
つまり、ソフトウェア開発を安定的に長く仕事にしたいという人にとっては、次のようなリスクがある。
万葉の出発点は、あきらかに後者である。世の中を変えられるのであればどんな職種でもやります、という話ではなく、ソフトウェア開発を長く楽しむために良い仕組みを作りたいという気持ちがある。もちろん、ソフトウェア開発を行う前提で自社プロダクト/サービスを作ることは可能なので、それは是非やりたい。ただ、「安定的に長くソフトウェア開発で食べていく」という目的には受託開発は実はあっている。なので、そう捨てたものではないと感じている。
特に最近、この形態だからこそできるのではないかと感じているのは、エンジニアの育成だ。
万葉は、実はRuby未経験者を多く採用してきている。Ruby経験の有無や、プログラミング経験の長さにはこだわっていない。それは、教えることができると踏んでいるからである。実務の品質に影響しない割合で初心者を入れ、チームで、社内でカバーしながら、実務をやってもらいながら育てることができる。実際に、ここ数ヶ月は私自身もかなり教育タスクが多かった。いろいろ知見が得られて楽しかった。
このような育成は、すでにできあがった巨大なサービスの改良や、新しい高度なプロダクトの短期リリースが至上命題であるような職場では難しいと思う。もし世の中の現場が全部そんな感じであれば、初心者が一人前のエンジニアになるためのパスはとても細いものになるのではないか。
そう考えると、私たちも、ごくごく小さいものではありながら、一応の社会的意義というか、役割を果たしているんじゃないかな。というように思えてくるのである。
]]>http://www.junkudo.co.jp/tenpo/evtalk.html#20120322ikebukuro_talk
http://d.hatena.ne.jp/t2os/20120306/1331010954
明日は今執筆している本のからみで「仕事でRubyを始める人たちへ-私がRubyを始めた理由(ワケ)-」というトークセッションがジュンク堂であります。
秋以降、仕事が忙しくなってしまい刊行がのびのびになって大変ご迷惑をおかけしているのですが、そんななか刊行予定で敢行されるトークセッション。弊社の運命の人である櫻井さんが、華々しくデビューする予定ですので、予定のない方はぜひいらしてください。SonicGardenの倉貫さんが司会、masuidriveとjpmobileの小川さんがトークする豪華な顔ぶれです。
執筆してる我々もみな駆けつけて応援予定です。
もしかして「行きたいけど電話が嫌だ」って知人の方がいらっしゃれば、twitterでメンションくれれば代理します。...たぶんigaigaさんあたりが :)
まだ席があるようなので、ぜひぜひよろしくおねがいしまーす!
]]>Rubyを使うようになってからのような気がするが、私は日頃、コードを「呼び出し側から書く」ようにしている。とても役に立つ手法だと思うので、ここで紹介したい。
例えば、勤務表から総役務時間を得たいとする。
このとき「ええと、勤務表である MonthlyWork クラスのインスタンスには日ごとに DailyWork があって、それらのうち実役務時間と有給休暇を足して... 」といったことを考えたりは *しない*。
「どうやってその機能を実現するか」を最初は考えないようにする。「本当にその機能を実現できるだろうか、不安だ」というような感情が襲ってくることもあるだろう(特に初心者には)。しかし、大概のことは最終的には実現できるし、もし本当に実現できない問題があったとすればそれは個人のせいではない。
「どうやってその機能を実現するか」を考え始める代わりに、私はまだ存在しないその機能を「呼び出してみる」。
具体的な手順はこうだ。Railsならばコントローラなりビューなり、そのメソッドを呼び出したい場所が「何処」であるかを考える。そして、そこに行って、こんなかんじで打ち込んでみるのである。
総役務時間: <%= monthly_work.total_work_time %>
このようにすることで、最初に考えることは次の3つに絞られる。
この3つは、オブジェクト指向プログラミングにおける基本的かつ重要な設計事項である。ここをいい感じにすることにまず力を注ぐ。
もし、.を打ったあと手が止まってしまうようであれば、SPACEALCなどで調べたり、Googleで検索したり、チャットで意見をもらったりして、適切な言葉を探す。この段階でけっこう時間をかけることもある。
書いてみて、なにか格好悪く感じたり、気に入らなければ、心ゆくまで書き直す。いわば、自分の感性を利用して、I/F設計を練るわけだ。そして、納得のゆく呼び出し側コードを完成させる。
呼び出し方が決まったら、次は実装だ。今回のようなケースではこの後にスペック(単体テスト)を書いたりする。MonthlyWorkクラスのtotal_work_timeというメソッドとして実装することがもう決まっているので、スムーズに書き始めることができる。(逆に言えば、どのクラスのなんというメソッドにするかが不安定な状態で闇雲にスペックを書こうとするよりも、まずI/F設計に集中したほうがよい。テストファースト以前に設計ファーストだ。)
スペックを書いたらそれが通るように実装を行う。冒頭に挙げた「どのようにして総役務時間を計算するか」を考えるのはこのタイミングである。これより前に考える必要はない。ちなみに、実装中に、たとえば日単位のデータを持つ DailyWork に新しいメソッドが必要であるとわかったら、ここでもまず呼び出し側コードを書いて同様の手順で実装していく。
最終的に、スペックが通るようになったら、ブラウザを起動して、一番最初に書いたビューを表示する。ちゃんと動いているはずだ。
以上、「呼び出し側から書く」手法について書いてみた。日頃「書いたコードがどうもしっくり来ない」「この機能はどこに書くのが正解なのかな?」というような悩みを抱えている人の参考になればうれしい。
]]>私は2007年4月に株式会社万葉という会社を友人と二人で設立して、以来、社長という立場で「会社を経営」し続けている。
正直なところ、さして立派な社長ではないと思う。しかし、ともかくも一応もう5年くらい「自走」しているわけなので、最悪の部類ではないと思う。というか願っている。
それで、会社をやっているとさすがに色々と勉強になって、見えてくるものがある。モヤモヤもする。そういうのをぼちぼちと日記に書いていこうかな、なんて思ってきた。前からそんな気分はあったのだが、
というような理由で、踏み出していなかった。しかし、色々なことを考えたり気づいたりしているのなら、それを書いていくのは悪くないと思うので。
とりあえず今日は、「会社をやっているとき、地面は止まっていない」ということを書こう。
会社には「会社を大きくするか、《そのまま》でいくか」という選択肢は本当はない。これは、自分で会社をやってみるまで分からなかったことの一つだ。
「そのまま」という部分がポイント。人数、資本、事業規模を現状と変えないで過ごす、ということが「そのまま」であると、昔は自然に思っていた。ところが、実際にはそうではない。人間は年を取る。お金には利子がつく。人数や資本や事業規模を変えない、ということは「そのまま」ではなくて「ゆるやかな後退」なのであると気づいた。例えるなら、流れのなかで、流れてゆかずに敢えて意志を持って立ち続けているような感じだ。
私と専務は、会社を立ち上げるときに、「無理に大きくしない」「堅実にやる」という合意をしていたが、実際に会社をやってみると、私たちの求めていた堅実とは、人数等を変えない「そのまま」ではなかったことに気づいた。巨大なモーターで流れを10倍くらいにして爆走する気はもともとないが、流れに逆らって立ち続け、実質的に後退する道も選びたくない。ゆるやかに流れていくのが気持ちいい。流れのままに少しずつ大きくなるのが、私たちの求めていた「そのまま」なのだなと思った。
会社には「会社を大きくするか、《そのまま》でいくか」という選択肢は本当はないと書いた。その意味は、実際は「会社を大きくするか、後退するか」しかないのではないかということだ。
もちろん、必要なときは後退もする。大きくするのが良くて、後退は悪いことである、などというつもりはまったくない。それは選択に過ぎない。一番自分にとって衝撃的で、書いておきたかったのは、会社は作ったときから流れの上にあり、止まっている状態は作れないということ。
ちなみに、このことにはっきり気づいたのは昨年、震災の後に耐震性の良い事務所に引っ越すかどうかの判断を迫られた時だ。経営的には悩ましい状態だったが、引っ越さないことも「とどまる」という意志表示であることに気づいた。悩んだ末に引っ越した。その結果が出るのはもう少し先だろう。
]]>今月は熱心に片付けをしている。結果からいえばこの1、2週間は人生でいちばん片付いた家で生活しているといえる。
これまでたどってきた経過はこうだ。
この間、段ボールをはじめ色々とゴミが出て玄関は大変なことになったが都度がんばって捨てていった。
まだまだ道は遠いが、きれいな家はいい。とてもいい。
きれいな家がいいと心から思ったことって実はあんまりなかった。結局これが一番重要な変化なのか。
私のことだからこの先についてはあまり自信がないが、ひとつ言えることは、人間は意外と変われるということかな。ただし、すごく時間をかければね。
]]>