⇧ Rust導入はセキュリティ的な脆弱性を回避するためなんかな？
というのも、最近、参加したRustのイベントで、コンパイルが遅いって話を聞いたのと、ネット上の情報でも、
⇧ コンパイル遅いって話があったので、少なくとも、開発スピードを上げるような目的での導入では無いのかなと。
ちなみに、
⇧ 2016年頃より前は、さらに遅かったということなんかね？
By the way、Androidでも、
GoogleがAndroidに使用しているほかのメモリー安全性を備えた言語には、JavaやJava互換のKotlinがある。AOSPで主流の言語はまだCとC++だが、Android 13は、新しいコードの半分以上がメモリー安全性を備えた言語で書かれた最初のバージョンになった。
⇧ 脆弱性に対しての対応としてRustを導入してるらしい、というかJavaとか使われてる理由って、メモリー安全性のためだったんか。
Androidと言えば、
⇧ 10年にも及ぶ「Java著作権訴訟」がありましたけど、Androidの全ての機能をRustで代替できるのであるならば、将来的にAndroidからJVM言語が除かれる可能性もあるってことですかね。
ちなみに、
⇧ RustのWebフレームワークのリポジトリが突然、閉鎖された事件も影響してるのか分かりませんが、
⇧ Rust Foundationなる団体が設立されてるそうな。
Webフレームワークの開発を支援してくれるのかは分からんですが、突然、Webフレームワークが利用できなくなるというようなリスクは減ったのかな？
RustでのWeb開発とかも学習していかねばならなくなってくるんかね...
よく、時間は作るもの、って言う人いるけど、物理的に学習時間の捻出にも限界があるって話ですな...
設計書の作成に何を使うかのベストプラクティスは未だに定まらない模様
基本的に、設計書を書く時はMicrosoft ExcelやGoogleスプレッドシートのようなものを利用したことしかないのですが、ネットの情報だとExcelで設計書を書くことについて批判的な意見は多いものの、代替案を提示してくれている情報が少ないので、いまいち、設計書の作成に使用するツールとしてのベストプラクティスがハッキリせず、モヤモヤしてますと。
そんな中、
⇧ 厚生労働省が管理してるシステムで、Microsoft Office（Word、Excel）で作成された基本設計書を、別の設計ツールに移行したいって話をネット上で見つけたのだけど、受注先は決まったのかな？
どうやら、
⇧ 日立製作所さんが落札したとありますな。
とりあえず、日立製作所さんが、要求・要件定義だけ担当して、他の作業を「SES（System Engineering Service）」に発注するのか、開発の全ての工程を別の「SIer（System Integrator）」に発注して丸投げするのかは分かりませんが、どういう結論（Microsoft Office系の代替となる設計ツール）を出すのか気になりますな。
それにしても、「公募」の「落札者」が調べにくい...検索しやすいようにしておいて欲しい...
ちなみに、
⇧ 上記サイト様にある説明を見てる感じだと、Excelであっても事前に共通認識とか噛み合っていれば、十分だと思うんですけどね。
2015年頃から、議論されてるネタではあるにも関わらず、これといって有効なExcel代替案は普及していないんかな？
2015年と言うと、まだ、IT業界に転職する前で異業種にいた頃だけど、日進月歩の感があるIT業界で、開発側の環境というのは課題が残り続けてる感じなんですかね？
あとは、Excel以外だとコスト面がネックになる気はしますかね。
設計書を作成するツールに対して、
- ツールの利用方法についての学習コストを許容してくれる
- ツールの利用にかかる月額コストを許容してくれる
ようなプロジェクトなのであれば、Excel以外のツールで設計書を作るのも大いにありだとは思いますけど、そういった予算を割いてくれるプロジェクトばかりでないと思いますし、そもそも汎用的でないところが辛いというのはありますかね。
別のプロジェクトでは、設計書の作成ツールにかけられてる予算が限られたり、そもそも予算は回せなくて、結局、別のツールを利用せざるを得ないってことになると、また学習コストかかりますし...
その点、ExcelであればVBAのようなマクロを組み込んだり、関数を多用したりしていない、といったような条件付きであれば、誰でも直感的に利用できるという意味では汎用性は高い気がしますかね。
Windows以外であれば、Excelの代替として、LibreOfficeのcalcを利用すれば良さそうですし。
Excelで設計書を作る場合でも、
- 基本的な共通ルールを決める
- 基本的なフォーマット（雛型）を決める
- 設計に落とし込む内容の認識合わせをする
- 変更履歴を付ける
- 図を用いる場合は凡例を付けて図の意味を説明する
- 分かり辛い点には注釈を付ける
- 参照する情報には参照先が分かる情報を載せる
など、最低限、気を付けるべきことはいろいろあると思いますけど、このあたりは、Excel以外で設計書を作成することになったとしても同様の話なのかなと。
バージョン管理には、
⇧ 工夫が必要そうですけど。
先にあった厚生労働省の公募の件で、
『現在の年金業務システムの基本設計書は、ドキュメント量が多く、OAソフト（Word、Excel）で作成されていることから、関連性が分かりづらく可読性が著しく低い。』
ってあるけど、そもそも、Microsoft Office（Word、Excel）以外のツールで作成したとしても同じことになる可能性は十分あるわけだし、そう考えると、初めに基本設計書という成果物の仕様を明確に定義するのが重要な気がしますけどね。
『銀の弾丸はない』、という言葉はよく言われますし、設計ツールを変更したとしても解決できる問題と解決できない問題はあるわけで、要求を要件に変換するところが重要になってくるってことですかね。
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』（ぎんのたまなどない ソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、英: No Silver Bullet - essence and accidents of software engineering）とは、フレデリック・ブルックスが1986年に著した、ソフトウェア工学の広く知られた論文である。
論文概要
原論文は英語である。日本語では『銀の弾丸はない』と、翻訳されることもある。ブルックスは、「銀の弾丸」（Silver Bullet）として、魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間（論文が著された1986年の時点から10年の間）は現れないだろう、と記載した。
⇧ 1986年から幾星霜、時代が変わっても、ソフトウェア開発から『銀の弾丸はない』という言葉は未だに消えていないのだね...
『銀の弾丸はない』という言葉をソフトウェア開発界隈に知らしめたフレデリック・ブルックス氏はと言うと、
フレデリック・フィリップス・ブルックス・ジュニア（Frederick Phillips Brooks, Jr. 、1931年4月19日 - 2022年11月17日）は、アメリカ合衆国のソフトウェア技術者で、計算機科学者である。IBM のメインフレームである System/360 およびそのオペレーティングシステム OS/360 の開発者として有名である。その過程を率直に描いた著書『人月の神話』と論文『銀の弾などない』は、ソフトウェア工学およびソフトウェアプロジェクト管理の世界で多くの人々に読まれ、大きな影響をあたえている。
それら著作も含め、コンピュータアーキテクチャ、オペレーティングシステム、ソフトウェア工学への貢献から、1995年にはアメリカ国家技術賞、1999年にはチューリング賞を受賞した。
バーチャルリアリティ技術に大きく貢献した人物でもある。
⇧ 2022年11月17日に鬼籍に入られてるそうな。
経歴と業績
2010年、WIRED誌のインタビュー記事で、「あなたの最大の技術的貢献は何だと思いますか?」と聞かれ、「私が行った最も重要だった決断は、1バイトを6ビットから8ビットに変更したことだ。それによって小文字が使えるようにした。この変更はあらゆる場所に伝播していった」と答えている。
⇧ と言うか、1byteを8bitにした人なのか。
晩年のブルックス氏が、現在のソフトウェア開発における『銀の弾丸』についてどのように考えていたのか知りたかったですな。
ちなみに、
「金で解決できることは、ある」
⇧ 上記サイト様によりますと、「銀の弾丸」は無いけど、お金の力である程度のことを解決することを「金の弾丸」という言葉で表現している人がおられました。
まぁ、お金はあるに越したことはないけど、多くの開発プロジェクトは予算に余裕が無いからして、お金の力を利用できないことが多そうよね...
ソフトウェア開発における設計については、AIとかの発展に期待するしかないんかな...
脱線しましたが、設計書を作成する際のベストプラクティスについて「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」が情報を公開してくれたら良いんですけどね。
ソフトウェア開発における一連の作業で発生し得る成果物についての作成方法のベストプラクティスとかについて、最新情報を反映した内容で情報発信を積極的にして欲しいですな。
Wikipediaによると、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
日本のソフトウェア分野における競争力の総合的な強化を図る。情報処理の促進に関する法律の一部を改正する法律（平成14年法律第144号）により、2004年（平成16年）1月5日に設立され、同法附則第2条第1項の規定により解散した、特別認可法人である情報処理振興事業協会（IPA）の業務等を承継した。
⇧ となっており、
『日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）』
と謳っているので。
一応、IPAのサイトで
⇧ 情報が公開されてるのだけど、時が止まってる感は否めない...
IPAが公開している設計書をダウンロードしてみましたけど、Excelを使ってるっぽいですね。
まぁ、上記でIPAが公開してる資料は、エンタープライズ系のシステム（業務システム）に閉じた話になってるのかもしれないので、何とも言えないのですが...
とりあえず、IT人材不足が声高に叫ばれてることもありますが、ここらでソフトウェア開発に対して標準となるようなものを再定義してもらいたいところですな。
多分、IT系の資格が意味ないって言われる大きな理由の1つは、こういった実際の現場の感覚とのミスマッチを考慮できていないところが大きいと思うので、旧い情報は更新していって欲しいですね...
IPAは、今一度、ソフトウェア開発の現場で必要とされる知識を整理し直した方が良い気はする。
ちなみに、デジタル庁が公開している情報で、
⇧「（参考）標準ガイドライン研修資料」なる資料には、特に成果物のファイル形式などは言及されておらず、必要な情報が揃っていれば良いというようなスタンスっぽいですね。
『冒頭でも説明しましたが、適用対象は「政府情報システム」です。』とあるので、限定的なシステムの話とは思うのですが。
それにしても、上記の資料ですが、「政府情報システム」の一覧とかが参照できる情報が無いのが辛いですな...まぁ、内輪（内部向け）の資料だから問題ないと言われればそれまでですけど、適用対象が分からん状態で説明受けるってモヤモヤしないのかね...
脱線しましたが、日本のソフトウェア開発での設計書の作成ツールのベストプラクティスとかは特にないというのが現状というところでしょうか。
脱線ついでに、
americanprojectmanagement.blogspot.com
⇧ 上記サイト様によりますと、海外だと、ソフトウェア開発の事情が異なるというのもありますが、もし、日本の一般的なソフトウェア開発とは異なる体制のプロジェクトに参画する機会がある時は、ゴール（成果物）の内容についての認識合わせはしておいた方が良さそうってことですかね。
それにしても、日本と他の国でのソフトウェア開発の成果物の違いとかは気になりますな。
あと、ソースコード読めば分かるから詳細設計書は不要って話も良く聞くけど、障害とか起きた時に対応する運用・保守については、考慮して無いってことになるんかな、だってソースコードを組んだ人が運用・保守してくれるとは限らないわけですし。
そう考えると、ソースコードを読めば分かるってのは結構無責任な感じに思えてきますな、まぁ、工数が無くて設計書まで手が回らないってこともあるあるなので設計書を作成できない時もあると思うけど...
なので、
『ソースコード読めば分かるから詳細設計書は不要』という発言は、正しくは、
『詳細設計書を作る時間が取れないので運用・保守の人に甘えさせてもらいます。ソースコードを読解する工数を運用・保守の方に負担させることになりますが何卒よろしくお願いいたします。』
と言っていることと変わらんってことになるってことですかね。
例えば、C#しか触れたことが無い人間がCOBOLのソースコードを読んで即座に理解できるとは思えんし、仮にいくつものプログラミング言語を詳細にマスターしている人間がいたとして、そんな人間は滅多にお目にかかれないと思うから、『ソースコードを読めば分かる』発言が如何に破綻しているか分かりそうなものなのだけど...
日本だけかもしれないですが、ただでさえ、IT人材不足と言われている中で、『ソースコードを読めば分かる』を達成できる確率は、高くならない気がするんだけどな...
運用・保守するシステムの寿命をどれぐらいと見積もっているのかに依りけりだとは思いますが、「開発」と「運用・保守」のどちらに負担させるかのトレードオフと言うことになってくるということですかね。
システムの運用・保守の期間が長期になることが予測できているのなら、将来、システムの面倒を担当することになるであろう人間の知識がハッキリしない以上、工数に余裕があるのであれば、未来の担当者のためにドキュメント化しておいた方が良い気はしますが...
使い捨てるようなシステムであれば、ドキュメント不要で良いかもしれませんけど。
何が言いたいかと言うと、IPAはソフトウェア開発の基本形となるような情報を整備し続けて欲しいってことですかね。
作ったら終わり、って良くないってことだと思いますし。
毎度モヤモヤ感が半端ない...
今回はこのへんで。
