ソフトウェア工学

2021/05/08

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

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

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

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

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

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

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

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

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

| | コメント (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

テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #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/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)

ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある

日曜にTwitterルームで聞いた、中嶋聡さんの話が面白かった。
ラフなメモ。

ソフトウェア開発は、人数が増えると失敗する。
優れたソフトウェアは1人の優れたプログラマから生まれる、と。

人月の神話を思い出す。
炎上したプロジェクトに人を追加すれば、さらに納期は遅れてしまう。

コンウェイの法則を思い出す。
チームメンバーが増えるほど、ソフトウェア開発はどんどん複雑になっていく。
システムのアーキテクチャは、組織構造の壁を反映する。

平鍋さんは、ソフトウェアとはコミュニケーションウェアだ、と言われた。
コミュニケーションパスの複雑さは、仕様の伝言ゲームを生み出し、ソフトウェアを複雑にさせる。

モデレータの女性からは、別の話で、Teamsは使いづらい、Zoomの方が使いやすい、マイクロソフトは面白くないね、と話をしていた。
Teamsでは、組織やチームごとのコミュニケーション管理の機能があるが、組織に属していない人にとっては入りにくいので使いづらいらしい。
僕は、Teamsに慣れてしまったので、便利に感じる。
Teamsであれば、チャットとテレビ会議の両方が使えるし、チャットもログに残る。
Zoomは使いやすいが、ログが消えてしまう。
Slackも便利だが、テレビ会議の機能がないのが惜しい。

| | コメント (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)

2021/03/11

信頼度成長曲線はなぜS字型曲線になるのか

信頼度成長曲線はなぜS字型曲線になるのか、について色々調べてみた。
以下、考えたことをラフなメモ書き。

【参考】
バグの成長曲線(ソフトウェア信頼度成長モデル)の係数の意味 - ウィリアムのいたずらの開発?日記

ソフトウェア信頼度成長モデルに基づく最適リリース問題 山田 茂

信頼度成長曲線の落とし穴: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

信頼度成長曲線の書籍を図書館で借りまくったら、80~90年代の本がとても多い。
ソフトウェア品質保証の考え方と実際―オープン化時代に向けての体系的アプローチ」も読んだが、内容は相当古い。
おそらく、信頼度成長曲線の理論は既に枯れた話なのだろう。
実際、2010年代に発行された本は、「ソフトウェア信頼性の基礎 -モデリングアプローチ-」ぐらいしかない。
色々探したら、「演習で学ぶソフトウェアメトリクスの基礎」が分かりやすかった。

【1】信頼度成長曲線はなぜS字型曲線になるのか?
指数型曲線にはならないのか?
なぜ、ゴンペルツ曲線を採用するのか?

S字型モデル、ゴンペルツ曲線を採用する場合は前提条件がある。
それは、欠陥発見率の時系列グラフでは、欠陥発見率が放物線を描くと仮定しているから。
バグ発見率は、最初はゆっくりと上昇し、最高点に達して、その後は下降してゼロに近づく。

たとえば、最初はテストするほどバグはよく見つかるし、バグをどんどん修正して解決できるので、バグ発見率は高くなる。
しかし、じきにバグはある程度摘み取られて、簡単に見つかるようなバグはなくなり、解決が難しいバグとか、非常に稀なケースでしか発生しないようなバグだけが残るので、バグを見つけにくくなる。
つまり、バグ発見率は小さくなる。

このケースでは、テスト担当者の能力は経験曲線を仮定しているように思える。
つまり、テストするほど、テスト環境やテスト手順そのものに慣れたり、このあたりにバグがあるだろうと当たりをつけたりするので、当初はテスト効率は上がっていく。
しかし、残存バグが減っていくと、難易度が高いバグしか残らないので、テスト担当者がいくら成長しても、バグ発見は頭打ちになるわけだ。

一方、指数型曲線では、欠陥発見率の時系列グラフは、逆比例、または双曲線のように寝る形を仮定している。
つまり、バグ発見率は、テスト開始直後が最も高く、テストするほど減っていき、ゼロに近づく。

このケースでは、テスト担当者はテスト対象のシステムを知り尽くしていたり、テスト担当者の能力が高いので、当初はテストでどんどんバグ出ししていく。
しかし、残存バグが減っていくと、逆比例するようにバグは発見できなくなっていく。

よって、S字型曲線を仮定する場合は、テスト担当者の成長を見込んでいる前提があると考える。
一方、指数型曲線を仮定する場合は、テスト対象システムを知り尽くしている、とか、テスト担当者の習熟度が高い、など、テストが順調に進む場合を前提していると考える。

【2】信頼度成長曲線は、なぜ収束するのか?
なぜ、バグは収束すると言えるのか?
バグはテストするほど発散するケースは考えていないのか?

信頼度成長曲線はそもそも、製造業における大量生産した製品の品質管理技法をソフトウェアに流用したものだ。
よって、大量生産製品の品質が部溜まりに達するはず、という前提を引きずっている。

信頼度成長曲線では、バグが収束する理由には前提をおいている。
よく知られている根拠は2つあると思う。

1つは、用意したテストケースを全て実施したら、そのテストケースを何度繰り返しても、バグは見つからないから、というもの。
結合テスト、システムテストで用意したテストケースを準備したら、そのテストケース数は確定している。
すると、そのテストケースを1回転やりきったら、2回目を繰り返しても、バグ修正でデグレードが起きない限り、バグは見つからないはずだ。

もう一つは、テストしてバグ修正していくうちに、残存バグが減っていくので、発見できるバグは相当減ってしまうから、というもの。
これは当たり前。

【3】信頼度成長曲線には前提条件がある。
テストケースの粒度は均一であり、品質が良いこと。
各テストケースで発見できるバグの確率は、基本は均一であること。

しかし、バグはシステムの機能にまんべんなくばらまかれている、ということまでは前提にしない。
バグの発生場所は、特定の機能に集中しているかもしれない、という状況は認める。
そうでなければ、信頼度成長曲線はS字型曲線ではなく、時系列に直線グラフになってしまうから。

| | コメント (0)

一括請負契約はソフトウェア開発にやっぱり向いていない

一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。
理由は2つある。

【参考】
ERPの落とし穴part4~システム移行という名のデスマーチ: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。
結局、発注者に全てリスクで跳ね返ってくる。

発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。
民法の請負契約では、受託側は成果物の完成責任があるからだ。
しかし、その契約スタイルはソフトウェア開発になじまない。

たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが最後、発注側は外部ベンダーに作業指示を出すことはできない。
請負契約では、そもそも発注側が請負側に直接指示を出したり、管理したりすることを禁止しているからだ。
つまり、発注者がベンダーの作業の進捗管理を行うことは、契約上できない。

すると、発注者はベンダーに完全にお任せ状態になってしまい、ベンダーの進捗報告すらなければ、最後に、ベンダーから、納期が遅れてしまいます、と言われて慌ててしまう、みたいなケースが頻発しやすい。
納期が遅れたからと言って、成果物責任をベンダーに求めても、未完成で動かないシステムを納品されても困るわけで、発注者もベンダーもお互いに揉めるだけ。
せいぜい、紳士協定で、ベンダーさんに、進捗報告は定期的にしてね、と言うのが関の山。

つまり、一括請負契約で、ベンダー側にリスク転嫁しているつもりでも、発注者に全てリスクで跳ね返ってくる。

【2】もう一つは、品質を高めるインセンティブが働かないこと。

昔の製造業では、発注者側の大企業と下請けの中小企業で一括請負契約があったとしても、大企業側から優秀な技術者や管理者を下請け企業に派遣して、下請け企業の部品製造の品質管理や進捗管理を行う事例はよくあったらしい。
たぶん、大企業側は、自社製品のサプラチェーンを維持すること、サプライチェーン上の品質管理や進捗管理は自社で守るべき、という意識が強かったのだろう。
一方、下請け企業も、大企業の技術者から技術力や品質管理力を継承したり、大企業の管理者に進捗管理を委ねることで、自分たちは製造に専念できる、というメリットもあったのだろう。
つまり、製造業では、元請けと下請けという多重請負構造があったとしても、品質を高めるインセンティブが双方にあった、と思われる。

しかし、ソフトウェア開発では、発注者は外部ベンダーにベンダーロックインされて、ベンダーの言いなりになってしまう。

たとえば、ベンダーに委託して作らせたソフトウェアを、発注者自身で保守することは事実上難しい。
そもそも、発注者側では、情報システム部門に管理能力がない、とか、そもそもソフトウェア開発能力がない場合が多い。
発注者側に開発チームがいれば、まだ可能かもしれないが、他の会社が書いたソースを自分たちで保守するのは、非常に面倒なことは誰でも分かる。
結局、システムを作らせたベンダーにそのまま運用保守をお願いするしかないし、費用を値切らせたとしても、本番障害が出たとしたら、結局、費用を支払うしかない。

すると、そのシステムがビジネス上重要な役割を保つ場合であれば、ベンダーに依存してしまうしかない。
そして、ズルズルと保守を依頼するうちに、システムの減価償却が終わっても、リプレースするまでに、保守コストは膨れ上がってしまって、誰もその金額に手を出せなくなる。
ベンダー自身もそのシステムがブラックボックス化してしまっていることもよく知っている。
リプレースする時は、最初の初期投資額よりも倍の費用がかかってしまうこともザラではない。
また、リプレースという案件は、たいていソフトウェア開発案件として失敗しやすいことは昔から言われている。

ベンダー側としては、システムを納品してしまえば、そのシステムは発注者にとってブラックボックスであり、触らぬ神に祟りなしみたいな状態になるから、発注者がたとえ高飛車な態度を取っていても、困ることは知っている。
だから、ベンダーもそこそこの品質で納品してしまえばいい、みたいな結果に落ち着く。

発注者側も、複数のベンダーに相見積もりさせたり、コンペさせたりして、ベンダーロックインのリスクを回避しようとするが、他人が書いたソースを自分たちが保守したくはないし、リプレース案件が火を噴くことは誰でも知っているから、よほどのことがない限り、自分たちから火中の栗を拾うようなことはしない。
結局、ベンダーロックインになれば、発注者はリスク転嫁できていないことになる。

【3】こんな事を考えていたのは、ベンダーに一括請負で委託した案件では、経営陣からプロジェクトの進捗報告を求められた時、定量的なデータで報告する手段が結局無いからだ。
普通は、EVMを使って工数ベースで管理したり、発生原価を進行基準で計上するなどしてコスト管理するのだろうが、一括請負の作業が含まれると途端に、事実上は運用が難しくなる。

なぜなら、請負契約上、ベンダーに作業の計画工数や実績工数の報告を求めることはナンセンスだし、ベンダーに直接指示を出すような、ベンダー作業の進捗管理を行うことは禁止されている。
プロジェクトの原価計算を進行基準で運用したとしても、ベンダーから定期的に報告される進捗率をそのまま受け入れるしか無い。
その進捗率は普通はかさ上げされている場合が多いので、受け入れ検収したら、納品物の品質がすごく悪くて、そもそも使えない、だから、検収費用はすぐに支払えません、みたいなこともよくありがち。

本来は、ベンダーの現場に直接出向いて、現場にいる開発者の能力やモラールなどを感じ取ったり、ベンダーのプロジェクトリーダーから報告された進捗内容が本当に正しいのか、見極めたい。
しかし、請負契約だから結局できない。

【4】そんなことを考えると、一括請負契約は製造業のビジネスモデルに向いた契約スタイルであって、ソフトウェア開発には向いていないな、と改めて思う。

結局、ソフトウェア開発はたとえユーザ企業であっても、自社で内製開発するか、自分たちでソフトウェア開発案件をマネジメントできる能力を持っているか、というレベルが求められるのだろう。

アジャイル開発、そしてスクラムが注目されているのは、そういう古いソフトウェア開発のビジネスモデルではなく、内製開発を中心としたSaaSのようなビジネスモデルにとても向いているからだろう。

自分は、受託側で一括請負契約の案件で苦い経験がよくあったが、発注側でも一括請負契約の案件は、正直ベンダーコントロールすらできていない現場がほとんどなんだな、と改めて感じた。




| | コメント (0)

より以前の記事一覧