aris world

Time 2021-01-03 12:03:45

Web Name: aris world

WebSite: http://motohasi.hatenablog.com

ID:155232

Keywords:

aris,world,

Description:

比較的新しいMacBook Air/Proで発生する事象を紹介します。MacBook Air 2020 は、ACアダプタに接続したままでも、100%から90%ぐらいまでバッテリを使い、それから充電される事象が発生しました。だいたい一週間に一度程度の割合です。ACアダプタに接続してもバッテリが92%まで減っているACアダプタに接続されていてもバッテリが92%になっていることを アクティビティモニターで確認できます。この件についてアップル社サポートに問い合わせました。サポートの指示に従い、SMCのリセットなどを行っても、この症状は再発します。オンラインのサポートではわからず、サポートからの指示でサービスプロバイダに持っていきました。一週間半ぐらい預けて、いろいろな検査を行っても異常なしで、念のためバッテリ交換しました。サービスプロバイダからMacBook Airをピックアップして、ACアダプタで接続して使い始めた直後に、事象が再発しました。すぐにアップル社スペシャリストに連絡しました。アップル社への問い合わせは4回目です。半日ほど調べていただき、連絡をいただきました。比較的新しいMacBook Air（おそらくMacBook Pro）では、バッテリの健康状態を保ち、バッテリの劣化を防ぐ機能が追加されました。support.apple.com長い間 ACアダプタを繋げていると、いったん充電を切り、90%程度まで消費した後、再充電する機能も含まれているようです。この機能は、Preferences > Energy Saver > Battery Health で指定できます。バッテリ管理の設定OSは、macOS Catalina 10.15.5です。この記事を書いたわけアップル社サポートにSMCリセットなど指示の関係もあり、計4回4人に問い合わせました。サービスプロバイダ修理受付にも持って行きました。私を含め、どなたも知らない機能だったようです。緊急事態宣言の影響もあり、外出しなかったので、この機能が発動していたようです。他の方もハマる可能性があるかと思って、メモを共有しました。これで安心です。 昔のことです。「なぜアジャイルが導入できないのか」が話題になりました。その当時、アジャイルが導入できない理由は＜文化＞であると、友人が調査を引用しTwitterで呟いていました。その＜文化＞とは、失敗を許さない＜文化＞、不確実性を忌避する＜文化＞（完全性を尊重する＜文化＞）、計画を尊重する＜文化＞のようです。そのような＜文化＞があるから、日本ではアジャイルが導入できないと結論づけていました。銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world の記事と関連し、2018年に数枚の図を書きました。そのうちの一枚の絵に対して、簡単に説明をつけて公開します。もはや伝説級の昔話かも、なので、物語的に楽しんでいただけたらと…人々は＜文化＞に縛られ、＜文化＞を作り出している人々は、「文化」によって思考や行動は規定されます。例えば、「恥ずかしい」と思うのも、「楽しい」と思うのも、このような文化を通じて学んできていることなのです。その一方で、「文化」は作られる側面もあります。そこに関わる人たちが文化を作り上げて、恒常的に維持しているのです。文化は存在するだけでなく、人々によって生産され、常に燃料を投下しているのです。では、なぜ、そのような失敗を許さず、完全性を求め、計画を尊重する文化が生まれたのでしょうか。そして、我々は、どのようにすれば良いのでしょうか。私自身は、SIerと言われる仕事をしたことはありません。でも、そのような仕事をしている友達は多く、いろいろなことを聞いていました。友達からよく聞くことは、第三者だからこそ、見えてくる風景があるのかもしれません。もちろん、ないのかもしれません。文化が生み出された理由をゆるく考えてみました。文化に燃料をくべて、燃え続けさせることアジャイルだとか、ウォーターフォールだとか、の話をする前に、ちょっと夏休みの宿題を考えてみましょう。夏休みの宿題を 最終日になっても 終わらせることができず、「ヤバイ」って言っている人いませんか。私、8月31日は、毎年のように「ヤバイ」って思ってました。例えば、最終日に1ヶ月分の日記をつけていました。毎日「晴れ、今日も元気でした。」と、書いてしました。毎日、元気なのは本当でしたが、「晴れ」なわけもないです。でも、毎日のように「晴れ、今日も元気」「晴れ、今日も元気」と書いていました。夏休みになる前に、早めに宿題をやろうと志します。そんな志をいだきながら、夏休みの終わりを迎える、そんな志のある子どもでしたw。もしかしたら、おおらかな時代や地域性だったのかもしれません。それとも親の方針だったのかもしれません。理由はよくわかりませんが、親からは何も言われなかったような気がします。ありがたかったです。でも、もし親が困ったとしたら、何て言うでしょうか。「計算や漢字の練習は、間違えないでね。」（まったく、この子は、ちゃんと見てないとやらないんだから）こんな、感じでしょうか。しっかりと計画を立てさせ、約束し、それ通りにやっているかを確認していく、そんな感じにやっているのではないでしょうか？文化の強化システムプロジェクトの成功率は高いとは言えない らしいそもそも、ITにおけるプロジェクトの成功率は、高いのでしょうか。JUAS、IPA、日経コンピュータなどが調査しています。例えば、検索したところ、日経コンピュータの記事がトップに出てきました。プロジェクト成功率(2018) ： 52.8％https://business.nikkei.com/atcl/opinion/15/100753/030700005/?P=1100円のジュースを10本買ったら、5本は飲めないってことですよね。だんだんとプロジェクト成功率が上がってきたとは言え、約半分は失敗している、ということです。さらに、（総務省 情報通信白書 2018）によると、IT投資しても十分に利益を生み出さない、資産にならないことが明らかになっています。このような業界に対して、信頼できますか？いろいろな理由があるにせよ、不安や不信が高まり、信頼がおけない状況になっていたのではないでしょうか。夏休みの最終日でも、宿題が終わっていないのか状態ですよね？？相互に信頼できないことが＜文化＞を強化しているのかもあるプロダクトが欲しいけれど、こんな失敗だらけで信頼できない相手とは、どのように付き合いますか？例えば、このような付き合い方をしちゃいませんか？一緒に力を合わせたら、共倒れになっちゃいます。しっかりと役割を分けましょう。ユーザ企業とIT企業（ベンダー）です。やるべきことを洗い出しましょう。ヌケモレがあってはいけません。完全なものを作っていても、ズレちゃいます。だから、もっと徹底して完全なリストを作りましょう。しっかりと計画を立てさせましょう。なんせ、相手は失敗だらけですからね。不確実性は、失敗を生みます。変動要因を明らかにして、リスク管理を徹底しましょう。プロジェクトが失敗したときは、投資が無駄になっちゃいますからね。失敗をしたら相手が悪いはずです。契約で決めておいて、しっかり回収しましょう。さまざまな標準や知識体系がありました。そのような知識体系をマジメにこなすことによって、このような＜文化＞を形成していました。さらに相互に信頼できないことによって、このような＜文化＞を生み出し、存続させてしまう側面があったのではないでしょうか。たとえば、こんなストーリーが目に浮かびます。プロジェクトが失敗する理由は、要件定義にあるそうですプロジェクトに対する調査では、様々な失敗要因が調査されています。満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。3回分の調査結果を見ると、プロジェクトが失敗する理由は要件定義の不備に集約できる。要件定義とは導入する情報システムで実現したい事項を整理し、決めることだ。https://business.nikkei.com/atcl/opinion/15/100753/030700005/?P=2「要件定義に不備があった」「追加の開発作業が発生」「仕様変更」など、もう百万回ほど聞いてきました、というのは、嘘だけど、失敗に対する精神的なインパクトを入れると、そのぐらいたくさん聞いてきた。宿題をやらないのが悪いのではなく、宿題を出す側の両方に問題があります。答えが明確でわかりやすい単純な問題であれば、予測を立てて行えます。しかし、あらかじめ宿題として、適切に提示できないことが問題になっています）新しいバズワードの表層的・強迫的な導入は、失敗を生み出すIT側の問題もあったのではないでしょうか。これまで、IT業界は、様々な技術や方法を紹介してきました。これまた長いリストになりそうなので、10秒ぐらいで書けることだけでも…そう、その技術や方法が紹介されたときは、「アジャイルさえ入れれば、世界は平和」とか、「人工知能の時代だ、世界は変わる」とかとか、そんな文言が踊ります。いや、そこまでじゃないか。でも、まぁ、いろいろな言葉が使われてきました。例えば、「アジャイル」が紹介された時も、多くの企業が飛びつきました（アジャイルでも、人工知能でも、なんでも良いです）。それもいいことだな、と、個人的に思います。経験し失敗することは貴重な情報です。これらの方法や技術を追いかけるのも、楽しいです。大好きです。ちなみに、過去で一番ハマったのは、コンピュータやインターネットの規格です。企画じゃありません、規格です。OSやアプリ、データベースからネットワーク、セキュリティからプログラミング言語仕様…、ホワイトペーパーやマニュアル、RFCなど、いろいろな規格を読みまくりました（法律も好きでした）。どのぐらい好きかというと、同僚が入院した際に、分厚いデータベースのマニュアルを持っていったぐらいです。ひどく怒られましたが、その時は何を怒られているか わかりませんでした。マニュアルや規格を読むほど楽しいものはないって思っていました。閑話休題。その上で、いいますが、やっぱり、それらはツールにすぎません。良いツールは人を助けます。けど、その先の世界を見つめる必要があります。本末転倒の状態を引き起こし、価値を提供し享受できない状況を生み出すことすらありました。こんなに面白いツールは、なかなかないんですけどね。どうにかうまくやっていくことを困難にすることもしバズワードのような感じで技術や方法を導入しようとしていたら、自分たちの問題が解決されないのではないでしょうか。どのような問題を解いているのか、どのような結果になるのかを、わからないでバズワードを使っているのです。しかも、いいような夢を見ながら泳いでいるです。雲の上に建築を立てようとしているようにも見えます。それだったら何もしないほうがマシです。百万人ぐらいから反論があると思うから、書いておくけど、この雲の上に建築の話は、私のことです。もしかしたら世の中にはそんな人がいるかもしれません。きっと、その人は、暗闇の中で泳いで頑張っている人です（そっと応援してあげてください）。いろいろなツールに対して、どんな問題を説いているのか十分に理解して使っていない、例えば、ノコギリで釘を打つような状態になってしまっているではないでしょうか。「ちゃんと宿題やりなさい」「早めにやるのよ」と言っても、授業をしっかり理解せず、宿題も理解していない状態に似ていませんか信頼と成熟に向けたストーリー今までだったら「国語の勉強しなさい」とか「この問題集を解きなさい」とか、親が発注者、子どもが受注者の関係のようです。去年の夏は、それをやめました。私自身は、国語がとても苦手です。第3子も、私に似たのか国語が得意とは言えません。そこで、去年の夏休みは、子どもと一緒に国語の勉強をしました。（ゆるい組織）国語についての書籍や資料をたくさん読み、子どもと一緒に問題集を解き、子どもに説明しました。（知の創造と共有）あくまで目安ではありますが、子どもの偏差値も20ぐらい上がりました。子供だけではありません。私の、論理力や抽象能力、表現力も、大幅に高まったようです（少なくとも、この文章よりヒドい状態ではあったのです）。ゆるい組織（ゆるい役割と立場）で、文脈を共有しよう夏休みの宿題は、宿題を出す側と、宿題をやる側の両方が歩み寄ると、楽しいことです。組織を分断し、対立を内包するような関係、いわゆる発注者と受注者の関係性、ではなく、お互いの文脈を共有できる組織（ゆるい組織）を実現しましょう。参考：ゆるい組織は、「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開：IPA 独立行政法人 情報処理推進機構に「組織構造のバウンダリをゆるめる」にも書きました。（透明性とは、それぞれ違う組織の状況を可視化したもの、組織をゆるめるは、組織間の境界を取り払う働きのことです）「知」の創造と「知」の共有ゆるめられた組織において、この文脈を共に観察し、共に学び続けていきましょう。今まで、子どもの勉強においても「あれをしなさい」「これをやってね」のようなスタイルと、子どもと一緒に学ぶスタイルの両方をバランスよく取り入れることです。学んだことを、構造化することによって、共有と修正できるようにするワークが有効です。（宣伝：気づきを構造化することで「知」を産み出し、その「知」を共有するためのパターンライティングのワークショップを開催しています）そのことから、このような文化が生み出されていくのではないでしょうか。あらたに作り出される文化の例苦手科目については、一緒に学ぶ（ゆるい組織と共に学ぶ）学んだことや気がついたことなどを共有する（「知」の創造や「知」の共有）共に作り上げている状態においての失敗は、責任を追求するものではなく、貴重な情報として扱われます。この失敗をどのようにすれば良いのか、共に考えるきっかけとなります（失敗を許さない文化より、共に学習しながら成長する文化）不確実であれば「正解」はわからなくなります。常に観察し、仮説を検証していくようになります。「データはどのようになっていますか？」「これは正しい問いですか？」や「どうやって確かめますか」の話題になるでしょう（不確実性を忌避する文化より、「観察」と「問い」が尊重される文化）。学びや観察も、健全なコミュニケーションが前提になります。相手を見下したり、無駄に攻撃的になったりすると、その創造や学習の文化は、簡単に壊れてしまい、破壊的な文化へと容易に移行します（完全性・計画を重視する文化より、健全なコミュニケーションを重視する文化へ）それに伴い、「失敗」「生産性」「品質」や「学習」などの言葉が、自ずと再定義されていきます。そして、お互いの信頼を回復させながら、共に歩んでいくことが良いのではないでしょうか（と、その当時は思いました）。夏休みは好きだったな。宿題を除けば4枚書いた絵のうち、1枚しか紹介できませんでした（残りの3枚については、何かの機会に議論したいです）。現在のバリエーションは、「知」の創造と共有の＜文化＞、観察と学習の＜文化＞としてみました。それぞれについては、いろいろお話しながらお声がけください。ワークショップも開催します（宣伝）。そもそも、夏休みの宿題は、なんのためにあるのでしょう。学びってなんでしょう。そんなことを考えながら、今日はお開きとさせてください。落ち着いたら、美味しいものでも食べにいきましょう。オンラインでの雑談も大好きです。 このところ、批判についての投稿や、その批判に対する批判についての投稿を目にします。＜Choice Map＞（選択の地図）は、 他の人への反応するときの選択、質問するときの選択の地図です。10年ぐらい事務所のホワイトボードに貼ってある＜選択の地図＞があるので、少しだけ紹介します。ホワイトボードに貼ってある選択の地図学習の文化はたやすく壊れてしまうチームや組織、コミュニティでの活動は、自然に文化が生まれます。文化とは、それぞれの人が行動や思考を決定づける規範のことです。この自然に生まれた文化によって、逆にそこに参加している人々の行動や思考が決められてしまいます。この文化には、さまざまな評価基準や尺度が議論されています。その中でも、学習の文化があります。この学習の文化は、建設的な成長をもたらします。しかし、この学習の文化は、比較的容易に壊れてしまいます。そのため、いろいろなコミュニティや組織で、行動規範やルールとして明示されているのです。例えば、Code of Conduct（行動規範） | Ubuntu Japanese Teamの行動規範など、とてもよくできています。文化を守るのは、あんがい難しいさて、このような文化を壊さないために、どのようにすれば良いのでしょうか。破壊している人に、破壊をやめてもらうのは難しいです。破壊は、好んでやっている場合や、破壊を通じて自分の承認欲求を満たす人もいます。また、破壊的であっても批判によって物事をよくしようと考える人もいます。聞き手の認知の歪みを修正するのは難しいです。自分の健康状態や認知の歪みによって、破壊的に感じることもあります。このような健康状態や認知の歪みを修正する方法は議論されていますが、ここでは扱いません。また「心掛け」や「気持ち」ではなく、具体的な方法が必要です。そこで、私のホワイトボードに貼ってある＜選択の地図＞を簡単に紹介します。裁判官か学習者か二つの選択肢があります、一つは、裁判官 (Judger) の道と、学習者の道です。メモ：裁判官(Judger) は、本来の裁判官を意味しているわけではありません。裁判官のように誰に責任があり、何が正しいかを判定するチームメイトや市井の人のことです。破壊的な作用をもたらす批判を強調するために、ここでは裁判官と書きました。改善を意図して批判しているにもかかわらず、破壊的な作用をもたらす場合を含みます（適切な日本語が見つかれば、その言葉に書き換えます）。裁判官への道裁判官への道は、こんな質問です。「誰のせいなんだ？ (Whose fault is it?)」「私がどうしましたか？何かまずいことでも？？ (What’s wrong with me?)」「どのように私が正しいことを証明できるんだろう (How can I prove that I’m right?)」悲観的、ストレス、制限の雰囲気 (A mood of pessimism, stress, and limitation)「攻撃か防御か」の態度での関係 (Relating with “attack or defensive” behaviors「何が事実なのか。 (What are the fact?)」「私は何をしたいんだろう。 (What do I want?)」「私はどんな仮定をしているんだろう。 (What assumptions am I making?) 」楽観的で、希望と可能性の雰囲気 (A mood of optimism, hope, and possibilities)接続と共創の関係 (Relating that is connected and collaborative)私は、裁判官になっていないか？ (Am I in Judger?)これは、私が感じたいことですか？ (Is this how I want to feel?)私は、どちらになりたいですか？ (Where would I rather be?)実際、他の人の行動を変えることは、難しいです。現実的に破壊的な人と距離を置くことしかできないこともあるでしょう。なので、その場所が、どのような文化に支配されているのかを観察することは、とても大切です。しかし、自分自身が発する具体的な言葉を意識してみることによって、自分が変わり、もしかしたら、自分の周り＜文化＞が少しだけ変わるかもしれません。私の答えは タスクのマネジメントを、文芸的にやっています。 クヌース氏の文芸的プログラミング Literate programming をもじったものなので「文芸的プログラミング」と検索して参照してください。（この文章は、ちょっと疲れていたので、気分転換（現実逃避）に書きました。自分の考えを文章にする行為は、整備体操するように体が温まり、気持ちよく、すっきりします。気がついたら5,500文字程度になり、仮に公開することにしました。）5人が、それぞれが別々のことをやっています。それぞれの相手先があり、そちらの言説で動いています。相手先のフォーマットが統一されておらず、用紙やPDFファイル、画像や動画、電話やテキストメッセージの時もあります。場合によっては、官庁などの場合もあり、こちらからお願いすることは、現実的に不可能です。（多様性）共同作業もあれば、異なる作業もあります。おおよそにおいて、別々のことをやっています。物理的に同じ場所にいる時もあれば、離れている時もあります（リモート）。それぞれのタスクは、同期しておらず、別々の時間や場所で行われ、終わる時間もバラバラです（非同期）。日常的に、毎日のように行うべきことが変化するので、大まかな予定しか立てることはできません。大きな流れだけをつかんでおいて、状況に対応していきます（変動性）。ただし、それぞれのタスク量は、多いものではありません。毎週のタスクが10から20ぐらいで、タスクばらしによって40から60ぐらいでしょうか、タスクは少なめです（少数のタスク）。タスクの粒度は、変化しています。タスクを実行可能な状態にする「タスクばらし」によって、細分化されていきます。自在に論理構造を行き来することになります。場合によっては、カテゴリ自体が変わってしまうこともあります（あいまいさ）。本来であれば、暗黙的に状況や文脈を理解していることが前提にあります。しかしながら、その部分を明示的にすることによって、本末転倒になりにくくします。暗黙的な状況や文脈とタスクを明らかにする行為と、タスクを行う行為を分離できる時と、分離することによって、いくつかの問題が発生する時があります（可視化）。タスク管理ツール（Trello, Redmine, Apple Reminder, Google Tasks,,,）を使いました。しかし、不定形のタスクの管理には、無理があって使い勝手がイマイチでした（非定型）。定型のタスクは、このようなツールをそのまま使っています。いくつかのタスクは、それぞれの状況や文脈に埋め込められています。 タスクだけが存在しているわけではありません。タスクだけが切り離された状態だと、そのときの背景を忘れがちです。問題（問題とフォース）このような文脈を含めた不定形のタスクをすべて見ながら、行動するためには、どのようにすれば良いのでしょうか。ふりかえりや計画づくりなどを行うことは大切です。しかし、タスクを転記することがあり、手間がかかります。転記することが整理することであれば、転記それば良いと思います。大きめの仕事や目標を、状況に埋め込まれられた「今週」「今」のワークをに結びつけるためには、現在の状況や文脈、制約を調べながら具体化していく必要があります。付箋紙やホワイトボードなど物理的なツールで ふりかえりやタスクを洗い出しを行うことは直感的でわかりやすいが、その場所から離れると参照・更新ができません。もし、完全にマッチするようなタスク管理ツールがあったとしても、プラットフォーム(OS)などのアップデートによって使えなくなります。データの移行は、自分たちなりの使い勝手が実現されません。そもそも、タスクを管理することは側面でしかなく、「成果を上げること」のために「なんとかする」「やりくりする」こと（マネジメント）することです。1それゆえ、文芸的にタスクをマネジメントしています。ふりかえりも、計画づくりも、タスクばらし、と実行を分けずにドキュメントに記載していきます。 気軽にアクセスできるツールを選びます（環境）思いついたことは、なんでも書いていきます（入力）適当なタイミングで計画を立てます（計画）タスクをバラシながら実行します（実行・出力）ふりかえります（フィードバック）導入に手間がかかっては本末転倒です。手軽に使えて、多くの人に使われている（≒ 長くメンテナンスされそうな）ツールを選びます。自分たちの環境にふさわしい道具を選びましょう。Google、Apple、Microsoft、フリーソフトでも、どこが作っていても かまいません。データ形式が一般的なツールを選びましょう。マインドマップ、アウトライン機能、自分たちにとって適切な道具を探してみてください。以前は、マインドマップツールを使っていましたが、テキストファイルに比べ、多くの人に使われているわけでもなく、データフォーマットが一般的ではないので、使わなくなってしまいました2。ポイントは、手軽さです。すぐにアクセスできることが何よりも大切です。今回は、メンバーが iPhoneかiPadと iCloudを使っているため、標準機能であるiCloud共有を使います。タスクのリストを入れても、容量は極々小さく、無料の範囲です。ツールは、OS標準のメモ(Notes.app)やリマインダ、カレンダーを使うことにしました。特にノートを使いこなします。iPhoneのロック画面からも新規のメモ(Notes.app)にアクセスできるなど、すぐにアクセスできることは大切です。思いついたことは、なんでも買いていきます GTDあらゆる思いつきをタスクとして登録しています。Getting Things Done (GTD)メソッドは、今でも有効です。GTDの流儀に従い、2分以内のタスクは、思いついたらすぐにやってしまいます。さくっとやっちゃいましょう。将来の夢のようなことも、ガリガリ書いていきます。整理する時に「将来の夢」みたいなメモに移動させます。適当なタイミングで 計画を立てますメンバーによって違います。毎週ごとにメモを新規作成しているメンバーもいれば、月単位のメンバーもいます。私個人のタスクは、月単位のメモで、毎週ごとに章立ています。 # 2020年6月1日の週計画たいていは、ふりかえりのあと、計画を立てます。ふりかえりで出たことを、それ以外にやりたいことを書き出してしまいます。先週のコピペもできるんですけど、たいていは新規で作った方が、やすらぎます。メモを書きながら、適当にタスクとして登録します。いろいろなタスクとして登録していきます。メモ(Notes.app)のショートカットキーは Shift-Command-L を押せばオッケーです3。今週前半は、疲れているはずなので、ちょっと睡眠を多めに取らなくちゃいけないんだけど、ついくだらない文章を書いてしまう。しかし、構成も書いたし、公開するか…我ながら- [ ] 駄文を書く - [ ] 文芸的タスクマネジメントのススメを書いて公開する - [ ] 駄文のリストがある。なんでやりたくなっちゃうんだろう。タスクばらしと実行ですタスクばらしとは、実施可能な粒度までタスクを小さくすることで、だいたい1時間弱から2時間程度のタスクにバラしています4。一日8時間でしたら8つから10ぐらいの分割します。- [ ] 文芸的タスクマネジメントのススメを書いて公開する - [x] 全体の構成を書く - [x] 状況を書く - [x] 多様性 - [x] 少数 - [x] 状況と文脈 - [x] 問題とフォースを書く - [x] タスクマネジメント - [ ] 解決策を書く - [x] 計画について書く - [x] 実行について書く - [ ] ふりかえりについて書く - [ ] 結果を書く - [ ] 参考文献を書く - [ ] 全体を読み直して修正する - [ ] 公開するこの時、文芸的タスクマネジメントは、このタスクの中で、文章を書いてしまうことも可能なのです。テキストで作っているので、そのまま他の環境にコピペすればいいのです。よくあるのは、基本的な構造やアイデアは、タスクのところに書いてしまい、それを参照・コピペして、本来の環境で作業することが多いです。タスクばらしは、前日にやっておきたいところですが、夕方と夜はバタバタすることが多く、なかなかできていません。今のところ、朝の最初のタスクは、タスクばらしとしています。ふりかえりを行います軽く、ふりかえりを行います。フォーマットは自由です。例えば、今週は「やったこと (Y)」「わかったこと(W)」「ためしたいこと(T)」を書いてみました。- やったこと - ワークショップの募集を開始した - 文芸的タスクマネジメントのススメを書いて公開した- わかったこと - 自分がいらない文章だと思っていても、読む人にとっては役に立つかもしれないこと - とりあえず、公開してみること- ためしたいこと - 価値について、カチカチ議論したいこの一連の流れが一つのメモの中で行われています。それ以外にも、必要なことは、このメモの中に入れていきます。文芸的タスクマネジメントの弱点は、文芸的プログラミングと同じように記述量が増えてしまいがちになることです。また、すでにタスク管理とその実行が適切に回っていれば、その方法があっているのだと思います。特に、文脈とは切り離されたことであれば、タスク管理ツール（リマインダを含め）を使うことを奨励します。しかしながら、文芸的タスクマネジメントは、状況や文脈に埋め込められた状態において、とても有効です。もし、特にITや文書を常に使うような仕事であれば、この方法はオススメです。参考になる資料本文の脚注以外に参考にした資料です。（スクリーンショットを掲載しようとすると、ほとんど黒塗りになってしまうので割愛しました）まとめ（オチ？）ああ、文章を書いて、頭と体がすっきりした。で、このような文章を衝動的に書かないために、タスクを管理する必要があるのですね（オチ？）。そもそも「管理」と「マネジメント」は違うというのが本書の大前提にあるスタンスです。日本語にすると混同してしまいがちですが、そもそもマネジメントとは「成果をあげること」が目的で、そのために「なんとかすること」「やりくりすること」の意味です。一方で、管理は手段に過ぎません。 https://kuranuki.sonicgarden.jp/2019/03/management-kanri.html 調べていませんが、編集可能なファイル形式として、テキスト形式は最も使われているんだと思っています。 エディタ iA Writer なら、ショートカットキー Option - Command - L で切り替わります。自分のツールのショートカットキーを覚えておくと、何かと便利です。 https://kuranuki.sonicgarden.jp/2016/07/task-break.html パタンについてのワークショップの依頼があり、準備をしています。知識を共有する従来のパタン（もしくは、パターン）に対して、仮説としてのパタンを「Hypo-pattern」や「仮パタン」と呼ぶことを提案します。この仮パタンは、他の場所では有用ではなく、自分たちでプロダクトやチームを作るときなどに用いる「自分たちだけのパタン」「その場所だけのパタン」で、必然的に自分たちの状況に適合してしています。昔に書いたパタン論文2013年に発表した論文です。https://dl.acm.org/doi/10.5555/2725669.2725708発表した後、会場にいた全員が立ち上がって拍手していただきました。 Ward Cunninghamさんから"Execellent work!"と握手してくださいました。参加者の何名かの方から"This paper is important."のように評価してくださいました。今でも忘れられません。この論文は、私一人の力ではなく、共著者を含め、多くの方々のご協力によるものです。心より感謝します。 また、昔やっていたことに興味を持っていただけるのはうれしいことです。知識共有のためのパタンとパタンランゲージ現在、パタンやパタンランゲージは、知らない分野の言葉を知るために有用な方法であり、ITや社会学などの多くの分野で活用されています。言語を知ることによって、その領域においての会話を助け、そのパタンの世界観による成果物を生み出すことを助けます。このようなパタン1やパタンランゲージは、成功体験を記述し共有します。パタンは、それまでの過去の出来事をまとめていることになります。未来のためのパタン（仮説のパタン）と自分たちのランゲージ一方、この論文では「Pattern for future （未来へのパタン）」を紹介しています。「未来へのパタン Pattern for future」は、状況や問題に対する仮説としての解決策であったり、解決策に対する仮説としての原因であったりします。仮説に過ぎず、検証されていないため、パタンの成立条件も満たしておらず、パタンの形式としても意味としても完成していません。パタンと仮パタンの関係論文の発表後、「未来へのパタン」と、似たような名前が提唱され困っていました。よくよく考えてみると、パタンとしては未熟な状態であり、単純にパタンと呼ぶと混乱を招きます。…（ここで数年が経過します）…仮パタン Hypo-pattern仮説の英語は Hypothesis です。"Hypo-"という接頭語を辞書で引くと、"below, beneath, under"が出てきます。「下」という意味のようです。つまり、「thesis （理論）」には満たない、「理論の下である2」の意味から「仮説 (hypothesis) 」となっているようです。「仮説 Hypothesis」と同様に、この未来へのパタンは、パタンとしては形式と意味のどちらともに十分ではありません。パタン pattern に接頭辞である hypo- をつけた「hypo-pattern」、さらには「仮パタン」「かりぱた」とするのが良いのではないでしょうか。 関連して「未熟なパタン」「みぱた」のように別名がわかりやすいのではないでしょうか。知識共有のためのパタンと、 仮パタン(Hypo-pattern)は違う問題領域検証されたパタン、または、そのパタンランゲージは人類の英知です。貴重な財産です。ある領域における知識を知るために有用な手段です。しかし、自分たちの個別の領域のいては近似的な解決策です。一方、仮説のパタンである仮パタンは「自分たちのプロダクト」「自分たちの場所」のような領域だけで使われます。事例としては発表できますが、他の領域においての有効性は保証できません。そのぶん、自分たちの領域においては、より状況に寄り添った＜質＞の高い仮パタンとなるのです。仮パタンこと hypo-pattern と、いわゆるパタンは、どちらも大切で相補的な関係であり、扱う問題領域が違うのです。ただ、第四次産業革命やDXが叫ばれる領域において、確定したパタンを活用するだけではなく、仮パタンを生み出し続けることこそに価値があるのではないでしょうか。これからの言葉を作るためにこれは、おそらく『デザインパターン』のようなIT業界や社会学などで広く使われているパタンとは少し違う世界です。「パタンを集めて公開し、それを使う」のではなく、パタンを生み出し続けながら使う世界は、残念ながらあまり一般的ではないようですので、少しだけ紹介しました。まだまだ書くべきことは多いのですし、適切な場所に投稿すべきとは思っていますが、共通認識のために仮にメモしておきます。宣伝：ワークショップや仕事しますこのような仮パタンづくりを含めた方法を多くの方に身につけ、活用して欲しいと思っています。書き足りないことも、議論します。そのため、オンラインで開催できるように準備しています。Twitter や Facebookでのアカウントも @motohasi です。 ポストコロナ時代1において、オンライン・コミュニケーションの知識を知り、実践する重要性が増しています。その知識をパターンとして記述し、何度も再利用できるようにします。そのため、1. オンラインコミュニケーションを通じ みんなでパターンを書くことと（オンライン・モブ・パターン・ライティング 2020年4月17日ほか継続的に実施）、2. パターンを使って、オンラインコミュニケーションの整理を行いました（2020年4月30日実施）。このことを通じて、オンラインコミュニケーションパターンと、それを生み出す方法について紹介します。この記事は緊急事態宣言 アドベントカレンダー | Chouseisanです。新型コロナウイルスの流行により、緊急事態宣言が発令され、物理的な対面するようなリアルなコミュニケーションが取れません。リアルなコミュニケーションがないと、知識の伝達する機会が減少してしまいます。オンラインでパターンの書き方を学びながら、自分の持っている知識や経験をパターンとして共有したい。自分の経験や知識を自分で認知し、他の人にも伝わりやすい言葉にすることは大切でありながら、難しいです。自分の経験や知識を言葉にできたとしても、その背景や目的を考えることはマレです。パターンの書き方についての書籍や論文を読んでも、自分の知識をどのように書いてくのか、学ぶことは難しいです。パターンは変化していくために加筆修正していきたいが、一人か二人だけで公開していくのは時間がかかりすぎて、限界があります。それゆえ、みんなでワイワイ、パターンを書いてみよう（オンラインでモブパターンライティング）公共の場所 https://scrapbox.io/OCP/で、ドキュメントを編集できるようにします。みんなでワイワイやりながら、パターンを作っていきます。実践者の経験や知識をパターンとして「なぜ、その行為を行ったのか」「その結果、どうなるのか」を記述できました。パターンを作るときに、どこに留意し、何を目的にするのか、などの具体的なポイントを共有できました。オンライン・モブ・パターン・ライティングを試すことによって、高い質に結びついていくことが期待できました。オンラインでワイワイやることによって、楽しみながら深い学びへと昇華できました。つまり、1. オンラインコミュニケーションによって、オンラインコミュニケーションについてのパターンを書く、ことと、2. オンラインコミュニケーションのパターンを使って、オンラインコミュニケーションを行う2、の二つの目的を同時に満たすことができました。このオンライン・コミュニケーション・パターンは発展途上です。モブパターンライティングの後も、皆さんによってパターンが追加・改善されています。ぜひ、一緒にやりましょう（ご連絡くだされば、編集権限を付与します）。このパターンライティングは、パターンのごく一部しか紹介していません。これからもいくつかのワークショップを開催していきます。 Stay Tuned.OCPで書いてくださった方、オンライン上のコミュニティであるホワイエのパターンの部屋などで議論してくださった方、これまでご指導くださった方ここで紹介したパターンやダイヤグラム、ロゴなどは Online Communication Patterns https://scrapbox.io/OCP/ で作成され、 CC BY-SA 3.0で継承されています。

TAGS:aris world 

<<< Thank you for your visit >>>

Hot Websites