ラ・ラ・ランドを見た。
誰といるのか？
何をするのか？
人生における大切なことが詰まっている作品だった。
何を大切にするのか。
良く考え後悔の無い人生を。
ラ・ラ・ランドはみんな幸せで終わった
基本情報にビジネスサイドの問題が多いことの意味について思ったこと
DDDの話とかを勉強してるとドメインについて詳しいことであったり認識合わせを行う事の大切さであったり、という話が多く出てくるところから着想して、プロとして情報を扱う場合には、ビジネスサイドのことをわかっておかないといけないよという文脈の中でビジネス世界の話が試験に出てくるのかなと想像した。
DDDの1章をビジネスサイドに読んでほしいというところと同じく、ビジネス界の最低限知っておいてほしいビジネスドメインの共通のことを学ばせようという背景を少し感じる。
あまり意識したことなかったけどそういうことなんだろうなと思いました。
IPA 独立行政法人 情報処理推進機構：制度の概要：基本情報技術者試験
引用
業務と役割について
基本戦略立案又はITソリューション・製品・サービスを実現する業務に従事し、上位者の指導の下に、次のいずれかの役割を果たす。
1. 需要者（企業経営、社会システム）が直面する課題に対して、情報技術を活用した戦略立案に参加する。
2. システムの設計・開発を行い、又は汎用製品の最適組合せ（インテグレーション）によって、信頼性・生産性の高いシステムを構築する。また、その安定的な運用サービスの実現に貢献する。
期待する水準について
１ 情報技術を活用した戦略立案に関し、担当業務に応じて次の知識・技能が要求される。
① 対象とする業種・業務に関する基本的な事項を理解し、担当業務に活用できる。 ② 上位者の指導の下に、情報戦略に関する予測・分析・評価ができる。 ③ 上位者の指導の下に、提案活動に参加できる。
２ システムの設計・開発・運用に関し、担当業務に応じて次の知識・技能が要求される。
① 情報技術全般に関する基本的な事項を理解し、担当業務に活用できる。 ② 上位者の指導の下に、システムの設計・開発・運用ができる。 ③ 上位者の指導の下に、ソフトウェアを設計できる。 ④ 上位者の方針を理解し、自らソフトウェアを開発できる。
なるほどなぁ。
ビジネス側とお話しして作った企業にとって重要度のある問題作りを話し合いの中で相談して作ったんだろうなと想像すると少しほっこりする。
試験づくりのプロジェクトXとかみてみたいかもしれない
E2Eでのテストで何を検出/表明するのか
E2Eで検出する、表明することは、領域ごとに異なる開発者が作ったものに認識齟齬がないかを検出し、プロダクト全体の機能を表明する。
それが、E2Eテストの役割だと自分は考えている。
領域ごとに集まりミーティングを重ね仕様を決めていっても、認識齟齬や漏れはいくらかは発生してしまう。これを早期発見することで安定した開発が行うことができるだろうと自分は考えている。
なぜならUnitテストまではできていて結合で詰まったり、結合前のモンキーテストで問題が見つかり、今更リリース時期を動かしにくい状態の時にプロジェクトが乱れていくのを経験したからだ。
リリース時期を正直に言ってずらすべきだという意見の正しさも理解できるしそうするべきだったができるだけのことをすればまだ間に合わせることができたので対応を頑張ってしまったこれはこれで問題はあるが、日々のE2Eテストの自動化を設けていないことも開発としての問題だと考えてこの結論に至った。
組織としての柔軟性は何回かリリースを伸ばしていたし今回も伸ばせただろうという意味では十分にあったのでこの点は一旦保留としたい。
ここで言いたいのは、認識齟齬は生まれるし、認識の漏れは生まれるので段階的にE2Eの自動化目指そうという話。
正しさ
正しさは変わっていく
正しさは現実に最適化される
正しさにはコストがかかる
ルールはいつあるべきか
ルールがあるべきタイミング。
みんなが欲しいと思ったとき。
開発の前にそのルールがあればよかったのにと思わせないようにする。
ルールは緩くできるという意識があればまずルールを作るとい運用は可能かなと思う。
検証必要。
選択肢があるときの判断基準
先行研究を無視して曖昧な用語をバンバン使っていて申し訳ない。
仮説1
選択肢が複数あるときの判断基準の一つにフィードバックが早く発生するかしないかがある際は、早い方を選んだ方が良い結果になるように思う。
良い結果とは無理のない生産活動を継続できている状態。
