目標の5基準 SMART

SMARTってなんやっけ？っていっつもあいまいにしか記憶できていないので、メモ。

1. Specific(具体的): 何かが明確であること。「何か」が特定されていること。
2. Measurable(測定可能): 量で測れること。あるいは後から検証可能、もしくは完了したかどうかが分かるようになっていること。
3. Achievable(達成可能): 現実的で達成するのに特別の努力が要るもの
4. Relevant(重要性): この達成が、目的達成にとって意味がある(寄与できる)こと
5. Time-bound(具体的な期間): 達成までの期間が限定されていること。期限が決まっていること。

この基準を満たすように目標設定しよう！
ふりかえりなんかで改善案を出すときは、意識しよう！

以上。

Developers Summit 2015 - 2日目レポ

1日目はこちら。
Developers Summit 2015 - 1日目レポ - 前半 - 毎日Learning
Developers Summit 2015 - 1日目レポ - 後半 - 毎日Learning

参加してから一週間裁っていまいましたが、2日目のレポ。

私が聴講させていただいたセッションは、以下。

実戦での Scala - 6つの事例から知る Scala の勘所 - に参加してきました

実戦での Scala 〜 6つの事例から知る Scala の勘所〜 - 実戦での Scala | Doorkeeper

2015年2月21(土) 14:00からスマートニュースさんの新社屋をお借りしたScala勉強会に参加してきましたー。

Scalaは、私の中で、現在、再注目の言語でまだまだ勉強中なのですが、これからクラウド上でサービスを展開していくにあたり、マイクロサービスアーキテクチャを構築していくことをJVM上で考えていくのであれば、これかなーと思っております。

また、今回は、かなり運よくデブサミ2015にも参加させていただく機会を得ておりましたので、「これは運命だ！Scala－！」と思って勢い勇んで参加させていただきました。

内容や感想は以下から！

Developers Summit 2015 - 1日目レポ - 後半

デブサミ1日目レポの後半部分。

前半のリンクは以下。
Developers Summit 2015 - 1日目レポ - 前半 - 毎日Learning

後半に出たのが以下のセッションです。

2015/02/19 デブサミ2015【19-B-6】スクラムならうまくいく？～グリーのネイティブゲーム作りの歴史をひもとく、そして未来へ～ #devsumiB - Togetterまとめ

2015/02/19 デブサミ2015 【19-B-7】2020年のアーキテクチャ #devsumiB - Togetterまとめ

感想は以下。

Developers Summit 2015 - 1日目レポ - 前半

Developers Summit What's NEW：：Developers Summit
に来ております。

朝4時起きで新幹線に飛び乗り15時までセッション休まずマラソン受講しました。

私が聞いたセッションのTogetterは、以下。

2015/02/19 デブサミ2015 【19-B-1】身近になりつつある人工知能。エンジニアとして知っておくべき勘所とは？ #devsumiB - Togetterまとめ

2015/02/19 デブサミ2015 【19-B-2】DMMのビッグデータ分析のご紹介 ～Sparkによるリアルタイムレコメンド～ #devsumiB - Togetterまとめ

2015/02/19 デブサミ2015【19-A-3】技術選択とアーキテクトの役割 #devsumiA - Togetterまとめ

2015/02/19 デブサミ2015【19-A-4】javaエンジニアのscalaへの挑戦～新プロダクト開発秘話と最大の難関「Monad」の攻略法～ #devsumiA - Togetterまとめ

アーキテクチャ記述 ( Architecture Description ) の章立て

先日、以下の書籍を読み終えたうえで、

ソフトェアシステムアーキテクチャ構築の原理を読み終えて - 毎日Learning

じゃあアーキテクチャ記述のアウトプットをどうしようかなって考えて、色々と調べて参考にして、以下の構成でアウトプットすることにしようと一旦、決めた。

1.  目的
2.  目標
3.  システム概要
4.  ステークホルダ
5.  ビューポイント
6.  コンテクストビュー
7.  機能的ビュー
8.  情報ビュー
9.  並行性ビュー
10. 開発ビュー
11. 配置ビュー
12. 運用ビュー
13. 品質特性
14. 重要なシナリオ
15. 決定待ちの課題
16. 付録

こんな感じでいこうと思う。

中身を書くうえで必要な考えるポイントとかは、

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

をバリバリに参考にしまくって考えていく。

そんなイメージです。

ソフトェアシステムアーキテクチャ構築の原理を読み終えて

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

読了しました。

 

アーキテクチャ設計を今までフェーズとして担当したことがなかったのですが、

 

お仕事の機会もあり、きちんと標準的なところからプロセスを理解して取り組みたかったので、

 

この本を読んでみました。

 

アーキテクチャ設計とはなんぞや。

 

から、プロセス、各フェーズや視点から漏れの危険性や注意点、気をつけるべき網羅ポイントなどが学べました。

 

アーキテクチャ設計は、なかなか一言で表現しにくい取り組みだと感じていますが、

 

ある一面では、リスクに対してどうするか？という取り組みとも言えます。

 

なので、細かすぎたり、時間をかけすぎたり、こだわりすぎたりしては、リスクに対処する行為自体が、リスクになり得るという。

 

ややこいけど、とてもとても重要なフェーズであり、お仕事だなーと思いました。

 

もっと、このアーキテクトに近づくべく取り組みたいと思いました。

 

また、アーキテクチャ関連で知ったり、気づきがあればアウトプットしていきたい。