Agile

2022/06/19

プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある

とある勉強会で、プロセス設計はどの範囲を指すのか、を議論した。
自分の考えをメモ。
ラフなメモ書き。

【参考】
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

プログラマとスクラムが社会実装を変えていく #Findy_GovTech: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

DXとは組織論である: プログラマの思索

ソフトウェア・ファーストの感想: プログラマの思索

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール: プログラマの思索

【1】プロセス設計とは何か?

「SEはプロセス設計する能力が必要」と清水吉男さんは言われていたと思う。
PJ計画時に、担当SEは担当PJでどんなプロセスが必要でどんな成果物が必要なのか、を明確にすべき。
なぜならば、システムの特徴、PJ特性に応じて、プロセスや成果物はどのPJでも微妙に異なるからだ。
それを不明確なまま進めると、じきにプロジェクトの運営がうまくいかなくなる。

イメージとしては、XDDPならばPFDというDFDを描いて、プロセスと成果物のデータフロー図を描くものと思う。

【2】プロセス設計の考え方は標準から各PJへのテーラリングが基本

では、プロセス設計とはどんな構造を持つのか?
きちんとしたSIであれば、社内に標準プロセスがあり、それを担当PJごとにテーラリングしたサブプロセスを定めることになる。
つまり、「プロセス」クラスと「サブプロセス」クラスという型が継承関係にある。

プロジェクト計画が確定すると、「サブプロセス」のインスタンセスが生成される。
PJ実行フェーズで、プロセスのインスタンスをもとに、具体的な成果物(たぶん、設計書などのExcel帳票)が作られていく。

つまり、プロマネは担当PJの特徴、システム特性に応じて、標準プロセスをテーラリングないしカスタマイズする自由度は許されている。
ここにプロセス設計の能力が必要とされる。


【3】プロセス設計の範囲は、PMO事務局とプロマネで異なる

では、プロセス設計の範囲はどこなのか?
(1)プロセス設計とは、プロセスインスタンスから標準プロセスへ抽象化する手法?
(2)プロセス設計とは、標準プロセスをプロセスインスタンスに具体的に実現する手法?
(3)プロセス設計とは、標準プロセスからサブプロセスへテーラリングする手法?

僕の考えでは、プロセス設計の範囲は、PMO事務局とプロマネで異なる。

全社横断的PMO事務局は、社内の案件に対し、標準プロセスを定めたガイドラインを定義し、その推進活動を担当する。
PMOの作業範囲は、「プロセスというクラス」の部分で標準プロセスの型をガイドラインで定義し、各案件のPMには、標準プロセスは守ってもらうことになる。
一方、プロマネには、PJ特性に応じて成果物やプロセスを取捨選択したりカスタマイズしてテーラリングする。

つまり、PMOが担当するプロセス設計の作業範囲は「プロセスというクラス」になる。
なぜならば、標準プロセスを定めたガイドラインの保守改訂はPMOの範疇だから。

一方、案件のプロマネの作業範囲は「サブプロセスというクラス」でPJのテーラリングを行ったプロセスを取捨選択ないしカスタマイズして決めて、PJ計画の活動で具体的なプロセスと成果物(たぶんExcel帳票)を確定すること(プロセスインスタンス)になる。
なぜならば、プロセスをテーラリングして詳細化する作業は、プロマネの担当だから。

【4】テーラリングはどのように評価されるのか

実際の現場では、PMOとプロマネの間で対立はある。

PMOは、ガイドラインがベースラインなので基本はPMに守ってもらうことが最優先であり、実際の案件とのギャップがあれば、それは吸い上げて真因を深掘りする作業を担当する。
テーラリングの自由度は許される範囲内でプロマネにあるから、プロマネの説明の根拠を一つずつ確認して、問いただしていく作業が必要がある。
実際は、そのテーラリングの妥当性で揉めることが多い。

たとえば、プロマネが案件の予算を申請する時、役員を含めた経営陣やPMO事務局が投資計画の内容を精査して、案件の予算確保と実行承認を決定するだろう。
その時に、会社標準のプロセスに即して投資計画を立案しますが、基本はテーラリングが必ず入る。

テーラリングの例としてはこんなものがある。

・標準では許されない工程の重複や統合、省略を許す
・標準化されていない開発方法、技術を適用する
・メトリクスの許容値を調整したり、代替メトリクスを計画する

たとえば、SAPのようなパッケージ製品の導入であれば、すでに開発プロセスがベンダ製品に埋め込まれている。
社内標準とは異なるベンダ製品のプロセスを社内の体制で実行できるか、などをPMが経営陣に説明する必要がある。

あるいは、機械学習の開発基盤を導入する案件であれば、標準化されていない開発手法を適用することになる。
開発リスクを見込んだスケジュールを作っているか、コストを見込んでいるか、をPMが経営陣に説明する必要がある。

あるいは、品質基準を変更してPJ用にテーラリングしたならば、品質基準を変更した妥当性の根拠をPMが経営陣に説明する必要がある。

プロマネが作った投資計画書やPJ計画書をレビューして、細かく精査すると、コストの妥当性、開発リスクの検討、品質基準の設定が甘い時も多い。
そういうレビューを通じて、投資計画の精度を高めるし、プロジェクト実行時の各ゲートレビューでPJの実行状況をPMOがモニタリングしてチェックすることになる。

【5】とは言え、プロセス設計とその評価プロセスの質は、SIであってもユーザ企業であっても、バラつきが多い。

システムの有効性を知りたい経営者、利用ユーザなどの第三者であれば、こういう仕組みがしっかりしていると、安心してシステム開発を任せられる。
たぶん、日本政府のデジタル庁が目指しているあるべき姿も、この辺りの内容に近いのでは、と推測する。
なぜならば、内製部隊を持てない場合、ベンダに委託する必要があるが、こういうプロセスの仕組みをしっかりすることで、ベンダから提供される成果物が標準化できるし、社内でもユーザ要求や仕様をまとめる能力が高まるし、最終的にベンダロックインを防いだり、プロジェクトの進行状況を適宜チェックする仕掛けができるからだ。

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

| | コメント (0)

2022/05/08

小説活動にプルリクエスト駆動が必要になってきた

小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。

【参考】
Pull Request駆動で小説を開発する

GitHub上に構築した小説執筆環境について

akipiiさんはTwitterを使っています: 「コミット履歴を整理するためにプルリクエストを使う発想。面白い。Pull Request駆動で小説を開発する https://t.co/EJ5fHkyr1O」 / Twitter

【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること

【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。

小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。

【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。

本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。

そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。

【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。

トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。

プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。

【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。

akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii まだ、なさそう https://t.co/PO5I82pmft 参照してください」 / Twitter

デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter

過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。

GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。


そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。

そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。

| | コメント (0)

2022/05/06

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/04/21

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール

プロジェクト管理の基本はテーラリングだと思う。
そして、Redmineはプロセスをテーラリングするツールだと思う。
ラフなメモ。

【1】プロジェクト管理の基本的な考え方は何だろうか?

QCDのコントロール、課題管理、スケジュール管理とか、色々あるだろうが、僕は、標準プロセスを各案件、それぞれの現場にテーラリングする能力が問われている、カスタマイズする能力が問われていると思う。
なぜならば、現場にあるプロジェクトはどれもバラバラであり、過去の経験と全く同じプロジェクトはありえない。
そこで、標準プロセスを元に、過去の経験やベストプラクティスのいずれかを、それぞれの現場の案件に適用して、プロジェクトの成功を目指すことになる。

つまり、案件の特徴を見抜いて、標準プロセスから、案件に合ったベストプラクティスを適用して効果を引き出すわけだ。
プロジェクトマネージャは、案件を自分のコントロールの配下におくために、自分の手持ちの武器のうち、有効な武器だけを抽出して、プロジェクトごとにカスタマイズして適用しているわけだ。

すると、2つの疑問が湧いてくる。

【2】1つは、標準プロセスがなければ、そもそもテーラリングができないので、テーラリングという考え方が合っているのか、という点。

PMBOKのようなプロジェクト管理の基本知識では、予実管理が基本だ。
つまり、標準が前提としてあって、実際の実績が標準からどれくらい離れるのか、を測定して制御するイメージ。

しかし、標準プロセスが事前に定まっている環境は、大企業や歴史の長いSIなど、それなりに自分たちの開発の歴史を持って、そこから標準プロセスを作り出した人たちだろう。
そうでない場合は、標準プロセスがあいまいか、そもそも存在しないかもしれない。

そういう状況は、カオスと言えるだろう。
案件を受注するたびに、いつも初めてのプロセスを自分たちで作って運用していかないといけない。
それはあまりにも大変すぎるし、失敗しやすい。

アジャイル開発がそんな場面で利用されやすいだろうが、スクラムのようなきちんと決まっている最低限のフレームワークを用いることで、そういうカオスを制御しようとしている。
スクラムから離れて自分たちのアジャイル開発を見出すのは、スクラムの守破離のうち、守りをきちんとマスターした後でいい。

だから、何らかの標準プロセスが前提にあるのが基本ではないかと思う。

【3】もう一つは、プロマネが標準プロセスからテーラリングできる自由度の範囲はどれくらいあるのか、という点。

PMOの立場では、標準プロセスを策定して、各案件のプロマネに提示して使ってもらう。
しかし、案件ごとに特徴がバラバラだから、標準プロセスをそのまま100%当てはめるて運用は難しい。
だから、プロマネには、基本は守ってもらうけど、ある程度カスタマイズして、プロジェクトをスムーズに運用してください、とある程度のカスタマイズお自由は手渡す。

では、どれくらいの自由度がプロマネにはあるのだろうか?
この自由度は、その会社のプロマネの能力レベルに依存する、という身も蓋もない話。

プロマネの能力が高ければ、標準プロセスを元に、担当案件ではこの部分をカスタマイズして、プロジェクトを運用しやすくします、と宣言して進める。
プロジェクトをコントロールするには、この部分のカスタマイズが必要だと彼らは分かっている。
彼らは、カスタマイズする根拠を説明して、ステークホルダーに納得させるだけの能力を持っている。

一方、プロマネの能力が低い場合、彼らは、プロジェクトの実績の妥当性を標準プロセスに求めたがる。
こういう運用をしているのは標準プロセスに即しているからです、開発を委託したベンダの成果物の品質が悪いのは標準プロセスに従ったからです、などと平気に言う。
つまり、プロマネは、案件の遂行の妥当性を第三者に説明する根拠として、標準プロセスを使おうとする。

すると、PMOは、標準プロセスが現場にフィットしていないからそういう意見が出てくるのだ、と判断して、標準プロセスをどんどん詳細化し、ガチガチに決めていく。
そうすることで、テーラリングの自由度が下がり、プロマネが自由に運用できる裁量が狭くなる悪循環に陥る。
自分で自分の首を絞めている感じ。

そういう現象も多いので、標準プロセスの策定では、プロマネにどんなインセンティブを与えれば、彼らが良い方向にカスタマイズしてくれるか、を考える時が多い。

その気持ちは、まるで法律家みたいだ。
政府が定める法規制によって、市場や社会を良い方向へ誘導しようと計画するが、実際は、生身の人間は小賢しいので、その意図をすぐに行動に反映して自分の利害に合うように変な方向にカスタマイズする、みたいな感じ。
マクロ経済学で言えば、ルーカス批判。
量子力学で言えば、不確定性原理みたいなものか。

【4】他方、Redmineを使うと、標準プロセスとテーラリングのバランスをある程度保証して、プロマネに運用してもらうことができると考える。

Redmineはとても自由度が高いプロジェクト管理ツールだ。
とはいえ、Redmineも汎用ツールなので、Redmineに埋め込まれた機能によって、プロセスの自由度はある程度限られる。
つまり、Redmineで提供する「プロジェクト」ごとに、スクラッチのシステム開発やパッケージ製品導入、サポートデスクなどのドメインで、ワークフローやチケット管理などをテンプレート化しておく。
そのドメインのテンプレートをプロマネに手渡し、そこから先はプロマネに自由に運用してもらう。

つまり、ドメインごとのテンプレートで標準プロセスは固めておき、それから先の運用はプロマネの自由裁量にある程度任せる。
もちろん、チケット起票やチケットの完了条件については、Redmineの機能で制限することは難しいから、運用ルールで縛ることになる。
ただし、各案件ごとに、開発者のスキルが違っていたり、開発やリリースの手順が違う時もあるだろうから、チケット管理にテーラリングを当てはめて、ある程度の自由裁量で運用ルールを変更する余地は残す。

そうすれば、Redmineで標準プロセスを元に、プロマネがテーラリングして、案件ごとに合った運用ルールを策定できて、プロジェクトを成功させる確率を高めることができるはず。

ただし、この運用の前提条件は、プロマネがRedmineの機能やカスタマイズできる範囲を理解し尽くしておくことだ。
つまり、Redmineをプロセスのテーラリングに使うツールとして用いることができる能力を前提としている。

そうでなければ、プロジェクトのテーラリングをRedmine上で実現できないからだ。
個人的には、Excel手順書で運用ルールを逐一テーラリングするよりも、ある程度ツールで標準プロセスを遵守して、ツールの基板上でテーラリングする方が、コントロールしやすいのではないかと考えている。

| | コメント (0)

2022/03/04

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か?進捗率はどう決めるべきか?面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90%のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか?

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか?

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか?
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか?

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。

| | コメント (0)

2022/02/18

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想

文庫本「V字回復の経営」をふと読んで、ようやく、なぜ米国企業はことあるごとに、自分たちの経営手法の源流にトヨタ生産方式をあるのだ、とトヨタ生産方式を礼賛するのか、理由が分かった気がした。
一言で言えば、戦前の日本の敗戦と同じく、米国人に日本の経営の手の内は完全に読み取られただけなのだ。
適当なラフな感想。

【1】「V字回復の経営」を読むと、日本企業が官僚化して、世界の潮流から遅れてしまった原因は、設計→製造→販売というサプライチェーンが社内で分断されて、リードタイムが長くなっているからだ、という点に尽きると思う。
だいたい、日本人は、チームワークよりも、専門家として能力を発揮しようという考え方が強いと思う。

実際、大企業として組織の規模が大きくなると、設計→製造→販売の一まとまりのプロセスを一つの組織に任せるのではなく、設計だけの組織、製造だけの組織、販売打系の組織、という形で専門分化しがちだ。
なぜなら、図体だけ大きくなりすぎるから、機能別に組織を細かく分けて、それぞれの専門性を発揮させようとするからだ。
その方が規模の経済を活かしやすく、人も組織もスケールしやすい。
また、専門性を持たせるような組織の方が、仕事の中身が限定されるので、組織のトップとしても人事制度が組みやすいし、戦略も立てやすい。

しかし、大企業になるほど内部組織が専門分化すると、官僚制組織になってしまう。
日本政府のように、コロコロ変わる政治家を無視して、各省庁が勝手に動いて決めて、その結果、戦略性のないまま、あらぬ方向に暴走しやすくなる。
日本の組織論の失敗事例を分析し尽くした本である「失敗の本質」に、その有様が詳しく多面的に書かれている。

【2】では、米国企業は80年代に日本企業に負けた後、どうやって90年代に復活したのか?
米国人は、日本的経営手法を丸裸にして分析し尽くした後、リエンジニアリング、シックスシグマ、サプライチェーン、アジャイル開発など、手を変え品を変えて、その概念を経営戦略やソフトウェア開発に適用してきたのだ。

V字回復の経営」によれば、米国人によって日本の手の内は完全に読み取られた。
米国人は自分たちで、日本解体新書を作り上げてしまった、と。

ちょうど、戦前の日本が、日清戦争・日露戦争で一躍世界に躍り出たものの、第二次世界大戦では日本の暗号を米国に完全に読み取られて、最後は完全にやられてしまったのと同じように思える。

【3】では、米国企業は日本の手の内をどのように分析し尽くしてきたのか?

V字回復の経営」を読むと、4つの観点があると思う。
それは、プロダクトポートフォリオマネジメント、かんばん方式は時間の戦略であると見抜いたこと、バリューチェーンで経営戦略を類型化したこと、ITを駆使して設計も生産も販売も経営も全てリードタイムを短縮化できると見抜いたこと、の4つだ。

【4】プロダクトポートフォリオマネジメント(PPM)

20世紀後半に日本企業が急激に成長したメカニズムは、PPMの発想と同じ。
つまり、日本企業は米国企業と違って、短期的な利益よりも、長期的な観点で、まずは市場シェアの拡大を狙う。

すると、市場シェアの拡大→売上増加→経験曲線効果により単位あたりのコストは低下→低コストの強みを活かしてシェアを拡大する、という一連の拡張ループが生まれる。
米国人のコンサルがこのアイデアをPPMという世界初の経営戦略理論を生み出したわけだ。

【5】かんばん方式は時間の戦略である

米国企業は、日本企業の強さに生産現場での高品質、効率化にあると分かったが、なかなか真似ることはできなかった。
米国の労働者は能力にばらつきがあるし、QCサークルやワイガヤみたいにチームの一体感を生み出すことも難しい。

しかし、米国人のコンサルは、トヨタ生産方式を分析して、かんばん方式の本質は在庫減らしではなく、時間の価値という新しい戦略要素を追求する手法と見抜いた。
企業は時間の戦略によって、新たな競争優位を生み出せる、と導いた。

一般に、ビジネスとは、設計→製造→販売という一連のプロセスから成立する。
ここにカンバン方式が生み出した時間の戦略を当てはめれば、設計→製造→販売というプロセス全体のリードタイムをいかに短くするか、という問題に置き換えられる。

つまり、企業戦略の要素であるヒト・モノ・カネ・情報の次に、時間が大事だと見抜いたわけだ。
この発想は、ビジエスプロセス・リエンジニアリング、サプライチェーンマネジメントからアジャイル開発に至るまで、その背後にあるように思う。

日本の大企業を見ると、組織の図体が大きくなると、設計→製造→販売というプロセス全体のリードタイムが長くなりがちなので、設計だけ、製造だけ、販売だけ、というプロセス単体の効率化に走る。
すると、各プロセスに特化した設計事業部、生産事業部、販売事業部という機能別組織を新たに作ったり、あるいは、設計だけ、生産だけ、販売だけの子会社をたくさん分社化しがちだ。
実際、日本の家電メーカーや自動車メーカーを見れば、生産と販売が分社化されているのがほとんどだ。
今では、家電メーカーも自動車メーカーも、派遣や委託という形で、製造すら、どんどん外部へアウトソースしている場合がほとんどではないか。

すると、どの組織もタコツボ化されてしまい、自分たちの製品を受け取る顧客からどんどん遠くなるので、顧客のことを考えなくなる。
まったく顧客志向ではない。

一方、米国企業は、時間の戦略が重要と概念化し理論化することで、スピード重視の経営スタイルに変革した。
そのやり方は、たとえば、業務プロセスを改革しリードタイムを短縮させるというリエンジニアリングだったり、原材料の仕入れから設計、製造、販売までのプロセスでリードタイムを短縮するサプライチェーンマネジメントだったり、ソフトウェア開発ならばユーザーストーリーで要件をまとめて設計からプログラミング、テスト、リリースまでを一気通貫に開発してしまうアジャイル開発だったりするわけだ。

つまり、製造業の生産プロセスのリードタイムを短縮するという手法を、一連の供給連鎖、価値連鎖、ソフトウェア開発まで一般化することで、よりスピーディに対応できるようにしたわけだ。

【6】バリューチェーンで経営戦略を類型化

一方、ポーターはバリューチェーンを提唱した。
そこから、経営戦略は、ポーターの基本戦略であるコストリーダーシップ戦略、差別化戦略、集中戦略に類型化される。
ポーターの基本戦略からの結論は、99%の企業は差別化戦略しかありえないことだ。

すると、企業は市場においてポジショニング戦略を取ることで、差別化したポジションを取り、競争優位を生み出そうとするわけだ。

【7】ITを駆使すれば設計も生産も販売も経営も全てリードタイムを短縮化できる

他方、90年代から現代まで急激に進化したものは、ITを駆使すれば、設計→製造→販売という一連のプロセスだけでなく、あらゆる業務のリードタイムを短縮できることだろう。
ブルーカラーの生産現場だけでなく、ホワイトカラーの生産性も同様に、トヨタ生産方式を導入することで同じように効率化できる。

たぶん、アジャイル開発がその典型例だろう。
日本のソフトウェア開発では、今もウォーターフォール型開発が典型的であり、請負契約や準委任契約というビジネス慣習の制約もあるために、なかなかアジャイル開発を実践しにくいのが一般的だろう。
IPAの資料にも、アジャイル開発が偽装請負にならないように気をつけるべき注意点を公開していたと思う。

アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 - Publickey

ソフトウェア開発ビジネスが他の生産や販売のビジネスと異なる点は、ソフトウェアは販売後でも簡単にリリースした機能を変更できること、製造やコピーというプロセスがないので素早くリリースできて大規模に販売できる点だろう。

この特徴を生かしているのがSaaSであり、GAFAが展開しているプラットフォームビジネスだろうと思う。
そして、アジャイル開発のやり方を自動車業界に展開しようとしているのがテスラであり、彼らは、Appleが「電話ができるコンピュータ」であるスマホを生み出して携帯電話もデジカメも駆逐してしまったように、「移動能力を持つコンピュータ」である電気自動車を生み出してガソリン車やハイブリッド車を駆逐しようとしている。
中島聡さんのメルマガを読んでいると、自動車業界はソフトウェア開発をベースとしたビジネスへ置き換えられるように変わっている時代なのだ、と気付かされる。

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索

特に直近30年間では、日本人は世界標準から見てソフトウェアに弱いと思う。
日本ではソフトウェアビジネスやビジネスモデルの基盤にソフトウェアをおくことができていないと思う。
今も日本人はソフトウェア開発とソフトウェア開発に向いた組織づくりに苦闘しているように思える。

【8】そんなことを思うと、日本人がトヨタ生産方式を徹底的に分析できず、米国人にそのアイデアを経営手法やソフトウェア開発手法まで洗練化させて概念化して理論化できたのはなぜなのか、と思ったりする。
なぜ、日本人は融通が効かず、新しいアイデアや環境を取り入れられないのか?
日本人は抽象的な思考能力が低かったからなのか?
正直良くわからない。

| | コメント (0)

2022/02/09

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること、というツイートを見つけたのでメモ。
自分は理解できていないので、疑問点も一緒に自分用のメモ。
以下は自分の直感を適当に書いたので、論理的ではない。

【参考】
akipiiさんはTwitterを使っています 「中島聡さんのメルマガでテスラの凄さをよく解説されてるがピンとこなかったが、このスレッドで意味がすこし分かる気がした」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「テスラ・イーロン真理教の人も、トヨタ・日本車信仰の人もまあみんな落ち着いて。相手を知らず自分の信じたい情報だけ見てても何の進歩もありませんよ。まず日本の自動車メーカーの何がすごいか理解しましょう。テスラの話はその後です。日本メーカーの強さは簡単に言うと、」 / Twitter

テスラが従来の自動車メーカーと異なるところ - Togetter

【0】中島聡さんのメルマガも合わせて考えると、テスラが自動車製造にソフトウェアを持ち込んだメリットは3つあると思う。

週刊 Life is Beautiful 2022年2月8日号:自社製チップと粗利益率 - まぐまぐ!

【1】1つ目は、メーカーにも関わらず、売上高粗利益率が圧倒的に大きいので、どんどん新設備に投資できる財務基盤があること。
普通の自動車メーカーの粗利益率は10%台であり、トヨタですら16%くらい。
一方、アップルは40%、テスラは30%の粗利益率を持つ。
ソフトウェア専業のマイクロソフトは80%の粗利益率らしい。

売上原価には、1台の自動車を作る部品、原材料、人件費、設備の減価償却も含む。
もちろん、外注した部品代金、外注した車載半導体、外注した車載プログラムの開発費用も含まれる。
ソフトウェアの売上原価は、所詮、電気代とサーバーの減価償却と人件費くらいなので、製造業に比べれば圧倒的に低い。

中島聡さんのメルマガによれば、テスラやアップルはハートメーカーでありながら、自社で製品設計して、その製品を圧倒的に安く作るために韓国や台湾の製造専業メーカーに製造委託する。
だから、圧倒的に安く作れるので、売上原価は小さい。
一方、自社では、M1チップ、あるいは、自動運転の学習エンジン専用の半導体まで製造する。

そこで、アップルなら自社のOSやiTuneプラットフォーム、テスラなら自動運転のソフトウェアをオプションで付けて、安いハードに付加価値を付けて高く売りつける。
ユーザは、その利便性を求めるし、顧客満足度を高めることにより、ブランド価値を高めて、ロイヤルティを持たせる。
だから、メーカーでありながら粗利益率が圧倒的に高い。

でも、財務基盤の仕組みが分かっていたとしても、ソフトウェアの技術力が高くなければ、そう簡単に真似できないだろう。
ソフトウェア開発は、優秀な人材に依存するものであって、マネーの資本を注ぎ込んでも規模の経済は働かないから。

【2】2つ目は、工場の生産ラインそのものもソフトウェアでバージョンアップしやすくすることで、生産性が圧倒的に高いことだと思う。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「イーロンは車両設計より工場の設計の方が100倍難しいと話すほどで、伝統OEMの常識から外れ、1-2年で主要設備を入れ替えたり、プラットフォームの大幅改善を行ったりします。発売時には既に数年古い技術の車となるOEMとは異なり、テスラからは常に最新の車が出てきます。参考: https://t.co/wA7liu1n1B」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「彼らのソフトの力がこうした離れ業を可能にしており、伝統OEMは全く理解できていません。VWも隣町にGiga Berlinが現れて初めて自社の生産性が完全にテスラに劣ると気づいたのですhttps://t.co/Rmbra4XoZN テスラは21年、トヨタを抜いて北米で最も生産性の高い工場になりましたhttps://t.co/QPx0tuLxa3」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「何年も同じラインのままの伝統OEMと1-2年毎にラインが進化するテスラ。既に上海工場はフリーモント工場より高い生産性を実現しており、車両の質までも上がってきています。そして来たるベルリン、テキサス工場…競争力のない工場をいくつも抱える伝統OEMと比べいかにテスラが筋肉質かわかります。」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「製造が進化する為、車両の質も日々上がり続けます。Model3の航続距離が突然伸びたり、価格が下がったりするのはこのためです。更に彼らはOTAを通じて購入後も常に車両性能を更新します。購入時既に古く、どんどん古くなる車と、買った時常に最新でその後も最新を維持するテスラ。どちらを選びますか。」 / Twitter

この辺りは僕は詳しくないのでよく分かっていない。
OEM生産といえば、スーパーがよくやるプライベートブランド商品を外部メーカーに委託する生産のイメージ。

テスラの生産ラインは1~2年でどんどん進化するらしいが、トヨタのような自動車メーカーの生産ラインは4~5年おきのように古いままなのだろうか?
今、スマート工場や工場のDXが叫ばれているが、日本の工場は古い製造ラインを数年も放置したまま製造しているのだろうか?
そんなに日本の工場はアナログなのだろうか?

このツイートが正しいならば、フォルクスワーゲンのようなドイツ企業、GMのようなアメリカ企業も同様に、彼らの工場の生産ラインは古くて生産性が低いのだろうか?

【3】3つ目は、EV製造に関わるソフトウェアは、いろんな事業とシナジー効果が大きいこと。
自動運転のソフトウェアの開発の為に、機械学習専用の半導体チップを製造したり、バッテリや充電施設を強化したり、果てはスペースXのような宇宙事業にまで、シナジー効果がある。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「こうした強さを支える根幹がソフトウェアです。ソフトの重要性を理解しているテスラは、工場のデジタル化はもちろん、半導体チップから内製し、自社で自動運転トレーニング用のスパコン(Dojo)まで開発しています。ここまでやってる企業は他にいません。Dojoの計算能力は日本のスパコン京を凌駕します。」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「また、80台ほどしか販売してないホンダレジェンドや試験走行のWaymoやCruiseと異なり、テスラは数百万台の実車両からのリアルデータが収集・学習され、より堅牢な自動運転ソフトウェアの開発に寄与しています。今や取り返しのつかないほどの差になってきています。1点彼らの自動運転思想の特徴として、」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「LiDARを廃しカメラのみで自動運転を実現しようとしている点があります。これについては賛否あり、私個人は難しいのではと感じています。いずれは低機能低価格のLiDARと組み合わせるなど妥協策が出てもおかしくありません。さて次はエネルギーです。手短にいきます(疲労)」 / Twitter

中島聡さんのメルマガでは、人間は2つの目というカメラで運転しているのだから、自動運転技術はカメラだけで十分であって、LiDARにまでコストを掛ける必要もない。
LiDARをつけたソフトウェア開発は余計に複雑になるから、と書かれていて、なるほど、と納得した。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「ソフトの強みは当然自動運転技術にも生きてきます。全部書くと長くなるので一例を紹介します。例えばラベリング。伝統OEMは未だに多額で外注したり、何ヶ月もかけて人の手で行なっていますが、テスラでは同じ規模のラベリングを自動で1週間ほどで実施してしまいます。悲しいほどの差です。」 / Twitter

このツイートもよく分かっていない。
OEM生産のラベリングとは、所詮、プライベートブランド商品に製造ラベルを貼り付けるだけだと思う。
自動車メーカーのラベリングは数ヶ月もかかるような手間がかかるものなのか?
ラベルを大量生産する仕組みを今まで作っていなかったのはなぜなのか?

【4】このツイートを読んで思うことは、ハードに対するソフトウェアのメリットは、プログラムの頻繁なバージョンアップによって機能強化できることにより、ユーザにとっては、古いハードであっても、いつでも新しい機能を使えて利便性が高まることだ。

つまり、ハードは一度リリースしたら変更できない。それは当たり前。
一方、ソフトは一度リリースしても、ファームウェアのアップデートやソフトウェアのバージョンアップによって、手持ちの製品がいつでも最新版の製品に生まれ変わることだ。
それにより、ユーザの生産性もどんどん上がる。

そういうソフトウェアの特徴を生かして、工場の生産ラインにも反映して、生産ラインを制御するソフトウェアをどんどん進化できるような仕組みを作っているのだろうと思う。
だから「工場も一つの受注製品」という主張が成り立つわけだ。

DevOpsやアジャイル開発では、コミュニケーションが大事とよく言われるが、僕はそんな所にイノベーションとか価値があるわけではないと思う。
むしろ、製造とリリース後の保守も含めて、全てをソフトウェアで一貫して制御することにより、1人のプログラマが全ての工程をコントロールできるようになったことが大事だと思う。

従来であれば、各工程の専門家による分業体制でしか製造できなかった製品が、たった1人あるいは数人のソフトウェア開発チームで製造できるようになったこと。
ビジネスモデルは、規模の経済からソフトウェアによる少人数のチーム開発へ変革された。
たぶんそこに、ソフトウェアが従来の製造業と異なる価値をもたらしているのだと思う。


| | コメント (0)

2022/01/23

「ハリウッドリライティングバイブル」のマインドマップ

脚本術の本の一つ「ハリウッドリライティングバイブル」を読んだ。
映画や小説はどんな構造(ストラクチャー)とストーリー(感情を揺さぶる物語)を持つべきなのか、とても理解ができた気がした。
その時のマインドマップを後で自分が読むためにアップしておく。

物語を構成する要素はプロットである: プログラマの思索

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

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

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

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

【1】どうやら、直近5年間に脚本術の有名な本がどんどん翻訳されているらしい。
理由は知らないがニーズはあるのかな?

ゲームシナリオにハリウッド脚本術は使えるのか?おすすめ本の紹介とともに|卍凸凹|note

(引用開始)
ここ数年、ハリウッドの脚本術の本が色々と出版されています。
ハリウッドで定評のある本は、どれも非常に論理的にわかりやすく説明しており、シナリオを書く人にとっては何かしらの発見がある読み物かと思います。
(引用終了)

僕も、下記の本を読み上げた。
2000年代以前の映画をたくさん見た人にとっては、脚本術の本に載っている映画のストーリーやシーンが分かるから、より一層楽しめると思う。
映画は視覚の芸術だからこそ、小説とは違って、より緻密に構造化されていて、そのおかげで量産化できるようになってビジネスになり、大金をもたらす。
小説家や脚本家になりたい人だけでなく、ロールプレイングゲームを作りたい人にとっても、役立つ本だと思う。

SAVE THE CATの法則 本当に売れる脚本術 | ブレイク・スナイダー, 菊池淳子

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術 | シド・フィールド, 安藤 紘平, 加藤 正人

素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2 | シド・フィールド, 安藤紘平, 加藤正人, 小林美也子, 菊池淳子

最高の映画を書くためにあなたが解決しなくてはならないこと シド・フィールドの脚本術3 | シド・フィールド, 安藤紘平, 小林美也子, 加藤正人

ストーリー ロバート・マッキーが教える物語の基本と原則 | ロバート・マッキー, 堺三保, 越前敏弥

【2】脚本術の本に興味を持っている理由は、アジャイル開発におけるストーリーによる要件定義手法を理解したいためだ。

ユーザーストーリー、ユーザーストーリーマッピング、ストーリーマッピングなど、似たような言葉が沢山出てくる。
また、カスタマージャーニーやデザイン思考の背後にも、ストーリーという概念が背後にあるように思える。

たぶん、欧米人が語る「ストーリー」という言葉は日本人が持つ言葉のイメージと違うと直感している。
単に物語という意味ではない。
起承転結という仕組みよりも、アリストテレスによる悲劇の分析で三幕構成が提唱されてからずっと、たぶん彼らは舞台劇や小説を理論化してきていると思う。

実際、「ハリウッドリライティングバイブル」「映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術」「素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2」を読んでみると、映画のワンシーンという一つのプロットに小さなストーリーを埋め込み、全体の構成の配置、構造化に数多くの原則を彼らは見出している。
欧米人は、脚本術のおかげでプレゼン能力がすごく高いのではないか。

実際、単純な因果関係で説明されても人の心には響かない。
でも、感情を揺さぶる物語形式がバックボーンに埋め込まれていると、堅苦しいプレゼンを聞いているはずなのに、感情を揺さぶられて聞き入ってしまう、そういう感じがする。

アジャイル開発でも、システムの要件定義というIT技術の言葉が氾濫して難しい現場において、システムの詳細を知らないユーザが理解できるように、脚本術でストーリーを持ち込んで、一連のストーリーとして理解できるようにしたように思える。

今後の僕のテーマの一つは、欧米人が理論化した脚本術を、astahを使って、概念モデルやプロセスの構造に落とし込んで理解したいことだ。


| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

より以前の記事一覧