« 2021年3月 | トップページ | 2021年5月 »

2021年4月

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)

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

思考力と注意力のトレードオフを因果ループ図で描いてみた。
世の中の現象を因果ループ図で描く練習の一つ。
ラフなメモ。

【参考】
「情報」と「注意」のトレードオフ | 楠木建 ようするにこういうこと|DIAMOND ハーバード・ビジネス・レビュー

【ロジックの流れ】
知識が増える
→思考する時間が増える
→知識をより要求する

一方、
知識が増える
→記憶した知識を整理する注意力が増える
→注意力は限度があるので、知識量を抑える
→思考力は限界で伸び悩む

人間の脳の処理能力には一定の限界がある
→注意力・意志力は有限のリソースになる
→知識が増えすぎるほど、思考力も限界に達する

では、どこで解決策を考えるのか?
パターンは3つある。

思考力を強化して、思考力向上ループを強める。
注意力を弱めて、注意力散漫ループを弱める。
知識量を調整して、注意力散漫ループよりも思考力向上ループを高めるようにする。

トレードオフがテーマなので、思考力や注意力を強めても、他要素に悪影響がある。
システム原型「成長の限界」と同じ。

限られた有限リソースの注意力を思考の質向上に使う。
よって、注意力散漫ループの負のループを弱めるために、知識量を減らす。
知識量を減らすには、情報収集チャネルを減らし、インプットすべき知識量を減らす。
一般には、雑念を増やすような媒体、テレビやスマホ、無駄なSNS、無駄なネットサーフィンは避ける、みたいなロジックなのかな。

【気づき】
システム思考の重要性は、アジャイル開発やスクラムの書籍でよく言われている。
しかし、実際にシステム思考を使いこなすのは非常に難しい。

因果関係を見つけるのも大変。
そのフィードバックで元に戻る、というロジックを見つけるのが難しい。

その因果関係は本当に正しいのか?
漏れている因果関係はもっとあるのでは?
と考え出すときりがない。

システム思考の研修で聞いてみたら、書き方は何種類もあっていい。
正しい回答はない、ということだった。
つまり、因果関係はその人のマインド、固定観念を表す。
そこからメンタルモデルを見つけて、新たな観点の気づきを得る、みたいな対症療法みたい。

今後も色々書きなぐってみる。

| | コメント (1)

2021/04/26

Ciscoのshowコマンド一覧

Ciscoのshowコマンド一覧をメモ。
GNS3でコマンドを叩いていると、showコマンドの中身から、ルータやスイッチの状況を把握する場合が多い。
オプションが少し違うだけで、IPアドレスは表示されるが、サブネットマスクは表示されない、とか、細かな違いがあるので注意。

【参考】
Ciscoルータ/Catalystコマンド一覧 - ネットワーク入門サイト

CCNAで覚えなきゃならんshowコマンドの一覧39個

Ciscoコマンド一覧|FEnetインフラ

自分の理解のために書いておく。

コマンド 説明
show arp ARPテーブルの表示
show cdp CDPの情報を得る
show cdp entry 特定の隣接Cisco機器の情報を表示
show cdp interface CDPが動作しているインタフェースの情報を表示する
show cdp neighbors 隣接Cisco機器の簡易情報を表示
show cdp neighbors detail 隣接Cisco機器の詳細情報を表示

show interfaces インターフェースの確認
show interface fa0/0
show interfacce fa 0/1 switchport
show interfaces trunk turnk情報を表示
show interfaces status インターフェースの状態確認

show ip access-list IPアクセスリストの表示
show ip arp エントリを指定してARPテーブルを表示
show ip eigrp neighbors EIGRPのネイバー情報を表示する
show ip eigrp topology EIGRPのトポロジテーブルを表示する
show ip eigrp traffic EIGRPのトラフィック情報を表示する

show ip interface インタフェースのIPに関する情報を表示する
show ip interface brief インタフェースのIPに関する情報を簡易表示する
show ip nat statistics 実行されたアドレス変換の統計情報を表示する
show ip nat translation NATテーブル一覧表示

show ip ospf interface OSPFのインターフェース情報を表示する
show ip ospf interface fa 0/0 OSPFのインターフェース情報を表示する
show ip ospf neighbor OSPFのネイバー情報を表示する
show ip ospf database OSPFデータべースを表示
show ip protocols ルーティングプロトコルの情報を表示

show ip rip database RIPのデータベースを表示する
show ip route ルーティングテーブルを表示
show ip route ospf OSPF情報を表示
show lacp neighbor LACPにより形成したEtherChannelで隣接するスイッチのポート情報を確認

show mac-address-table MACアドレステーブルを表示
show mac-address-table aging-time MACアドレステーブルのエージングタイムを表示
show mac-address-table dynamic MACアドレステーブルのダイナミックエントリを表示

show port security ポートセキュリティの設定の確認
show protocols インターフェースの状態確認

show spanning-tree スパニングツリーの情報を表示する
show spanning-tree interface fa 0/1
show spanning-tree vlan 1

show startup-config 現在の設定(show startup-config)確認
show running-config 現在の設定(running-config)確認
show version IOSのバージョンとハードウェアに関する情報を表示

show vlan VLAN情報の表示
show vlan id 30
show vtp status VTP情報の表示

改めて思うのは、ルータもスイッチも複雑だな、と。
ちょっとコマンドを間違えたり、IPアドレスやサブネットマスクを間違えて設定すると、すぐにPingすら通らなくなる。

ちょうど、RubyやPythonでプログラミングしていると、スペルミスしたり、ロジックを1行ミスしただけで、思い通りに動作しなくなるのと同じ。
どこかのネット記事で、プログラミングを全く知らないユーザ企業の社長が、忙しい合間にRails研修を受けてプログラミングを経験した結果、コーディングはこんなに繊細なものなのだ、と分かった、という話を読んだことがあった。

同様に、ネットワーク担当者なら当たり前なのだろうが、実際に経験してみて、その肌感覚が僕もようやく理解できた。

| | コメント (0)

2021/04/25

ビジネスの基本戦略には規模の経済があるのではないか

戦略の経済学」という本を借りて読んでみて、世の中のビジネスの基本戦略には規模の経済があるのではないか、というアイデアを持った。
結論がなく、ロジカルでないラフなメモ書き。

【参考】
「規模の経済」で読み解く -食品容器メーカーの資材調達担当課長・伊藤の悩み | GLOBIS 知見録

すぐ分かる経営戦略論: チャンドラーモデル

ポーターの3つの基本戦略 | 経営を学ぶ~経営学・MBA・起業~

規模の経済性と経験曲線効果 - 読書遊民

規模の経済と経験曲線効果のメモ: プログラマの思索

ポーターの競争戦略の考え方: プログラマの思索

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済という法則がどの業界の中小企業でも大企業でも働いているのではないか。
最初は中小企業であっても、売上が増えて事業が好調になると、人手や設備が足りなくなるので、営業マンやエンジニアを増やしたり、最新の機械や設備を借金して購入し、事業をもっと拡大させようとする。

事業を拡大するのが良い理由は、たぶん、規模の経済が働くからだろう。
たくさんの商品や製品、サービスを作り出せば、固定費はその分薄まるので、単位あたりのコストは下がって、その分、利益が増える。

たとえば、製造業であれば、大量生産することで、単位あたりのコストを下げるだけでなく、工場労働者の学習能力も上がることで、経験曲線効果も得られる。
つまり、より上手く作れるのでコストが下がり、利益も増える。
自動車であれ、パン屋であれ、酒造会社であれ、たくさん作る方がコストが減って利益が増える重力が働くから、経営者はその方向性に自然に意思決定する。

規模の経済は機械製造業や食品メーカーだけではない。
クリーニング屋、コンビニ、スーパー、ファーストフード、居酒屋チェーン、フランチャイズチェーンなども同じ。
たくさんの店舗で同一商品や同一サービスを大量に販売する方が、コストが減って利益が増える。
特定地域に集中出店するドミナント戦略は、コストリーダーシップ戦略を活用した戦略ではないか。

規模の経済の本質は、固定費が単位当たりの製品単価で下がること。
規模の経済の効果は、たくさんの製品・サービスを同じ手順で量産するので経験曲線効果も得られること。
また、大量仕入れによる発注コスト削減も期待できる。

だから、たぶん世の中の経営者は規模の経済を活用した意思決定を行うことが多いのではないか。
ずっと小さな企業規模であっていい、という判断ならば、社員を増やしたり設備投資したりする動機はないから。

しかし、規模の経済からいつも恩恵が受けられるわけではない。
ある一定量を境にして、逆にコストが増えて、規模の不経済が働くのが普通。
たとえば、装置産業、労働集約型産業ではそうだろう。
たくさんの設備があったとしても、たくさんの労働者を集めたとしても、結局、その重荷を会社が耐えられなくなる。

なぜなら、企業規模、組織構造が大きくなりすぎると、意思決定のための情報を全て集めにくくなり、それに基づく意思決定が遅くなる。
あるいは、企業規模が大きく、組織構造が複雑になりすぎると、企業内で調整するコスト、つまり取引費用が大きくなってしまう。
だから、取引費用を最小限に抑えるという別の重力が働いて、規模の経済を妨げる。

個人的には、規模の経済が組織構造を複雑化させて、コストが増え続けて、その重みに耐えきれなくなって、規模の経済を逆回転させる動きになるのではないか、と考える。

最初は、規模の経済を利用しまくって、規模の経済の逆回転が動きそうになったら、そこでいったん打ち止めして、別の事業に注力していく、みたいな意思決定になるのだろうか。

| | コメント (0)

GNS3の代わりになるシミュレータEVE-NG

GNS3の代わりになるシミュレータEVE-NGの記事を見つけたのでメモ。
暇な時に試したい。

【参考】
雑草エンジニアの備忘録的なサムシング: EVE-NGインストールメモ

EVE-NGを使って仮想NW環境を用意する~1. インストール編~ - Qiita

EVE-NGを使って仮想NW環境を用意する~2. ノード追加編~ - Qiita

EVE-NGを使って仮想NW環境を用意する~3. はじめてのルーティング編~ - Qiita

EVE-NG Download

EVE-NGとは ? VM環境でお手軽インストール | Network-arekore.com

【キャプチャ画像で詳解】EVE-NGのインストールの方法

個人的には、GNS3が使いやすい。
僕は「GNS3によるネットワーク演習ガイド ――CCENT/CCNA/CCNPに役立つラボの構築と実践」のサンプルソースを触りながら、やっとルータやスイッチのいじり方が理解できた。
本当は数十台のCisco実機を触って、試行錯誤しながら社内LANを構築するほうが良かったかもしれない。

ネットワーク設計については、理解が深まったとともに、今までのシステム構築の経験を振り返って色々疑問点があるので、また書き留めておく。

| | コメント (0)

2021/04/18

なぜInfrastructure as Codeが必要なのか?

最近ようやく、Ciscoのスイッチやルータの使い方が分かってきた。
GNS3上のルータやスイッチをCiscoコマンドで設定したり、動かしているうちに、ネットワーク技術の奥深さや難しさが何となく見えてきた気がする。
以下はラフなメモ書き。
間違いがあれば後で直す。

そもそも、ネットワーク技術の根本問題は何なのか?
根本には、ネットワークは動いていて当たり前という高品質が前提の上で、コスト、高性能、冗長性、セキュリティというパラメータのトレードオフがあると考える。

コスト=F(高い品質、高い性能、冗長性、セキュリティ)という複雑な方程式から、最小コストとなるパラメータの組み合わせを探そうとしている。

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察: プログラマの思索

ネットワーク技術の必要性が高まっている: プログラマの思索

ネットワークは動いて当たり前であり、通信できなくなると、即座に業務が止まってしまう。
ルータやスイッチを設定してみて分かったのは、設定が複雑すぎる。
数十、数百のスイッチ、ルータの設定が1つでも間違えば、ネットワークは動かなくなる。
ネットワークの素人では無理。

たとえば、中小企業で100人以下で、バックボーンエリア1個だけで済むようなルーティングのOSPF構造の経験があっても、エリアIDが2個、3個と増えて、ルータが数百台になってしまうと、相当に難しいと思う。
ネスペ・支援士塾 - connpassで講師や参加者の話を聞くと、普通のエンジニアでは、エリアIDが1個だけのルーティングしか経験がない人が多い感じ。

たとえば、冗長性を実現することで、どこかで配線が切れても、代替のルートで通信を継続できる。
いわゆる耐障害性につながる。
冗長性は、スイッチではSTPで実現するか、PAgPで実現するか、色々ある。
しかし、L2層ではフレームのTTLが無いので、下手なNW設計では、L2ループが発生してしまい、通信帯域を消費して、通信速度が落ちてしまう場合がある。
「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」を読むと、STPで冗長性を確保するトレードオフとして性能悪化してしまう症状に対して、どんなネットワーク設計をすべきか、をすごく丁寧に説明してくれている。
他にも、デフォルトゲートウェイとなるサーバーの冗長性をHSRPで実現したり、floating static routeでバックアップのdefault routeを設定したり、色々ある。

たとえば、ネットワーク設計ではセキュリティが非常に重要だ。
データリンク層のスイッチのレベルでは、スイッチに不正接続があればPortSecurityを使ってポートそのものをシャットダウンできる。
VLANで営業部、経理部などの組織単位でサブネッティングできる。
ネットワーク層のルータのレベルでは、ACL、NAT、RADIUSサーバー認証などでパケットフィルタリングできる。
また、SNMPで常時監視、Syslogにネットワーク機器のログを残したりできる。

Ciscoルータ/Catalystコマンド一覧のリンク: プログラマの思索

GNS3の情報のまとめ: プログラマの思索

ネットワーク学習のためのチートシートのリンク: プログラマの思索

では、最近、なぜInfrastructure as Codeが必要なのか?

上記のように、たくさんのスイッチ、ルータ、ワイヤレスLANコントローラ、DNSサーバー、NTPサーバー、DHCPサーバー、SNMPサーバーなどのネットワーク機器を個別に1つずつ設定するのは非常に大変すぎる。
数百台、それ以上のネットワーク機器のstartup-configを一つずつ手作業でセットアップするのは、現実的でない。
1つでも設定が間違えば、L2ループが発生して通信帯域を圧迫して性能を落としたり、通信経路そのものが遮断されてしまって代替経路が動かない、とか、色々起こってしまう。

「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」で印象に残った話は、ユーザはスイッチの空きポートがあると何を差し込んでもいいと勘違いしていて、そこに量販店で買ったブロードバンドルーターを接続して、付属したDHCPサーバーが動いてしまい、フロア全体の通信を落としてしまった、実は新人の私でした、という話があった。

だから、それらネットワーク機器を一括設定、管理するような機能、つまり、SDNが必要になる。
そのSDNを仮想化したアーキテクチャとして、Infrastructure as Codeがあるわけだ。

僕は、Infrastructure as CodeをApahceのhttpd.confなどをGitで構成管理するぐらいの程度で考えていたが、たぶん全く違う。
そういうアプリケーション層ではなく、データリンク層、ネットワーク層のレベルでネットワーク機器を構成管理して、Infrastructure as Codeを実現しようとしているのだろう。

SDNコントローラで制御できるならば、管理画面からREST API、NetConf、SSH、Telnetで一括操作できる。
以前なら、ChefやPuppetが紹介されていたが、今はAnsibleが一般的なのだろう。
なにせ、SSHやNetConfが使えるし、エージェントレスだし、Playbookを書いてPushするだけでいい。

すると、Infrastructure as Codeによって、ネットワーク設計の仕様が一連のプログラムないし設定ファイルというテキストで管理できる。
テキストであれば、Gitで履歴管理できるから、設定ファイルのUndo、ReDoも簡単だ。

そして、ネットワークの仮想化、ソフトウェア化によって、クラウド環境が一般的になった今では、そういうネットワーク設計仕様のテキストは、kubernetesで可搬性を持つようになる。
kubernetesがもっと進化すれば、AWSやGoogleCloud、Azureというクラウド環境にも依存しない設定ファイルとして使えるようになるはずだ。
そうすれば、ネットワーク設計を抽象的に設計できれば、その設計構造をkubernetesで書くだけで、どのインフラ環境でも、どのクラウド環境でも動作できるようになるはず。
つまり、6つの品質特性のうち、移植性を完全に実現できるはず。

ネットワーク設計であれ、Windows7やWindowsServerの廃棄対応であれ、ソフトウェアの移植性は従来からずっと問題だった。
Infrastructure as Codeという考え方はそれを解決する一つの技術と捉えられるのだろう、と思う。

| | コメント (0)

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/10

SQLは画面や帳票のインターフェイス層に相当する

下記の記事で、データモデリングではSQLは画面や帳票のインターフェイス層に相当する、という点に気づいた。
ラフなメモ書き。

【参考】
顧客も技術者も不幸になる人海戦術に終止符を、実データで設計を吟味せよ | 日経クロステック(xTECH)

杉本啓さんはTwitterを使っています 「これを読むと、データ中心アプローチの人々がサロゲートキーを嫌う理由がよくわかるよね。サロゲートキーを使ったDBでは、ユーザーがこんな風に気軽にデータをいじれない。 サロゲートキーは、ユーザーを「データベース=帳簿」から隔離して、技術的な存在にしまう。」 / Twitter

【1】僕はSQLは好きだ。
下手にExcelでデータをこねくり回すくらいなら、RDBに入れたデータをSQLで自由自在に抽出したり集計する方が楽だから。
一方、データモデラーではSQLは重視しない点にちょっと違和感があった。
しかし、上記の記事で、SQLは画面や帳票のユーザインタフェースに相当する事に気づいて納得した。

実際、正規化されたテーブルがあれば、欲しいデータはSQLで取ればいい。
その欲しいデータは、画面にあらわれているデータであり、帳票として印刷されるデータそのものだから。

よって、モデラーが業務の制約条件を上手くテーブル設計に反映しておけば、ユーザはSQLで好きなようにデータを抽出できるはず。

一方、訓練された設計者であれば、ER図を眺めれば、そこから業務フローや帳票、画面をイメージできるだろうが、外部設計フェーズで画面設計や帳票設計に注力してしまい、DB設計は単にデータベース定義書を作るだけ、という考えでいると、複雑なシステムになってしまい、失敗しやすいのだろう。

【2】サロゲートキーで統一されたテーブルでは、Webシステムは作りやすい。
Railsが典型的な例。
URLとメソッド、テーブルが1対1に関連付けられるので、URLベースで設計すれば、そのままプログラミングできる。

一方、DOAでモデル駆動開発を推進したい時、サロゲートキー中心のデータモデルでは、テーブル間の関係が判別しにくい。
テーブルを結合したり、入力データの制約がすぐに見えないからだ。
よって、業務を知るユーザがSQLを駆使して、テーブルを結合して、欲しい帳票を得る手法が取りづらくなる。
だから、データモデリング主導の開発では、サロゲートキーは廃止して、明示的にテーブル間の関数従属性を可視化できるようにしておきたい欲望がある。

【3】業務フローからテーブル設計するのはPOA。
本来のデータモデリングでは、AsIsの業務で手元にある帳票からER図を洗い出せる。
これは「楽々ERDレッスン」と同じ考え方。
やはり、既存の帳票はデータモデルの源泉になるから。

他方、あるべきデータモデルから、業務フローや画面構成を想像することはできるか?
これができれば、業務の要件定義がやりやすくなる。
これをやるには、個人的には、T字型ERの手法がやりやすいと思っている。
なぜなら、リソースやイベントのテーブル同士のリレーションシップは一定の法則で決定づけられる、という方針なので、初心者には使いやすいから。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

| | コメント (0)

テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA

@t_wadaさんがテスト駆動開発のライブコーディングをやっていて、歩きながら聞いていた。
@t_wadaさんがブツブツつぶやいてくれているので、画面を見なくても、聞くだけで想像できる。
まるで、テスト駆動開発のラジオドラマみたいな感じだ。

Developer eXperience Day CTO/VPoE Conference 2021 - connpass

akipiiさんはTwitterを使っています 「#dxd2021 #streamA @t_wada さんのライブコーディングを歩きながら聞いていて、低い声質が良いし、テスト駆動のコメントや呟きがDJみたいて聞きやすい。バグ修正とリファクタリングは分けましょうね、とか、独り言みたいな呟きが自分事でリアルに感じる」 / Twitter

@t_wadaさんの呟きで面白かった点を記録しておく。

テストプログラムを書いていると、バグ修正とリファクタリングが混じってしまう時がある。
お勧めは、バグ修正だけに注力するか、リファクタリングだけに注力するか、モードを意識的に切り替えること。
思い通りの動きにならない時に、バグ修正とリファクタリングが入り交じるのはお勧めしない。

テストプログラムを書いていくと、テストプログラムがドキュメントそのものになる。
すると、状況の下に機能を置くか、機能の下に状況ごとに書いていくか、どちらかの方針がある。
どちらも正しい。

テストプログラムの観点では、状況の下に機能を書く方が、書きやすい。
状況はグローバル変数として共通化されるので、ソースコードは短くなるので保守性は高くなる。
しかし、機能が直感的に分からないから可読性は低くなる。

一方、機能の下に状況ごとにツリー構造にロジックを書いていくと、テスト仕様書のようになるので読みやすい。
機能のツリー構造は、業務システムアプリとかWebアプリのメニューみたいなものだから、どこに機能があるのか探しやすい。
しかし、状況があちこちに散らばるので、重複したソースコードが多くなり、保守性は下がる。

つまり、テストプログラムの可読性と保守性はトレードオフになる。
どちらが正しい、というわけではない。
テストプログラムを書く人の永遠の問題。

そこで、このトレードオフを緩和するために、パラメトライズド・テストプログラミングのテクニックがある。
つまり、テストメソッドやテストプログラムをパラメータで増やすやり方がある。
これにより、テストプログラムを機能別に書いたとしても、状況をパラメータとして増やすことができて、テストプログラムの可読性を保持するとともに、保守性も高める。

テスト駆動開発がXPで出てきてからもう20年も経つ。
改めて聞いて、色々気づきがあってよかった。





| | コメント (0)

2021/04/08

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2021/04/04

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

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

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

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

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

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

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

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

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

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

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

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

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





| | コメント (0)

Clubhouseは路上ライブや朗読のためのツールかもしれない

Clubhouseの使い方は正直良く分かってない。
主張のないラフなメモ書き。

【参考】
Clubhouse (アプリケーション) - Wikipedia

Twitterは最速のメディア: プログラマの思索

Facebookはセルフブランディングの最強ツール: プログラマの思索

【1】Clubhouseはアプリの機能がとても貧弱過ぎる。
痒い所に手が届いていない。
3つほど不満がある。

1つ目は、興味のあるルームを探しにくい。
カテゴリ、ジャンル、タグなどで探したいのに、なかなかヒットしない。
Twitterほど検索機能は優れていない用に思える。
だから、わざわざ別サイトで、人気ランキングから類推するしか無い。

Clubhouse 人気ランキング

2つ目は、スケジュールの機能がない。
だから、よく聞き逃すし、落胆する。
ルームは突然告知される理由かもしれないが、開始、終了の時間帯をスケジュールで入れておきたい。
今は、気づいた時に探したり、ルームで予告された話を聞いた記憶を頼りにしている。
しかもリマインダー機能もないので、よく忘れる。
本来は逐一記憶したくない。
GoogleCalendarのリマインダー機能が使いたい。

さらに、聞きたいルームがバッティングしやすいので、スケジュールを入れておきたい。
2つのルームを入れ替わり聞くこともできるはず。

3つ目は、聞いた履歴が見れない。
音声を録音できない設計思想なので、それは許すが、せめて、いつどのルームを聞いたのか、ぐらいの履歴は後で見たい。
履歴を見れば、思い出に浸ったり、後から考え事もできる。

そういう感じで、アプリはとても使いにくい。

【2】Clubhouseはどんな使い道があるのか?

僕はそんな不満を感じながらも、雨降る日曜午後に、Clubhouseを聞き流しラジオみたいに使っている。
僕が興味あるのは、朗読と音楽の聞き流し。

朗読しているルームは良かった。
たまたま、芥川龍之介の杜子春を朗読していたのを聞いた。
あらすじも知っているが、アナウンサー経験のある落ち着いて、キレのある声は聞きやすい。
高校生の頃にラジオドラマを聴いていた気分になった。

また、ジャズやピアノを練習代わりに垂れ流しているルームは良かった。
月の光、を聞いた時は、心が和んだ。

何となく、大阪駅前の路上ライブの演奏を聞いている感じだった。
その場での即興であり、Youtubeで後から聞くことも見ることもできないから。

割とうまい人でも、時々間違えたのか、音が外れている時に気づくが、むしろそれが気にならなかったりする。
練習の曲を弾いた後で、ちょっとしたコメントを話すのがとてもリアルに感じたりする。

他には、有名人が入って、個別テーマで議論しているルームも面白い時もある。
一方、井戸端会議に近いので、時間の無駄だな、と思う時も多い。
他方、有名人の顔はWebで見ているし、Youtubeなどで声や動作も知っているけれど、生の声を聞くと印象が変わる。

Clubhouse以外にも、TwitterライブやVoicyなどの音声ツールで有名人の声を聞く時がある。
中嶋聡さんは、Web記事やメルマガでキレのある内容を書いていて、割と研究者みたいな人なのかな、とか思っていたら、こんなに声が低くて太くて、すごく威厳のある人だな、とか。
ちきりんさんは、ブログでは現状の社会の問題点について切れのある意見を言う人なので性格もきついのかな、と思っていたら、生の声の配信を聞くと、こんなに女性らしい声なのか、となぜか印象が変わってしまったり。

コロナ禍でリモートワークが多くなり、パソコンやスマホに触れる時間が以前よりもかなり増えてしまって、目が疲れやすいと感じる。
眼を使わずに楽に聞きたい、という気持ちが強い。
よって、Clubhouseで聞きたいと思う時がある。

【3】Clubhouseは路上ライブや朗読のためのツールかもしれない、と思う。

Youtubeで流せば、その動画は一生残るので、ストックとして扱える。
広告料ももらえるから、マネタイズもしやすい。

しかし、Clubhouseは臨場感がある。
その時だけの音声、という希少さがある。
路上ライブがそんな感じ。

その人の声が、その人の顔、性格を連想させる。
朗読では、語る声に、その文学作品に対する、その人の思い入れが伝わってくる。

コロナ禍という時代でなければ、Clubhouseは見向きもされないツールだったかもしれない。
いつでも外出して、野外コンサートで聞いたり、舞台や劇場で見れるならば、わざわざ使う必要もないから。

Clubhouseはコロナ禍という時代だけに特化したアプリのような気もする。
コロナに罹患するリスクが高ければ外出できず、部屋に閉じこもるしかない。
YoutubeやNetflixを暇な時に見ればいいかもしれないが、飽きる時もある。
部屋に閉じこもっていれば、こういうツールでラジオの聞き流しみたいに聞きたくなる。

| | コメント (0)

2021/04/01

要件定義プロセスはDXで終焉するのか

デジタル化の流行と「上流工程」の終焉 - ブロックチェーン企業で働くエンジニアのブログがとても良かった。
要件定義プロセスはDXで終焉するのかも、と思った。
ポエムのようなラフなメモ。

【参考】
デジタル化の流行と「上流工程」の終焉 - ブロックチェーン企業で働くエンジニアのブログ

業務に詳しいがプログラミングやインフラ基盤、クラウド、新しい技術に弱い、中年のコンサルは、上記の記事のような落とし穴に陥りそうな気がする。
なぜなら、既存の業務フローを元に、こういうシステムが必要だ、と要件や仕様を洗い出した、としても、全く異なる分野の新しい技術が既存の業務の問題を完全に解決してしまう可能性が、今はとても大きいから。

上記の記事では、工場での品質管理システムを伝統的なDOAで要件を固めてシステム開発するWF型開発に対し、AIで不良品を判別する品質判定ソフトウェアとAPIで抜本的に入れ替えることができる事例がある。
業務そのものがAI化できる場合、元々の業務フローもなくなるし、その業務に張り付いた社員も不要になってしまう。

こういう劇的な変化は普通はないように思えるが、昨今のコロナ禍でビジネスの前提条件が大きく変わってしまったことを考えると、おかしくはない。

従来の開発スタイルのように、じっくり要件定義をやって、開発費用を確定させて予算取りして、それから長期で開発していくやり方が今後も続くのか?
それとも、新しい技術が今までのやり方そのものを置き換えてしまい、その業務に張り付いた人もその知識も不要になるかもしれない。

上記の風景は5Fsの「代替品の脅威」を連想させる。
ライバルは、同じ業界の同業者ではなく、全く別の業界の参入者であって、あっという間に市場を飲み込んでしまうケースが今後増えるのではないか。

アジャイル開発も、小さなサイクルで安定してリリースできるプロセスだが、それだけでは足りない。
開発する対象のシステムがそもそも必要なのか?
システムの基盤を別の新しい技術で置き換えることはできないか?
業務そのものを別の新しい技術で置き換えることはできるか?
たぶんそれが仮説検証。

| | コメント (0)

統計学と機械学習の違いは、データの説明かデータの予測か

統計学と機械学習の違いについて、明確な回答があったのでメモ。
統計学は「データの説明」、機械学習は「データの予測」に目的がある。

【参考1】
統計学と機械学習はどう違いますか?一方にできてもう一方にできないことは何ですか? - Quora

「統計学と機械学習の違い」はどう論じたら良いのか - 渋谷駅前で働くデータサイエンティストのブログ

(引用開始)
記事中では「統計学は『説明』するためのもの、機械学習は『予測』するためのもの」という表現をしています。
(引用終了)

【参考2】
データ分析の事始め~統計学と機械学習の違い~ | 株式会社豆蔵

(引用開始)
統計学は「データの説明」に、機械学習は「データの予測」に重きを置いていると言えます。
この違いはデータ分析を行う側にとって大きな違いであり、使い方を間違ってしまうと、データから有用な知識を得られない可能性があります。
(引用終了)

【参考3】
「統計」と「機械学習」の違いの整理で多くの事業会社で「機械学習」が使えない理由が視えてきた! - Qiita

(引用開始)
「機械学習」は予測や判断は行うもののなぜそうなったのかは一般的にはブラックボックスだ。
「統計」で行う予測や判断は、なぜそういう結論になったのかの理由付けが重要になり(理由付けを行うための学問であり)、理由はホワイトボックスとなっている。

なぜ多くの事業会社が「機械学習のアプローチを使えない」のか?
要因の整理に力を入れることが目的の「統計」は社会科学の課題解決に向いており、「機械学習」は自然科学の予測やロボットでの自動処理に向いている。と、
(引用終了)

【参考4】
【図解】コレ1枚でわかる統計学と機械学習の関係:ITソリューション塾:オルタナティブ・ブログ

(引用開始)
「データを使って問題を解決する」という方法論において、「統計学」も「機械学習」も違いはありません。両者の違いは、方法論、すなわちアルゴリズムやテクノロジーにあるというよりも、その目的にあると言えるでしょう。

統計学は、データを「説明」することを目的としており、記述統計(descriptive statistics)と推測統計(inferential statistics)に分けることができます。
(中略)
一方、機械学習は、データから「予測」して、分類・識別・判断を最適におこなえるようにすることを目的としています。

予測とは、まだ分かっていない答えを知るためのモデル(推論モデル)をデータから作り、これをいまのデータに照らし合わせて、将来何が起こるのかを予測する、この対象をどのグループに分類するのが適切なのかを決める、いま目の前にあるのは何かを識別するなどを行います。つまり、データを与えれば、推論モデルに照らし合わせて、分類・識別・判断を自動化することを目指しています。
(引用終了)

【1】Pythonで機械学習や深層学習のプログラムを写経したり、真似て書いていると、まだ分かってないな、という気持ちになる。
その気持になった原因を探ってみると、データをモデル化して構造を見たいのか、データをモデル化して予測に使いたいのか、を混同しているような気がした。

たとえば、統計学とは~という中身の本は、データをモデル化して構造を見るためのアルゴリズムだけを紹介している。
だから、昨今の機械学習や深層学習ではどうなの?という疑問があった。

統計学は「データの説明」、機械学習は「データの予測」、という基準で使い分ければ、ちょっとは迷子になりにくいだろう。

【2】しかし、統計学でも、機械学習でも、利用シーンに応じてアルゴリズムを使い分ける必要があるが、アルゴリズムの数が膨大なので、どの場面にどのアルゴリズムが有効に利用できるのか、なかなか分からない。

現実世界では、データをモデル化した時、モデルの数は星の数ほどあるだろうから、それぞれのモデルに合った統計アルゴリズムも星の数ほどある。
それらを逐一覚えるような気は正直起きない。

scikit-learn「アルゴリズム・チートシート」のリンク: プログラマの思索

でも、何らかの基準は欲しい。
結局、それぞれの事象に対して、そのモデルに見合ったアルゴリズムを見つけては、新規性がある!と叫んで、どんどん発見していき、植物学や動物学みたいに、数多くのアルゴリズムという標本集めをやっているだけなのかだろうか?
この辺りはもうちょっと考えてみる。

| | コメント (0)

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

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

【参考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年3月 | トップページ | 2021年5月 »