ravelll の日記

よしなに

2016 -> 2017

あけましておめでとうございます。今年もよろしくお願いします。

去年の感想やまとめと今年の気持ちエントリです。

2016 と 2017

2015年の7月まで8ヶ月ほど休職し、フルタイムの仕事に戻ったのは去年の2月で、2016年はリハビリ期間という感じだった。

一時は本当に社会復帰できるのか、アルバイト生活になるのでは等々考えていたものの、多くの人に助けてもらいなんとか復帰することができた。感謝しております。

復帰後は後輩の開発サポートから始まり、大きめな機能開発を担当したりWEB+DBへの寄稿機会をいただけたり4万人以上が使うアプリケーションの稼働言語のバージョンアップを単独で任せてもらったり(これはまだ終わってない)と、それなりに立ち回ることができた。

またメンタリティについて、"自分がどうなりたいか" を基準に行動選択できるようになってきたのは大きな変化だったと思う。これまでは周囲の凄く見える人達を見ては無闇に自分と比較し、自身の成果を蔑んで自己肯定感を失いがちだった。

一方で睡眠障害との付き合いはずっと変わらず頭を痛めているところ。

これについては、その日の体調に合わせて出社時間や勤務時間を調整できればストレスを減らせ、余計な悩みで学習が阻害されることも減り、パフォーマンス上昇最高じゃん、という見解があるので2017年中に何らかの方法でフレックスや裁量労働の勤務形態で働ける状態にしようと思っている。

睡眠障害の云々を除いても、多少出社時間がズレても進捗に影響しない業務にあたっている中で、市役所や病院に行くために給与を削って遅刻したり有給を取得したりすることに馬鹿らしさを感じていることも理由にある。

それも含め、2017年は身辺の変化が色々起こる見込みだけど、2016年にできた成長を大きく上回って成長したいと強く思っている。

テーマは「できないことはやらない」と「結婚しても困らない年収にする」の二本立て、やっていくぞ!!!

読書

読了したものが31冊、途中まで読んだものが15冊くらい。読了したものの過半数が漫画。全然読めてないなと思う。

技術書は途中で移ろいがちだった。移ろうことが必ずしも悪いとは思わないけど、1分野くらいはどしっと腰を据えて深い知識を付けるべきだったように思う。結構な頻度で移ろってしまった。

PHPデザインパターンの学習を進めているので、ひとまずこれを集中・継続していこうと思う。成功体験を得たい。

日本酒

お店や人の家で飲んだものは記録漏れが多くあるので自宅で飲んだものに絞ってリスト。

思ったより飲んでなかった。

今年始めて飲んだ銘柄では特に風が吹くや百春、死神が美味しかった。別の造りのものも飲んでみたい。

その他では花陽浴や王祿は安心の美味しさで最高だった。あと奈良萬の酒未来には1升3000円弱でここまで美味しいお酒があるのかと驚かされたことを覚えている。

余談だけど2016年は恐らく10回以上飲んだあと記憶を飛ばしたので、2017年は飲み方を改めたいと思っている。

"品質" ってなんだろう?

このエントリは pepabo Advent Calendar 2016 の23日目のエントリです。

前日のエントリは @Asuforceペパボのエンジニア研修を通しての成長体験 でした。

彼がアルバイト入社していたとき僕がメンターについていたこともあって、エントリを読んで子の成長を見る親のような気持ちになりました。

さて今日はソフトウェアの品質についての話です。ところで僕に子供はいないですし既婚者でもないです。

"品質" ってなんだ?

我々ソフトウェアエンジニアを始めシステムの提供者はみな、提供するシステムの品質を高めたいと思っていることでしょう。しかしながら、"では品質とは何なのか" と尋ねられたとき、答えに窮する人も少なくないのではと思います。品質の不理解は、提供者にとっては高い品質で提供しているシステムが利用者には低い品質とみなされる、といった不幸な認識のズレに繋がることが考えられます。

ここで、品質について何らかの分類モデルがあれば、システムの機能を分類した上でそれぞれをカバーするに適当なチームを構成したりタスクを割り当てたりすることができそうです。そこで今回は、ISO/IEC 25010:2011 で規格化されている "製品品質モデル" を紹介しようと思います。

ISO/IEC 25010:2011 の製品品質モデル

この国際規格では、システムの品質を "システムが様々な利害関係者の明示的ニーズ及び暗黙のニーズを満足している度合い" とし、8つの品質特性、更に各品質特性における副特性に分類しています。

以下の表に品質モデルの品質特性とその説明、属する副特性をまとめます。副特性の説明までまとめると長くなるので省略しています。各特性の説明についてはこちらより引用しています。

1. 機能適合性

明示された状況下で使用するとき,明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い。

  • 副特性: 機能完全性、機能正確性、機能適切性

2. 性能効率性

明記された状態(条件)で使用する資源の量に関係する性能の度合い。

  • 副特性: 時間効率性、資源効率性、容量満足性

3. 互換性

同じハードウェア環境又はソフトウェア環境を共有する間,製品,システム又は構成要素が他の製品,システム又は構成要素の情報を交換することができる度合い,及び/又はその要求された機能を実行することができる度合い。

  • 副特性: 共存性、相互運用性

4. 使用性

明示された利用状況において,有効性,効率性及び満足性をもって明示された目標を達成するために,明示された利用者が製品又はシステムを利用することができる度合い。

  • 副特性: 適切度認識性、習得性、運用操作性、ユーザエラー防止性、ユーザインタフェース快美性、アクセシビリティ

5. 信頼性

明示された時間帯で,明示された条件下に,システム,製品又は構成要素が明示された機能を実行する度合い。

  • 副特性: 成熟性、可用性、障害許容性(耐故障性)、回復性

6. セキュリティ

人間又は他の製品若しくはシステムが,認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように,製品又はシステムが情報及びデータを保護する度合い。

  • 副特性: 気密性、インテグリティ、否認防止性、責任追跡性、真正性

7. 保守性

意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い。

  • 副特性: モジュール性、再利用性、解析性、修正性、試験性

8. 移植性

一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い。

  • 副特性: 適応性、設置性、置換性

特性の多様さを見ると、単一の職種でシステム全体の品質を担保することが如何に難しく、エンジニア、デザイナー、ディレクターなど複数の職種が各々の責任範囲を認識し協力しあうことが品質の向上には欠かせないと分かります。

また、セキュリティのように、チームの単位ではなく会社全体の規模で取り組む必要がある品質特性もあることが分かりますね。

まとめ

このエントリではシステムの品質とは何か、というテーマで ISO/IEC 25010:2011 の製品品質モデルを紹介しました。

明日の担当は @udzura さんです。楽しみですね!!!

ここ1〜2ヶ月で買ったり読んだりした本たち。

どうしても複数の本をその時々の気分で読み進めてしまって、相変わらず読み途中の本が複数ある。

読了

のみじょし 3 (バンブーコミックス)

のみじょし 3 (バンブーコミックス)

漫画はシュッと読める一方で財の摩耗も大変スムーズなので安易に開拓しないよう気をつけてる。

途中

The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering

The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

パーフェクトPHP (PERFECT SERIES 3)

パーフェクトPHP (PERFECT SERIES 3)

JPEG・MPEG完全理解

JPEG・MPEG完全理解

パーフェクト PHP は2周目。入社1年後くらいに一度ざっと読んだとき以来で、PHP の基礎を固めたい気持ちになりじっくり読み返してる。

人月の神話は原著しか電子版がないので原著を読んでる。英語がスラスラ読めるわけではないので鈍行です。

積読

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

社の Slack でちらりと話題に挙がり、調べてみたら面白そうだったので。

今は会社では Rails アプリにほとんどコミットしてないんだけれど、数少ない馴染みあるフレームワークなので継続して触れていきたい。この本はもうしばらく前に出たんだけどね。