昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと

「昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと」という文言をどこからか拾って、なるほど、その通りだと思った。

【1】昭和の管理者は、部下が提案書を作成して、申請した書類に判子を押印して承認する。
判子押印にはいくつかの儀式があった。
上司にお辞儀をするようにわざと左30度傾けるとか。
今ではあまりにも考えられないが。

【2】一方、令和の管理者は、部下がチャットで意見を提案した時に、いいねボタンを押して、承認したことを認める。
以前の平成の管理者は、部下の申請メールに対し、わざわざ文章を書いて、承認したことを返信する手間がかかっていた。
だから、いいねボタンを押すだけなら、わずか0.1秒で承認処理が済ませられる。

なぜなら、令和の管理者は意思決定の回数が多すぎるのだ。
たぶん、普通の企業の管理職や役員は、毎日100通以上のメールを処理しているのではないだろうか。
そのメールを処理することは、意思決定しているのと同じ。
メールのやりとりだけで数時間、半日を使ってしまうのではないか。

令和の時代は、TeamsやSlackなどのチャットで部下とやり取りするから、承認するなら、いいねボタンでいい。
いちいち文章を書いて返信する必要もない。

【3】LIFE SHIFT(ライフ・シフト)の一節に、1990年の仕事のやり方と2015年の仕事のやり方の違いが書かれている。

1990年の仕事は、全てが紙ベースだった。
顧客とのやり取りは、近ければ電話や会社訪問、遠ければ郵送による手紙のやり取り。
だから、海外出張する時は2週間や1ヶ月ぐらいかけるのが普通だった。
タイプライターを打つ女性に、提案書の書類のイメージを伝え、添削して返す。
この頃は、手紙や申請書を判子で押印する承認処理が多かった。
意思決定する時は慎重に行える時間や余裕があった。

2015年の仕事は、全てがオンラインになる。
顧客とのやり取りは、メールやチャット。
海外出張したとしても、1週間以内で慌ただしい。
毎日、100通以上のメールを読んで、処理して、日々の意思決定を下す。

この四半世紀で、承認処理も意思決定も大きく変わった。
意思決定の手法が変われば、意思決定の中身も変わってくると思っている。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか？

チケット駆動開発のプロセスとチケット管理システムの全体像 from akipii Oga

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か？
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット＋プロセス＋アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん（Redmine警察）は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ（Redmineの活動タブ）を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel！ Redmineでアジャイル開発を楽々管理：エンジニアがお薦めする 現場で使えるツール10選（3）（1/5 ページ） - ＠IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ！ Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

リーダーシップの要は抽象的思考とトレードオフだ

「リーダーシップの要は抽象的思考とトレードオフ」という言葉をメモしていた。
この言葉は何を意味しているのか？

【1】プロマネの仕事は、プロジェクトを完遂するために必要な意思決定を行うことだ。
プロマネがリーダーシップを使ってプロジェクトを回す時に必要な要素は、抽象的思考とトレードオフの2つであると言っていると思う。

その意思決定の要素が2つあると考える。

抽象的思考とはモデリング能力を指す。
たとえば、PJ内の作業の業務フローを描いて、どこを効率化すればいいのか、どこに問題があるのかを探る。
たとえば、問題が発生した時、その問題の解決策をロジックツリーで分解して、その効果のインパクトや実現可能性を比較する。
たとえば、問題が根深く、悪循環のシステムから問題が発生しているなら、因果ループ図で悪循環ループを描いて、その構造を壊す仕組みを考える。

つまり、目の前の問題を見える化するために、モデルを描く。
モデルを描くことで、問題の解決策を見出して、意思決定の根拠を持つことで自身を持って意思決定できる。

トレードオフは、複数の意思決定の代替案を評価する能力を指す。
あちらを立てればこちらが立たず、みたいなものだ。
品質を保つためには、リソースをもっと投入する必要があり、それはコストを増やす。
最悪の品質を現状許されるレベルに上げるには、スケジュールを延ばすしかない。
そういうQCDのトレードオフはプロジェクト運営のあちこちで見られる。

意思決定するときには、そこそこの品質でそこそこのコストに抑えて、納期を守るようなBetterな対策を選ぶ。
科学者とエンジニアの違いは、エンジニアはトレードオフの思考と意思決定ができることだ。
現実的に実現可能なレベルの代替案の中で、より良い意思決定を下す。
一方、科学者ならば、真理の世界に生きているので、妥協する必要はない。
ひたすら、自分の思索を脳内で突き詰めればよい。

つまり、プロマネがプロジェクト運営する時、抽象的思考であるべき姿や問題解決をモデル化して解決を目指す。
その解決案の選択では、QCDのトレードオフを考えて、線形計画問題のような考え方で、最善の案を選んで意思決定を下す。
その意思決定の連続が、最終的にプロジェクトのゴールを目指す。

【2】抽象的思考とトレードオフのことを考える時、僕はほぼ日手帳に手書きでラフな絵を描く。
とにかく手で書き出す。
「外資系コンサルの知的生産術」では「数学の問題を解く時はとにかく手を動かしなさい」「数学は手で解く」「マーケティングではとにかくグラフにしなさい」「統計はとにかくグラフにしなさい」というアドバイスがよく出てくる。
つまり、手を動かすことでアイデアがどんどん閃く。

その後、手書きの絵を元にastahで清書する。
astahで描いたら、その後は色々微修正する。
ロジックを整理して推敲していく感じ。

そういう意味では、抽象的思考にはastahというモデリングツールは必須。
モデリングツールastahがなければ、的確な意思決定はできないだろうと思っている。

【3】個人的には、astahは好き。
astahのメリットは、モデリング作業のうち、ロジックツリー、フロー分析、因果ループ図による構造分析が操作できること。
これだけモデルを描ければ、大抵のアイデアは表現できる。

astah*の因果ループプラグインがいいね: プログラマの思索

snytng/inga: astah* plugin to analyze a usecase diagram as causual loop.

astahの唯一の弱点は、マトリクス型の表記がやりにくいこと。
アクティビティ図で代用できるが、縦軸の軸名を縦列に表示できないので読みにくいのが唯一の欠点と思う。
そこだけ解消できれば嬉しい。

JIT改善による赤字悪化を因果ループ図で描いてみた

“JIT生産”を卒業するための本―トヨタの真似だけでは儲からないを読んだら、JIT改善による赤字悪化の構造が書かれていたので、それを真似て因果ループ図で描いてみた。

JIT改善のポイントは、ボラティリティをできるだけ減らす為、平準化生産を目指すこと。
自動車のような製品は、最終組立メーカーが需要をコントロールできるので、平準化生産しやすい。
しかし、一般の工業製品、食品加工品、季節モノの衣料品などは、平準化生産をやりにくい。
そんな製品にJIT改善を適用すると、こんな赤字悪化の因果ループ図になるのでは、という構造がよく見える。

JIT改善による赤字悪化 from akipii Oga

astahで簡単に因果ループ図を描けるのがとても良い。

astah*の因果ループプラグインがいいね: プログラマの思索

snytng/inga: astah* plugin to analyze a usecase diagram as causual loop.

思考力と注意力のトレードオフを因果ループ図で描いてみた: プログラマの思索

因果ループ図を再考する～問題の症状をシステム構造として捉えて解決策を見つける: プログラマの思索

現代の営業プロセスは分業化されている～THE MODELの感想

「THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」を一気に読んだ。
SaaSをベースとした現代の営業プロセスとはこんなものなのか、ということが分かっただけでなく、営業というものが何なのか、何となくイメージできた気もした。
ラフなメモ。

THE MODEL（MarkeZine BOOKS） ｜ 翔泳社の本

過程を自分のものにすればどんな環境でも再現できる 『THE MODEL』出版記念イベントレポート (1/2)：MarkeZine（マーケジン）

営業効率を最大化する「The Model」（ザ・モデル）の概念と実践 | セールスフォース・ドットコム

MQL（Marketing Qualified Lead）とは

理解した事は３つ。
たぶんこんなストーリーだと思う。

【１】一つ目は、現代の営業は商談前に既に終わっていて、その前のリード獲得とリード育成が鍵である事。

この営業プロセスはSaaSのようなサブスクリプションのビジネスモデルに向いているし、SaaSならリードのアクセス履歴から顧客の活動履歴ら顧客満足度まで全てトレースできるのが強みなので、まさにカスタマーエンゲージメントに注力しやすい。

SFAは商談の管理と言う狭いパッケージ製品であり、CRMはリード獲得とリード選別から商談、アフターフォローまで全ての業務を含むパッケージ製品。

日本企業のパッケージ製品はSFAが多い。
それらは、営業マンの日報管理システムに過ぎない場合が多いと思う。
だから、すぐに飽きられるし、そんなに役立たない。

一方、CRMでは、見込み客をLeadと呼んで、受注済みの顧客と区別する。
さらに、LeadをMQL（Marketing Qualified Lead）とSales Qualification Leadに区別し、MQLを発掘する部署とSQLへ育てる部署を分業化する。
MQLを経て見込度を高め、SQLへと育成していき、最終的には商談時に契約を結んで顧客へ導く。

【２】二つ目は顧客フォロー、別名はカスタマーサクセス、カスタマーエンゲージメントが重要である事。

SaaSの営業プロセスでは、顧客に毎月の契約更新を促す必要がある。
顧客満足度を上げるために、どんなフォローが良いのか、どんなプロモーションやキャンペーンが有効なのか？
それらは、顧客の活動履歴を通じて、顧客の不満を読み取り、顧客が満足してくれるような対策を打てばいい。
大量のアクセス履歴をデータマイニングしたり、機械学習や深層学習エンジンに食わせて、彼らの心理構造を見抜き、対策を打てばいい、みたいな感じになるのだろうか。

【３】三つ目は、現代の営業プロセスは分業されていて、プロセス間の移行判定基準とプロセス実行結果であるKPIを準備して、評価されて決まる事。
もちろん各プロセスには部門や担当者がアサインされて、KPIが彼らの業績指標として文字通り評価される。分業されているから、未経験の新人も、プロセス毎に経験を積んでいき育成もできる利点がある。

KPIは、Leadが契約する顧客に至るまでの各プロセスの通過率。
KPIは、各プロセスのフィルタリングみたいだ。
このKPIが低いプロセスがボトルネックなので、その原因をさらに分析して対策を立てる。

たとえば、リード→商談→受注では、商談化率、受注率を見る。

この本の面白い点は、リード→商談→受注の各プロセスで脱落したLeadを将来の見込み客とみなして、「リサイクル」することだ。
つまり、未商談、失注、未フォローの既存顧客は、リサイクルされて、新たなLeadに生まれ変わるようになる。

【４】「THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」を理解するために、astahでモデルを色々描いてみた。

「THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス」では、業務プロセスやLeadの概念、組織の関係図などが数多く記載されているので、astahで真似しやすい。
理解した内容はまた今度まとめる。

The model 営業プロセスの分業化 from akipii Oga

DB Browser for SQLiteを使う

SQLiteを使う機会があった。
GUIツールとして、DB Browser for SQLiteが使いやすかったのでメモ。

【参考】
DB Browser for SQLiteの使い方

SQLite入門 | DBOnline

SQLite | ビューを作成する

SQLite | 日付と時刻を取得する(date関数, time関数, datetime関数, julianday関数, strftime関数)

CSVをインポートすれば、SQLが使えるのでAccessみたいに扱える。
割と便利。

Accessのクエリの代わりに、Viewを作っておけば、Viewを組み合わせて割と複雑なデータ集計もできる。

僕はやっぱりSQLは好き。
データがあれば、SQLを駆使すれば、いくらでも好きな集計データを作れるのがいい。

法律とは大いなる常識に過ぎない

僕は法務が大の苦手。あの長ったらしくて、因果関係のわかりにくい法律等有の日本語が嫌いだ。
そこで、handys97さんに、法律とは結局何なのですか？と聞いたことがある。
曰く。法律とは大いなる常識なのですよ、と。
僕が理解するには、その時代の特定の場所で、大多数の人が共有している基本的な価値観が法律という善悪の価値基準になるわけだ。
実際、セクハラ、パワハラ、非嫡出子、女性の活躍に関する価値観はこの30年間で大きく変わったから、法律も同様に変わってきている。
つまり、その時代に生きている人の価値観で、法律で規制すべき常識は変わる。

では、法律における基本的な常識とは何か？
基本パターンはいくつかあると思う。
弱者は守る。特に労働者や子供とか。
権利のある者は守る。債権者や株主とか。
目的を妨害するものは排除する。会社の存続とか。

こういう使い道は、人間は元々悪い方向に行きやすいから規制すべきだ、という性悪説に基づいている。
実際、トラブルが起きた時に初めて法律に向き合う時が多いからだ。
「ナニワ金融道」「カバチタレ」を読むと、人が最底辺のワルに陥るとああいう人生を取るしかないのか、と思ったりもする。

一方、人々の意識や行動にインセンティブを持たせて、ある方向へ誘導するやり方もある。
法律で最も面白い手法と思う。
たとえば、独占禁止法の課徴金納付命令では、公正取引委員会が調査する前に事前に申告したら、課徴金を免除するみたいなルールがある。
つまり、早めに自首したらお咎めなしにするよ、と。
アメリカの司法取引もそういう目的なのかもしれない。

知的財産の法律もインセンティブを付与するやり方だと思う。
あなたの技術を特許庁に提出したら、公開はするけど、知的独占権を一定期間与えますよ、と。
ライセンス収入もOKですよ、と。

この種のインセンティブのやり方を法律で規制する場面はもっと広げられないのだろうか。

「林業におけるRedmine活用」は林業におけるDXの良い事例だ

第21回勉強会 - redmine.tokyoで、「林業におけるRedmine活用」の講演は林業におけるDXの良い事例として、はてぶでバズっていたらしい。
ラフなメモ。

【参考】
第21回勉強会 - redmine.tokyo

第21回東京Redmine勉強会の感想 #redmineT ～Redmineは業務も組織も包み込む柔軟性がある: プログラマの思索

林業のタスク管理をRedmineでやる話｜株式会社百森｜note

[B! Redmine] 林業のタスク管理をRedmineでやる話｜株式会社百森｜note

深津 貴之 / THE GUILD / noteさんはTwitterを使っています 「DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/PTBB6RFfnM」 / Twitter

【他ツイート】
akipiiさんはTwitterを使っています 「この発想はありうる。RT @murasakimitsuru: リン業…林業にもredmine導入で農業・酪農にもredmine導入ありそう。（モバイルredmine化を妄想）」 / Twitter

yuutaさんはTwitterを使っています 「林業におけるRedmine活用 https://t.co/x6duLhY4ty」 / Twitter

akipiiさんはTwitterを使っています 「興味深い講演でした。まさにDX。配信内容は見れますよ。RT @fladdict: DXです。これが本当の意味のDXです。すごい。Redmineとイシュー管理で、森を整備する話。 https://t.co/tm7QNJwDhH」 / Twitter

金森悠介｜才流さんはTwitterを使っています 「業務の見える化と、文字情報に落とす意義がよくわかる事例 林業におけるRedmine活用 https://t.co/TI33f0hhI4」 / Twitter

れぐなむさんはTwitterを使っています 「現場の地図が付いてるだけでわかりやすさ段違いって印象受けるな。これ手作業なら絶対貼らないけどITなら一瞬だもんな。こういう地味な改善ってドローン飛ばしてあれこれするより効果でかそう / “林業のタスク管理をRedmineでやる話｜株式会社百森｜note” https://t.co/IQpDaQF6fO」 / Twitter

宇埜隆士さんはTwitterを使っています 「DXへの第一歩。チケット文化を根付かせることができたのは凄い（小並感）。 / 他74件のコメント https://t.co/zxrf1ZiT4n “林業におけるRedmine活用” (545 users) https://t.co/QHobwimNdt」 / Twitter

株式会社グローバルネットコア【サーバー・クラウド・Webシステム&ホームページ制作・セキュリティ】さんはTwitterを使っています 「wikiやredmineを林業で活用・・・これは素敵ですね！！当社のようなIT系企業でよく使っているようなデジタルツールを、第一次産業の現場で導入している成功事例です。これぞまさにDX！！ #DX #DX推進 #デジタル化 https://t.co/3ZkqysJTFe」 / Twitter

中野ヤスオ｜ARIさんはTwitterを使っています 「勇気をもらえます。常識にとらわれず、もっとより良い働き方を追求していきたいです。 / 他70件のコメント https://t.co/xmmZzE8qzc “林業におけるRedmine活用” https://t.co/qkV5jAhww5」 / Twitter

ぽっとさんはTwitterを使っています 「プロジェクト管理システムとしてはかなり好きRedmine。あとはガントチャートの棒がドラッグ操作で動かせたら完璧のぺきなのよ（販売されているプラグインでできることは知っています） https://t.co/nGgFfQE8Uq」 / Twitter

(call me #'knjname)さんはTwitterを使っています 「Redmineの汎用性は異常なので、何かシステム組むぐらいならまずRedmineに落としてみてほしい現場はたくさんある / “林業におけるRedmine活用” https://t.co/ke9qHiRhgT」 / Twitter

きのくにさとしさんはTwitterを使っています 「IT木こりとして、興味深く拝見した。 https://t.co/8PcZGv8ezF ちゃんとみんなを巻き込めているのがすごい。そこに一番苦労しそう。」 / Twitter

Katsue NagakuraさんはTwitterを使っています 「林野庁出身のすごいDX人材が農水省にいらっしゃるのもあって、個人的には勝手に農業林業とDXが熱いです、最近 林業におけるRedmine活用 - Speaker Deck https://t.co/FjZQgdUhnJ」 / Twitter

テキスト×音声で記録するAI電話ピクポン代表の小幡さんはTwitterを使っています 「林業におけるRedmine活用 の第21回勉強会で発表した内容です！ ひとことにITと言っても様々な業態があるように、林業にも様々な業態があります。今回説明させていただいたのも、あくまでも林業という多様な業界の一例である、というこ… https://t.co/Si920QOsQz https://t.co/YcLwuD2FJL」 / Twitter

t_takataさんはTwitterを使っています 「とても良い事例だった。作業をチケットに分割できてチケットテンプレート化できればかなり楽になるのは実感がある。 / 林業におけるRedmine活用 https://t.co/sqxWarxw0z」 / Twitter

【1】林業にRedmineを入れた背景となる問題意識としては、労働者の高齢化が進んでおり、口頭伝承の作業代わりと多いことだろう。
結局、若い人にノウハウが伝わらないし、単純な肉体労働みたいなイメージに思われてしまう。

そこで、Redmineを導入したことにより、チケットで全ての作業を手順化して作業の平準化と臨機応変な担当のアサインを図ったこと、作業チケットから生まれたノウハウや経験談はWiki（Note記事を読むとDocBaseのサービスらしい）にナレッジとして蓄積していくようにした。
すると、作業者の意識も主体的になる効果もあったらしい。
ツールを入れることでプロセスを改善するだけでなく、従業員を含めた組織文化も変化させた点が素晴らしいと思う。

【2】「木こりのジレンマからの脱却」という問題意識はよくある。
作業を手順化して標準化し、IT化しやすいようにしたいが、そんな作業に時間を書けるくらいなら、実際の作業をすることでビジネスでお金を稼ぐべきだ、みたなジレンマがよくある。

こういう苦労は普通はJカーブを描くのだろう。
つまり、作業のチケット化、作業の手順化や標準化をすることで、一時的に生産性は下がるが、その効果が出ると一気に効率が上がる。
こういう木こりのジレンマは、林業に限らず、事務処理でもIT業界のシステム開発でもよくあるだろうと思う。

【3】今回の林業の事例では、Redmineの導入により一連の作業をIT化したのは、思い切った改革なのだろうなと思う。
そもそもITに慣れていない従業員も多かったはずだろうだから、苦労も多かっただろうと推測する。

一方で、どこかの勉強会で、日本の省庁の中で最もデジタル化が進んでいる省庁は、実は農林水産省です、という話を聞いた時がある。
農林水産業は実はITと相性がいいのではないか、という仮説も持てる。
なぜならば、元々IT化されていない作業が多いだけでなく、IT化することで生産性が大きく増える点があるからだ。
今回はRedmine導入による作業の標準化、ナレッジ蓄積という問題解決だった。
他にも、ドローン導入やGPSを使って広大な農地を管理したり、AIを使って農産物の品質判断したり、という事例とか、素人でも色々実現可能なアイデアは割とたくさん出てくる。

つまり、農林水産業はDXと相性が良いのではないか、という仮説を持つこともできるだろう。
この辺りのアイデアも膨らませてみたい。

物語を構成する要素はプロットである

最近のアジャイル開発では、企画フェーズや要件定義フェーズでユーザーストーリーを使った手法が多い。
この風潮に僕はまだ腑に落ちていない。
たぶんその理由は、ストーリーや物語の構造を欧米人の文脈で理解できていないからでは、と思っている。
たまたま、良いツイートのまとめを見つけたのでリンクしておく。

その中で、ストーリーとプロットは相異なることも理解した。
理解したことをラフなメモ。
特に結論なし。

【参考1】
ストーリー第1回目　三幕構成とはなにかな？ - Togetter

ストーリー第2回目　第一幕　状況設定ってなんだ、キャラクター設定どうしたらできんの？ - Togetter

ストーリー第3回目　第一幕　“欲しいもの”は二段階で考える？“欲しいもの”と“欲しいもの”の衝突が葛藤を生む。 - Togetter

ストーリー第4回目　セントラル・クエスチョンを意識してみよう - Togetter

ストーリー第5回目　群像劇でも主人公を立てよう　その時に注意しなければならないことは？ - Togetter

ストーリー第6回目　ダイヤモンドの各塁はどのような役割を果たしているのか　ターニングポイントについて - Togetter

ストーリー第７回目　メインプロットとサブプロットの構造を理解しよう - Togetter

ストーリー第８回目　　共感か驚異か - Togetter

ストーリー第９回目　シナリオライティングの参考書は何を読むべきか？ - Togetter

ストーリー第10回目　２幕目をぐいぐい動かすための小技を紹介するよ！ - Togetter

プロットの書き方　前編 - Togetter

プロットの書き方　後編 - Togetter

【参考2】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

「ストーリーマッピングをはじめよう」本の感想～ストーリーによる企画や要件定義はSaaSと相性がいい: プログラマの思索

【1】「SAVE THE CATの法則 本当に売れる脚本術」「アウトラインから書く小説再入門 なぜ、自由に書いたら行き詰まるのか?」「ストラクチャーから書く小説再入門 個性は「型」にはめればより生きる」を読むと、「ストーリー」という言葉はあまり使われず、「プロット」と言う言葉をよく使う。
ストーリーは出来事を単に時系列で並べたもの。
プロットは出来事の原因と結果を抜き出したもの。
プロットは因果関係である。

プロット (物語) - Wikipedia

【2】プロットには、数多くの種類がある。
メインプロットは“事件”である。
メインプロットは主人公が辿るべき話の流れであり、ストーリーラインである。
メインプロットは大抵の場合、主人公の葛藤、それを乗り越えた成長や旅を表す。

【3】サブプロットは、メインの物語とは違うもう一つのテーマを語るパート。
サブプロットは、“心”についてのプロットだと考えればいい。
つまり、サブプロットは主人公の心理描写。
実際は、ラブストーリーがサブプロットによく当てはまる。

メインプロットがA面なら、サブプロットはB面、裏面のストーリーとなり、物語をより複雑に奥深く見せてくれる。
インプロットとサブプロットが互いに影響し合うことで、ストーリーは非常に多くのバリエーションを持つことになり、その展開は観客の予想を超えたものとなるわけだ。

【4】プロットポイントは、三幕構成内の幕と幕を繋ぐイベント。
具体的には、1幕と2幕の切れ目、2幕と3幕の切れ目にあたるイベント。
プロットポイントは、ターニングポイントとも呼ばれる。
つまり、ターニングポイントは主人公に行動を起こさせ、物語の方向を転換させる出来事になる。

第一幕の終わりには、第一ターニングポイントがあり、ここでガラっと舞台が変わる。
第二幕の終わりには、第二ターニングポイントがあり、ミッドポイント（第二幕の真ん中）で結末に向かう方向性を見出した主人公が、さらに結末へと向かうことになる出来事になる。

【5】こういう脚本術の本を読んでいると、映画や小説を欧米人は徹底的に構造化して組み立てているんだな、と思う。
臭いストーリーだなと思いながらも、なぜかハマってしまう。
たぶんその理由は、人間の原始的動機を揺り起こすように上手く構造化して緻密に作られているのに、その原始的動機を上手く隠し通しているのではないか、と思ったりする。

プリコラージュの対となる概念はエンジニアリングになる

【1】図書館で借りた本でふと見つけた言葉。
「レヴィ・ストロースが提唱したプリコラージュの対となる概念は、エンジニアリングなのだ」と言う言葉にものすごくしびれた。
こういう発想があるとは思わなかった。
Redmineによるチケット駆動開発は、たぶんプリコラージュに近い概念と思う。
一方、ソフトウェア工学のようなエンジニアリングはその対極にある。

【2】「勝つための論文の書き方」では、プリコラージュをこんなふうに説明している。
構造人類学を創始したレヴィ・ストロースは、どんなに原始的に見える未開人の行動や思考にも、それなりの論理と構造があるのだという事実を、フロイトの無意識理論やソシュールの言語論を構造把握の手法として借りて、証明した。
こういうやり方、つまり、他の分野から方法を借用して把握する方法をプリコラージュ、すなわち、素人大工仕事と呼んだらしい。

【3】Redmineでチケット駆動開発を実践するというアイデアは、元々は、多機能化した障害管理ツールをソフトウェア開発のプロジェクト管理全般に適用しようというものだ。
つまり、手元にある道具が割と高機能だったから、これを目の前の問題に当てはめてみよう、みたいな感じから始まったと思う。

RedMineでチケット駆動開発！: プログラマの思索

チケット駆動開発の戦略: プログラマの思索

そのアイデアは、タスクの発生から担当者のアサイン、プログラムによる実装、テスト、ビルドしてデプロイまでの一連の作業履歴をチケットに全て集約することで実現される。
つまり、チケットは、ソフトウェア開発で発生する全ての作業のライフサイクルを全て包み込む。

チケット駆動開発の適用範囲part4～ウォーターフォール型開発への部分適用の注意点: プログラマの思索

【4】さらに、BTSには集計機能、分析機能が使えることから、データ集計基盤、さらにはソフトウェア工学のデータ基盤として使えないか、という発想に発展させることができる。
元々、障害管理ツールなのだから、バグの傾向分析や信頼度成長曲線は簡単に出力できるからだ。

ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索

【5】そんなことを考えると、本来はチケット駆動開発は、高機能化した障害管理ツールをプリコラージュした手法に過ぎなかったのに、いつの間にか、ソフトウェア工学を支援できるプロセスに発展できるのではないか、という妄想につながる。

2008年に僕が初めて講演したRedmineでチケット駆動開発を実践する～チケットに分割して統治せよでは、「チケット駆動開発は、中身は古いが新しい衣をかぶったアジャイル開発」と呼んだ内容は、プリコラージュの意味で使っていたのだと今になって気づいた。

2021年の今となってはもう当たり前の概念だし、普通にみんな使っているけれど、こういう考え方で新しく構造化できるのは面白いと思う。