の作業記録
準備を進める月曜日
- 作業記録の共有
- Textbox>inputbox>library+ブクログのフィード処理に噛ませる処理を作る
- Textbox>TaskGround+簡単なページを作る
- メルマガ+ツイート
- メルマガ+ファイルの準備
- メルマガ+原稿1
8:00
おはようございます。今日はメルマガの準備を進めて、Textbox周りの作業もやっておきましょう。
あとで読む:常に老若男女で“ざわついている”書店 ポイントは「探しやすさ」を考慮しない店内設計(1/3)〈AERA〉 | AERA dot. (アエラドット)
読む:かんばんについて:
かんばんはソフトウェア製品を開発するための方法である。さらに、かんばんは、ソフトウェア開発者に過剰な負荷をかけずに、ジャスト・イン・タイムでのソフトウェアリリースを強調したプロセスでもある。このアプローチでは、顧客へのデリバリーに必要なタスクの定義を行い、そのタスクをソフトウェア開発プロジェクトの関係者が理解するために、プロセスを視覚化する。そして、タスクの作業者は、作業をキューから引っ張って（プル）していく。
方法論としての「かんばん」は、デイヴィッド・アンダーソン（David J. Anderson）によってまとめられた。物理学者のカール・デイヴィッド・アンダーソンとは別人。
著作。
AMSEが2003年で、Kanbanが2010年。かなり近年に整理された概念。
かんばんは、作業進捗とともに変わるものであり、プロセスを進化するアプローチであり、組織に合わせてシステム（仕組み）を変化する。かんばんでは、Work-in-progress（WIP：まだ完成していない作業を指し、日本語だと製造業で使われる仕掛品に該当する）を制限したプル型システムを実現する。プル型システムの核となるメカニズムによって、システムの運用やプロセスの問題を明らかにし、システムの継続的な改善に必要な協力作業を促す。このプル型システムの一つの例が、かんばんシステムであり、WIP制限されたプル型システムという一般的な形を経て、かんばんシステムとなった。
基本原則
- 現在、何をしているかを理解することから始める
- インクリメンタルに進化させ、変化を追求していく
- 現状のプロセス、役割、責務、職位を尊重する
- すべての地位でのリーダーシップを求める
6つのコアプラクティス
- 可視化する
- WIPを制限する
- 流れを管理する
- 明確なポリシーを作る 5.フィードバックループを実現する
- コラボレーティブに改善し、実験的に進化する（モデルや科学的な方法を利用する）
まず、「方法論としてのかんばん」と「ツールとしてのかんばん」がある。で、後者は前者を実現するために機能する道具だと言えるだろう。たしかにカンバン型のツールは、方法論としてのかんばんに大部分が適合している。
問題は、「インクリメンタルに進化させ、変化を追求していく」がどこまで達成できているか、だ。ツールが枠組みを与えすぎることで、固定化してしまっているのではないか。
かんばんでは、開発現場に存在する役割やプロセスの発見から始め、継続的かつインクリメンタルにそれらを刺激する。そして、現場のシステムを進化させ、変化を起こしていく。
ようするに上の部分が未達になっており、しんなるカンバンではなく、カンバンっぽいものになっているのではないか。
＊ ＊ ＊
別の話。
タスクの作業者は、作業をキューから引っ張って（プル）していく。
これは作業監督者から作業をアサイン（でいいのかな）されて、それを任務（タスク）として実行していくのとは違う、という意味だろう。
＊ ＊ ＊
タスクを定義し（そう、タスクは定義されるものなのだ）、プロセスを明確にし、あとは各々の作業者が、その全体像を見ながら「今の自分は何をするのか」を決めて実行する。そうすることで、アサイン型とは違ったワークフローが起こり、無理や歪みが見えやすくなり、それがフィードバックのトリガーを引く、ということだろう。
＊ ＊ ＊
カンバン仕事術 | Marcus Hammarberg, Joakim Sundén, 原田 騎郎, 安井 力, 吉羽 龍太郎, 角 征典, 髙木 正弘 |本 | 通販 | Amazon
＊ ＊ ＊
「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
かんばんの目的は、上流プロセスが下流プロセスに必要な場合にだけ部品を生産することでプロセス間のWIP(Work-In-Process(進行中))、すなわち、在庫を最小化することです。「プル」とは、下流の作業員が上流プロセスから必要な部品を引き取ること、または、「引っ張る」ことです。
仕掛かり仕事(WIP)＝在庫を最小化すること。なぜなら在庫は財務的にマイナスだから。
そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます
そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や「キュー」として機能します。「運搬係」と呼ばれる下流プロセスの作業員がストアに来て、新しく完成した部品を拾い上げると、同時に次の製造を指示します。すなわち、下流は上流からものを引っ張ると同時に、かんばんカードを通して上流に情報を押し出します。これが必要なのは、上流プロセスが下流プロセスからの指示がなければ、決して部品を製造しないからです。
「タスクストア」という名前はどうか。
図1で示すように、Withdraw Kanbanはプロセス間を循環します。一方、Production Kanbanはプロセス内で循環し、ストアで交換されます。この仕組みについてもう少し見てみましょう。図2は、「かんばんの交換」がストアにおいてどのような役割を果たすのかを示します。
WIPの観点で言えば、これまで倉下が書いた記事で、本になっていないもの（本になるものをまっているもの）はすべてWIPであり、在庫であり、つまりはまだ利益を生んでいないもの、という在庫であろう。その量はすさまじいことになっている。
下流にいる運搬係は、部品を取り出す合図を受けます。ここで合図が下流プロセスで定義され、以下の2つのうちのいずれかになります。(a) 集められた引き取りかんばんの量によって合図される。(b) 周期的に合図される。運搬係は、購入リストとして集めた引き取りかんばんと空っぽの荷台を持って上流を訪れます。引き取りかんばんは、下流プロセスで必要なものと量を示します。
二つのポイント。「こういうのが必要」というのがまず集められる。でもって、パターン的（ルーチン的なもの）もそこに加わる。それぞれ引き取りかんばんとして定義される。
空っぽの荷台に、その「こういうのが必要」という札を載せて上流のストアに取りに行く。
それと並行して上流では部品を作り、それをストアにおいておく。そこには仕掛りかんばんも置かれている。
運搬係は、引き取りかんばん(購入リスト)で指定された部品を取り出し、部品に付いている仕掛りかんばんと合うかどうか確認して、2つのかんばんを交換します。
ここでかんばんの「交換」が行われている。ちょうど機能考えていた、ボードを移すとタスクの文面が変わる、というのに似ている。
かんばんの6原則」と呼ばれるかんばんを運用するための厳しい規律があります。
- 顧客(下流) プロセスは、かんばんで指定された正確な量の部品を引き取ります。
- 供給者(上流) は、かんばんで指定された正確な量の部品を順番に従い生産します。
- かんばんを持たずに生産されたり、移動されたりする部品はありません。
- かんばんと各部品は毎回同時に動きます。
- 欠陥品や量が違うものは、けっして次の下流プロセスに持ち込まれません。
- 在庫を少なくして問題を明らかにするために、かんばんの数は注意して減らします。
在庫が多すぎると、問題が見えにくい？→TOC理論っぽいな。『ザ・ゴール』。
タスクが多すぎると、問題が見えにくい？→何が価値・利益を生んでいるのか、つながっているのかに無頓着になる。
＊ ＊ ＊
かんばんのプロパティ
- Physical (物理的): かんばんは物理的なカードです。手に持ったり、移動したり、何かに入れたり、壁に貼ったりできます。
- Limits WIP (WIP制限): WIP (進行中)を制限します。言い換えれば、過剰生産を防ぎます。
- Continuous Flow (継続的な流れ): ストアの在庫がなくなる前に、生産が必要なことを通知します。
- Pull (引き出す): 下流プロセスは上流プロセスから部品を引き出します。
- Self-Directing (自己決定): 何をするかという情報を持ち、非集中化された方法でミクロの管理を必要とせずに生産を自律させます。
- Visual (見える化): 視覚的に現在の状況を示すように積み上げられたり、貼られたりします。
- Signal (信号): 状態が目に見えることで、次の引き取りや生産の動きに合図を送ります。
- Kaizen (改善): プロセスフローの見える化により改善の必要性が分かります。
- Attached (取り付ける): 供給される物理的な部品に取り付けられて移動します。
＊ ＊ ＊
ネタ帳とアイデアリスト。
何かを書くという下流の出来事が発生して、「じゃあ、何を書こうか」とネタ帳を探しに行く。これは仕掛かり仕事が最小化される。
逆に、「これについて書きたい」「あれについて書きたい」とやってしまうと、仕掛かり仕事は際限なく増えていく。
その意味で、連載は強力なWIPの制限だと言える。「あれについて書きたい、これについて書きたい」ととりあえず一列に並ばせることができる。
つまり、作業のWIPよりも、「これについて書きたい」「あれについて書きたい」のWIPをどうにかすることが必要なのだろう。それが結果的に、「時間」というリソースをどう分配するのか、という問題につながってくる。というか、その問題を解決するためのヒントを提示してくれる。
＊ ＊ ＊
おそらく必要なのは、そのボードをちらっと眺めて、「じゃあ、何をするのか」を決めるためのヒント（補助線）にできるようなもの。
＊ ＊ ＊
だいぶアイデアを抽出できた。
9:00
メルマガ:
ファイルの準備だけやっておきましょう。
断片:
現状、結城タスクの真似っこで、ターミナルで「mm」とうてばメルマガ用のVS Codeワークスペースが開くようにしているが、一段階噛ませた方がいいかもしれない。つまり、writing-processとかを打つと、プロジェクト名がだだっと表示されるので、そこから選ぶ、という方法。
そうすると、コミットしているプロジェクトの一覧をかならず目にすることになる。
WIP→「コミット中のテーマ」「関心があるテーマ」「area of interest」「area of concern」。
これを制約することが目的として、そうしないと状態が混乱してしまう、という点があるだろう。あるいは関心を持つテーマは広くていいが、ある期間にtocuhするものは限定した方がいいだろう。
よって「関心がある」よりは「コミットしている」がよい。
「Focused topic」はなかなかよい。「Active field of interest」もよい。subjectという単語は使えるか。
ミッション？ダンジョン？クエスト？
PIF（Project in focus）TIF（Theme in focus）
断片:これは何か？
そこに並べたい対象。
- project-th
- project-pt
- bcb
- セルフパブリッシング本の作成
- 確定申告を進める
- うちあわせCastの書き起こし
- ツール開発
こうしたものを並べる場所を作るとして（階層化は必要だろうが）、これらは自分にとって何なのか。プロジェクトと呼ぶべきなのか、それとも何か別の呼称が可能なのか。
ゲーム？ シナリオ？ ストーリー？ トピック？ アイテム？
「タスク」ではない。それはたしか。
ゲーム？試合？マッチ？バウト？プレイ？ミッション？クエスト？エリア？フィールド？スポット？プレイス？シーン？サイト？
トピック？サブジェクト？
あるいはアバウト？ 名詞ではなく前置詞の方が感覚を表すのに適している？
＊ ＊ ＊
「題」だろう。課題や問題、お題といったもの。いわゆるsubjectだがむしろ「題」と読んでしまう。英語なら「dais」とする。
dais-management
まずここからはじめよう。
＊ ＊ ＊
たとえば、これをクリックすると、それぞれのフィールドにおけるより詳細な情報に移動する。あるものはノートだったり、あるものはリストだったり、別のあるものはボード（カンバン）だったりしていい。
ただし、ここに掲載するものの量は制限する。制限されたDIF（dais in focus）
＊ ＊ ＊
この下の部分に「タスクカード」を並べる？ でもって、それがtouchした順で移動する？
15:00
Textbox:
プロトタイプができました。
ページの表示変更以外はすべてまだ手入力ですが、イメージしているのはこんな感じ。
下部のタスクは、jsonから拾って生成し、たぶん上部の表示もjsonから拾うことになるでしょう。
17:00
Textbox:
ブクログのfeedをチェックして、最新の更新を取得するコードに、ISBNからlibrary.jsonに追加するコードを書きましょう。