2008年5月アーカイブ

2008年4月に東京で開催したMT4LP5の大阪版として、CSS Nite in Osaka, Vol.9(Movable Type特集)を開催します。基本的にMT4LP5の再演です。

大阪版

名古屋版

ということで、大阪(2008年6月8日(日))と名古屋(2008年6月9日(月))で開催されます(当初名古屋は私は行けない予定だったのですが、予定が空いたので参加させていただくことになりました)。

僕が話すのは東京での話と基本的には同じ(ユーザー指向の管理画面を作る - 管理画面のカスタマイズ)なのですが、最近作ったいくつかのプラグインとか新しいネタも少し織り交ぜて話したいと思います。

東京の時をはじめ、何度か話しましたしこのブログでも書いているので少しは一般化? してきたかもしれませんが、「CMSのユーザビリティ」に注目してユーザー指向の管理画面を作る、というところに進むとサイト構築が一段階楽しくなりますし、それも制作者のスキルのうちです。

と、いうあたりをライブなデモを交えてご紹介します。よく練習しておきますね。


2回目? で既に恒例となった感のある討論会ですね。あんまり真面目に読んでないのですが「10年は泥のように」って言葉が話題のようで。

誰も「我が社に入った人は...」とか言ってるんじゃないんだと思うのだけど、「入社して最初の10年は泥のように働いてもらい、次の10年は徹底的に勉強してもらう」という言葉は会社が20年後も同じくそこに存在していることを前提にした言葉だよね。

もちろん「転職とか会社が存続しなくなって別の会社にいるか独立してるか別にして、10年は...」という意味にもとれなくはないけれど。

ひとつ言えるのは「10年後、その会社、その業種が同じ姿でそこにある時代ではない」ということ。10年後、20年後を考えるのは無駄なことじゃないけど、モノゴゴロ付いて20年も経っていない若い時期に10年20年後を考える必要もない。せいぜいが5年。5年経てば (会社は存続しているまでも) 勢力図は全く変わっているかもしれない。それはどこの業界に行っても同じ。

だからその5年は会社のために働くのではなくて、「自分のために *」仕事の基礎体力をつける時期くらいではないか?

* 勘違いして欲しくないのだけれど、自分のためってのはもちろん「会社で与えられた役割、課せられた責任を果たすことを通じて」ってこと。自分勝手に自己の利益のために働けってことじゃない。

もし初めて働く(働こうとする)会社で20年、30年間スパンのキャリアパスや働き方の話をされたら、ひいちゃっていいと思うよ。だって何の保証もないんだから。僕なら「5年後 (3年後) 会社がなくなってても困らない仕事力をつけろ」くらいに言ってるけどな (実際いつも言ってるな)。

もちろん、会社の規模も歴史も全然違うわけだけど、既に「会社が大きいから安泰」なんて時代じゃないのだと思う。

そして、一方で「個々人の突出したスキル」で勝負したいのであれば、10年、20年を睨んでこんなキャリアパスなんですよ、ってな場所を選ぶのが間違っているのであって「本当に自分が売れると思う人は、そういう個々人のスキルが最大限に生かせる企業に行くといい」というのは全く持ってその通り。そういうところでは、10年20年30年なんてレールがそもそも存在しないのだから、10年後20年後どうなっているかは自分が切り拓いた結果次第 (会社が存続しているかどうかだけではなくて収入とかも結果によって大きく変わる *)。そして、その場合の会社選びは「この人たちと一緒に切り拓いて行きたいかどうか」という視点で選ぶといいのではないかな。

* そのかわりその時になって結果が良くなかったとしても「大手はボーナスが良くていいよな...」とか言うなよ。大きなリターンが得られるチャンスもあるわけだから。

面白い話だな、と思った。

Vista のベータテストの実施中に,あるベータテスターから「『ようこそ』スクリーンでスペースキーを押してもビープ音が鳴らなくなったのはなぜか?」という問い合わせがあった。

意図的に削ったわけではなく,仕様変更によって生じた些細な副作用のひとつに過ぎない。でもなぜそんなことを,このベータテスターは気にするんだろう?

そのベータテスターは目が見えなかった。 Windows が起動したことを確認するために,件のビープ音を利用していたのだという。

こうして,ひとつの特殊処理が Vista に付け加えられた。製品版の Vista では,「ようこそ」スクリーンでスペースキーを押すとビープ音が鳴るようになっている——意図されたデザインによって。

例えば、僕の作成したこのサービスのあるユーザーはPDFをスクリーンリーダーで読むために「Orbit」をインストールして「スタートアップ」に登録している。ブラウザでPDFへ移動したら、Orbitを経由してダウンロード、開いて読むのだそうだ。Orbitの開発者は多分そんな使い方は想定していないに違いない。

また、例えばこいつの「ルビ」ふりモードは、日本語を学習中のある留学生の方が好んで使っているそうだ。また、Color Questは色弱者の方が使うことを想定していたけれど、意外とデザイナーの方が使っているというし。

また最近携帯を「らくらくホン」に変えて携帯サイトを読み上げ機能で読んでいるのだが、これもある意味で作り手が意識していなかった使われ方だと思う。HPRの存在は知っていても携帯で読み上げが出来るって知らない人は作り手の中にもまだまだ多いと思うし。

作成者はどうすればいいかというと、とにかく固定概念をとっぱらって想像力をフルに働かせて考えるということなんだろうが、やはりテストが重要且つユーザーからのフィードバックをちゃんと得やすいしくみにしておくことが大切 (何かあたりまえの話に落ち着いてしまったな)。

「億単位のユーザーを抱えるソフトウェア」でなくともこういうことは良くあって、『ソフトウェアやサービスはしばしば作り手の想像していなかった使い方をされる』ということは常に意識しておきたいと思う。改めて。

「らくらくホンプレミアム」買った。携帯に6万円も使ったの初めてだ。携帯電話の端末ってタダみたいなもんだと思っていた。

ハーモニー・アイさんのセミナーに参加させていただいて、大げさでなく正直感動した。携帯電話の操作が音声ですべて確認できる。サイトも読み上げられるしメールも読み上げれられる。声でメールも作れる(音声メールサービスも申し込んだ)。メール→ブログとか仕込んでおけば、ブログの投稿だって声で出来るのだ。で、これが持ち歩ける。これはすごい!

もう一歩進めば、声で操作指示を出し、音声でフィードバックするものになるのではないか。まさに対話するコンピューター。

Webの読み上げ機能についての詳細はまた改めて書こうと思うが、取りあえずどんな様子なのか音声を貼付けておく(ちなみに「5/14 18:00」でちゃんと日付として読み上げたり、なかなかのものだ。辞書の登録も出来る)。

わかりにくいかもしれないが、途中で文字入力をしているのは「録音中」と入力している。

* junnama って読めるのがなんだかすごい。富士通さんの辞書には「junnama」が登録されてるんだ。

読み上げたのは「MovaTwitter」。サイトを選んだ意味は特にないんだけど、たまたまえふしんさんのエントリーを読んでいて僕は「iPhoneはキャズムを超えない」と思っていたのが関係しているのかもしれない。

少なくとも、これからの日本において若者って少数派だ。アックゼロヨンのときに麻生太郎氏がいっていた「小さい文字で目が疲れるから携帯でウェブなんてみないよ」ってのの反対方向に進んでもそれは若者(これからの日本では40代の自分は若者扱いだ)の間での流行にすぎないと思う。そして若者は少数派であり、マーケットの中心ではなくなっていくのだし。

でも、何がどうってiPhone は人生を変えないもの。ライフスタイルに若干の変化があったり、人生を楽しくハッピーなものに少しはしてくれるかもしれんけど、でも読み上げ機能の付いたこいつには人生を変える力がある。僕がもし明日視力を失ったら、PCではなくこれを使うと思う。実際ボタンの数も少ないからブラインドタッチっていうか、一日触っていれば目でみなくてもそれなりに操作できるようになる。

らくらくホンプレミアム(外観-1)
らくらくホンプレミアム(外観-2)

* 携帯の外観を携帯でとれないので、Macの内蔵カメラで撮った。

ベタほめですけど、一カ所気に入らないのは「決定」ボタンが小さくて手で触って探しにくいこと(見ないで操作すると間違いやすい)。通常のボタン操作はもどればそんなにストレス無いけど携帯サイト使っているときは他所に飛んでしまうと何だかストレスだ。

また、硯箱のようなデザインを変えて若者向けにデザインし直したらそれはそれでもっと売れるのではないかな。iPhoneにかぶれた若者がHandheld Computer /Mobile Webをメチャクチャにしてしまう前に若者に普及させるべきですよ、富士通さん。

昨日の続きです。ちょっと必要があって書いてみたのだけど、なんだかんだと忙しくて本日はギブアップ。だけど一通り動かしてみて一応意図通りに動いてるっぽいので晒しておきます。名前負けです。ファイルマネージャーみたいなもんを最初は意識していたのですが、ちょっと頭混乱したので出来るだけシンプルな実装にしてみました(とはいえ結構トリッキーなこともしているかもしれませんが...)。

要するに、MTから生成された静的ファイルのうち、不要なものをまとめて削除するプラグインです。

改造/再配布自由です (Artistic License)。 <<だったらMTOS/MT問題ないですよね。

但し! ファイルを消去するプラグインなので、自己責任、プライオリティの高いサイトで使うにはテスト不十分です。何か気づいたことがあればご指摘ください。実用的というよりも、実験的なものくらいに考えてください。

利用方法

プラグインをインストール後、一度全再構築してください。その後アーカイブマッピングを削除したり変更したりカテゴリーのベースネームを変更したりして静的ファイルが残ってしまうシチュエーションになったら、再び全再構築してください。再構築完了時に不要な静的ファイルをまとめて削除します。

やっていること

再構築を一度かけた段階で吐かれたファイルの情報をDBに保存します。静的出力されるアーカイブに影響のあるオブジェクト(Template,TemplateMap,Category,Author)が保存された時、あるいは削除された段階で影響のある(かもしれない)静的ファイルに対して削除フラグを立てます。エントリーを非公開にしたり削除した時には、関連する日付ベースのアーカイブに削除フラグを立てます。

再度全再構築をかけた時には、吐き出されるファイルのパスと一致するファイル情報のレコードをチェックして削除フラグが立っていたらフラグを外します(そのファイルは必要なファイルなので)。全再構築処理の完了時に、削除フラグが立ったままのファイルが存在したらその静的ファイルをまとめて削除します。

制限事項・その他

ブログの公開パスを変更した時は...対応していません。さすがに全部が対象になるし。 既に結構無駄な処理してると思います。もっとスマートに出来るよって方は是非ヒントをください。細かくやるのは大変そうな気がします。

MT4.15では再構築に色んなバリエーションが出来ます。正直そこまで頭回っていません。

引き続き考察とか

サイトの運用状況にもよるのですが、削除のタイミングを間違うとリンク切れが発生します。MTでエントリーを先に再構築してインデックスを後に再構築するのはこの点に配慮しているからだと思います。カテゴリーなんかは保存時にベースネームが変更していたらその場でファイル消去してしまいたいところですが(インデックスアーカイブの出力先変更の場合も)、ただその場で削除してしまうとリンクが切れます。そこで、とにかく変更があったオブジェクト (に関連する出力ファイル) に削除フラグを立てて、次の再構築時にフラグを外し、再構築完了後にフラグが立ったままになっているファイルを消去するようにした、ということです。

いきなり削除するのではなくて、一度一覧を表示して選択削除できるようにすれば、結構実用的になるんじゃないかと。

ただ、当然ですが各処理時にDBへのアクセスが発生しますので、負荷はバカにならないと思います。スペックに余裕のある場合でないと現実的にはしんどいでしょう。あと、ファイル削除時に空になったフォルダとかは現状は削除しません。

企業サイトとかだと、意図しないファイルが公開されて検索にひっかかったりするのを避けたい時もあるし、結構制作過程であれこれ変更が入る時があります。そんなケースにどうするかってのを考えていて取り敢えず手を動かしてみた次第です。

追記メモ: アーカイブマッピングを「修正」は良いけれど削除すると駄目なことに気づいた。対策は明日以降。対処済み。

力のある奴をそれなりの報償で連れて来てそれなりの案件やサイト、クライアントにあてがえば会社が回るってそれいつの時代のジャイアンツ野球?

どちらにしても実務経験に乏しい学生の中から人材を見つけるのはバクチと同じであって、少人数の企業が人材を集める方法としては、非合理と言わざるをえません。

この部分に限って言えば根拠に乏しいと思うし、少なくとも僕の考えは違います。ここを放棄している会社に先があるとは到底思えません。

すると、多くの場合は Find Job! のような求人サービスを使ったり、保証があれば伝手に頼ったりする方が多いのではないでしょうか。

「伝手」の方はともかく、『Find Job! のような求人サービス』で『クライアントの要望をヒアリングして自社の提案を導き出すといった、知識集約型の業務フェイズだけで請求の費目を上げられるくらい』の仕事にたえうる人材が、『ネットバブル期以降に創業』した新興の制作プロダクションになんかくる筈がないのです。

求人サービスに登録してスカウトを待ったり広告をみて「ポチっと」応募をしたりしている人ってのは一定の人々がぐるぐる回って市場を形成しているのであって、この業界でほんとうに出来る人ってのは市場を経由せずに行き先を決めてしまうか、さっさとフリーになるか、はてまた会社でも作っていることでしょう。

だから、繰り返すと『『ネットバブル期以降に創業』した新興の制作プロダクションが『Find Job! のような求人サービス』で『事業本部長クラスか経営者に匹敵するスキル』を持った人間を採用出来る筈がない』のです。

かといって『Find Job! のような求人サービス』で採用することが無意味なことではなくて、実務経験のない学生でも多少の『労働集約型業務』経験者でも良いのですが、伸びしろを持ちビジョンに共感出来る若い人材を見つけて採用することには意味があります。

どのみち、どんなに出来の良い人間を集められたとしても「自力で人材を育成出来ない制作プロダクション」がこの先やって行けるはずがありません。「出来が良い」のは、あくまでもその人でありその人を育てたこれまでの環境であって、プロダクションの出来が良いわけではないからです。

そして、これが一番大切なことなのですが、「人材の出来不出来」であーだこーだ言っているうちは、それは「経営ではない」のです。

どこへ行っても通用する人材にとっては、「この会社が自分の(金銭を含めた様々な)価値を最大化できる」場所であること。そうでない人材にとっては、「この会社であれば世間 (クライアントや市場と言い換えても良いでしょう) に通用する仕事ができる」。そういった「何か」を持っていなければ、出来る人材をつなぎ止めておくことも出来ないし、働く人にとっては「たまたま今ここで働いているけれど」という前提付きの仮の居場所にしかなりません。

『そういった「何か」』というのが即ち「長時間労働や従業員の報償を抑える」意外「魔法」であり、それを従業員側でなく経営側が提供できることが魔法を使う資格なのです。

例えば、従業員はさっさと帰って高い報償を得て、経営者が徹夜 * 、安い報償で働くってのも魔法の一種です。それでも逆のケースよりはなんぼかマシです。僕はごめんですが (そんなの本物の魔法なわけないし)。

* 経営者が徹夜ってのは冗談ですが、「従業員はさっさと帰って高い報償」を得られる職場や環境、ノウハウを確立するってのも経営側の大切な役割の一つなのではないでしょうか。

そのようにしてしか販路を開拓したり維持できない制作プロダクションは、遅かれ早かれ次のような対策をとるしかなくなります。第一に、コストなしという意味でのサービスを実現するため、工数がかかっても人件費が膨張しない魔法を使います。

工数とコストがかからないのが魔法です。労働時間が短縮されて収益性が上がり、アウトプットのクオリティが上がり顧客満足度があがれば良いわけです。そのためにプロセスの分解をしてノウハウを総動員して「ならではのやり方」を確立するのが仕事というものです。そしてそれは『労働集約型』の場合特に顕著に結果として現れてきます。

逆に『知識集約型』の落とし穴として、クライアントに対する『知識集約』に熱心なのはいいとして、自社のマーケティングや人材戦略に対する『知識集約』が出来ないというのがあります。自社のサイトが「作成中」状態のままだったり、ちゃんと欲しい人材へのメッセージが表現出来ていなかったりして。収益性や事業効率を自社のサイトを通じて改善出来ないものがどうして顧客の何かを改善できたりするのでしょう?

クライアントに対する『知識集約』に熱心な理由は、それが稼ぎにつながり満足が得られるからです。但しそれはあくまでも目の前の満足に過ぎないことを忘れてはなりません。放置したツケはやがて自分たちを疲弊させ、競争力を奪うでしょう。

そして、もうひとつ。『知識集約』は展開・育成するのが困難です。事実、経験者を見つけ、採用することにやっきになって、育成するのは現実的でないとかバクチだとかいう認識になってしまう会社の多いこと多いこと(ふた言めには社員の出来が悪いとかなんとか)。


ちょっとだけ話を変えます。ここ大切な視点なので。

前回は発注側に対して、ウェブサイトを自社の事業(部署)として運用すべきだという話を展開しました。

発注側は確実に変化していて、事業に本気なところ程社内にそういった部門をツクり、組織化しようとしているように感じます (そういったクライアントと仕事をすることが増えています)。

これは即ち「制作会社の人間にそんなものを期待しない」という流れです。そうなった時に、クライアントが制作会社、制作プロダクションに求めるものは何でしょうか? 大した力もなくクライアントの担当者程本気でもない上流工程の『知識集約型』人材でふくれあがってコスト競争力の無くなった制作会社を切る * ことか、数少ないウェブ業界の『知識集約型』仕事をこなせる人材を引き抜くかです。

* そのかわりに (例えば) クライアント自身の立てた事業戦略をスムーズに理解し下流工程までをカバーできてコスト競争力も高い発注先をピンポイントで新たに見つけるのです。

その時、どこで勝負しますか?

結局のところ、それがどんな業種であろうと『型』であろうとクリエイティビティを発揮すべきポイントは無数にあって、どの方向を選ぶのが正解なんてものはありはしないのです。且つそれは時間とともに変わって行きます。


そもそも5年以上のあいだ事業継続しているウェブ制作プロダクションがどれだけあるのか疑わしい

ようやく5期末を迎えようとしている段階で偉そうに言えたもんじゃないですけど。 今期は例えばFind Job! から入って来た若いスタッフがちゃんと結果を出せた期だったということを最後に付け加えておきたい (もちろん自社サイトやBlog経由でやって来たのも含めてね)。もちろん報償にもきちんと反映するし、ルールも決めてある (だからこんなこと書いてるわけだけど*) 。

* 業界のことは知らんが。というか何でこんなに業界にこだわる人が多いんだろう。

しかし、人材不足を悪化させないように現在の従業員の待遇を上げて流出を防げるかと言えば、殆どの制作プロダクションではそんなことをする余裕がないと言えるでしょう。

人材不足を悪化させないように従業員の待遇を上げる、という思考になった時点でもう負のスパイラルまっただ中です。従業員の待遇が上がるのはシナリオ通りであるべきで、それ以上の理由が必要だとしたら、その時点で負けているのです。


追記:
えーっと、ちょっと意識的に長めに書いてみたけど...読むのしんどかったよね、ごめんなさい。

ほとんどメモ。ToDo的に書いておく。

Movable TypeをEnterprise CMS的に使う場合に、生成されるファイルの取り扱いに注意が必要。エントリーの削除、非公開の際には静的生成されたファイルは削除されるけれども、例えば以下のような場合に静的に生成されたファイルが残ってしまう (場合によっては残したくないファイルが残ってしまい、意図しないファイルが検索にひっかかってしまったりする (ここでは「ゴミ」と呼ぶ) )。

  1. テンプレートが削除された時
  2. ブログの公開パスが変更された時
  3. カテゴリーのベースネームが変更された時(且つカテゴリーアーカイブ (カテゴリー - 日付別) が指定されていてベースネームがアーカイブマッピングに含まれていた時)
  4. カテゴリーが削除された時(且つカテゴリーアーカイブ (カテゴリー - 日付別) が指定されていていた時)削除されるようです。すいません。
  5. 特定のエントリーを削除または非公開にしたことによって、特定の日付アーカイブにエントリーが存在しなくなった時
  6. ユーザーが削除された時 (且つユーザーベースのアーカイブが指定されていた時)
  7. ユーザーのdisplay-nameが変更になった時 (且つユーザーベースのアーカイブマッピングにdisplay-nameが含まれていた時)

* 最新版のMTOSではどうなるか試していない。

これらの各タイミングで、静的に構築されたファイルを削除し、再度再構築を行うことで(ゴミが残らずに)正常なファイル構成となるよね。

面倒なのは「5 (特定のエントリーを削除または非公開にしたことによって、特定の日付アーカイブにエントリーが存在しなくなった時)」だろうな。その他は何とかなるだろう。

むしろ、ステージングサーバー上でファイルを生成して、そのファイルを公開サーバーへ反映させているような運用の場合は、fileinfoテーブルを元に一旦生成されたファイルをクリーンアップしてしまって再構築し直した方がはやいかもしれない。ということで、今からちょっとだけ書く (かも)。


ちょっと書きかけ段階でメモ追記:

まとめて削除するならば、 fileinfoテーブルもどきを作って構築日時を記録するようにしておいてから、

  • template,category,entry,authorのidが既に存在しないもの(blogは除外して考える) は削除対象
  • 何らかのオブジェクトを修正した後、全再構築をかけて、(DB上の)構築日時が更新されていないもの (Indexアーカイブは除く)は削除対象
  • Indexアーカイブは、再構築直後に同じテンプレートIDの他のアーカイブを削除

でいけるか...な? だんだん混乱してきたよ。最初はfileinfo見て処理しようと思っていたけど、エントリーアーカイブのマッピングを修正した時なんからは重複するfileinfoレコードを丸めて? しまうから削除すべきファイルのチェックには使えないので。

意外と意味があるんじゃないか、というお話。

「パンフレットをそのまま載せたようなコーポレートサイトじゃ意味ないよね」ってな論調があって (どこにだよ) 、それはまぁ確かにそうだと思う一面があるんだけど、業種や規模やその他諸々の事情から無理にウェブでやらなくてもってこともあるだろうと思う。問合せが増えると効率の下がる業種業態もあるだろうし、例えばその場合は無理に「双方向」とか言わなくてもいいし。

何でこんなこと書いているかというと、コーポレートサイトのターゲットを考える時に意外と忘れがちなのが「身内」なんじゃないかな、ということを感じたから (自分の実感としても感じているから)。

サイトに限らずもちろんパンフレットでも良いが、会社案内を一生懸命見る人って誰だろう? と考えた時、お客はもちろん (お客はそんなに一生懸命見てくれんかもしれん) 、社員予備軍である応募者ってのが浮かぶよね。もう一歩進めて考えてみると、応募者には応募者の周囲の人たちがいて (家族、友人、恋人とか、恋人になる手前の人とか)、応募者はやがて社員になって、周囲の人も変化していって (家族が増えたり新しい恋人ができたり)、その人たちもサイトを見るだろう。場合によっては社員は「元社員」になって、転職先の採用担当者がサイトを見るかもしれん。

で、コーポレートサイトを作る時にターゲットは「顧客」「顧客予備軍」「応募者」「株主」くらいは考えることが多いのだけど「身内」と「身内の人の周囲の人たち」をメインターゲットとして作るっていう考え方もあると思う。

つまり、大真面目に「自己満足」のコーポレートサイトづくりということ。

# 余談だけど今オフィスの引っ越しを画策中で、ビルの大家とかも見るんだろうな、とか、あんまり普段考えないところに実はサイトのビジターがいて、そういう人々に対してアピールできるってのが意外と会社の強さにつながったりするんだ、という なんというかつぶやきのようなエントリーですが。

GW脳? なのであんまり真面目に考えていないけど。

ウチのスタッフに良く「ブログを書けよ」っていうんだけど書いてるのは数人。

「書くこと無いですよ」とか「書く時間無いんですよ」とか言うし。

ひとつはコスト(書く労力) の問題。これは改善すれば宜しい。それが我々の仕事でもあるんだから、現在のブログシステムにブログを書くコストが馬鹿にならないのだとしたら考えればいいのだ。

もうひとつは「書く意味」と「テーマ」の問題。書く意味はつまりアウトプットの意味なんだけど、これが見つけられず意味を見いだせないのもちょっと違うかなぁ、職業的にさ。

ウチの会社のクライアントはすべてアウトプットの意味を考えに考えて発注してくるんだし、個人と会社と仕事とは違うってのもそりゃそうかもしれんが、たまにはそのあたり真面目に考えてみるといいと思うな。

あと、携帯もそうだ。ウェブの制作者である前に、やはり何かを買う立場とかウェブやテクノロジーやユーザーが触れるものの立場に立つことを忘れてはいかんと思う。

で、タイトルのことだけど、ふと思った。

ブログにエントリーポストするインターフェイスもそうなんだけど、例えば毎日ブログを書くということを「一日の終わりに世の中に向けてメールを1通書く。」くらいの感覚にして書いてみて、それでどんな変化が自分の周りと自分自身に起こるのか、っていう体験を観察する、くらいの軽い感覚でやってみてはどうだろう。

メールの何通かくらいは毎日書くだろうし、メール一通書くのにそんなにエネルギー割かないよね。

ということで、↓これでも仕込んで、

この程度でも構わないので↓書いてみたら? (あ、まだベータのままだった。入れ替えないと)

Facebook

Twitter

このアーカイブについて

このページには、2008年5月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年4月です。

次のアーカイブは2008年6月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6