時間は誰にでも平等なもの ～速く質の高い仕事が差を生み出す
周りをみると、膨大な仕事をこなし、大きな成果を出してしまう人がいます。
ですが、そんな人たちに人よりもたくさんの時間があるわけではありません。時間は誰にでも等しく１日２４時間、そして３６５日あります。
仕事が「できる人」と「できない人」の時間は同じなのでしょうか。１時間という時間は同じですが、中身は全く違います。
あなたの身近にいる「できる人」を想像してみてください。仕事は多忙なイメージがありますが、どこか余裕を感じます。懐が広く時間に追われていない、といってもいいでしょう。一方で、ずっとポジションが上がらない人は、自分の目の前の仕事に精いっぱいで「忙しい」「時間が足りない」といっています。
毎日毎日、時間に追われて仕事が片付かない人。余裕に見えながらも結果を出している人。何が違うのでしょうか。
【速さがものをいう ～ 仕事量＝速さ×時間】
まず、仕事の速さが差になります。１時間に２０ページの資料を作れるAさん、１０ページしか作れないBさん。１日に７時間資料作成をしたら、７０ページの差になります。１ヶ月、２０営業日では、１４００ページの差が生まれます。これが１年であれば、１６,８００ページもの違いになります。この差は年数とともに開き続けます。仕事は速いに越したことはありません。
速さには、３つの種類があります。
・ 動く速さ
・ 考える速さ
・ 決断する速さ
動く速さとは、実際の手作業であったり、駆けずり回って人に聞きまわる初動の速さだったりがあります。そして、思考自体が速くあること、その結果、決断を速くすることです。考えるのを速くするには、フレームワークを使うフレームワーク思考が最適で、その思考の結果を最短で決断することです。
【仕事の速さは考える時間を生み出すため】
なぜ仕事が速いといいのか、というと。余った時間を「考える」時間に使うことができるからです。仕事が速いからって、余った時間を何にも生かさず飲み会などに費やしてしまったら、「うさぎとカメ」のうさぎさんになってしまいます。早く終わった分、考える時間に使いましょう。
そして、その考える時間こそが大きな差を生む糧となります。
【質を伴うとさらに差が広がる ～ 成果 ＝ 質×速さ×時間】
考えて仕事をすればするほど、仕事の質があがります。質を伴ってこそ意味のある仕事の速さになります。質を、資料の質として考えてみたときに、１日で仕上げてレビューを受けて、ダメ出しをもらってさらに１日を費やす場合。２日で仕上げて、一発でレビューOKとなるケース。どちらも完成までに費やす時間は同じです。これでは意味がありません。 質の高い仕事を速くこなすことでより大きな成果の差を生み出します。普通の人の質を７０％としたときに自分の質は１００％を目指しましょう。
そうすると、さらに３０％大きな成果を生み出すことになります。
【参考】
ビル・ゲイツはたくさん本を読むことで有名です。いまでは第一線を退いていますが、あれほどの企業のトップを勤めていながら本を読む時間を確保していたというのはすごいことだと思います。 むしろ、自分の限られた時間を何に使うかをしっかりと分類し、適切に判断していたのでしょう。しっかりとインプットをする時間を確保すること、こればビル・ゲイツにとってとても重要な投資の時間だったのでしょう。だからこそ、しっかりと読書の時間を撮っていたのだと思います。 ビル・ゲイツだけでなく、ビジネスの世界で有名な人の多くはびっくりするくらい時間の使い方がうまいと思います。 仕事や読書だけでなく、ちゃんとオフの時間をとって有意義な時間を過ごしています。
参考図書
仕事を速くするにもいろいろなスキル・テクニックがあります。我流で追い求めるのではなく、書籍などから学びましょう。参考になった本を紹介します。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
- 作者: 中島聡
- 出版社/メーカー: 文響社
- 発売日: 2016/06/01
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
- 作者: 岡田充弘
- 出版社/メーカー: かんき出版
- 発売日: 2016/05/18
- メディア: ?
- この商品を含むブログ (3件) を見る
- 作者: 松本利明
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
SIMPLE RULES 「仕事が速い人」はここまでシンプルに考える (単行本)
- 作者: ドナルドサル,キャスリーンアイゼンハート,Donald Sull,Kathleen M. Eisenhardt,戸塚隆将
- 出版社/メーカー: 三笠書房
- 発売日: 2017/08/21
- メディア: 単行本
- この商品を含むブログを見る
- 作者: 岡田充弘
- 出版社/メーカー: かんき出版
- 発売日: 2017/08/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- 作者: 寺下薫
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/09/05
- メディア: 単行本
- この商品を含むブログを見る
- 作者: 岩田松雄
- 出版社/メーカー: サンマーク出版
- 発売日: 2012/10/09
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 77回
- この商品を含むブログ (16件) を見る
トラブルリカバリ日記－００４ ～現場に入る前にヒアリングシートを作る
トラブルプロジェクトの現状を把握するために、まずはドキュメントを集めて読み込み、そして何が、なぜ悪いのかと仮説を立てよう、ということをこちらの２つの記事で書きました。
さて、次は何をするかというとヒアリングシートを作ります。
ここまでのステップで、どのようなプロジェクトで、何を作っていて、どこに問題がありそうか、根本原因はどこにありそうか、というアタリがついている状況まで来ています。
ここまででも、一定の準備はできていると言えますが、もう一歩準備をすすめます。
ヒアリングシートを作るのです。
仮説を立てたなら、その次のステップは仮説の検証なので、プロジェクトメンバーにヒアリングをしないといけません。 そのヒアリングを効率的に行うためのヒアリングシートです。
誰に何を聞くのか。体制図を見ながら誰が何の担当であるか、なども考えながらヒアリングシートを作っていきます。
このヒアリングシートを作るときに意識をしておきたいことは、ヒアリング項目をカテゴリごとに整理する、ということです。
例えば、QCDであれば、品質（Q）、コスト（C）、スケジュール（D）というカテゴリです。QCDであれば、ざっくりしすぎているのでPMBOKの知識エリアをフレームワークにしたり、プロジェクト体制のチームをフレームワークにしてもいいです。
ポイントは、何かしらのカテゴリで整理するということです。そして、そのカテゴリレベルでMECEにしておくことです。
カテゴリレベルでMECEにしておけば、ヒアリングのときに新しい話がでてきたときに、それが該当するカテゴリに項目を追加していきます。そうすることで、漏れのない仮説検証を進めることができるのです。
もし、ヒアリングシートをつくる、といってExcelでノベタンで質問項目を書き出すようなイメージを持たれたとしたら、カテゴリ分類するワンステップを入れてみてください。
トラブルリカバリ日記としてこちらに書きしたためています。
過去の記事はこちらからご参照ください。
トラブルリカバリ日記－００３ ～現場に入る前に仮説を作る
最初の一歩の現状把握のために、資料などを集めましょう、とこちらの記事で書きました。
では、資料を読み込んだならば、次に何をすべきでしょう。
仮説を作りましょう。
仮説の観点はいくつかあります。
開発する機能がいくつかあるのであれば、 A機能、B機能、C機能、～～～～といったように機能ごとに品質や設計上の課題があるかないか、と考えます。
考えるといっても、適当に考えればよいのではなく、手元に集まった資料から読み解いていきます。
例えば、障害一覧があります。 トラブっている状態ですと、だいたい障害が多く発生している機能があります。
ただ、気をつけないといけないのは、障害数が多いからといって品質が悪いとは限りません。障害が修正されているならば、その時点では品質が確保されている可能性があります。
また、テストケースが少なければ発生障害数は少なくなるので、ケース密度も指標として見たほうがいいです。
これらは定量データからの仮説立てになりますが、実際の障害の中身もサンプリングで見るようにしましょう。その実の障害内容にトラブルとなった要因が転がっていたりします。
また、設計書を見てもわかることもあります。設計として書くべきことが書かれているか、メンテナンスされているか、機能ごとに記載レベル、内容は統一されているか、など。
体制図からも仮説だてをします。例えば、プロジェクト体制に会社組織の論理が持ち込まれていないか。プロジェクトへは会社組織の論理を持ち込んではいけませんが、往々にして持ち込まれるケースがあります。そしてそのような場合は、プロジェクトはうまくいかず、設計されたものは組織間で整合が取れていないケースがあります。
マスタースケジュールからは、どこかにスケジュールの歪みはないか、と見てみます。
プロジェクトのもともとのスケジュールはきれいなスケジュールが書かれているはずです。それがどこかから、進捗が遅れ、スケジュールに無理が生じてしまいます。そのタイミングがどこなのか、そこで歪が発生した原因は何なのだろうか、と考えます。
このように、まずは仮説を立ててからプロジェクト現場の中身に入っていくようにしましょう。現場に入ってからは仮説に対して検証をしていく、ということになります。
そして、仮説は外れているものもあります。外れていたならば、それを早く軌道修正して新しい仮説を立てましょう。いつまでも元の仮説に縛られてしまっては、いいトラブルシュートはできません。
トラブルリカバリ日記としてこちらに書きしたためています。
トラブルリカバリ日記－００２ ～最初の一歩は現状把握から
トラブルリカバリに突っ込まれたら、最初にやるべきことは何でしょう。
それは現状把握です。
まったくもって、何も知らない状況から入るのであれば、
- プロジェクトの要件・開発対象がわかる資料
- プロジェクトのマスタースケジュール
- 体制
- 設計書
等の収集から始めます。プロジェクトの内容がわからなければ何も始まらないので、スタートするにあたり必要な情報です。
そして次は、
- 課題票
- 障害一覧
- 週次報告書
などの資料を集めます。これはプロジェクトの要件・設計が分かっていても現状把握に必要なものです。 何がどうなっていて、どうトラブっているか、かをわかるために必要な情報です。
これらの情報・ドキュメントをできるだけ早く入手し、現場に行く前に読み込んでおきます。
現場に行く前に読み込んでおく、というのがとても重要なポイントです。
ひとたび現場にいってしまうと、メンバーとのコミュニケーションやお客さんとのコミュニケーションに追われることとなり、後手後手に回ってしまいますし、何よりも現状を把握していないとコミュニケーションが成り立ちません。
また、要件・仕様をまったく理解していないとお客様からの信用も得られません。
詳細までは把握・理解していないまでも基本的・概要的には理解し、最低限の専門用語を使いながら会話できるように準備しておきます。
今回の場合は、トラブルリカバリに入ることが決まってから、スケジュール的に実際に現場に入れるまでの日程が５日あったので、まずはドキュメントの送付を依頼し、実際に現場に入るまでの間に資料を読み込んでおきました。
お客様との会話も成り立たせることができたので、あらためて重要だと思いました。
トラブルリカバリ日記としてこちらに書きしたためています。
トラブルリカバリ日記－００１
ちょっとトラブってる案件があるんだけど、人出せないかな、という一言がきっかけでした。
「どういうスキルセットの人が必要ですか？」
と聞いたところ、
「・・・・」
、、、怪しい、、、
「とりあえず、何人でもいいから」
と。怪しい、、、、。
経験上の直感でわかりました。「これはやばい」と。
と、いうことがきっかけでトラブルリカバリに入ることになりました。
トラブルリカバリに入り始めて１週間ちょっとが過ぎてきていて、リカバリをすすめつつあります。
私のこれまでの経験やスキルを駆使してすすめています。
せっかくなので、そのトラブルリカバリーをここにしたためていこうと思いました。
実は、トラブルリカバリーにはセオリーがあります。 ですが、その期間中は忙し過ぎて、なかなか教科書的にまとめられたりしません。
ということで、今回の件を記録していくことで、教科書的にきれいにまとまらないとしても、参考書的になれば、と思います。
今後、リカバリ日記はこちらのカテゴリで書いていきますので、ざっと読みたいときはこちらからどうぞ。
リーダーが前向きでいることがチーム力を高めることになる
後ろ向きな、ネガティブなリーダーのチームはチーム全体もネガティブになり、チーム全体の力が発揮されません。なによりも雰囲気が暗いチームとなってしまいます。
一方で、リーダーが前向きでポジティブなチームは常に明るくチャレンジを続けます。
小さなことと思うかもしれませんが、この差はとても大きな差となります。 チーム人数✕日数という差が生まれ続けます。
難しい、厳しい状況となったときでも、
「絶好のチャレンジのチャンスだね！」
「こんなときこそ楽しんでやろう！」
など、前向きでいることでチームが大きく前に進みます。
逆に
「こんな状況、打開できるわけない」
「こんな仕事やりたくない」
とリーダーがいってはいけません。
自分がそのチームのメンバーになったと想像すればわかるでしょう。
リーダーが前向きでいること、とても重要です。
プロに謙遜はいらない
みなさんは、新しい環境に移ったり、新しい人と会ったりして自己紹介をするときに、自分のことを謙遜して自己紹介をするでしょうか？
私は過去のキャリア、スキル、経験を謙遜することなく説明します。
それには理由があります。
お客さんであっても、社内であっても仕事を始めるにあたり、実績をもとに信頼を持ってもらうためです。
初めてあって、
「まだ経験不足ですが、微力ながら貢献させていただきます。」
「新しい部署に来たので、新人のつもりでがんばります！」
と言われて、信頼を置く人はいるでしょうか？
謙遜は日本文化の特徴のひとつで、それを否定しているわけではありませんが、
ビジネスパーソンという視点に立てば、
プロフェッショナルとして謙遜してはいけないと思っています。
ある意味、極論です。場合によってはもちろん控えめにした方がいいときもあります。TPOです。
ただ、伝えたいことは、
自分の仕事に誇りと自信を持ってもらいたい、ということです。
特に若いうちは、できることも限られているので、自信といわれても・・・、となるかもしれませんが、
自分ができる範囲で精いっぱいやってきたことについては、誇りと自信を持つべきです。
言ってはいけない！ ｢即断即決｣をできない人の口グセ
仕事には、個人でする仕事とチームでする仕事があります。自分の仕事をどれだけスピードアップしても、チームのスピードがあがるとは限りません。
チームのスピードが遅くなる一番の要因は、人と人の間で発生する待ち時間です。チーム内にあるムダな時間であり、私はこれを何も動いていない時間という意味で「アイドルタイム」と呼んでいます。メンバー全員の仕事が速かったとしても、アイドルタイムが多ければチームのスピードは遅くなります
アイドルタイムはリーダーとメンバーの間、各メンバー間の作業と作業の間に発生します。決定事項をリーダーがメンバーに伝達するのが遅い。メンバー間の情報伝達が遅れ、作業に着手できなかった……。こうした時間を限りなくゼロにすればチームのスピードはアップします。
チームの中で「アイドルタイム」が最も発生しやすいのが、「決める」という場面です。仕事は誰かが決定しないと、次に進みません。これはひとりでする仕事も同じですが、チームでする場合はなおさら影響が大きいのです。
10人のチームであれば10人、100人のチームであれば100人が次のステップに進めずに立ち往生してしまいます。決めるのはリーダーだけではありません。メンバーが何人か集まってやる仕事もありますし、リーダーとメンバーの関係でなくても、後輩と一緒に仕事をするときに何かを決める、ということもあります。チームで仕事をするときは、「即断即決」を意識することが欠かせません。
ところが実際には、即断即決が苦手な人は少なくありません。そういう人は、常日頃からチームのために即断即決をする意識が乏しく、知らず知らずそれが「口ぐせ」にあらわれています。
即断即決を阻害する５つの口グセがあります。
情報が十分にそろっていない
即断即決できないパターンで一番多いのが、情報が不十分という理由です。時間をかければかけるほど、何かすばらしい理想のものができあがるのではないかという期待を抱いている人が陥りがちなパターンです。
ビジネスで情報が十分に集まることは永遠にありません。集まった情報から、思考して、未来を予測し、そして決めなければいけません。
責任が重い……
ビジネスには絶対的な正解はありません。十分と思えるほどの情報が集まったとしても、正解はないので、導き出した答えが合っているかどうかはわかりません。いつどんな状況であれ、決めたことには「あれでよかったのかな？」と不安がつきまといます。
決められない人は「この判断が正しいかわからない」「成功するかわからない」と臆してしまいます。答えがないのだから、成功するとしても失敗するとしても、いつか、どこかで決めないといけません。であれば、早く決めましょう。
もうちょっと考えさせて
「決めないから、前に進まない、チームが動かない」ということを理解していないパターンもあります。そういう人はたいてい、「もうちょっと考えさせて」とか「今は決められない」と言います。時間をかければよりよい解が見つかると信じているようです。
「時期尚早と言う人間は、100年経っても時期尚早と言う。前例がないと言う人間は、200年経っても前例がないと言う」
これは私の好きな言葉のひとつです。Jリーグの初代チェアマンである川淵三郎さんがJリーグの創設時に「時期尚早」とか、「前例がない」と反発を受けたときに、発した有名な言葉です。これは私が高校生のときに聞いた言葉ですが、いまだに脳裏に焼き付いていて、仕事をする上で強く意識していることでもあります。
決めなければ何も動きません。早く決めれば早く動き出すのです。プロジェクトのタスク状況を可視化するために、「ホワイトボードでやるか、模造紙でやるか、みんなで集まって決めましょう」という場面も経験しました。 とにかく、何が何でも、即断即決をしましょう。
持ち帰って確認します
ミーティングに出ると、自分の担当ではない分野の話になることがあります。その場では回答できないため「持ち帰って担当メンバーに確認します」という対応になるでしょう。自分がわからないことは、その場で回答せずに持ち帰ること自体は正しいです。間違った回答をしてしまってはダメですからね。
ですが、持ち帰って確認すると、ミーティングの後に「確認」と「報告」という2つの時間が必要となります。このようなときは「持ち帰り」をせず、ミーティング中にメールを送ることで時間短縮をします。
ミーティング中にメンバーにメールを送っておくことで、数十分速く動くことができ、場合によっては、ミーティング中に確認した結果がメールで返ってきます。そうするとミーティング中に報告することができ、持ち帰りはなくなります。
私は極力持ち帰り仕事を少なくしたいので、本当に至急の案件の場合はメールタイトルに一言入れます 「【至急】XXの件 確認お願いします」としておけば、すぐにメールを確認してもらえる確率が上がります。
さらに、CCに、そのメンバーの周りに座っている人を入れておき、「CC各位、このメールを見たら本人に伝えてください」と書いておきます。そうすると、本人がメールに気付いていなくても周りの人が伝えてくれて、すぐに対応をしてもらえます。
私のチームでは、私がいつもこういったオペレーションをしているので、私からのメールは優先的に確認し、すぐに返信してくれます。私が中国・大連に出張に行っていたとき、大連チームとミーティングをしている1時間の間に、日本チームと3往復くらいメールのやりとりをしたこともあります。持ち帰りゼロで、その1時間の間にすべてを片付けました。ミーティングで発生したことはミーティング中に片付けるとぐっとスピードがあがります。
とりあえず、こうしよう
すぐに決めることは大切ですが、その決定が中途半端だと逆効果です。「とりあえず、こうしよう」とか「いったん、そうしましょう」という会話がかわされます。私は、「とりあえず」「いったん」というこの2つの言葉は禁句として、使わないようにしています。この2つの言葉は、仮で仕事をする、暫定的な仕事をするという意味合いがあるからです。
なぜ、仕事を「とりあえず」やってはいけないのか。それは、「暫定的」「一時的」な仕事は、その後でいずれ仕上げの作業が必要になるからです。これは時間のムダです。一度始めたら最後までやる。中断はしない。これが、効率的に仕事を進めるコツです。
また、ひとつの仕事を中断すると、再開するときに「あれっ？ どこまでやったっけ？」といったことを考えるムダな時間も発生します。つまり、時間があいたことによって、効率も悪くなり余計に時間がかかってしまうのです。中断をなくすのは無理だとしても、仕事は一発で仕留めるという心持ちでやるようにしましょう。
私はもしメンバーから「いったん○○します」と言われたら、「＂いったん＂ってどういうこと？ どうして仮でやるの？」と問いただします。
とはいっても、本当に意図的な「仮の対応」が必要な場合ももちろんあります。そういうときはあえて「いったん」であることを強調します。
プレゼンの失敗NGあるある
プレゼンは、それだけで本が書けるくらいのたくさんのネタがありますが、今回はプレゼンの失敗NGあるあるを紹介します。 このNGあるあるは、失敗プレゼンのよくあるパターンなので、これらをしないだけでもプレゼンレベルが格段にあがると思います。
【あるある①】ポインターを使う
ポインターを使う人は結構多いですが、やめた方がいいと思っています。理由は次のとおりです。
- ポインターがブレブレになってしまい聞き手はその動きに意識がいってしまう
- ポインターを示すときにスクリーンを見てしまう
- ポインターがブレブレになることで、緊張しているときはより緊張してしまう
- なんか偉そうに見えてしまう
【あるある②】スクリーンを見ながら話す
スクリーンを見ながら、書いていることを読んでしまうパターンです。そうすると聞き手からは背中しか見えませんし、当の本人も聞き手の反応を見ながら話すことができません。
PCの配置場所を考えたりして、聞き手の方を向いて話せるようにしましょう。
【あるある③】資料をくばる
資料を配ってしまうと聞き手は資料を読んでしまいます。 私が資料をもらったときは、ざっと全ページに最初に目を通してしまい、だいたい分かったら細かく気になるところだけを詳細に読み始めてプレゼンを聞いてないパターンが多いです。
プレゼンは聞かせてなんぼなので、読み物に集中されないように資料は配らないようにしましょう。
大会場のプレゼンとかで、予め配らなければいけないときとかは、「資料はあとで読んでください」などと最初に言っておくようにしましょう。
【あるある④】文字の多いスライドを作ってしまう
これもよくあるパターンです。 プレゼン資料の王道は文字が少ないものです。 これを知ってか知らずか、現実には文字の多いプレゼン資料が多いのが実情だと思います。
文字が多い資料でプレゼンをしてしまうと、「説明」になってしまいがちです。
また、聞き手側は資料を読むことに意識がいってしまい話を聞いていない、とか、そもそも文字が読めなくてストレスを感じる、といった事態に陥ります。
【あるある⑤】最初に言い訳からはいる
自身のなさの保険をかけるために、プレゼンの最初に言い訳から入るパターンがあります。
例えば、
- 緊張してまして・・・・
- 資料が完璧でないですが・・・・
- 未熟ではございますが・・・・
といったセリフです。
最初に言い訳からはいると、聞き手は聞く気がなくなります。せっかく時間取って聞きに来たのに、とか、内容がないのであれば帰ろうかな、とか。
どんなに準備しても不安になります。完璧なプレゼンというのはないので、あえて言い訳を言うことはやめましょう。
スタート時点で負けプレゼンが確定してしまいます。
文字の最初と最後だけあっていれば文章は読めてしまう ～レビューはほどほどに
さて、まずは次の文章を読んでみてください。
こんちには みさなん おんげき ですか？ わしたは げんき です。
この ぶんょしう は いりぎす の ケブンッリジ だがいく の けゅきんう の けっか
にんんげ は もじ を にしんき する とき その さしいょ と さいご の もさじえ あいてっれば
じばんゅん は めくちちゃゃ でも ちんゃと よめる という けゅきんう に もづいとて
わざと もじの じんばゅん を いかれえて あまりす。
どでうす？ ちんゃと よゃちめう でしょ？
ちんゃと よためら はのんう よしろく
これはケンブリッジ大学の研究結果によるもの、と言われているのですが、実は都市伝説らしいです。このブログでは、そこについて追いかけるのが目的でないので興味あるかたはググったりして調べてみてください。出処は別のところにあるらしいです。
ポイントは、単語や文章の区切りで最初と最後の文字があっていれば、文章が読めてしまう、というところ。 つまり、ビジネスドキュメントで少々間違っていても読めてしまう、ということです。
仕事で資料を作るときには、細かくレビューをして一字一句チェックする場合もあります。果たしてそこまでのレビューは必要でしょうか？
Yesでもあり、Noでもあります。
ケース・バイ・ケースでしょう。
ちょっと間違っていてもいいような資料であれば、過剰なレビューはする必要ありません。
自分で力の入れ具合、抜き具合を考えて資料作成をしてみましょう。
ちなみに、私はブログでは細かくチェックしていません。ブログをめっちゃ書いてる人で、細かく自分でチェックする人もいるようですが、私におけるブログはスキマ時間でかける内容のものを書く、としているので見直す時間はあまり取っていません。
さて、このような文章を自動作成するツールみたいなものがありました。
neue.cc
上のブログの最後の文章を投げ込んでみました。どうでしょう？
ちみなに、 わしたは ブグでロは こかまく チッェク しせいてまん。
ブグロを めちっゃ かてるいひと で、 こかまく じんぶで チすッェクる ひとも いでうすよるが、
わしたに おける ブグロは スマじキかん で かける なよいう ののもを かく、
とていしる ので みおなす じんかは あまり とまてっいせん。
読みにくいですね。あまり区切りが長いとだめなようです。 単語単語で切るのがせいぜいなのでしょうか。おそらく頭の中にあるイメージとひも付きやすい単位でいいのでしょう。
