« 2021年2月 | トップページ | 2021年4月 »

2021年3月

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

会計システムにパターン言語の導入を試みた記事

会計システムにパターン言語の導入を試みた記事があったのでメモ。
関西IT宴会のメーリングリストでの議論の方が非常に参考になる。
記事とメーリングリストでの議論を理解した内容を書く。
浅はかな理解なので後で直す。

【参考】
事業報告と会計の分離 - 会計システムパタンランゲージ

akipiiさんはTwitterを使っています 「会計システムにパターン言語を適用する野心的な試み。確かに一般業務である情報流と会計業務である商流は、要件定義でも明確に分けるのが普通なので共感できる。事業報告と会計の分離 - 会計システムパタンランゲージ https://t.co/AkBfaASNTV」 / Twitter

【1】杉本さんも渡辺さんも、事業管理システムと会計システムを分離しようとする。
しかし、その分離方針の考え方が微妙に異なる。

渡辺さんの考え方では、「データモデル大全」のように、企業システムの論理構造は、事業管理システム・財務管理システム・会計システムなどのように分けられる。

事業管理システムは、受発注や在庫管理、売掛金・買掛金の管理などが含まれる。
財務管理システムは、ファイナンシャルや資産管理。
会計システムは、事業管理や財務管理などのシステムと連携し、その仕訳を取り込んで、BS・PLを出力したり、その会社特有の管理会計を行う。

個人的には、渡辺さんの分離方針はすんなり理解できる。
物流、情報流とお金の流れである商流を、システム上分離して、連携させる考えは、プログラミングの分割統治に似ている。

一方、杉本さんの考えでは、簿記の歴史を踏まえた観点を付け加える。
元々、中世イタリアの商人が海外貿易で得た利益を、出資者に分配する仕組みとして簿記が生まれた。
そこでは、事業報告が主体であり、事業報告に会計報告も含まれていた。

しかし、その後の歴史では、事業がどんどん複雑になるにつれて事業報告も複雑になり、会計報告もBS・PLの正当性を示す財務報告の観点を強めたことにより、事業報告と会計報告は分離された。
つまり、事業報告としての会計報告と、制度会計としての会計報告は分離すべきだ、という意見。

僕の理解では、この分離方針は、売上や原価をどの時点で検収すべきか、という観点で分けられるのではないか、と思う。
たとえば、日々の事業で得られる売掛金や在庫、人件費は毎月検収すべきだが、建物やソフトウェア資産、証券などの固定資産は年1回、その評価額を踏まえて検収すればいい。

そういう考え方もあるのは参考になった。

【2】では、外部ベンダーへのソフトウェア開発の一括委託費用はどのように原価計上すべきか?
完成基準であれば、ベンダーがソフトウェアを納品して、その検収がOKであれば、検収した時点で一括計上する。
たぶん、メーカーのような普通の請負契約では当たり前。

しかし、完成基準では、検収まで原価が発生せず、検収時点で大金が原価計上されて初めて赤字が判明するリスクがある。
よって、進行基準を適用して、ベンダーの作業進捗に応じて毎月、原価計上して、その経緯を見れるようにする、とか。

【3】僕が知りたいのは、世の中にあるいろんなビジネスモデル、具体的には事業について、何らかの観点で分類して理解することはできないだろうか、という点。

製造業のビジネスモデルでは、生産プロセスを部品表の観点で分類することで、その特徴を明確に洗い出すことができる。
その考え方は、「BOM/部品表入門」に書かれていた。

BOMのトポロジー類型~MRPとBOMの関係: プログラマの思索

部品表と工程表と製造指示の関係: プログラマの思索

たとえば、部品を組立加工して最終製品(自動車、家電製品)を作るA型、1つの原材料(石油、食肉など)から多種多様な連産品が作られてしまうV型、最終段階の加工フェーズで多種多様な製品(化粧品、プラスチック製品)を作り出すT型、複数の原材料を化学反応させて製品を作るが副産物(酒粕、おから)が作られてしまうX型(化学、酒造業)、とか。

部品表と生産プロセスは密接に絡んでいるから、生産プロセスで作られる最終製品や副産物をどのように在庫管理や調達管理して販売するか、はビジネスモデルに直結する。

同様に、世の中の事業の主活動プロセスをバリューチェーン(生産プロセスと対比)とみなし、そのバリューチェーンを支えるデータ基盤(部品表と対比)を分類することで、あらゆるビジネスモデルを分類して、その特徴を見出して、理解を深めるやり方はないだろうか?

上記のようなパターン言語が、ビジネスモデルを分類する観点をもたらしてくれないか、期待している。

| | コメント (0)

2021/03/21

Ciscoルータ/Catalystコマンド一覧のリンク

Ciscoルータ/Catalystコマンド一覧のリンクをメモしておく。

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

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

シスコIOSコマンド一覧 | IT SKILL MAP

CISCO IOS COMMANDS

オンプレのサーバー構成や社内ネットワークを構築する時、結局、Ciscoルータ/Catalystコマンドを知っておかないと話にならない。
最近は、PacketTracerやGNS3上で、Ciscoコマンドを実際に叩いて動作確認を検証できるようになったので、本当に良くなった時代だと思う。

とはいえ、CCNAとは | 本当に役立つ資格、全く役立たない資格にも書いてある文章に、思わずうなずいてしまった。

(引用開始)
しかし、このルーターやスイッチ、高額であるのはもちろんですが、導入時の設定が非常に複雑です。単にケーブルで接続するだけではなく、専用のソフトウェアを使って細かな設定をしなければなりません。つながっている全てのパソコンについて設定します。
慣れない技術者が設定をすると、まず正常に動きません。ほんの少しのミスでもネットワーク全体が正常に機能しません。ベテランの技術者がおこなっても何か必ず不具合が生じます。ネットワーク技術者には高度な知識が求められます。
では、どうしてそんなに高度で複雑かというと、ルーターやスイッチとはいえ1つのコンピュータであるからです。何台ものパソコンを制御するコンピュータですから当然パソコン以上に高機能です。導入する会社によってその動作環境は全然違います。接続する機器の種類も台数もバラバラです。全てにおいて対応する必要があるので想像以上に複雑になります。
(引用終了)

たぶん、普通の大企業や大手SIであれば、自前のデータセンターを持っている所は多いと思うが、ネットワーク関係のトラブルは様々な理由でとにかく多い。
ケーブルを付け間違えた、誤って電源アダプタを外した、サーバーのディスクが壊れた、という初歩的な原因もあれば、大量のアクセスが集中してロードバランサーがさばききれなくなった、毎月末の一定のタイミングでファイアーウォールの通信量の負荷が高くなって遅延した、とか、原因が複雑な場合も多い。

3月末や4月初めのように、期末・期首では、組織変更で社員の座席移動だけでなく、なぜかサーバーの移動も発生して、そこでケーブルや電源アダプタを付け替える時に凡ミスしたり、とか。
アホだな、と傍から見れば思うけれど、ネットワークインフラは動いて当たり前であって、止まると大混乱して、カスタマーサポートがパンクする時もある。
そんなことを思ってしまった。


| | コメント (0)

「データモデル大全」は良い本だ

渡辺さんの本「データモデル大全」を読んだ。
いろんな気づきがあるので、ラフなメモ書き。

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

渡辺式データモデリングの復習: プログラマの思索

第39回IT勉強宴会の感想~花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談: プログラマの思索

第66回IT勉強宴会の感想~データモデリングに数多くの流派が発生している理由: プログラマの思索

関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング: プログラマの思索

【1】「データモデル大全」のデータモデリングは多分かなり高度なので一般でないと思うけど、後で、なるほどと気づく。

たとえば、動的参照関係で、複数のテーブルのビューがあれば、外部キーの参照関係が生じるが、普通のER図では表現できない。

たとえば、「データモデル大全」のデータモデリングでは、ツリー構造のモデルが特殊。
ヘッダーと明細のテーブル二つに親子階層を持たせて、親テーブルにLLCという階層最小値を持たせて、ツリー構造を表現する。
再帰構造ではない。
たぶんこのデータモデルであれば、PLSQLのバッチ処理が書きやすいのだろうと想像する。
他方、Redmine ならば、チケットの階層構造は、入れ子構造のデータモデルで実現できてる。
こっちの方がプログラマは書きやすいだろう。

【2】「データモデル大全」のデータモデリングで最も特徴的なのは、2次識別子を使って、参照関係や連関テーブルを表現してる事。
製品の入出荷履歴などの沢山のテーブルは、受払履歴テーブルに集約させるが、その時に、取引管理番号を各テーブルで2次識別子に持たせる。
そうすれば、最初はNull値でも、後からデータ更新できるので、一意制約を持たせられる。

データモデル大全」全では、他に、逆に、入出荷指示明細テーブルから受払予定、受払履歴、売上履歴などのテーブルへばらすモデルを作り、指示を出したら、売掛金の履歴や在庫の履歴が見れるテーブルを用意してる。
この辺りは本当にすごいなと思う。

【3】惜しむらくは、データモデルしか記載がないので、どんな業務フローになるのか、どんな画面遷移になるのか、が分かりにくい事。
せっかくなので、このデータモデルからRailsで画面を自動生成して、簡単な画面遷移が作れると良かったのに、と思う。
そうすれば、データモデルの威力が分かるはず。

たとえば、データモデルからイメージできるのは、注文ヘッダ・注文明細の親子関係タイプと注文明細・商品情報の参照関係タイプがあれば、それらは一つの帳票を表す。
よって、データモデルから、本質的な帳票がいくつあるのか、を見抜けば、帳票を保守する画面数やバッチ処理本数を算出できる。

たとえば、データモデルから時系列の順序を導くのは、T字型ERの考え方を使って、トランザクション系テーブル同士に参照関係があれば、1:Nの関係があるので、先トランザクションテーブル:後トランザクションテーブル=1:Nとみなすことで、導ける。
よって、時系列に帳票が作成される順序を考えれば、業務フローが描けるはず。

この辺りのイメージはまたまとめてみる。


| | コメント (0)

ノートパソコンが入ってUSBポートが付属しているビジネスリュックを買ってみた

最近、プライベートでも出勤でも、ノートPCを持ち運ぶ機会が多くなった。

在宅勤務がメインと言っても、ノートPCを持ち帰る機会が多い。
プライベートでも、家にいると在宅勤務の気分になって嫌なので、ノートPCを持ち出して気分転換に外出しているけど、自転車で移動しているから、割と億劫なんだよね。
車で移動したとしても、喫茶店やチェーン店、自宅に移動する時に何かしらのカバンは必要だからね。

今のリュックではノートPCの持ち運びが面倒だし、システム手帳や書類、財布、キーケース、マスクなど色々入れると、リュックが満杯になるので、新しいビジネスリュックを買ってみた。

最近のビジネスリュックはいいね。
ノートPCだけ別スペースに入れて固定できて、周囲の壁が固めに補強されているので、持ち運びしやすいように思っている。

面白い点は、USBポートがビジネスリュックの側面に付属していること。
なぜUSBポートはあるのだろうか?
どうやら、ビジネスリュックの内側にはモバイルバッテリーを入れて、外側のUSBポートからスマホへ接続して充電できる機能として使うらしい。
なるほど、リュックを背負って通勤電車や駅中を歩き回る時、スマホを持っているのは普通なので、そういう利用シーンで使うわけだ。
単に、ツイッターやフェイスブックを見るだけでなく、YoutubeやClubhouseを聞いたり、好きな音楽を聞いたり、色々使っているから。

他のビジネスリュックでは側面にUSBポートだけでなく、イヤホンジャックのポートまで付いているみたい。
なかなか面白い。

他の皆さんは、ノートPCの持ち運びしやすいカバンやリュックはどんなものを購入しているのか、気になる。


| | コメント (0)

Redmine 4.1.2がリリースされた

1年ぶりにRedmine 4.1.2がリリースされた。

Redmine 4.1.2 and 4.0.8 released - Redmine

コロナ禍のためだろうか、JPLが忙しいせいだろうか、RedmineのVerUpが直近1年間なかった。
もちろんRedmineは日々コミットされて、パッチは積み上げられているので、Redmineは生きている。
しかし、正式バージョンが定期的にリリースされないと、ソフトウェアは死んでいるように思われてしまう。

とにかくRedmineがリリースされて良かった。


| | コメント (0)

2021/03/19

ネットワーク技術の必要性が高まっている

下記の記事を読んで、共感したし、ネットワーク技術の必要性が高まっているような気がした。
浅はかな理解のメモ。

【参考】
いまクラウドよりオンプレを学ぶべき理由 - Yuichi Murata's Engineering Blog

(引用開始)
この問題を解決したのは、チームでは新参のエンジニアであった。彼はもともとネットワーク・エンジニアとしてのバックグラウンドを持っていた。彼は持ち前のネットワークの知識を活用しつつ、このクラウド・ベースのアプリケーションの問題を一つずつ紐解いていった。

(中略)
通信が途絶える可能性のある経路をたどり、全ての仮説を上げて一つずつ潰していく。一つずつ被疑箇所を修正し、リリースし、変化を計測する。 一つの問題を解決するとタイムアウトの発生件数ががくっと下がり、複合問題がそれぞれの問題に分解され、より効果的に問題分析を進めることができた。 アプリケーション・ログや業者への問い合わせのみに頼ることなく、システムの下回りで何が起きているのかを、一つ一つ丁寧に掘り下げていった。

クラウドやマネージド・サービスは重要である。便利である。これらはあなたのシステムが扱いやすいように全てを抽象化してくれる。

一方、仕組みが抽象化された世界では、問題すら抽象化されてしまう。
つまりそのままでは解決が難しいということだ。 だから、発生した問題をネットワークやオペレーティングシステムといった低次元のレベルまで掘り下げて分析をしていかなければいけない。
(引用終了)

現代のIT技術者であれば、アプリ開発者であれ、ネットワーク担当者であれ、クラウドの知識と理解は必須だろう。
しかし、クラウドで注意すべき点は、「仕組みが抽象化された世界では、問題すら抽象化されてしまう」ことだという指摘には、なるほどと思った。
つまり、ネットワーク機器やネットワーク構造そのものがソフトウェア化されてしまったために、手で触ってみたり、実際に動かしてみる、という操作がやりにくい面がある。

逆に、Cisico機器のネットワークの経験があれば、クラウド上でのネットワークのトラブルシューティングにもその知識を応用できる。
そういう話を聞くと、Linuxのカーネルレベルの理解、コンパイラの理解があれば、ソフトウェアの理解やプログラミングの理解が早いということと同じような気がした。

クラウドの出現によって、アプリ開発者もL7のアプリケーション層だけでなく、L2のイーサネット層やL3のネットワーク層の知識や技術を要求されるようになった。
同様に、ネットワーク担当者も、L2のイーサネット層やL3のネットワーク層だけでなく、SDNやその実装ツールの一つであるAnsibleなどにも精通する必要が出てきた。
結局、アプリ開発者もネットワーク担当者も以前より深い知識が要求されている。
もはや単に、オブジェクト指向プログラミングができますよ、だけでは物足りない。

そういう状況は自問しておく。

他に、下記の記事に、AWSのVPCとオンプレのネットワーク構造の対比が図示されていて、なるほど、とようやく気づいた。

コラム - 知っておきたい Amazon Web Services のキホン | 第2回 AWSの仮想データセンタ「VPC」を理解する|CTC教育サービス 研修/トレーニング

クラウド上では、ルータやスイッチが仮想化されたことで、設定画面に埋もれてしまって、見えなくなっているわけだ。
自分はまだまだAWSが分かってないので、色々試してみる。

| | コメント (0)

2021/03/12

プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んだ。
色々気づきがあったのでメモ。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」で気づきを得たことは3つある。

1つ目は、プロダクトオーナーはスクラムのチームとプロセスを外しても、スクラムに依存しない存在であり続けること。

この本では、いろんな観点や具体例から、プロダクトオーナーに必要とされる能力を描き出している。
プロダクトオーナーは、戦略に基づいてプロダクトの方向性を決めて、プロダクトを具体化する。
ただし、その実装方法まで関わらない。

2つ目は、悪いプロダクトマネージャーの典型例が面白いこと。

プロダクトマネージャーは、プロダクトのみにCEOではない。

ウェイターのように、ステークホルダーや顧客から何が欲しいのか注文を受け、開発リストを作るだけの人は、プロダクトマネージャーではない。
こういう人は、どうやって、優先順位を着けるべきか、という質問ばかりする。
それこそが彼の仕事なのに。

プロジェクトマネージャーの経験をたくさん持っている人が、その意識のままであっても、プロダクトマネージャーではない。
プロジェクトマネージャーは、いつ、という納期に責任を持つ。
プロダクトマネージャーは、なぜ、というプロダクトのビジョンに責任を持つ。
アジャイル開発では、プロジェクトマネージャーの責任はチームの中に分散され、管理責任そのものがメンバーに権限移譲されるので、プロジェクトマネージャーという存在はチーム内では不要になる。
プロジェクトマネージャーの経験が詳しくても、プロダクトマネージャーの仕事も役割も違うのだから、ビジネスや顧客、マーケット、組織を意識したマインドセットが必要になってくる。

3つ目は、SAFeを批判していること。

SAFeでは、プロダクトマネージャーはプロダクトオーナーのマネージャーであり、外部にいるユーザとの対話や管理に責任を持つ。
そして、プロダクトマネージャーは、プロダクトの要求やスコープを定義し、それをプロダクトオーナーに渡す。
SAFeのプロダクトオーナーは、内部に目を向けて、開発チームと一緒に、プロダクトバックログを作成して、その優先順位を決定することに注力する。

このやり方では、プロダクトオーナーはユーザーから切り離されて、顧客の問題を理解しようとしないから、効果的な解決策を提示できない。
プロダクトマネージャーからプロダクトオーナーへ、WF型開発のように、要求や要件が上から落ちてきて、それを詳細化していく役割に準じてしまう。
プロダクトオーナーは、そもそも、落ちてきた要件が本当に作るべきものなのか、検証することも許されていないからだ、と。

確かに、SAFeでは、複数のスクラムチームがアジャイルリリーストレインによって、リリース時期を同期させるように開発を進める。
そこでは、プロダクトオーナーもスクラムマスターも、アジャイルリリーストレインという満員電車の中に組み込まれていて、彼らが自発的に、自分たちが作っているもの自身を疑ったり、検証したりすることは推奨されていない。
そういう意味では、SAFeはトップダウン式の開発スタイルであり、スクラムの精神からズレている部分もあるのだろう。

スクラムを理解する時、プロダクトオーナーという役割は正直理解しにくいと思う。
スクラムマスターの役割は、アジャイル開発を進めていくと、そういうファシリテーターのような役割が必要になることは体験できる。
しかし、プロダクトオーナーの役割は、アジャイル開発以前に、顧客やマーケットの要求や組織のビジョンを元に、どんなグランドデザインを描いてプロダクトに落とし込むか、という別のスキルが要求されるので、難しいと感じる。
SAFeのプロダクトオーナーのように、上から滝のように落ちてきた要件を拾い集めて、優先順位付けすることが彼の役割ではないのだ。

プロダクトオーナーの役割が曖昧になりやすい理由は2つあると思う。
1つ目は、スクラムの誕生時には、スクラムマスターと開発チームは存在していたが、プロダクトオーナーが存在していなかった背景も絡んでいるのではないか。
実際、「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、サザーランドがスクラムを生み出した時、スクラムマスターと開発チームでアジャイルに開発を進めた経験があったが、その後の経緯から、プロダクトオーナーが生まれた、という文章があった。

2つ目は、市谷さん著作「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」の通り、高速にアジャイルに開発できることと、ユーザの価値を最大限に活かすような製品をリリースすることは別次元の話だから。
アジャイル開発プロセスを実践できるチームであっても、プロダクトのビジョンやプロダクトの方向性が間違っていれば、ゴミを高速に出しているのと同じ。
正しいものを作ることと正しく作ることは違うよ、と。

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

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察

以前から、インフラ基盤の知識を身に着けたいと思っていて、今更ながらCCNAの教科書や資料を読み始めている。
Cisco機器のコマンドにもだいぶ慣れてきた。

【1】ネットワーク技術の根本問題は一体何だろうか??

ネットワーク技術の問題に対して、印象は3つある。

【2】1つは、GNS3のエミュレータとかPacketTracerのシミュレータでもいいので、実際の知識やコマンドを試す環境が必要なこと。
ネットワーク技術を身につけることが割と難しい理由は、ルータやスイッチなどの実機を購入しないと実際に試せないからだ。
しかも、ルータ1個では意味がなくて、ルータやスイッチを5個、10個集めて、実際にSTPやOSPFを試せるようなネットワーク構造を作らないと、試せない。
つまり、個人でネットワーク技術を体験するには、コストも場所も必要になるので、壁が高い。

しかし、直近10年くらいで、GNS3のエミュレータとかPacketTracerのシミュレータによって、ルータやスイッチを仮想的に実現できるようになったおかげで、PC上で簡単にネットワークを作れるようになった。
すると、BGPとかEIGPレベルは難しいけれど、STPやOSPFレベルのネットワークなら、実際にCiscoのコマンドを叩いて試せる。

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

とはいえ、ネットワーク初心者にとって、この環境を整備するだけでも割と大変。
だが、JavaでもRubyでもPthonでも、開発環境を整備するのが大切で、実際にプログラムを動かして、初歩的なミスとか、本当に基礎の部分が理解できていない所を一つずつ試すのが大事なのと同じだな、と思う。

個人的には、GNS3のUIの方が好きだが、DHCPやNATの疎通確認ではVMを作るとか、無線LANの疎通確認では、無線アクセスポイントなどの実機を実際に接続する手間がかかる。
一方、PacketTracerはUIがあまりイケてないが、DHCPやNAT、疑似Webサーバー、IP電話、無線アクセスポイントの機能があるので疎通確認が簡単。
GNS3とPacketTracerを使い分けるのが良いのかもしれない。

【3】2つ目は、ネットワーク技術の根本的な問題は、性能を出すために最短経路をリアルタイムに一早く算出することと、障害が起きても代替ルートで常時接続できる冗長性・耐障害性の確保、というトレードオフ。
そのために、L2のSTPやL3のOSPFとか、いろんな技術で回避しようとしている。

過去の試行錯誤の歴史によって、Ciscoのルータやスイッチは、ものすごく複雑な仕様になったんだな、という印象を受けている。
たとえば、STPがVLANよりも先に仕様が作られたために、STPの仕様がすごく複雑になったイメージがある。

【4】3つ目は、セキュリティの機能がすごく豊富なこと。
ルータやスイッチを経由して数多くのデバイスが相互に通信できて、スケールアップも耐障害性も確保できる。
しかし、何でもかんでも、どんな通信でもOKというわけにはいかない。
内部ネットワークに不審者が入っては困るし、社内ネットワークでも部門ごとに情報アクセスを制限したい。
そのために、L3レベルでACLやAAA、VPN、L2レベルでポートセキュリティやVACL、Dynamic Arp Inspectionなどの数多くのセキュリティ機能が用意されている。
こういう機能を見ると、過去のセキュリティ事故やウイルスの経験から、歴史的経緯によって、どんどん機能追加されて複雑化したのだろうと推測する。

【5】最近のIT技術の流れを見ていると、クラウドの普及のために、アプリ開発者はL7層だけでなく、L2のデータリンク層やL3ネットワーク層までの知識が要求されるようになった。
実際、AWSの膨大なサービスや機能を見ると、L2・L3層のスイッチ・ルータを仮想化することで、ネットワークそのものを仮想化してしまって、クラウド上で簡単にスケールアップできるようになっている。

一方、Infrastructure as Codeの流れによって、インフラ担当者も、L2・L3層だけでなく、L7層などのより上位のアプリ層レベルが要求されるようになった。
実際、Ansible、Docker、VirtualBoxなどの仮想化技術では、シェルスクリプトの実装だけでなく、Pythonでのプログラミングまで要求される場合が多い。

つまり、アプリ開発者もインフラ担当者も、クラウドが当たり前の現時点では、プログラミングもネットワークも両方の知識と技術、経験が要求されている。
さらに、機械学習やディープラーニングの急速な発展とクラウド上でのマシーンラーニング基盤の実装が簡単になったから、これらの知識や経験も要求されてきている。
個人的には、直近3年ぐらいで、急激にIT技術の環境が変わってしまったように感じている。

【6】昨今のコロナ禍によって、仕事も人付き合いもビジネスもオンライン化されてしまった。
今後は、ビジネスも仕事もAIでどんどん代替されていくだろう。
そして、中間層の仕事は不要となり、IT技術に関する高度な専門知識を持つ知的労働者と、対面でベタベタに人と関係するしか作業できない仕事、たとえば医療系や食事提供、観光などの、労働集約的な効率の低いサービス業の労働者に二分化されていくだろう。
つまり、社会がどんどん二極化していくのではないだろうか。

そういう時代の流れとIT技術の流れについて、色々考えていく。

| | コメント (0)

2021/03/04

GNS3の利用事例

GNS3を入れると、CiscoのIOSをPC上でほぼ完全にエミュレートできる。
そういう事例があったのでメモ。

【参考】
GNS3 でバックエンド開発を便利に(前編) - Qiita

GNS3 でバックエンド開発を便利に(後編) - Qiita

CentOS8 へのGNS3 インストール手順 - Qiita

今でも、会社のオンプレのインフラ構築、社内LANの構築では、Cisco機器を使う場合も多いのではないか。
やはり信頼性とか今後の運用を考えると、高額だがCisco機器を購入する場合は多い。

また、Cisco機器のルータやスイッチを自由自在に扱えるようになると、ネットワーク設計の知識も経験も十分に増える。
たとえクラウド化が進んだとしても、ネットワーク設計の基礎知識は必要。
Cisco機器を触ることができれば、色々理解できる内容も多い。

しかし、Cisco機器はとても高額なので個人で扱える代物ではない。
ヤオフクの中古品もあるらしいが、ルータやスイッチを5個以上揃えるとか、UTPケーブルやらラックを揃えるとなると、それなりにお金も労力もかかる。

そこで、GNS3をインストールできれば、IOSをほぼ完全にエミュレートできる。
上記の利用事例では、GNS3でネットワークそのものをエミュレートして、その先に現物のオンプレサーバー、Docker、VMにつないでいるらしい。
これはすごいし、面白いな、と思う。

ただし、GNS3で利用するIOSはなかなか手に入りにくい点は注意。
代わりに、PacketTracerでシミュレートする方法もある。

個人的には、PacketTracerよりもGNS3の方がGUIが直感的だし、TeraTermが使えるので好き。

「GNS3によるネットワーク演習ガイド-――CCENT-CCNA-CCNPに役立つラボの構築と実践」のサンプルに沿って、GNS3でネットワーク図を自分で描いて、実際にルータやスイッチを動かすのが楽しい。
なかなか現物に触らせてもらえないからね。

サポートページ:GNS3によるネットワーク演習ガイド ―CCENT/CCNA/CCNPに役立つラボの構築と実践:|技術評論社

| | コメント (0)

2021/03/02

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

今夜、ガバテックの話をZoomで聞いていた。
話は面白かったが、色々考えさられた。
考えたことをラフなメモ書き。

【参考】
経済産業省デジタル化推進マネージャーと弁護士ドットコムが語る!行政にエンジニアが関わる意義 - connpass

【1】政府行政をエンジニアが関わって、DXを推進していくのがガバテックと言えるかもしれない。
パネラーが言うように、今まさに旬のテーマ。
デジタル庁ができるし、ITエンジニアがより政治に関わっていくこともできる。

パネラーは、エンジニアリングで社会実装を変えていく、と言っていたが、話を聞いていたら、僕は「プログラマとスクラムが社会実装を変えていく」という意見を持った。

理由は2つある。

【1-1】1つ目は、プログラマが政府行政のIT化で活躍できる場がすごく多く、昔から受け継がれる問題、今まさに直面している問題に対し、プログラマしか解決できないテーマが多すぎるから。

たとえば、コロナワクチン接種管理システムの構築もそうだし、コロナ不況で失業したり、緊急事態宣言でビジネスを制限された人達に補助金を出すシステムもそう。
こういうシステムが必要とされているのに、インフラ構築できない、Webシステムを構築できない、業務要件をデータモデリングでまとめられない状況にある。
政府行政にいる人達は、ITの専門家ではないのだから、そういう技術に詳しくないのは当然だ。
だからこそ、ITエンジニアがより深く関わるチャンスがあるし、それによって、社会を変革していく道筋も生まれる。

ハンコ押印を使った各種申請、税金の支払いが楽になるだけでなく、より積極的に、ITという手段を通じて、政府を通じて世の中をより良くしていく、という活動にコミットできるわけだ。

【1-2】2つ目は、プログラマが政府行政のIT化に関わっていく場合、組織体制はスクラムに即した体制にならざるを得ない印象を持ったから。
パネラーが言うには、政府行政で、パネラーに協力してくれる人達は、事実上、プロダクトオーナーの役割を担ったり、色んな部署と調整したり、逆にパネラーのようなITエンジニアを守ってくれるような活動をしてくれたらしい。
パネラーのようなITエンジニアと政府行政の人達の間に信頼関係が構築できたことで、より深くコミットすることもできた、と。

そういう話を聞くと、まさに、そういう組織体制はスクラムで実装することになるだろう、と思う。
なぜならば、スクラムを適用すれば、スクラムの3つの役割にピッタリ当てはまるからだ。

【1-3】国民の公共サービスの利便性を提供するようなサービスを提供するケースを考えよう。
すると、そのような業務要件を考えるプロダクトオーナーが必要であり、政府行政の業務や法律に詳しい、政府行政の人達自身が担当する。
インフラを構築したり、システムを実装したり、セキュリティ対策を考える人達は、各分野のITエンジニアがチームを形成する。
そして、外部から雇い入れたスクラムマスター、または政府行政の人でファシリテーションが上手い人が、プロダクトオーナーとチームの間で調整する役割を担うだろう。
結局、そのようなプロジェクトチームをシステム毎にたくさん作り、スピード感を持って政府行政のDXを推進していくしかないだろう。

【2】しかし、政府行政のDX推進を妨害する問題は、内製開発できずにベンダーに発注してベンダーロックインになってしまうことだろう。

現状は、政府行政の中の人達が、ITプロジェクトをマネジメントする能力が不足しているし、発注者として、プロダクトオーナーの役割を果たす能力も不足している。

【2-1】本来のあるべき姿は、政府内部で公共サービスを提供するシステムは、全部自前で開発できると一番いい。
リリース後も常に保守する責任を持つし、サービス利用者の声を集めることで、次々に新たなサービスを提供して利便性を高めて、世の中をより良くしていくことができるはずだ。

そういう内製開発が政府内で実現したならば、SaaSベースの開発スタイルになるだろう。
文字通り、ソフトウェアでサービスを提供するわけだ。
理由は、「ソフトウェア・ファースト」の本に書いてある通りと全く同じ。

そして、そのシステム開発のプロセスはスクラムで行われるのが自然だ。
政府行政内の人がプロダクトオーナーを担当し、その業務要件がプロダクトバックログで表現され、サービス利用者が使いやすいように、業務フローやデザインは、ストーリーテリングのように数々の利用ストーリーを踏まえたもので作られるだろう。

【2-2】しかし、現状はギャップが大きすぎる。
パネラーも言っていたように、いきなりデジタル庁で解決するわけではないだろう。
おそらくは、デジタル庁のメンバーは発注者のプロジェクトマネージャーの立場がまず求められて、そういう仕事から現状の問題をこなしながら、今後のあるべき姿へ地道に変革していくことになるのではないか。

【3】しかし、政府行政のIT化の根本問題は、個人のプライバシーとどのように折り合いをつけるべきなのか、があると思う。

【3-1】実際、確定申告のWebシステムであれ、コロナ接触管理アプリCocoaであれ、国民全員に10万円をばらまいた補助金であれ、全て、国民1人が持つプライバシーをどのように扱えばいいのか、に苦慮している。

そもそも、中国のような監視社会であれば、個人の行動履歴、購買履歴、所得や資産情報、医療情報も全て、政府が把握できているのだから、本当に困っている人達に特定して補助金を配ることもできるし、特定した感染者を強制隔離することで、世間の人達の健康を守ることもできる。

だが、政府の公共サービスでは、個人のプライバシーが他人に悪用されるリスクや脅威がとても影響が大きいために、セキュリティ面の対応によって、機能は複雑化し、業務フローもとてもややこしくならざるを得ない。
たとえば、確定申告のeTAXは、なぜあんなに、スマホでもPCでも使いにくいのか、とみんな思っているのではないか。

しかし、過去の歴史を踏まえると、政府に個人情報を預けると何をされるか分からないという、命に関わる危険性をみんなが持っていたし、政府を信用していないから、プライバシー保護という名目で、今までこの問題を放置してきた。

コロナ感染という特別な状況が、その問題が自分たちの生活に直結するぐらい重要である、と分かってきたのではないか。

【3-2】一方、今回のコロナ不況で薄々分かったことは、我々自身も、政府の行動が信用できるならば、自分の個人情報を預けてもいい、と考えているのではないか。

実際、現在の政府の公共サービスは全て申請主義なので、サービスを受けたければ、自分たちからたくさんの書類を集めて、大量の文書を書いて、提出後は長く待たないといけない。
本当に困っている人達に、給付金を直接渡すべきなのに、政府から困っている人達を特定できないから届けることもできない。
よって、失業者が溢れたり、犯罪者や自殺者も増えたりして、社会自体が重苦しく、不便なものになっていく。

だからこそ、そうならないように、例えば、本当に困っている人達に給付金を配ったり、あるいは、コロナワクチンを接種すべき人達を政府自身が特定すべきだし、それらを一括管理できるようにすべきだろう。

【3-3】他方、プライバシー保護のグレーゾーンや法律のグレーゾーンに積極的にリスクを取って関わっていくことで、新しいビジネスを生み出すことの重要性も分かってきたのではないか。

たとえば、テスラは電気自動車を単に提供するだけでなく、販売した電気自動車の走行ログをもとに自動運転技術をより強化させている。
また、走行ログというビッグデータをもとに、自動車損害保険ビジネスに乗り出す、とか、Uberのような配達ビジネスに自動運転をミックスしたビジネスも生まれるだろう。

アップルも、アップルウォッチを提供することで、個人の健康情報を収集することで、ヘルステックという新たなビジネスを生み出そうとしている。
個人の健康情報のログをもとに、医療サービスや保険サービスの新たなビジネスが生まれるし、健康に関わるスポーツビジネスも生まれるかもしれない。

【3-4】つまり、個人情報の保護がグレーゾーンであっても、それに関するビジネスにソフトウェアが決定的に重要な役割を果たし、大きく社会を変えている状況では、この流れに乗り遅れると、もはや国自体が衰退するしか無い。
実際、コロナ感染の社会状況において、日本の大臣は、日本はデジタル敗戦だ、という発言もした。
すなわち、日本はソフトウェアでビジネスを変革するだけでなく、ソフトウェアで公共サービスや社会を変革していくことすらも、他国から大きく遅れてしまった。

米国は、多くのベンチャー企業などが法律のグレーゾーンをものともせずに、ソフトウェアで新たなビジネスを生み出した。
中国は、一党独裁の統制社会を維持するために、ソフトウェアを上手く利用して、インターネット規制やネット検閲、監視カメラなどによる監視体制などを利用してきた。
もちろん、BATのようなIT大企業も生み出しているが。

EUもプライバシー保護や民主主義を掲げてGPDRとか色々作ってきているが、結局、米国や中国のソフトウェアビジネスやソフトウェアの変革の波から乗り遅れているのではないか。

【3-5】そんなことを考えると、プライバシーはもちろん重要だが、各種申請や税金支払、補助金受け渡しのような公共サービスの利便性を求めたり、コロナ感染のように公共性を重視すべき場面では、ある程度のプライバシーは政府に委ねる方向性に今後進んでいくような気がしている。

| | コメント (0)

« 2021年2月 | トップページ | 2021年4月 »