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

2021年4月

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月 | トップページ