スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第14話)


「As Is」をきちんとやっておくことでユーザーの方たちに納得のいく説明をしてあげられるという話をしました。
今日はその続きです。

・・・・・

いきなり「To Be」から入った場合、そのシステムの導入効果が抽象的にしか説明されていない場合が少なくありません。

「コスト削減を目指す」
「品質の向上」
「業務の刷新を図る」

とかの類いです。

どの部分をどう変えるからコストがこの位削減できるんだ

とか、

どこの作業がどう刷新されるんだ

といった根拠が具体化されないことが多いです。

それは無理もありませんよね。
現状を具体化する作業を行なっていないのですから、そこからの変化を具体的に表現することなんかできません。

「As Is」をきちんとやっておけば、システム構築に関わっていないユーザーの皆さんにもきちんと説明できる材料を得られるので、新しいシステムのスムーズな運用開始につなげられるのです。




(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 
                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

スポンサーサイト

プロセスバリュー・エンジニアリングとは(第13話)


「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあるという話をしました。
今日はその続きです。

・・・・・


「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあると言うのは、

ユーザーの方々と同じ視点で問題を捉え、違う見方の解決策を提示できることがある

からです。

バグでも何でもないのにユーザーから不満を寄せられていると言うときに、
およそそのユーザーの方たちは現状との差異を問題にすることが多いです。

だからその「現状」を知らなければユーザーの方たちの不満の原因を理解してあげられません。

さらに言うと、そのシステムを構築することにより得られるメリットが、現状が変わることよりもどれだけ優位性が有るのかと言うことを納得してもらうこともできません。




(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第12話)


いきなり「To Be」から入るようなシステム構築の進め方が火を噴くケースの話をしました。
今日はその続きです。

・・・・・

開発側にとっては開発工数や難易度に大きな差が無いような仕様の違いであっても、どちらを選んだかでユーザーから思わぬ批判を招くといった不幸な事件は時代やICT技術が変わっても相変わらず発生しています。

決して誰にも悪意などないのに、です。

システム構築において、

システム要件で迷ったときには、現状の仕様に近い方を選ぶ

それがセオリーです。

それはお分かりのように、現状のやり方には実績があるからです。
要件をどうしようか迷う程度の、問題視されていない部分の要件なら現行の仕様がいいのです。

ところが、「As Is」の作業を飛ばしてしまっていると、その「現行」がわかりません。
システム設計者にとって、重要な判断基準が得られていないことになるのです。

「As Is」をきちんとやっておくことで運用をスムーズに開始できることもあります。





(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第11話)


システム構築いきなり「To Be」から入るやり方の危うさについて触れてきました。
今日はその続きです。

・・・・・

「As Is」の定義を飛ばしていきなり「To Be」から入るやり方をしたがためによく火を噴くのは、
幸運な場合ならカットオーバー以前でのユーザーレビューの時が挙げられます。

それは要件説明の会議かも知れませんし、システムテスト結果の報告会かも知れません。
場合によっては、ユーザーによる試行運用かも知れません。
いずれにしても、構築関係者の範囲での影響に済みます。

そして、最悪のケースは、本番リリースした後です。

「どうしてこんな動作するんだ?」
「どうしてこんな出力なんだ?」
「どうしてこんな操作手順なんだ?」
     ・・・

今までと違う業務手順を突きつけられたユーザーから一気に不満が噴き出すのです。
そして完成してしまった後の修正はとても費用が掛かるのが通例です。


ところで実は火を噴く前に予兆があったはずです。

「どっちの要件にしようかな?」
「どっちのパターンにしようかな?」

要件を詰めていくに当って、システム設計者が判断基準を持っていないために迷った瞬間があったはずです。
あの時にそっち仕様にしておけばこんな炎上は起きなかったのに!Y(>_<、)Y

みたいな後悔するはめにはならなかったのではないでしょうか?



(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 
                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第10話)


システム構築いきなり「To Be」から入るやり方の危うさについて触れました。
今日はその続きです。

・・・・・

これは価値観の問題にもなるのでしょうが、
いきなり「To Be」から入るやり方でも大丈夫な場合は、
その方が好ましいという考え方もあろうかと思います。

そのような考え方を支持する方がいらっしゃることについて、別に私は反対しません。

理学的なものの見方をしているのか、
それとも
工学的なものの見方をしているのか、

そういった違いに近いところだと考えるからです。

問題にすべきは、「As Is」の定義を飛ばして「To Be」に進むことが相応しくない場合の対応です。

それで行けるか行けないかは、一体誰がその「To Be」の設計者なのかでだいたい想像が付きます。
構築したそのシステムの想定ユーザーと「To Be」設計者との関係を見れば、おおよその場合当ります。


さて前々回で

現状分析は構築したシステムが受入れられるかどうかの生命線とも言える

と書きました。
もう一言足すならば、

現状分析は構築するシステムの要件に対する納得性や支持を得られるかどうかの生命線である

と言うこともできます。


(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第9話)


前回、システム構築の生命線と言える要件定義について、静的な要件と動的な要件を区別して行なうことの重要性について触れました。
今日はその続きです。

・・・・・

要件定義がシステム構築の生命線だとすると、現状分析は構築したシステムが受入れられるかどうかの生命線と言うこともできます。

手間を惜しんでか、費用を惜しんでかわかりませんが、いきなりシステム構築またはシステム導入をするケースがありますね。

いわゆる「As Is」の定義を飛ばして「To Be」を描き、それに突き進むのです。

果たしてそう言った活動のウチどのくらいの割合が成功しているでしょうか?

システム構築またはシステム導入の推進者と、そのシステム利用者がほぼ同じ人間と言える場合なら、いきなり「To Be」から入るやり方でも大丈夫でしょう。

もしくは力関係がハッキリしていて、システム利用者に「押付け」が通用する状況下でも大丈夫なことが多いと思います。

しかし・・・

(続きはまた今度・・・(^^)/ )


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第8話)


前回、システム要件定義について話を始めました。
今日はその続きです。

・・・・・

要求定義も要件定義も、どちらもシステム構築の生命線と言える重要なものです。


静的な要件と動的な要件とがあります。
静的な要件とは、画面や帳票書式と言ったものがあります。
動的な要件には能動的な要件と受動的な要件があります。

能動的な要件とは定型パターンに沿って処理が進む要件です。

受動的な要件とは、例外処理や条件分岐のように、状況に寄り処理が変化するものです。やっかいなものになると、条件分岐自体が状況により変化するものがあります。

難しいのはこの動的要件を定義するところです。
ですので、要件定義の作業の中で、静的な要件と動的な要件を区別して管理することが助けとなります。


(続きはこちらへ・・・)





              <Time Slip>
           ☞ 前回   ☞ 第1話 




                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

情報節という考え方(第6話)


前回は「通過節」というものを紹介しました。
今日は情報節の2つめです。

・・・・・

2.分岐節(ぶんきせつ)

情報内容によって異なる処理(作業)に振り分ける節です。

通過説同様にこの節でも情報の内容が変わったり、何か新しい情報が加わったりしません。

しかし「判断」が行なわれています。

見落としてしまうような例外処理がアルゴリズムの中に生じるリスクが高い節と言えます。





(続きはまた今度・・・(^^)/ )



              <Time Slip>
              ☞ 前回   ☞ 第1話 



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第6話)


現状把握のために行なうヒアリングの方法における留意点について話してきました。

今日はその続きです。
・・・・・

ヒアリングは実態を知るために行なうのですが、あまりにもそれに捕らわれすぎて尋問口調になってしまってはいけません。

また完全主義にならないような寛容さも大事です。

あまり厳しく求めてしまうと相手が萎縮して思い出すものもの思い出せなくなってしまいます。
そもそも現状を聞いている相手のその人は、現状調査の後に行なう業務改革実施フェーズでは当事者もしくは関係者になるのです。

一緒に改革していく仲間になる人たちなのです。

だからヒアリングの機会を通じて信頼関係が築けるようにしないといけないのです。



(続きはこちらへ・・・)





              <Time Slip>
           ☞ 前回   ☞ 第1話 
                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

情報節という考え方(第5話)


前回、情報の流れを理解して整流化するには「情報節」というものを理解すると助けになりますよという話をしました。
今日からいろいろな「情報節」について順番に見ていくことにします。

・・・・・

1.通過節(つうかせつ)

文字通り、情報が通過しているだけの節です。

情報の内容が変わったり、何か新しい情報が加わったりしません。

メモ用紙に書いてきたので、それをワープロに打ち込んで・・・なんていうこともしません。
(難しい言葉で言うと、媒体変換もしないと言います)







(続きはこちらへ・・・)



              <Time Slip>
              ☞ 前回   ☞ 第1話 




                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

情報節という考え方(第4話)


活動の生産性を左右する情報の流れ。
では、情報の流れにはどんな特徴があるのでしょうか?
・・・・・

川の流れを思い浮かべればわかるように、情報の流れも時には淀んだり、止まったり、場合によっては消えてしまうこともあります。

それらの情報の流れを上手にコントロールしてあげることが重要です。

敵を知り、己を知れば、負け知らずの戦を100回でもできるという有名な格言がある通り、この情報の流れとはどんなものかを知りましょう。


情報の流れを理解するには「情報節」(じょうほうせつ)というものを考えるといいと思います。

「節」(せつ)とは、情報の接続点と言う意味です。

情報を受け取る、情報を発信する、情報を加工する・・・など情報と結ばれた作業=プロセスが「節」です。



「情報節」は私の独自の見方なので一般的ではありませんが、この「情報節」の種類を頭に置いておくと役に立つと思います。


次回から「情報節」の種類と特徴を見ていってみましょう。




(続きはこちらへ・・・)



              <Time Slip>
              ☞ 前回   ☞ 第1話 



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

プロセスバリュー・エンジニアリングとは(第5話)


現状把握のためのヒアリングは、先入観と偏見を持たずに謙虚な気持ちで向き合わなければいけません。
しかしだからといってただ素直に聞いているのもダメなのです。

今日はその続きです。
・・・・・

私は初めから終わりまで相手の話全体を振り返り、今発言している内容で矛盾点はないか?飛躍は無いか?とリアルタイムでチェックします。

そこにはそれまでの経験を総動員した「勘」がアンテナを張っています。

またあるときは、とぼけて同じ内容の質問を時間をずらしたり、表現を少し変えたりしてぶつけたりしてみます。

時にはどんな答えが返ってくるのかほぼ想定できるような質問も混ぜながら相手の気付きを誘います。

時折、オブザーバー的に入る第3者がわかったような口を挟んでこのテクニックの足を引っ張ることもありますが、その場合でも少し時間を置いてリトライします。

「事実は小説より奇なり」という言葉はありますが、業務分析の世界では事実の積み重ねには納得性が伴うのです。

納得できないと「勘」が「おかしいぞ!」っていうシグナルを発します。




(続きはこちらへ・・・)





              <Time Slip>
           ☞ 前回   ☞ 第1話 





                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

プロセスバリュー・エンジニアリングとは(第4話)


現場の生の声を聞くことが重要なのだけれど、それは結構難しいものだというお話をしました。
でもそれを乗り越えなければ現状把握が進みません。

今日はその続きです。
・・・・・

現状把握の為の聴き取りは、先入観を挟まずにしっかりと聞くことが大切です。
しかし、相手の言葉の中に事実と違うものや事実から離れた表現が混ざっていることがしばしばあります。

そう言う場合、相手を責めることは百害あって一利無し。
聴き取りが壊れてしまうこともあります。

別に相手が意図的に嘘を付いているわけではないのですから。

不正確な言葉混じりの回答をできるだけ浄化して、事実を浮かび上がらせるためには、会話が重要です。
ただ素直に聞いているだけではダメなのです。それなら素人でもできます。




(続きはこちらへ・・・)




              <Time Slip>
           ☞ 前回   ☞ 第1話 




                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

データフローダイアグラムの使い方(第2話)


データフローダイアグラム(Data Flow Diagram、データフロー図)を取り上げて話し始めました。

今日はその続きです。
・・・・・

DFDの書き方を紹介している記事は多いですが、使い方について触れた話題というのは少ないようですね。

「DFDの書き方」と「DFDの使い方」はとても近い概念ですが、「使い方」の方がより強く「意図」が込められることになります。

習った「書き方」に捕らわれることなく、「意図」「目的」によりその作法や使う記号などをアレンジして構わないと思います。道具なんですから。

通常では、DFDを書くことは目的でもゴールでもありません。
あくまで目的を達成するための通過点です。中間生成物です。

だから自由な発想で使って良いのです。


ただし得意なこと、不得意なことがあるのでそこはよくわきまえている必要はありますが。


まず心構えとして、DFDは

「概要を」「短期間に」把握するための道具

だということを忘れてはいけません。
そこからはみ出していくとDFDの最大の特長である「シンプル表現」という特性を失ってしまいます。

さきほどの「作法や記号をアレンジして構わない」という記述と矛盾しているように受け取られては申し訳ないのですが、

角を矯めて牛を殺す

の轍を踏んではいけないということを理解しておいて欲しいのです。


繰り返しますが、DFDは対象業務のおおよそのイメージが理解できていればいいのです。

抽象的な表現になってしまいましたが、例えば5W1H(When,Where,Who,What,Why,How)が解れば上出来ですが、「誰が何をしている」のように主語、目的語、述語の3つだけが揃うだけでもいいのです。

書き方の説明の中で、

DFDでは「誰が」を書かない/書けない

と記述したものも時折見掛けますが、そんなことはありません。多くの場合「誰が/どこが」は重要な情報なのです。






(続きはまたいつか・・・(^^)/~~~ )




              <Time Slip>
           ☞ 前回


                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

プロセスバリュー・エンジニアリングとは(第3話)


「敵を知り、己を知れば、百戦危うからず」という格言が、プロセスバリュー・エンジニアリングにも通じるという話をしました。
今日はその続きです。
・・・・・

敵を知るということは、よく言われる言葉では「現状把握」というものが当てはまります。

ただ、把握だけしてもアクションにつながらないので、把握した結果を分析するところまですることが重要です。

分析までを含めて「現状把握」と呼んでもいいし、もっと明示的に「現状分析」と呼んでも構いません。

PVEでは後者、すなわち「現状分析」という呼び方で現状の把握から分析までを含めています。


現状分析の良し悪しで、その後の活動が大きく左右されます。
通常はそこで発見されるもしくは共通認識される事実によって、活動の方向性が決まるからです。


現状を把握するためには、対象となる業務に携わっている人たちからいろいろ聞かせてもらわなくてはいけません。
資料も重要ですが、生の声をきちんと拾い上げないと本質的な部分が見えてきません。

なので生の声を聞くことが非常にキーポイントとなるのですが、そこが結構難しいのです。

難しい理由の1つに、聞かれる側の人たちがうまく言葉で言い表わせないケースがあります。
普段何となく感じていることでも、いざ人にきちんと説明しようとすると相応しい言葉が浮かんでこないようです。

また、「こんなこと言ったらまずいよな」みたいに感じるのでしょう、知らず知らず防衛的な姿勢となって言葉を濁してしまうこともあります。

そういったハードルを乗り越えないと、重要な事実を聞かせてもらえることができなくなるのです。




(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回   ☞ 第1話 





                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

プロセスバリュー・エンジニアリングとは(第2話)


プロセスバリュー・エンジニアリング(PVE)の紹介を始めました。
今日はその続きです。(^^)
・・・・・

「敵を知り、己を知れば、百戦危うからず」という有名な孫子の兵法がありますね。
これはいろいろな場面にも通じる格言だと思います。

もちろん業務の生産性や品質を高めるための取組みにも応用できます。

この場合「敵」に例えられるのは、改革・改善対象の組織です。
「己」は改革・改善に取り組む人たちです。

「敵」の特徴、実態、その背景や経緯を理解することです。
「己」の手腕、経験、意欲、体力、予算、そして武器とも言うべき手法を理解することです。

ただ、単に敵を知り、己を知っただけでは準備完了とは言えません。
その戦いをする場所の地形や気候といった環境も調べて、戦略や戦術を組み立てなくてはいけません。


業務の生産性や品質を高めるための取組みに当てはめると、種々の「制約条件」を押さえることです。






(続きはこちらへ・・・)




              <Time Slip>
           ☞ 前回



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

情報節という考え方(第1話)

企業活動だけに限ることではありませんが、多くの活動には

「モノの流れ」

とそれを潤滑に確実に行なうための

「情報の流れ」

が関わります。

 ※ ここでの「モノ」はいわゆる「物」ではありません。
   形のあるもの全ての総称です。お金や人も含まれています。


例えば、製造業であれば材料を仕入れて製品に加工してそれを市場に送り出す

というのがモノの流れですね。

サービス業であれば、例えば旅行会社であれば旅行客を募集して旅行に送り出してそして旅行が終わるまで

がモノ(ただしくは「人」ですね)の流れですね。

これらのモノの流れがきちんとしていることが重要なことは当然ですが、時として「きちんと」流れてくれていないことがあります。

その場合、「情報の流れ」が整流化されていないことが原因であることが案外少なくありません。







(続きはこちらへ・・・)



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

プロセスバリュー・エンジニアリングとは(第1話)

Process Value Engineering(PVE)という言葉をご存じない方も結構いらっしゃると思います。
PVEは業務の生産性や品質を高めるための技法です。

企業や役所、学校など、おおよそ組織と呼ばれるものは、多くの人が関わりながら活動しています。
それらの活動を「業務」と呼ぶことにします。

業務には手順や手続きがあります。これが業務プロセスです。

業務プロセスのやり方が洗練されて、スムーズに、スピーディーに、ハイクオリティーに遂行されている状態を、プロセスバリューが大きい状態と言います。

すなわち、余計なムダや余計なムラがなく、安定的に高い成果を出している状態が、プロセスバリューが大きい業務が行なわれている状態なのです。

「えっ?余計じゃないムダなんてあるの?」

と思った方もいらしたかも知れませんね。

そうなんです。
ムダやムラが全て余計だと言うことではないんですよ。



さて、組織はなるべく費用を抑えて、なるべく大きな成果をあげたいと思っているのが普通です。
企業に限らず、慈善団体や野球チームのようなスポーツ団体もそうですね。

  ※ 例外的には、一部の特殊法人や財団法人のように、
    活動成果を真剣に追求しなくても存続できる組織
    もいますがあくまで例外として、想定から外します。(`´)

組織の業務プロセスを改良して、なるべく少ない費用でなるべく大きな活動成果をあげられるようにするための技法がPVEつまりプロセスバリュー・エンジニアリングなのです。





(続きはまた今度・・・(^^)/ )






                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

プロフィール

sugimotom

Author:sugimotom
ようこそ!
職業は業務改革パートナー。余暇は篠笛や和太鼓の響きを楽しんで過ごしています。
そんな私の仕事のこと、趣味のこと、日々感じたことなど 徒然に書き留めています。

私も気が付けば半世紀もの月日を重ねてしまっていました。
飛び去るように過ぎて行く貴重な人生の合間に、ほんの少しだけ立ち止まって、さぁ深呼吸!

大切な今を思いっきり感じましょう。
    → → → プロフィール

最新記事
FC2カウンター
月別アーカイブ
最新コメント
最新トラックバック
..
ブログパーツ アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。