~ my tech diary ~

ソフトウェア要求のためのビジュアルモデル を読んだ。 数年前の積読に目を通してみた。 この書籍は、RML(Requirements Modeling Language)（要求モデル）をどのように区分し、どう使えるかをまとめながら、要求をモデリングしていく手段を提供している。システム開発全体の中で、目標、人間、システム、データのそれぞれに焦点を当てながらモデリングする手段を整理している。様々な知見を有していると特別目新しいものは少ないが、それぞれに対して実際に例を提示しながら説明しているところがとても良いと感じた。 目標 システムのビジネス価値に対して、要求とフィーチャーに優先順位をつける ビジネス目標モデル 目標チェーン KPIモデル フィーチャーツリー 要求マッピングマトリクス 目標空間の境界を定める 人間 システムの利用者を、ビジネスモデルと目標とともに表現する 組織図 プロセスフロー ユースケース 役割権限マトリクス 人間空間の境界を定める システム ユーザインタフェースの外観、システムの相互作用やその振る舞いを表現する エコシステムマップ システムフロー ユーザインタフェースフロー 表示アクション応答モデル デシジョンテーブル デシジョンツリー システムインターフェーステーブル システム空間の境界を定める データ データのライフサイクルを表現し、様々なレポートとしてデータを使えるかを示す ビジネスデータダイアグラム データフローダイアグラム データディクショナリ 状態遷移表 状態遷移図 レポートテーブル データの空間の境界を定めるMore

ビヨンド ソフトウェア アーキテクチャをずいぶん前に積読にしていたので読んだ。 読む前はシステムアーキテクチャの話だと思っていたのだけれど、フタを開けるとソフトウェア開発に関する全般を扱っていた。単にシステム開発に限った話ではなく、ソフトウェア開発する対象や、マーケット、人といった様々な要素に対するアーキテクト、つまり様々な構造にまでその話の範囲を広げていた。 ソフトウェア開発と人の関わりから始まり、ソフトウェア開発とマネジメントの話(ここには、プロダクト開発におけるコンセプト提案などの重要なところも書かれていた)に入りながら、だんだんとシステムによっていく。作るシステムのマーケティングの話やテクニカルな話。もう少し進むと、ログやセキィリティ、リリース、変更管理なども取り扱う。 このように、ソフトウェア開発においてシステム自身の狭義のアーキテクチャではなく、全般を扱っている内容となっていた。 そういえば、私は大学なんかでプロジェクトマネジメントを少し学んだり、話を多く聞かせてもらったのだけれど、こういう全般的な話を受けたなーと思いながら読んでいた。社会人になって、経験も多少積んで、その上で読むと頭の中を整理したり、そういえばこれも必要だったなと思い出すことができた。 最後に。この本で印象的だったことは、品質保証という役割が度々出て来たことと、その活動の範囲の広さをちゃんと説明しているところだった。More

ZERO BUGS シリコンバレープログラマの教えを読んだ。 タイトルと、その副題の高品質なコードを書くための物語というところですね。 エッセイ形式なので、全体を通して、物語を楽しむように読んでいきました。 わかる、あるある、なるほどなーというようなところが色々あり面白かったです。 「すべてのエラーは、あなたが最後にプログラムを変更した場所から3行以内にある」 by Joe Armstrong の引用。 ドナルド・クヌースの、ソースコードがドキュメントになるような文芸的プログラミング(literate programming)に対する考え方。 トランザクション処理のACID(Atomic, Consistency, Isolation, Durability)への言及。 人月の神話と、小さなチームならどんな方法論も上手くいくという話。これは、プログラマが習熟すれば、自分自身を実質的に管理できるようになるから。 Linuxカーネルのコードスタイルにある、それぞれの関数のすることは1つのことだけという姿勢。それとそのコードたちがPolymorphism、オブジェクト、関数型プログラミング、メッセージパッシングの全てをCで実現していること。 OpenBSD開発における、1箇所の修正に対して全体を見直すという、局所と全体の繰り返しのループ。 Erlangのモジュール同士のメッセージパッシングの形が、アラン・ケイがオブジェクト指向で表現したかったアイディアの理想形の1つであるという話。 などなど。 私の専門は品質/テストにあたる分野ですが、そのような立場の人も様々な領域を学ぶ必要があるのと同様、こういう話も知ってもらいたいですね。 「ソフトウェア品質の重要性が広く理解され、もはやこの仕事を能力のないテスターにアウトソースできなく」だそうです RT ソフトウェア開発におけるソフトウェアテスト（2）–開発者とテスターの違い https://t.co/E3J0PeQs4q @zdnet_japanさんから — Tsuyoshi Yumoto (@yumotsuyo) June 4, 2017More

実践 日本人の英語を読んだ。 3作目。 ちょっとしたtipsとして読める点が良いですね。その中で、自身が出来ていること/いないことを確認しながら頭の中に印象付けることができている感じがします。 そういえば、so/very は同じ副詞として使えると思っていたのですが、違ったのですね。お恥ずかしい。 so…that… の形が必要で、感嘆詞などはこのthatが省略されているから類似用語として使うことができる。一方、この that… が使えないような文章の場合はsoではなくveryを使っていくべきという。例を見ていると、感覚的には正しく使えていたみたいですが、運が良かっただけぽい。 接続詞のつながりも。so, since/because, as, for, and 。因果関係の繋がりで、 so が強く、 and がよりカジュアルな弱い感じになるとか。 as/for は書き言葉のような強さがあるみたい。これらはあくまでも論理的関係性だけを指す模様。 普段、 and と since, so をよく使うなーと読んでいたのですが、所々、因果関係が弱い(必然性がない)のに so を使うところとかちらほらあった気がします。 and と since はそこまで外れた使い方はしていなかったぽい。最近。 あと、小技として紹介されていた副詞の位置、接続詞、分詞構文の使い方は感覚的にやっているところもあったけれど、色々と説明を読んで入るとこうする方が良いのかとか気づけてよかった。 色々と自分のケアが届いていないところだけれど、意味としては大事なところに気づかされるというのが良いですね。この本。 反射的に英語が出る、出すことができる語彙/文法はまだ限定的だけれど、それがスラスラ出るように継続して学んでいきたいですね。More