プロジェクトマネジメント

2021/05/14

日本人の弱点は忖度しすぎること、理論化できないことではないか

4月末と今夜、平鍋さんがアジャイル開発について語る勉強会を聞いた。
日本人の弱点は忖度しすぎること、理論化できないことではないか、という気づきをラフなメモ書き。

【参考】
今こそ必要な実践知リーダーシップとスクラム - connpass

BPStudy#164?アジャイル開発とスクラムの今を語ろう - connpass

【1】野中先生の肉声を初めて聞いた。
86歳らしいので、平成上皇と同い年らしい。
すごくハキハキした口調で、英語の論文にも慣れているのだろうか、知的バトル、とか、割と英単語が出た。

スクラムを生んだジェフがすごいのは、ベトナム戦争で偵察機の経験があったこと。
その経験をベースに、スクラムを生んだ。
ソフトウェア開発の手法は幾多数多あるが、それを理論化できたのはジェフがフィロソフィーを持っていたから。

野中先生の論文でも、スクラムでも、共感ありきで始まる。
欧米の哲学は、デカルト以来、コギト、我思う故に我あり、から始まるが、そうではなく、共感をベースにした。
だから、上手くいく。

一方、日本人は、元々共感力があるので、スクラムをやるのにもっと共感を重視しようとすると、忖度しすぎてしまう。
忖度するのではなく、もっと知的バトルをすべきだ、と。

僕らの頃は、ジャパン・アズ・ナンバーワンと言われていたが、DXの流れに乗れず、今はその面影もない。
だから、またジャパン・アズ・ナンバーワンを目指してほしい、と。

【2】日本人の弱点は忖度しすぎること、理論化できないことではないか、という考えを思い巡らすと、今まで読んできた本のいろんなフレーズを思い出してくる。

【3】「採用基準」「生産性」はマッキンゼーの元コンサルが、日本人や日本の組織に足りない要素2つを書いている。
それは、日本人には問題解決リーダーシップの能力が足りないこと、問題解決の生産性の意識が低いこと、の2つ。

リーダーシップ経験のない日本人が多すぎるから、評論家ばかりで、実際の問題を泥臭く解決していこうとする能力も意識も低い。
リーダーシップとは、自分の意見を持ち、周囲を巻き込んで、リスクを取って、問題を解決していく。
しかし、リーダーシップを発揮する日本人は、出る杭は叩かれる、ばかりに思われるので、たぶん自然に忖度してしまう。

また、生産性をコストダウンの事ばかり考えすぎる。
日本人が得意なプロセス改善の手法は、コスト低減による付加価値を上げる手法の一つに過ぎない。
生産性=付加価値/コストで考えるならば、コスト低減よりも、付加価値を圧倒的に増やす方がはるかに生産性は上がるはず。
しかし、日本人サラリーマンは斜陽産業でコスト低減ばかり経験しているので、ホワイトカラーが付加価値を上げるために、今までの手法を捨てて、全く新たなアイデアや手法を採用して、リスクを取っていく、という発想も能力もない。

【4】「経済数学の直観的方法 マクロ経済学編」では、世界の経済戦争の重心が、製造業の競争力強化から、世界全体の資金の流れを上手く誘導して流す方向に変わってしまった。
しかし、日本は、製造業があまりにも成功したので、マクロ経済学における動的均衡理論を取り入れる機会を逸してしまった。
そして、世界中の中央銀行がインフレターゲット政策を運用し始めた頃、慌てて、動的均衡理論を学習しようとしたが、従来のケインズ経済学とは異なり、解析力学をベースとした高度な数学理論を使うので、とても学習しづらい。

ちょうど、欧米では、これを学んだ人たちが政治経済の中枢に占めているのに、日本では学習し損なった世代がブランクになり、そのギャップを埋めることが難しい状況らしい。

かつて、日本では、ケインズ理論に従って、政府の公共政策による景気浮揚策は良いことだ、という理解が、割と世間の人たちも認識が共有されていた。
ちょうど、その頃は、日本の製造業が無敵の時代だった。
しかし、コンピュータやITが直近の四半世紀でまたたく間に普及して、ITなしでは生活もビジネスも経済も成り立たなくなった。
経済学の主導権もケインズ理論から動的均衡理論に代わったが、日本は追いつけていない。
さらに、世界中の資金を自国に誘導するように、情報や経済理論を整備して発信していく、というやり方に日本は乗り遅れてしまった。
「ミクロでマクロを制する」という発想は、日本人は弱いらしい。

| | コメント (0)

2021/05/08

『オブジェクト指向でなぜつくるのか』第3版が出版された

『オブジェクト指向でなぜつくるのか』第3版が出版されたのでメモ。

【参考】
『オブジェクト指向でなぜつくるのか』第3版

オブジェクト指向でなぜつくるのか 第3版|日経の本 日経BP

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索では、第2版を改めて読み直してみた。
オブジェクト指向プログラミングがヒープ領域を使っていることから、UMLによる汎用の整理術、XPに至るまでのアジャイル開発、そしてパターン言語まで幅広い。
こういう一大ストーリーでまとめているのはすごいと思う。

僕が思うに、オブジェクト指向の考え方をアジャイル開発、特にスクラムに適用している所が一番興味はある。
たとえば、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」では、「スクラムチームはブラックボックスとして扱うべきだ」という主張が何度も使われている。
つまり、スクラムチームはInputとOutputだけ管理すればよく、プロジェクトマネージャはマイクロマネジメントする必要はないし、マイクロマネジメントすべきでない、という主張が一貫して流れている。
これもオブジェクト指向のカプセル化がわかっていれば、とても腑に落ちる。

More Effective Agileは良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」本はずっと読まれ続けてほしいと思う。

| | コメント (0)

astah*の因果ループプラグインがいいね

astah*の因果ループプラグインを教えてもらったのでメモ。
使ってみるとなかなか良いです。

【参考】
snytng/inga astah*の因果ループプラグイン

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

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

astah*の因果ループプラグインのメリットは、因果ループ図からロジックをリバースしてくれること。
要因Xが増えれば、要因Yが増えるのか、要因Yが減るのか、表示してくれる。
ロジックを見直す時に役立ちそう。

【1】教員希望者が減っているニュースを見て、その背景にあるロジックを書いてみた。

教員の過酷な労働実態相次ぐ投稿でオンライン上の報告会開催 | 教育 | NHKニュース

小学校教員倍率、過去最低2.7倍 質の確保急務: 日本経済新聞

Photo_20210508114201

ニュースでは、下記のロジックが読み取れる。

「教師希望者」が増えれば、「教師の質」が増える: 1 (自己強化=1, バランス=0)
→「教師の質」が増えれば、「モンスターペアレント」が減る: 1 (自己強化=1, バランス=0)
→「モンスターペアレント」が減れば、「教師の作業負荷」が減る: 1 (自己強化=1, バランス=0)
→「教師の作業負荷」が減れば、「教師希望者」が増える: 1 (自己強化=1, バランス=0)

そこで、教師希望者を増やすために、教師増加キャンペーンを実施したわけだが、本当に効果があるのか?
レバレッジポイントはそこなのか?
他の要因を増減させるような施策の方が優先ではないか?

他にも隠れたロジックがないか?
色々考えが思いつく。

astah*の因果ループプラグインの他の機能では、下部欄の因果関係をクリックすると、因果ループ図の線にフォーカスしてくれる。
ただし、Same(+)は実線、Opposite(ー)は破線なので注意。

| | コメント (0)

2021/04/29

デジタル庁で応募中のアイデンティティアーキテクトは昔のDAと同じ役割か?

デジタル庁でアイデンティティアーキテクト、データアーキテクトを応募しているツイートを見つけたのでメモ。
ラフなメモ書き。

【参考】
yoshi sanさんはTwitterを使っています 「アイデンティティアーキテクトなる独立したポジションがあるんだ。」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクトってなんだよと思ったけどめちゃまともな内容だった」 / Twitter

Yoshikazu NojimaさんはTwitterを使っています 「デジタル庁のアイデンティティアーキテクト、超重要かつ超高難易度な仕事にしか見えないのだけど、どんなキャリアパスを積んで、どれほどの研鑽を積めば担えるのか想像もつかない。 https://t.co/2iU02v4WLr」 / Twitter

akipiiさんはTwitterを使っています 「アイデンティティアーキテクトとは、昔のDAと同じ役割か?」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト https://t.co/raIDjeGhb9 めちゃくちゃ楽しそう(発狂しそうなほど大変だと思うけど)」 / Twitter

ミジンコOLさんはTwitterを使っています 「アイデンティティアーキテクト、あの先輩しか思い浮かばない。 ・行政証明書コンビニ交付サービスの開発経験有 ・某メディア企業の大型サービス利用ID統合経験 ・プラポリにも詳しい ・認証・認可詳しい ・IPA上級資格9割持ってる ・泥臭いPJTの中でも爽やか #デ https://t.co/Ue6JVxsyLh」 / Twitter

【参考】
中途採用|デジタル庁創設に向けた準備サイト

『アイデンティティ管理技術解説』システムアーキテクトを志す方のために IPA

【参考1】
アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
デジタル庁(仮称)においては、行政サービスのデジタル化・ワンストップ化を推進するにあたって、利便性が高く安全な識別・認証の仕組みを構築することにより、多種多様なシステムにまたがった円滑なデータ連携を実現していくことが求められます。

アイデンティティアーキテクトは、各省庁の担当者や専門家と連携して、デジタルガバメントのサービス高度化に必要な、アイデンティティ管理、データ連携の枠組みを構想し、その整備を推進する役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

政府情報システムに関わるアイデンティティ管理の計画策定全般

住民制度、公的個人認証、マイナンバー制度に関わる個人のアイデンティティ管理もしくはGビズID、商業登記電子証明書等に関わる法人等のアイデンティティ管理

行政事務と住民・事業者向けシステム、住民・事業者向けシステム間をつなぐ国のシステムを理解した上での、業務プロセスの見直し、移行計画の立案、変革の推進

国民・事業者向けサービスや各省庁のシステムにおける利便性の高い安全な識別・認証の仕組みづくり

各省庁や地方公共団体の専門家と連携した横断的なプロジェクトの推進
(引用終了)

【参考2】
データアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
データアーキテクトは、デジタル庁(仮称)において、社会全体のデータの現状と将来像を俯瞰し、データ戦略の策定を主導するとともに、標準やルールに加え基礎データ、プラットフォームなどを整備し、その活用を推進していくことが求められます。また、多数のステークホルダーとの調整を進めながら、デジタル時代の新たなスタンダードを構築していくための強いリーダーシップが求められます。

政府は、多量のデータを保有するデータホルダーとして、またデータプラットフォーマーとして、先導的な振る舞いを期待される立場です。本ポジションは、あらゆる社会・経済活動に不可欠なデータを、国の競争力の源泉とするために、また、豊かな生活を実現する上で不可欠な基盤とするために、中心的な役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

体系的なデータ整備に係る中長期戦略・計画の策定

データ標準・データ連携プラットフォームの整備

政府内におけるデータサイエンスやAIの活用の推進

デジタル庁(仮称)内外のデータに関する人材育成

データに基づいたEBPM(Evidence-Based Policy Making、証拠に基づく政策立案)の推進

国際機関や関係各国との交渉
(引用終了)

【感想1】
デジタル庁でアイデンティティアーキテクト、データアーキテクトの募集背景・業務内容を読むと、本当にガチの内容だ。
個人的には、一昔前のデータアーキテクトの業務を連想する。

その頃は、テーブルを新規追加したり、カラム1個を追加するのに、わざわざデータアーキテクトに申請して、内容の詳細や対応期限を説明して、開発環境にやっと反映される、みたいな牧歌的な時代だった。
データアーキテクトは、ER図やデータディクショナリの保守担当者みたいなイメージを持っていたので、あまりカッコイイ職種には感じなかった。

しかし、実際の業務システムの要件定義では、データモデリングの技量の違いがその後の設計、開発の室に直結する。
業務フローのようなプロセスばかり書いても、フワフワしていて、テストでデスマーチになりがち。
データ基盤がしっかりしていれば、そこから業務の制約条件をプログラマも読み取れるし、テストデータを作ったり、保守していくのもかなり楽になる。

さらに、データアーキテクトの職種だけでなく、アイデンティティアーキテクトという職種まで応募しているのはとても興味深い。
単に、公共サービスのデータ基盤、データディクショナリを揃えるだけでなく、その根本となる一意な主キーを見出し、それを維持管理していく重要性を認識しているのだろう。
もちろん、マイナンバー制度という国民をユニークに識別する仕組みにも直結する。
国民を一意に識別してデータを管理できる基盤があれば、今のコロナワクチン予防接種の履歴管理に使えるし、今後のワクチンパスポートの発行にも発展できる。
他にも、収入や資産の追跡、税の徴収だけでなく、本当に困っている人たちを特定して補助金を直接届ける、という仕組みも作れるはず。

また、アイデンティファイアの整備は、認証基盤にも直結する。
政府の膨大な公共システムを利用する場合に、利用者の国民が安全に利用できるだけでなく、バックエンドの事務に携わる公務員や保健所の人たちが安全にログインできて、その操作履歴をきちんと管理できる仕組みも必要。
さらには多種多様な利用権限の制御まで考える必要もあるだろう。

つまり、価値ある公共サービスを提供するためにデータ基盤のアイデンティファイアは必須要件だが、人権やプライバシーの保護の観点からアイデンティファイアの認証・認可・アカウンティングの機能要件も必須という、高度なハードルがある。
想像するだけでも、アイデンティティアーキテクトという職種は非常にタフで難儀な内容であるのは間違いない。

だからこそ、こういう職種が必要ときちんと公開して打ち出しているのは信頼が持てる。

【感想2】
最近はITコミュニティ以外にも、官公庁の関係者がオンライン勉強会で登壇して色々話してくれる場が多くなった。

直近で、農林水産省とウーオが語る!林業・水産業をITで変えるチャレンジ - connpassを聞いた時、今の官公庁で最もデジタル化が進んでいるのは、実は農林水産省なんです、という発言を聞いて驚いた時がある。
その時の事例では、ベンチャー企業が、漁港で取った魚と都市部の魚市場のマッチング処理のシステムを開発して、お互いの利益を向上させる、という話だった。
他にも林業で、日本産の木材が、今はコロナなので実は高く売れている、そういう市場をITの力で支援している、という話もあった。

おそらく、楽天、メルカリのビジネスモデルのように、生産者と消費者のマッチング処理を農業や水産業の市場に適用して、両者がWin-Winになるような方向を目指しているのだろうと思う。
そんな話を聞くと、単に業務システムを開発したり、ITビジネスでお金を儲けるだけでなく、IT技術を社会の問題解決に適用し、多くの人達のために社会貢献する方向に進化しているように感じた。

| | コメント (0)

2021/04/18

Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか? #redmine

Excel駆動でWBSやガントチャートが作れない人は割といる。
ExcelからガントチャートやWBS管理を作ろうとしているが、その品質が悪い。
Excelで出来上がったガントチャートやWBS一覧の完成形を見せつけられているので、Excelで作ろうとするが、上手く完成できない。

若手のプロジェクトリーダーでもガントチャートに穴がある時があるし、いつもタスクのこなしが遅い人はそもそも全てのタスクを洗い出せていない。
だから、進捗管理をやろうとしても、何が遅れてやばいのか、どこに課題があるのか、を一つずつ解決できていない。
最初から全てExcel上で、PJ計画の作業をするのがそもそも間違っている、と思う。

では、どこに原因があるのか?

1つの観点として、そういう人たちは、PERT図を描いた経験がないのだろうと思う。
つまり、タスクの全体の構造が見えていない。
タスク同士の因果関係、タスク同士の依存関係が見えていない。

たとえば、ガントチャートを作る前にタスクをExcelで洗い出すだろう。
しかし、Excelで縦列に並べたタスクを見ても、その先行・後続の関係や優先度はそれぞれ違う。
それらをつなげて一つのガントチャートを作った、という経験がないようだ。

進捗管理の基本はクリティカルパスをきちんと管理することだ。
クリティカルパスとなるような重要なタスクさえ抑えれば、他のタスクはクリティカルパスから追跡できる。
そういう考え方をしていないリーダーがいた。

つまり、Excel上で、タスク一覧をこねくり回しても何も進まない。

では、どうやると治療できるのか?
一つの案では、連関図法のように、タスクを付箋紙で全て書き出して、グルーピングして、先行・後続でつなげていく、という作業を何度か経験すればいい。

そうすれば、タスクをグルーピングして依存関係を考えるうちに、このタスクも必要だから付け足そう、このタスクは他のグループにまとめたほうがいい、とか、これらのタスクは並行で稼働させたらメンバーを有効活用できる、とか、色々気づくはず。
あるいは、インフラ担当のメンバーが1人しかいないので、彼のタスクは全てクリティカルタスクになってしまう、とか、担当者のタスクが溢れている、とか分かれば、早めにメンバー確保するとか、色々対策を打つはず。
そういう試行錯誤が重要だ。

結局、付箋紙で洗い出してタスクの先行後続、依存関係を考えている、ということは、PERT図を描いているのと同じ。

具体的な案として、Redmineのチケットで全てのタスクを一括登録して、それらチケットをつなげてPERT図でを作り、先行後続の関係をガントチャート上で編集して、ガントチャートを作る。
あるいは、リリース日の単位でチケットをグルーピングしてロードマップを作る。
そういう作業をやってみれば、実際に気づきが多いはず。

Redmineのガントチャート標準機能では、ガントチャートの編集はできないが、LycheeGantChartを使えば、先行・後続関係を付けたり、ガントバーを移動したりできる。

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2~RedmineでEVMを実現 Lychee EVM: プログラマの思索

RedmineをMSProcjetっぽく使う事例: プログラマの思索

Redmineを使わないならば、OSSのMSProjectクローンであるProjectLibreを使えばいいだろう。
Excelでタスク一覧を作っておき、ガントチャート画面で先行・後続関係を付けられる。

OSSのMSProjectクローンProjectLibreの使い方: プログラマの思索

OSSのMSProjectクローンProjectLibre: プログラマの思索

実際は、ガントチャートの保守は非常に面倒だ。
単に、タスクの先行後続をつなげればいい、だけの話ではない。

たとえば、1人日は8時間しかないのに、1人の作業が1日15時間働くような作業を組んだガントチャートになりがちだ。
だから、リソースヒストグラム画面で行き来しながら、作業負荷を考えて、タスクの分担を調整する。
いわゆる山崩しだ。

たとえば、ガントチャートを作るとPERT図という別のビューで見れるので、TOCの合流バッファの考え方を適用して、合流バッファには余裕をもたせることで、クリティカルチェーン上にゆとりをもたせて納期を厳守する。

たぶん、こういうガントチャートの管理手法は、メーカーの生産計画の手法と相性がいいので、本来はもっと自動化されるべきだろう。
しかし、ソフトウェア開発は、ハード製品を大量生産するケースとは全く違うので、PJ計画時に立てたガントチャートは、あくまでもイメージに過ぎず、たくさんの課題や障害が発生する都度、解決して、何とかリリースにこぎつける、みたいなパターンが多いはず。

だから、Excelのガントチャートが完成形に見えたとしても、所詮それは幻想に過ぎない。
そういう計画作業で得られた知見、試行錯誤して考えているうちに気づいたリスク、という方が大事だと考える。

次回の東京Redmine勉強会のパネルディスカッション「Excel中毒者のためにRedmineワクチンを施してみた」ではそんな話をする予定。
是非、参考にして欲しい。

第20回勉強会 - redmine.tokyo

| | コメント (0)

2021/04/08

プロジェクトのリスクはコストの増減で管理する

「プロジェクトのリスクはコストの増減で管理する」のであり、「コスト管理と課題管理は同じではない」。

【参考】
コストマネジメント(コストコントロール体系) | イノベーションマネジメント株式会社

プロジェクトリーダーのレベルではなく、事業部長や複数プロジェクトを取りまとめる組織の長の観点では、各プロジェクトのリスクをどのように軽減したり、回避したりするか、に注力するようになる。
リスクを完全にゼロにすることは、お金もリソースも使い過ぎるので、現実的ではない。

各プロジェクトでは、計画時にプロジェクト特性に応じて、リスクを洗い出す。
プロジェクトリーダーは、プロジェクトのキックオフ後、実行中では、リスクがどのように変化して、増大して手に負えなくなるか、事前に防げるか、に注力していく。

一方、事業部長や部課長の観点では、どこかのプロジェクトで火を噴くリスクがあると考えて、事前に各プロジェクトのリスクをコストで予算化しておく。
そういう予算は、プロジェクト外費用ならコンティンジェンシー予備費だし、プロジェクト内費用であればマネジメントリザーブ(マネジメント予備費)になる。
そして、実際に火を噴いたら、マネジメント予備費を使うし、更に足りなければ、コンティンジェンシー予備費を投入してでも、火を消すようにする。

一般に、マネジメント予備費を使う権限は、プロジェクトリーダーの采配と組織の最末端の管理職である課長の采配の2つで決まるだろう。
マネジメント予備費は契約時に、利益やコストを見込んで、契約金額に上乗せして積まれている。
マネジメント予備費を使うほど、利益は落ちるので、プロジェクトリーダーの権限ですべてを使っていいわけではなく、最低限の利益ラインを超える場合は、課長の承認が必要になるだろう。
普通は、一旦プロジェクトが火を噴けば、際限なくコストは膨らんでいく。

そして、コンティンジェンシー予備費は、事業部のトップである事業部長の承認で決まる時が多いだろう。
コンティンジェンシー予備費を使う段階まで来ると、経営陣にもその使途理由を問われるので、社内では相当な噂になりやすいだろう。

駄目なプロジェクトでは、プロジェクト計画時にリスクをそもそも洗い出せておらず、単なる課題一覧に過ぎない。
適当に解決するだろう、という期待を含めた課題管理に陥っている。
だから、リスクが顕在化して手に負えなくなると、肝心の予算がなく、単なるデスマーチ案件となってしまって、会社のお金や人員を無尽蔵に浪費していってしまう。
元々、リスクに対する予算などの手当がないので、何の戦略もなく、ズルズルと状況に押し流されるだけになる。

本来は、リスクの内容に応じて、影響度や深刻度、重要度に応じて、そのリスクが発生した場合にかかる費用を見積もり、それらの合算をコストとして予算として見込む。
もちろん、全てのリスクを洗い出して合算したら、途方もない金額になるから、ある程度のリスクは許容することで予算化しないことになる。
あるいは、コストが掛からない対策があれば一番良いが。

PMOの仕事をしていると、プロジェクト運営という観点だけでなく、プロジェクトの採算やコスト管理まで見るようになってきた。
その時に、駄目な会社では、ISO9001を運用していると標榜しながらも、プロジェクト計画書に記載されたリスク一覧が単なる課題一覧に貶められている風景を何度も見てきた。
本来、リスク管理とは何だろうか?という疑問があったが、リスクはコストの増減で管理するという発想が必要と分かり、ようやく腑に落ちた。


| | コメント (0)

2021/04/04

沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね

沢渡さんの資料「テレワークに役立つ8つのスキル」が参考になるので、メモしておく。

【参考】
経営課題解決のためのテレワーク導入・活用Webセミナーレポート|トピックス|ハマリモ! 浜松テレワーク推進プロジェクト

テレワークが主体になった仕事では、以前とは違ったスキルが必要になっていると感じる。
特に、周囲に誰も居ないので、自分自身でスケジュールや仕事の内容をコントロールすることが重要になったし、それがさらにシビアに厳しくなった感じだ。
テレワークによって、正社員であっても、個人事業主が請負契約で仕事しているイメージに近い。

なぜなら、テレワークの成果物としてアピールすべきものは、目に見える成果として出さなければ、存在しないのと同じだから。
よって、より高いアウトプットを定期的に出すためのスキルが別途必要になっている、と考える。

「テレワークに役立つ8つのスキル」では、下記がある。
・ロジカル・コミュニケーション
・セルフマネジメント
・ヘルプシーキング
・クリティカル・シンキング
・チームビルディング
・プロジェクトマネジメント
・ファシリテーション
・ITスキル/リテラシー

「テレワークに役立つ8つのスキル」を分類すると、2つのカテゴリに分類できるだろう。
他者とやり取りする技術、そして、自分自身を律する技術。

テレワークでは、他者とやり取りする手段がチャットやTV会議に限られるため、対面よりも情報量が圧倒的に少ない。
だから、いかに濃い情報をやり取りできるか、が鍵を握ると考える。

そのために、論点を明確に手短に話したり、議論している内容から課題を抽出して構造化・言語化したり、お互いに率直に話せる環境を醸し出したり、などのスキルがいる。

また、テレワークでは、自分一人で成果物を作り出す能力がより求められるので、自己管理がより重要になる。
問題を整理し、ゴールを定め、ゴールまでのプロセスを作り、作業に分解して、作業しながら自分の立ち位置を自己測定する。
つまり、プロジェクトマネジメント力がかなり求められる。

また、集中して仕事できる環境を整備し、時にはモチベーションを奮い立たせたり、リラックスできる環境もいる。
もちろん、オンライン会議ツール、チャットツール、チケット管理ツール、オンラインスケジュール、オンラインファイル共有などのツールを使いこなすことも大事。
つまり、セルフマネジメントの環境を整備するのも大事。

無理ならば、アラートをあげて他者にヘルプを求めたり、専門家に頼れるルートもいるだろう。

自分でリモートワークしていて、こういう考え方が必要だな、と色々思いつくものの、整理できていなかったので、こういう図で言語化できて、とてもありがたい。
他人に話す時にも使えるので有用と思う。





| | コメント (0)

2021/04/01

プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ

プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきではないかと考えた。
考えがまとまっていないので、ラフなメモ。

【参考1】
日本型管理職はアジャイル実践の夢をみるか?. アジャイル時代のマネジャー育成計画 #1 | by Hiroyuki TAKAHASHI | WingArc1st Inc. | Medium

(引用開始)
PMBOKは、コストが開始時点で決まっていたり、成功条件がコスト・スケジュール・スコープの達成の場合にとても有効なManagement手段でした。
ソフトウェア開発を、内製よりも外注することが多い日本の企業では、コストははじめから決まっていることがほとんどです。
そんな背景もありPMBOKがスコープとする開始と終了がある「プロジェクト型開発」の考え方は、広く受け入れられました。
一方で、このことが日本におけるアジャイル導入の弊害になっていたかもしれません。
計画駆動でうまくいく「プロジェクト型開発」によって、昨今アジャイルがわかるマネジャーが少ない要因にもなっているのでは?と思うのです。
(引用終了)

PMBOKはPJ管理の基本を知るのに良い知識体系と思う。
日本のように、政府も企業も予算駆動で案件が動く場合ではとても有効と思う。
しかし、世界の流れは別次元で加速している。
おそらく、プロジェクト型開発の経験だけではやっていけない。

(引用開始)
PMI(PMBOKガイドを制定し世界的にプロジェクトマネージメントを広めている団体)もそこには気がついていて、PMBOKガイド第6版から「アジャイル実務ガイド」という冊子をリリースしています。
ただ、個人的には水と油感が否めず、別冊にしているのもPMBOKガイドに「混ぜ込めなかった」からかなと思っています。今後の進展に注目したいと思っています。
(引用終了)

昨今のSaaSのようなプロダクト型開発では、その考え方で全てをやり切るのは正直違和感があった。
PMBOKは確かにプロジェクトで駆動するPJ管理手法だから、始まりがあり終わりがある。
そこが一番のボトルネックなのかもしれない。

プロダクト型開発でPJ管理を行おうとすると、おそらく自然に、スクラムのような組織体制にならざるを得ないだろう、と直感している。
この理由付けは色々考えてみる。

【参考2】
なぜ大規模なシステム開発は失敗するのか|最首 英裕|note

(引用開始)
現行業務がわからない現状
さまざまな企業と話していると、自社の業務を正確に把握している企業は、実はほとんどないのだというのがわかってくる。
今や、業務のほとんどはコンピュータ化されている。なので、業務内容を理解することは、コンピュータの中でどのような処理をしているのかを理解することと同義となる。
でも、通常は毎日意識しないままコンピュータが動き、業務は進む。だから、わかっていたこともわからなくなり、自社の業務に関する知識はドンドン失われているのだ。
(引用終了)

今までのアナログの業務や作業をシステム化すると、ERPであれスクラッチであれ、現場業務の意図は失われる。
自動化されてしまって、全てが当たり前になってしまうからだろう。
ブラックボックスと化したシステムをリプレースする時に初めて、そのリスクに直面する。

(引用開始)
機能を足し算して複雑化するシステム
そして状況を悪くするのは、せっかく再構築するなら、欲しかった機能を色々と追加しようとする間違いだ。
使いやすいと感じるものは、大抵の場合、シンプルさと裏腹だったりする。
(引用終了)

どうしても日本人はカスタマイズにこだわる。
自分たちの業務プロセスに愛着があって、自分たちのプロセスにパッケージ製品やERPを合わせようとする。
しかもそのカスタマイズの要望は、ある一つの部門だけなのに、各部門の要望を集めて、それを実現してしまう方向に行ってしまいがち。
日本の要件定義の打ち合わせでは、総論賛成、各論反対になりやすい。

(引用開始)
インクリメンタル(プログラムはどんどん捨てる)
そして最も重要な4番目の要素が、インクリメンタルだ。
冒頭にも説明したように、開発しようとしている業務は、誰も全貌を理解していない可能性が高い。しかも将来を見据えた機能などという要素が出てくると、わからないことはさらに多くなる。
だからやるべきなのは、一度に大きな仕組みを作るのではなく、少しずつ完成に近づけていくこと。しかも、途中まで作ったプログラムを捨てながら完成させていくことだ。
(引用終了)

「途中まで作ったプログラムを捨てながら完成させていく」フレーズから、犠牲的アーキテクチャを思い出した。
一度作ったプログラムを全て捨てて、一から書き直す勇気も必要な時がある。

犠牲的アーキテクチャ~リプレースを正当化するアーキテクチャ: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

Martin Fowler氏の語る“犠牲的アーキテクチャ"

でも、SaaSでは犠牲的アーキテクチャは相当難しいと思う。
なぜなら、本番稼働中のサービスのシステム基盤を刷新してリリースするのは、並大抵の大変さではないからだ。
この辺りはどのように問題解決するのか?

| | コメント (0)

2021/03/30

ソフトウェア開発は打ち合わせ駆動開発だ

ソフトウェア開発は打ち合わせ駆動開発だ、と思う。
WF型開発でも、アジャイル開発でも、同じように思える。
以下、ラフなメモ。

たとえば、一般的なWF型開発では、各工程の終了ゲートでは、顧客やステアリングコミッティの承認を得るための会議を開いて、そこを通過するのを目的とする。
その会議のために、プロジェクトマネージャはパワポの資料をわんさか作成する。
その会議で報告して最終検収するために、メンバーはその会議資料の元ネタとなるプログラミングしたシステム、その設計書、テスト仕様書、不具合一覧、リリース手順書などを揃える。

もちろん、設計、開発、テストの各工程では、レビューを通過しなければ、先に進めない。
レビューアが承認する、という儀式が待っている。

一方、アジャイル開発では、各工程のゲートはないが、スプリントプラニングやスプリントデモなどのイベントがある。
それらイベントが、開発チームの行動を制約して、プロジェクトの目的をメンバーに思い出させる。

では、ソフトウェア開発以外のビジネスでは、打ち合わせ駆動のスタイルではないのか?
営業であれば、打ち合わせするよりも、お客様の現場に直行して交渉するほうが大事だ。
受付や店頭販売の人であれば、窓口や店頭でお客様に商品説明するほうが大事だ。
工場の生産現場であれば、打ち合わせよりも実際に生産ラインで組み立てるほうが大事だ。

つまり、普通のビジネスでは、SEやPMのように、1日のスケジュールが打ち合わせで一杯になる、なんてあまりないのではないだろうか。
換言すれば、ソフトウェア開発では、打ち合わせで仕様を詰めたり、アーキテクチャの方針を決める、という創造的な仕事よりも、出来上がった成果物のレビューで完了承認する、とか、作業が遅延していないか進捗確認する場の方が良いのではないか。
とにかく、ソフトウェア開発に関わる人は打ち合わせが多すぎる。
だから、会議室をたくさん用意するほど、どんどん会議室が埋まってしまう症状が見られやすい。

ソフトウェア開発が打ち合わせ駆動開発になりやすい原因は何だろうか?
平鍋さんは、ソフトウェアはコミュニケーションウェアだ、と言われたが、まさに、数多くの伝言ゲームを経て、一つのソフトウェアが作られる。
ソフトウェアは目に見えないものなので、逐一、みんなが額を寄せ合って、プログラムの意図や意味、バグ、アーキテクチャなどを説明しなければ伝わらないのかもしれない。

ソフトウェア開発が打ち合わせ駆動開発になりやすい特徴があるならば、その打ち合わせをもっと有意義なものにすればいい。
PMBOKでも、会議体というコミュニケーション計画は重要なマネジメントの一つ。
アジャイル開発では、故意にイベントを設けて、イベントが開発チームのモチベーションを上げるような仕組みを提供した。

そういう事を考えると、打ち合わせを制するものはソフトウェア開発を制するのかもしれない。

| | コメント (0)

2021/03/26

ITの技術や知識はツールの習得と表裏一体である

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。
とても当たり前の内容かもしれない。

【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。
でも何か分かったような気がしなかった。
何か真似事しているだけのような気がした。
なぜだろうか?
いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。

【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。
具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。

理由は、2つある。

【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。

たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。
昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。

今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。
実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。
PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。
ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。

たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。
特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。
それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。
ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。

たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。
実際にモデルを描いてみると、数多くのモデル管の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。

特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。
ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。
だから、データモデリングの考え方自体も普及していない。

【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。

たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。
RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。
しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。
つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。
もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。

たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。
しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。

実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。
IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。
100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。
そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。
そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう

たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。

たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。
すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。
また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。
つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。
Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。

逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。
Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。
たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力もあったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。
「ツールがプロセスを改善していく」という発想が僕は好き。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索

ツールがサポートすれば考え方も変わる: プログラマの思索

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

開発プロセスの型をツールで構築する #tidd: プログラマの思索

【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。
換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。

それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。

だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。
そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。

最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。
いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。
視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。

昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。
そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。

| | コメント (0)

より以前の記事一覧