“異文化理解力”を読んだ

異文化理解力を読んだ。

現在、新しいチームの立ち上げとして異文化の環境で活動を始めている。
その中で、単なるGitHubなどの上での活動ではなく、直接議論したり、対話したりする必要がある。

この書籍自体を信じるすぎることは、特定の文化などへのステレオタイプを生むことになったりとマイナスな面もある。そのため、こういう面もあるという一つの意見としてしる、に止めることが大事だと思う。そのため、そのことを考えながら読んでいた。

異文化を考えるときに考慮した方が良い指標として、以下をこの書籍では言及している。

  1. Communicating
  2. Evaluating
  3. Persuading
  4. Leading
  5. Deciding
  6. Trusting
  7. Disagreeing
  8. Scheduling

この中では、日本も多々出て来ていて、日本やアジア圏はハイコンテキストな文化というような、自分でも納得するような見解も述べられている。一方で、日本人でも自分の周辺は少し雰囲気が異なる面もいくつかあり、やはり1つの意見として触れる方が良いという感じ。

また、フィードバックを行うときなど、”ネガティブさ”を強調する、弱める言葉がある。フィードバックは大事だが、簡単に関係を壊したり、逆に意図が伝わらないことも多い。そのためこういう言葉を使いつつ、ちゃんと伝える/和らげることを覚えたい。

批判を和らげる言葉としては: kind of, sort of, a bit, maybe, slightlyなどがある。
批判を強める言葉としては: absolutely, totally, stronglyといったお馴染みの言葉が並ぶ。

多分化なチームはやはりコミュニケーションコストが増える。そのため、時間を節約したいのであれば文化の違いを抑える構成にする必要がある。一方で、イノベーションや創造性といったところを時間の節約以上に重視するのであれば文化の多様性を、プロセスをしっかりした上での取り入れると良い。

このような視点からも、この異文化というものは見て取れることができる。

信頼の形もいくつかあって、1. cognitive trust(認知的信頼) , 2. affective trust(感情的信頼)にも分けられる。

これは、前者はタスクのような認知されるものをベースにする一方、後者は関係性といった要素をベースにする。つまり、業績や技術といった確実性に対する確信に基づく信頼と、親密さや共感・友情といった感情から形成されるものに分けられる。

全体を通して、日本に関して言及しているものの中でも納得できるもの、できないものもあった。そのため、やはりステレオタイプではなく、全体としてこういう 多様さがある ことを認識する1つの意見と理解するのが良いのだと思えた。

英語で対話することが中心になるため、他者にも伝えることができるようにこの書籍の原書よりも少し新しい、英語の The Culture Map を読んでみようかと思っている。

[Kotlin]SoftAssertions with Kotlin and AssertJ

Hi there,

Do you know soft assertions provided by AssertJ?

In many cases, one test case has one assertion.
But sometimes we’d like to collect some assertions within one assertion, and then we can use SoftAssertions() for the purpose.

Of course, we can use AssertJ in JUnit. In addition, we can use it in Kotlin like the following.

SoftAssertions().apply {
  assertThat(1 + 1).isEqualTo(1)
  assertThat(1 + 3).isEqualTo(2)
  assertThat(1 + 1).isEqualTo(3)
}.assertAll()

So useful syntax 🙂

「The Art Of Software Testing 3rd Edition」を読んだ。

The Art Of Software Testing 3rd Editionを読んだ。

翻訳がされている2版との、大きく差分になっている箇所を主に。その主に増えていたのは、Agileの話とモバイルの話。3版であるこの本は、2011年に出ているので、モバイルが流行りだした前後になるのでしょうか。

Agileは、Agile Manifestoや、XPの話が紙面を割いていたことが印象的でした。モバイルは、Connectivity、Diversity Devices、Device Constraint、Input Devices、Installation and maintainceといった特性から入り、実機などの話や挑戦的なところの話が含まれていた。

いずれも、私個人の経験としてはずれていない話だったのですんなり読むことができた。これは、なるべくは特にテスト界隈に触れる人たちには読んで欲しいものの1つですね。

XPの話がこのソフトウェアテストの話にもでるように、やっぱり技能としてはプログラミング能力の必要性は高いのだろうな。

「ソフトウェア・グローバリゼーション入門」を読んだ

ソフトウェア・グローバリゼーション入門  I18NとL10Nを理解する を読んだ。

2017/07/11現在のものです。まだβ版らしいですね。

I18NやL10Nから入り、G11Nへ続く入門としてとてもまとまっていて良かったです。
断片的に知っていることも、知らないことも含めて学ぶことができました。

ゲーム業界でよく言われるカルチュライゼーションや、翻訳コンテンツの品質の話、質を向上させるために どのような情報・コンテキストの共有が必要か といったこと。
また、ある有名企業における L10N をどのように 開発プロセスに組み込んでいるか と行ったちょっとした例も。

そのほか、よく誤りやすい日付や時刻の話もちゃんと記載されていました。他には文化的なものや、慣習(数字の数え方とか…)。

翻訳の質を評価する方法としてのAccuracy、Fluency、Terminology、Style、Design、Locale convention、Verityや、 エラー評価の体系的な参考の存在 など。

こういう分野は世界を見ると避けては通れないところである上に、膨大な知見が必要になるはずなので、この手の方向性を持つエンジニアは今後重宝されるのではなかろうか…

Continuous Localization系の、モバイルアプリに関するものは現段階で見当たらないので、何か作りたいですね。作れるかな…実際、こうなると最高という形は思い描けていても、それを実現するための技術的な制約が大きすぎる…

「ソフトウェア要求のためのビジュアルモデル」を読んだ

ソフトウェア要求のためのビジュアルモデル を読んだ。

数年前の積読に目を通してみた。

この書籍は、RML(Requirements Modeling Language)(要求モデル)をどのように区分し、どう使えるかをまとめながら、要求をモデリングしていく手段を提供している。システム開発全体の中で、目標、人間、システム、データのそれぞれに焦点を当てながらモデリングする手段を整理している。様々な知見を有していると特別目新しいものは少ないが、それぞれに対して実際に例を提示しながら説明しているところがとても良いと感じた。

  • 目標
    • システムのビジネス価値に対して、要求とフィーチャーに優先順位をつける
      • ビジネス目標モデル
      • 目標チェーン
      • KPIモデル
      • フィーチャーツリー
      • 要求マッピングマトリクス
    • 目標空間の境界を定める
  • 人間
    • システムの利用者を、ビジネスモデルと目標とともに表現する
      • 組織図
      • プロセスフロー
      • ユースケース
      • 役割権限マトリクス
    • 人間空間の境界を定める
  • システム
    • ユーザインタフェースの外観、システムの相互作用やその振る舞いを表現する
      • エコシステムマップ
      • システムフロー
      • ユーザインタフェースフロー
      • 表示アクション応答モデル
      • デシジョンテーブル
      • デシジョンツリー
      • システムインターフェーステーブル
    • システム空間の境界を定める
  • データ
    • データのライフサイクルを表現し、様々なレポートとしてデータを使えるかを示す
      • ビジネスデータダイアグラム
      • データフローダイアグラム
      • データディクショナリ
      • 状態遷移表
      • 状態遷移図
      • レポートテーブル
    • データの空間の境界を定める

read “Beyond Software Architecture”

ビヨンド ソフトウェア アーキテクチャをずいぶん前に積読にしていたので読んだ。

読む前はシステムアーキテクチャの話だと思っていたのだけれど、フタを開けるとソフトウェア開発に関する全般を扱っていた。単にシステム開発に限った話ではなく、ソフトウェア開発する対象や、マーケット、人といった様々な要素に対するアーキテクト、つまり様々な構造にまでその話の範囲を広げていた。

ソフトウェア開発と人の関わりから始まり、ソフトウェア開発とマネジメントの話(ここには、プロダクト開発におけるコンセプト提案などの重要なところも書かれていた)に入りながら、だんだんとシステムによっていく。作るシステムのマーケティングの話やテクニカルな話。もう少し進むと、ログやセキィリティ、リリース、変更管理なども取り扱う。

このように、ソフトウェア開発においてシステム自身の狭義のアーキテクチャではなく、全般を扱っている内容となっていた。

そういえば、私は大学なんかでプロジェクトマネジメントを少し学んだり、話を多く聞かせてもらったのだけれど、こういう全般的な話を受けたなーと思いながら読んでいた。社会人になって、経験も多少積んで、その上で読むと頭の中を整理したり、そういえばこれも必要だったなと思い出すことができた。

最後に。この本で印象的だったことは、品質保証という役割が度々出て来たことと、その活動の範囲の広さをちゃんと説明しているところだった。

Read “Functional Programming: A PragPub Anthology”

Functional Programming: A PragPub Anthology を読んだ。まだβだったけれど、内容はだいぶまとまっててあとは微調整して発売という感じを受けた。

The Functional Paradigmから入り、Scala、Clojure、Elixir、Haskell、Swiftと関数型というテーマに絡めたそれぞれの言語の特性に触れながら話は進む。それらがひととおおり終わり、考え方を経験した後、Going Deeperということでそれらを再び題材に、より言語毎の特性、テスト(コード)の話、タイプシステム、The DCI architecture、そしてLuaと理解を深めていく。

この書籍をまるっと読むと、いくつかの言語から関数型言語、関数型な考え方に触れ、それらを学ぶことができる。さらには軽くそれらに触れることで、いわゆる写経もやりながら理解を深めることができるので、とっかかりとしても有用な内容だった。特に前半は、その言語に触れたことがある人からすると読み物的な内容に見えるので、考え方を整理するという形で触れることができると思う。

個人的にはElixirやSwift、Testing周りが関係が強いので、そこら辺は特に楽しむことができた。

例えば、ElixirやSwiftのProtocolの話。SwiftではProtocolはGlobalスコープに対して定義される一方で、Elixirでは特定の型に対して定義することができる。そのため、影響範囲を限定することができるのでより安全に利用することができるという話も。

テストの話としては、Elixir、Haskellが題材になっていてよかった。Elixirの話では、TrueStoryを題材にして、可読性の高い(テストしたいシナリオ・ストーリーを理解しやすい)テストコードの書き方に対しても言及している。その中で、パイプ演算子を使った関数型としての書き方に触れながら話を進めている。

Haskellでは、型システムのほか、C言語で書かれたコードをHaskellでラップしてテストコードを書いていく方法を載せている。ほかの言語をテストするためにHaskellを使う形は興味深かった。

やー。思いの外、Elixirに関する話が多かったのとHaskellを使った説明も多く、個人的にはそれだけで満足度が高かった。Haskellはがっつり触れたことはなく、考え方を学ぶために触れている側面が強いけれど、触れる機会が増えてきたらまたこの書籍でさっとHaskellは頭の中を整理したい気分。

read “ZERO BUGS シリコンバレープログラマの教え”

ZERO BUGS シリコンバレープログラマの教えを読んだ。
タイトルと、その副題の高品質なコードを書くための物語というところですね。

エッセイ形式なので、全体を通して、物語を楽しむように読んでいきました。
わかる、あるある、なるほどなーというようなところが色々あり面白かったです。

「すべてのエラーは、あなたが最後にプログラムを変更した場所から3行以内にある」 by Joe Armstrong の引用。

ドナルド・クヌースの、ソースコードがドキュメントになるような文芸的プログラミング(literate programming)に対する考え方。

トランザクション処理のACID(Atomic, Consistency, Isolation, Durability)への言及。

人月の神話と、小さなチームならどんな方法論も上手くいくという話。これは、プログラマが習熟すれば、自分自身を実質的に管理できるようになるから。

Linuxカーネルのコードスタイルにある、それぞれの関数のすることは1つのことだけという姿勢。それとそのコードたちがPolymorphism、オブジェクト、関数型プログラミング、メッセージパッシングの全てをCで実現していること。

OpenBSD開発における、1箇所の修正に対して全体を見直すという、局所と全体の繰り返しのループ。

Erlangのモジュール同士のメッセージパッシングの形が、アラン・ケイがオブジェクト指向で表現したかったアイディアの理想形の1つであるという話。

などなど。

私の専門は品質/テストにあたる分野ですが、そのような立場の人も様々な領域を学ぶ必要があるのと同様、こういう話も知ってもらいたいですね。

read “実践 日本人の英語”

実践 日本人の英語を読んだ。

3作目。

ちょっとしたtipsとして読める点が良いですね。その中で、自身が出来ていること/いないことを確認しながら頭の中に印象付けることができている感じがします。

そういえば、so/very は同じ副詞として使えると思っていたのですが、違ったのですね。お恥ずかしい。
so…that… の形が必要で、感嘆詞などはこのthatが省略されているから類似用語として使うことができる。一方、この that… が使えないような文章の場合はsoではなくveryを使っていくべきという。例を見ていると、感覚的には正しく使えていたみたいですが、運が良かっただけぽい。

接続詞のつながりも。so, since/because, as, for, and 。因果関係の繋がりで、 so が強く、 and がよりカジュアルな弱い感じになるとか。 as/for は書き言葉のような強さがあるみたい。これらはあくまでも論理的関係性だけを指す模様。
普段、 andsince, so をよく使うなーと読んでいたのですが、所々、因果関係が弱い(必然性がない)のに so を使うところとかちらほらあった気がします。 andsince はそこまで外れた使い方はしていなかったぽい。最近。

あと、小技として紹介されていた副詞の位置、接続詞、分詞構文の使い方は感覚的にやっているところもあったけれど、色々と説明を読んで入るとこうする方が良いのかとか気づけてよかった。

色々と自分のケアが届いていないところだけれど、意味としては大事なところに気づかされるというのが良いですね。この本。
反射的に英語が出る、出すことができる語彙/文法はまだ限定的だけれど、それがスラスラ出るように継続して学んでいきたいですね。

「続・日本人の英語」を読んだ。

続・日本人の英語を読んだ。

前回読んだ日本人の英語に引き続きですね。

特に文体が変わったとかもなく、なぜそう英語で表現するか、日本語からの英語訳、その逆などで一方の言語では表現できないこと、その逆などが説明されています。

個人的に、使役動詞に関するところの認識が一部想像してたことと異なるところがあり、学びになりました。

確か、あと実践編があった。