「ソフトウェア品質の経済的側面」

ソフトウェア品質の経済的側面

読みました。

日々品質の良いソフトウェアを書こうと心がけて過ごしてはいますが、「スタートアップでは品質ではなくスピード重視だ」とかいう言葉もちらほら聞きますし、そもそも何のために品質を求めているの?そもそも品質って何なの?という辺りから改めて視野を広げるべく購入しました。

ざっくりとした概要

ソフトウェアの品質による経済的価値

  • どう品質が高いと、どんな経済的価値が得られるのか
  • あるいはどう品質が低いと、どんな経済的影響があるのか
  • 社内向け/社外向け/組み込みなど分野別に記載
    • 「高品質で手戻りが少ない」と、「再実装の工数が減る」
    • 「高品質で顧客満足度が高い」と、「プロジェクトをキャンセルされる確率が減る」
    • 「高品質で顧客がUIを理解し易い」と、「サポートによるコストが減る」
    • 「高品質で他社よりも顧客信頼度が高い」と、「売上が上昇する」など

どうやって品質を計測するのか

  • 基本、FP法を用いる
  • 筆者の会社は13,000のプロジェクトを調査したそうな

開発のどのフェーズのどのような活動が、どれくらいの割合でソフトウェアの品質に影響を与えるのか

  • 例えば要件の誤りが一番大きな影響を与え、次いでDBやモジュール設計などの影響が大きく、コードの記述方法などはさらにその次などになる

品質を向上させるための各種活動について

  • 正規のインスペクションが良い、とか
  • アジャイルプロセスは1,000FP位の規模までは有効、とか

感想

  • 要するに「品質が低いと結局お金かかるよ」ということだった
  • 色々な分野について、数値で色々語られており、なるほど感はあった
    • しかし、表の合計値が異なることがあり(原著がそのままであるとの注付き)、どう読んでいいのか悩ましい数値もあった
    • ただ自分の経験上の感覚とそう外れた感じではなかった気はする
  • FP法がどこまで信頼に値するのかについてはよくわからないなぁ
    • ただ本書のように、一人の人なり一つの会社が統一した基準で計測を実施できているのなら、比較指標としては有効なのかな
  • 要求仕様と出来上がりが違ったら、そりゃ一番痛いことになるよなぁ
    • 自分はアジャイルプロセスをやってみたくてWeb業界に入ってきたが、その点アジャイルプロセスはそこをちゃんとケアしようという意志はあるのではないかと思っている
  • 「スタートアップは品質ではなくスピード重視だ」という言葉の中には、「品質」という多面的な意味を持つ言葉が含まれているので、読んだ人によって色々は反応が起こるのだろうなぁ
    • 「複雑クソコード / 行き当たりばったり設計による品質の低さ」 => 結局はスピードも出ず金もかかるので不幸になる
    • 「拡張可能な設計 / 読みやすいコードを保ちつつ、要件を絞ったことによる品質の低さ」 => 必要な時に必要なものを足せば良いので無問題
      • だから、「スタートアップだからエンジニアのスキルが低くてもいいや」は適切ではない
  • もうちょっと読み込んで、非ソフトウェアエンジニアに品質の意味を説明するための語彙を錬成したい

「会社のITはエンジニアに任せるな!」

読みました。

自分はITエンジニアそのものなのですが、自分のITスキルをより効果的に世間に活かすため、視点を増やすことができたらいいなぁ…と思って購入しました。

頭に残っている概要

ITには大別して2種類ある

  • その場の課題を業務担当者個人が活用して解決する「ツール型IT」
  • 工場の生産ラインのように、その事業そのものを表現する「プラント型IT」

どこまでプラント型ITを適用できるのかは、事業によって異なる

  • 銀行などの金融業は、プラント型ITそのもの
  • 筆者の属するコンサル業などは個人に大きく依存するので、プラント型ITが適用できない
  • 上記の間のどこに自社が位置するのか

IT施策はエンジニアに丸投げしてはいけない

  • プロジェクトリーダが真ん中位に立ち、経営層、現場、IT部門を巻き込んで引っ張る必要がある
  • 経営層はちゃんとバックアップする必要がある
    • 極端な話、ITなんぞ要らんとか言う役員を飛ばすとかも含む

開発プロジェクトは複雑で予測困難である

  • 部品を使いまわせるビル建築ではなく、一つ一つの部品を作り込むサグラダ・ファミリアに近い
  • 最初に予算ありき、期限ありきでは難しく、失敗する確率は高い
    • 30%のプロジェクトは失敗に終わる
  • 成功確率を上げるためには、経営も現場もITもセットでよくよく考え、調査検討して進むべき

その他

  • プロジェクトリーダの育て方
  • 開発プロジェクトを安くするためには
  • 成功事例的なもの

感じたこと

  • 概ねエンジニアとして伝わって欲しいことが書いてある感じがした
    • ほんと開発って複雑なんですよー
      • 根性と忍耐だけではなんとかしたくてもできないことが多い
  • イテレーション回す開発をしたとしても、そのプロダクトオーナーが業務を広く把握していないと、確かに効果的にはならないよね
    • 結局目的と外れた開発をしてしまった時の損害が一番でかいんだよなぁ
    • ↑についてはソフトウェア品質の経済的側面にも書いてあったことだなそういえば
      • こっちも後でブログにメモっておこう
  • 関係者が多くなると、どうしても声の大きい人対策とか男の嫉妬対策とかが必要になってくるんだよなぁ
    • 先日食事でご一緒させて頂いたコンサルな方も言っていたな

私はいちエンジニアとしては、技術を磨いて開発し、それが業務の改善に生き、そのヨロコビを得てMPを回復し、また開発にあたる…というサイクルが健全に回る環境に生きていたいと思うものですが。

その環境を作るための様々な努力も必要だなぁと改めて思ったのでありました。

これからも精進してまいりましょう。

過去最高の作業環境が出来上がった話

開発に集中していると、すぐに首が痛くなります。右側だけいつも痛くなり、そのまま頭痛につながって辛いのです。 何度か椅子やら机やらを変えてみたのですが、この度過去最高の作業環境が出来上がりました。

ここに至るまでの経緯を記したいと思います。

初期状態

イス

www.ikea.com

モニタアーム

サンコー 3軸式くねくねモニターアーム MARMGUS191B

サンコー 3軸式くねくねモニターアーム MARMGUS191B

椅子は前傾姿勢を保てるものでして、作りも丈夫で今でもオススメできるものです。 ただ、自分の場合は趣味で運動をした翌日は疲労のため姿勢の維持が難しく、また腰が痛い時などには前傾はできないので普通に座る -> 痛い なのでした。

電動リクライニングベッド導入

ベッド

アテックス 収納電動リクライニングベッド AX-BE556 0027

アテックス 収納電動リクライニングベッド AX-BE556 0027

モニタアーム

サンコー 3軸式くねくねモニターアーム MARMGUS191B

サンコー 3軸式くねくねモニターアーム MARMGUS191B

こちらの記事を拝見し、首に負担をかけなければいいじゃないか!と思って真似してみました。

私はいかにして怠惰な寝正月を過ごしたか – 介護ベッドと壁掛TVを使ったプログラミング環境の構築 | 株式会社インフィニットループ技術ブログ

しかし残念ながら、ベッドが自分の体に合わなかったのか、長時間使っていると体重がかかる背中〜尻の下の方が痛くなる始末。 膝の下に座布団を折って、膝を常時曲げておくことで改善したのですが、最初から膝下が持ち上がるタイプを買えばよかったなと後悔したのでした。 また買ったベッドはあまりに低すぎて、立ち上がるのに時間がかかるため、トイレもめんどくさくなって我慢してしまい、とても体に悪いようです。

更に引き続き使っていたお安めのモニタアームは、細かい位置調整が苦手で、首の負担ゼロにするのがなかなか難しく、つい首を上げてモニタを眺めて疲労が蓄積。 3ヶ月位で止めてしまいました。

ただ、ディププレイアームやベッドにもう少しお金をかければ(高さがちゃんとあり、膝下も持ち上がるタイプのものを買うなど)、快適な環境を作ることも可能かなとは思います。

スタンディングデスク導入

www.ikea.com

椅子 www.ikea.com

今度は立ってみたのでした。このころ流行っていたスタンディングデスクです。 (極端な方向に走りがち…)

椅子は以前のオーバルチェアとの併用です。 その時の自分の体調に合わせて微妙に高さを調整できることは、なかなかに快適でした。 リフレッシュするにはいいですね。

ただ体調が優れない時には当然座ることになりますし、ずっと立ち続けるわけにもいかないので、最初の首痛の完全な解決には至らないのでした。

電動リクライニングソファー

www.ikea.com

椅子 www.nitori-net.jp

キーボード

ディスプレイアーム

エルゴトロン LX デスクマウント モニターアーム 長身ポール 45-295-026

エルゴトロン LX デスクマウント モニターアーム 長身ポール 45-295-026

いやー、控えめに言って最高ですね。何が良いかというと、

  • 首や腰の負担がほぼ無くなる感じ
  • 電動で立ち上がるのが楽
    • トイレもすぐ行ける
  • 分割キーボードで猫背の悪化防止、空気たくさん吸える
  • エルゴトロンのアームだけでなく、スタンディングデスクが微妙な高さ調整をサポート。ディスプレイをベストの位置に
  • 椅子も新品で買っても5万程度、アーロンの一番安い椅子程度
    • リサイクルショップに偶然にも同型があったので16000円

もともとはコチラを読んで試してみようと思ったのですが、

ニトリさんで色々試したところ、今回選択した椅子が大変よろしく、しかも中古で売っていたため、エイヤと買ってしまったのであります。

f:id:ginkouno:20170515194737j:plainf:id:ginkouno:20170515194757j:plain

全国のニトリさんに行くと試用できます。 人それぞれ体型や症状などで合う合わないはあるとは思いますが、肩こりや首こりの肩は一度試してみて頂きたいですねー。

番外編

f:id:ginkouno:20150812203852j:plain

時間は前後しますが、ある日ぎっくり腰をやった時に急遽作ったのがコレ。 100円ショップで400円位で揃えた部材でその場を凌ぎました。 強度が無く、キーを叩くたびにビヨ~ンとしなるのもご愛嬌…

三が日にタスク選択用slack botを作った話

年始になると、今年やりたいことを書き出したりするわけですが、毎年いろいろなことを思いつき、それが多すぎて、どれをやろうかと考えているうちに、時間を浪費してしまうのであります。

そこで、何をやるのかを自分で考えなくてもいいしくみを考えて、酒飲みながら雑に作りました。

こんな感じに、trello上にジャンル別にタスクを並べておいて、 f:id:ginkouno:20170103174348p:plain

slackで神頼みすると、おみくじっぽく各ジャンルの1番上のcardを取ってくれます。 f:id:ginkouno:20170103174441p:plain

ついでに「そのタスクをやると、いいことがあるよ〜」的なメッセージも付いてきます。なんだかやる気が出てきますね! 決まったらあとはバリバリやるのみ。目の前の事に集中できます。

ふとこれを書きながら考えたんですが、リファクタリング的タスクとかも均等にとっていきたい時とか、こうやってタスクをサンプリングしていくと、技術的負債を一定額返していくことができるかもしれません。リボ払い。

コードはこちら(雑です) ginkouno/lucky_task

おまけ。 f:id:ginkouno:20170103174929p:plain

デバッグ中の画面ですが、typoも含め、縋っている感じが泣けてくる感じですね > 自分

ScrollViewとStackViewを組み合わせて使ってみる

最近、SwiftiOSアプリを作ろうと色々しています。

ScrollViewの上にStackViewを貼って、constraintを適切に設定しておいてあげると、中のviewのhiddenをtrueにしたりfalseにしたりするのに従って、ScrollViewの高さも調整してくれるんですなぁ。

f:id:ginkouno:20160506191429g:plain

便利便利。

なおconstraintは全てStoryBoard上で設定しています。

サンプルコードはこちら。

GitHub - ginkouno/ScrollViewTest1: ScrollViewとStackViewのサンプル

読んだ:オブジェクト指向でなぜつくるのか

Railsリファクタリング力を高めたいなぁと最近思っていたのですが、 その一環としてオブジェクト指向の復習がしたくなり、何冊か関連書籍を買って読んでおります。

その一冊がこれ

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

前提

  • オブジェクト指向を最初に勉強しようとしたのは15年前位
    • その頃は組み込みの仕事をしていた
    • C++を使い始めた時だった
    • いわゆる「哺乳類クラスと卵を生むクラスの多重継承がカモノハシクラスである」的な説明とかを読んだ気がする
    • メモリ上にどのように展開されるかとか、そういったことは興味を持って読んだ記憶があるが、だからこう設計するとよい的な事については確信的なものは得られなかった気がする
  • UMTPの一番簡単なやつ?は試験受けて合格した記憶がある

感想

  • 実装を通じて「methodや属性をまとめるための手法だよね」的な理解をしていたが、それはそれで間違ってなかったのだなぁと再確認できた
  • 「要件定義などのフェーズと実装のフェーズとでは、オブジェクト指向の文脈が異なるので注意」というのはなるほどと思った
  • オブジェクト指向的にコードが書かれてないとテストが書きにくくて仕方がないと思っていたが、「オブジェクト指向から生まれたTDD」なる説明があり、たしかにそういう側面はあるよなぁと思った
  • 「上流工程」「下流工程」という言葉には苦手意識が...

まとめ

オブジェクト指向でなぜつくるのか」という問いに対しては、「オブジェクト指向という練られた知恵とその周辺技術を使うことで、ソフトウェアの設計・開発がより品質高く効率的にできるから」ということでいいのかな? 良い総括と復習が出来たなぁという感じでした。

SQLを再度学習しようかなという話

Tokyu.rbの新年会で、 @joker1007 さんとRedshiftの話をした時に、ミックさんの本で勉強したということだったのですが、 自分が持ってて読んだのは古い本でした。

達人に学ぶ SQL徹底指南書

達人に学ぶ SQL徹底指南書

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

その時携わっていた業務ではとても役に立ったのですが、SQL業から離れた途端に読まなくなってしまっていたので、再度検索してみると...

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

おおお。新しいのが出てた。

@joker1007 さんはこれで勉強してRedshiftと格闘したという話だったので、自分も今日注文しました。 時間かかりそうだけどじっくり読もう。