a2 Tech blog

試したこと・調べたこと・感じたことを発信するITエンジニアの日記です。仕事とは直接関係ないけど興味あることを模索していきます。

書評 ロケットスタート仕事術「なぜ、あなたの仕事は終わらないのか」(中島聡 著)

すでにベストセラーなので読んだ方も多いかも知れません。ロケットスタート時間術 という時間管理に関する書籍ではあるものの中島聡さんの熱い想いが詰まった書籍なので、特に エンジニアの方 に読んでもらいたいと思いました。私も一応エンジニアなので私が感じたことを書くことで少しでもエンジニアの方が興味を持ってくれればなぁと思い、ブログに書くことにしました。

普段、読んだ本の所感は 読書メーター にサラッと書いて終わりにしています。気になる書籍は、少し長めにこうしてブログに掲載しています。

i.bookmeter.com

私もこの本を読むまでは中島聡さんについて詳しくは知らなかったのですが、日本マイクロソフトのde:code(2017/5/23-24) にゲスト出演されていた 堀江貴文さん のセッションを聞かせてもらった際に、購読すべきブログに中島聡さんの名前を挙げていたことがきっかけで、本書を読んでみようと思い購入しました。

本書でも中島聡さんの経歴がしっかりと語られていますが、中島聡さんと言えば、Windows95の開発に携わられ ドラッグ&ドロップ を普及させた人物というのが代名詞です。現在もエンジニアとしての活躍されている方です。

時間術の本ではあるが・・・

本書は、時間管理の方法としてロケットスタート時間術と題して40年間実践されてきたことを書かれています。もちろん、その方法はとても素晴らしい考え方で自身の仕事人生に取り入れて実践すべきことだと感じました。ただ私もエンジニアとして日々活動している身として中島聡さんが歩んできた エンジニアとしての考え方 の部分がすごく参考になると思いました。

ただの時間術のビジネス書でなく、エンジニアとしてのどのように活躍していくべきかという1つの指針 が書かれているように思います。

その中でも私が特にこの考え方は真似したいと思ったことを3つあげます。興味を持った方は是非、購入して読んで見てください。必ず今後のエンジニア人生のためになると思います。

「まず作ってみる」が、未来を変える

1つ目は、「まずプロトタイプを作る」 という仕事法です。中島聡さんがCANDYという機械や電子機器の設計書を作るためのソフトウェア、今で言うCADソフトウェアを開発していたというエピソードが書かれています。その開発は、最初の2週間で「なんちゃってCANDY」というプロトタイプを作成し、それを見せることでアドバイスを得る、改善するということを繰り返していたそうです。この仕事の進め方は、現在で言うところの Agail に通じるものがあるように私は感じました。また、中島聡さんはCANDY以外にも、OSにATOKを搭載するにあたりATOK側をなんちゃってATOKとしてプロトタイプを作成したり、マイクロソフトで次世代OSのプロトタイプを作成したことで、それがのちにWindows95の種となったエピソードの書かれています。

机上で設計し認識合わせを行なって進めていく方法は、日本のSIという特殊な文化が生み出してしまったものだと思っています。やはり、実際に作ってみる、プロトタイプを元に認識を合わせる、プロトタイプを改善していく、そういうアプローチでモノづくりを進めた方が本来は良いのではないかと思います。そのためには、いかに早く形にできるか という所が重要で、自分で手を動かして作ってみる 精神がエンジニアにとって重要な資質ではないかと思いました。

見積もるには、とにかくやってみることだ

2つ目は、作業の見積もりについてです。1つ目に取り上げた「まずは作ってみる」という考え方に共通するところもありますが、何か作業を依頼された際には、安請け合いをせずに、最初の2日(締め切りまでの期間の2割) でやってみる、そして8割終われば期間内でできると判断しそうでなければ期間内でできないと伝えるというロケットスタート仕事術についての考え方のベースになっている考え方です。

エンジニアであれば、見積もりを行うことは頻繁にあるのではないでしょうか。私も色々な仕事の依頼でどれぐらいで出来そうか聞かれます。その際には、何か過去の知見をあたかもそれらしい理由で見積もりに仕立てあげて、これぐらいで出来そうですと答えているのが実際です。しかも見積もりをそれらしく見せるために2日ぐらい時間を使ってしまったりします。それってムダだなぁって改めて痛感させられました。

2日あるなら、まずはやってみる。そこで得られた情報を元に判断する。これが見積もりのやり方なのかもしれないですね。エンジニアの仕事って見積もれるものじゃないと思ってます。もし簡単に見積もれる仕事であるなら、それはエンジニアがやるべき仕事ではないのかもしれません。

集中しなきゃいけない仕事はするな

本書では、仕事に対する考え方についても色々書かれています。私が気になったのは、「好きな事に思いっきり向き合う」「恐るべきは自分のやりたい事に不誠実になる事」「集中しなきゃいけない仕事はするな」 という言葉です。3つともに共通することなのですが、中島聡さんの時間術を実践して、自分の好きな事に時間を使いましょうという熱いメッセージです。

最近の社会の風潮として、早く帰りましょうみたいな感じになっています。過酷な長時間労働は悪であるのはもちろんその通りだと思いますが、自分が本当に心からやりたいことであれば、時間は苦にはならないのではないのでしょうか。私も小さい頃はテレビゲームを時間を忘れて没頭したものです。その時は、集中しようなんて考えてないわけで、苦にもならないわけです。極端な言い方ですが、そういう感覚で仕事ができるかどうかなのではないでしょうか。 (決して、長時間労働を肯定しているわけではありません。)

エンジニアの方は、つまらない雑用に忙殺されずに自分が本当にやりたいこと(新しい技術への取り組みとかですかね)に没頭できる環境を見つけるべきというメッセージだと受け止めました。

さいごに

あとがき に書かれている内容がとても私にはグサッと刺さりました。

日本では、そんな「ITインフラ」の構築はITゼネコンと呼ばれる、巨大なIT企業が受注し、設計だけして開発は下請けに丸投げする、という形で作られるのが一般的です。・・・中略・・・しかし、そんな開発手法では決して良いものは作れないし、優秀なエンジニアが働きたいような環境は作れません。国際競争力のあるソフトウェア企業も、そんな業界からは決して生まれてきません。

私もこの考えにはすごく共感します。この問題にどう取り組んで答えを見つけていくのかが今のSIerに求められていることだと思っています。

中島聡さんの熱い思いがつまった本書は是非、エンジニアの方に読んで欲しいです。

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

Visual Studio Team ServicesでCoded UI TestのBuild/Releaseパイプラインを作る

f:id:ninna2:20170411015358j:plain:w240

Coded UI Test を Visual Studio Team Services と連携して動かせるようにBuild & Release パイプラインを構築することをやってみたいと思います。Build & Release パイプラインを作ることにフォーカスしますので、Coded UI Testのやり方とかは過去記事を参考にしてください。

こんな感じの手順になります。

  • Build Agentの有効化
  • サンプルアプリケーションのビルド定義
  • Coded UI Testの作成
  • テストコードのビルド定義
  • アプリケーション/テストのリリース定義
  • リリース実行(テスト実行)

VSTSのプロジェクトの作成や、今回は使用しているAzureの設定などの細かいところは割愛してます。さて、始めていきましょう。

Build Agentの有効化

ビルドサーバをAzure上に構築して、Build AgentとしてVSTSから認識させます。こうすることで、テスト対象のアプリケーションやテストモジュールをBuild Agent経由でデプロイ、テストの実施を行えるようになります。VSTSとオンプレミスの環境の組み合わせや、Azure上でもロードバランサ等で区切られたネットワーク環境に対してデプロイしたいケースなどで有効な手段です。

一応、Build Agentの設定方法を前回記事にしておきましたので、構築の参考にしてください。ちなみに、前回記事では、Visual Studio 2017 on Windows Server 2016で構築していますが、わけあってVisual Studio 2015 on Winodws Server 2012 R2 で構築しています。Windows Server 2016で実は最初やってみたのですが、Build Agentから各サーバへのWinRMでうまくいかなくってTest Agentがデプロイできないという問題がありました。これについては解決できなかったので継続調査が必要です。セキュリティ周りでの設定があやしいなと思ってます。

ninna2.hatenablog.com

Build Agentが設定できると、VSTSのAgent queuesから見ると緑色になって正しく認識されていることがわかります。

f:id:ninna2:20170528221623j:plain

サンプルアプリケーションのビルド定義

サンプルアプリケーションには、前回のBuild Agentの作成でも使用した電卓アプリケーション(Simple Calculator)を使っていきます。これです。

code.msdn.microsoft.com

ソースコードは公開されているので取得して、VSTSのGitリポジトリに格納しておきます。

f:id:ninna2:20170528222724j:plain

サンプルアプリケーションのソースコードの準備ができたのでビルド定義を作成していきます。"Build & Release"から"Builds"とたどっていきます。"+ New definition"をクリックして、ビルド定義を追加していきます。Templateは、"Visual Studio"を選択し"Apply"。Nameは任意の名前を入力し、Solutionは“Simple Calculator/MyCalculatorv1.sln”を指定します。

NuGet、Copy Files、Publish Build Artifactsは不要なので削除します。代わりにCopy and Publish Build Artifactの追加します。Copy and Publish Build Artifactsの設定を入力していきます。"Copy Root"は。"…“から今回の対象アプリケーションのrootフォルダ(Simple Calculator)を指定、"Contents"は”**\bin"と入力、"Artifact Name"には"drop"と入力、"Artifact Type"には"Server"と入力します。

f:id:ninna2:20170522150201p:plain

“Variables"タブから、BuildConfigurationを"release"から"debug"に変更しておきます。また、"Options"の"Default agent queue"を"Hosted"からBuild Agentでビルドする方式(私の場合は "AzureVS2015”)に変更します。

これで定義変更は出来たので保存とビルド実行(Save & Queue)を行います。ビルド成功すればOKです。

Coded UI Testの作成

Coded UI Testのコードを作成していきます。サンプルアプリケーションが実際に実行される環境とPathなどを合わせないといけないので、今回は、C:\drop\配下にサンプルアプリケーション(MyCalculatorv1.exe)が配置される 想定で進めます。テストコードを作成する端末にC:\drop\MyCalculatorv1.exeを配置します。ビルド済みのモジュールはビルド実行した際のArtifactから取得して下さい。

配置で来たら、早速テストコードを作成していきます。まず、Visual Studioを起動します。Coded UI Testを行うためには、Enterpriseエディションでないといけないので、その点だけ注意してください。

私がいつもテストを組む時にやる方法としては、アプリケーションの起動部分と起動後のテスト実施部分を分離して定義していきます。アプリケーションの起動は、毎回同じ操作になるはずですので、TestInitiaraizeにて行えばよく、毎回行う必要性がないからです。

TestInitialize()部分にアプリケーションの起動部分をBuilderを使って記録していきます。極力マウスにて操作するのでなくキーボードのみで操作する方が後からの再現性を保証できるので良いかと思います。

f:id:ninna2:20170528225054p:plain

次にそれぞれのテスト部分を作成します。とりあえずテストケースが1つ作成できればよいので、適当な動作を記録してテストケースとしています。[1000-273]という計算をテストケースにしました。

f:id:ninna2:20170528225446p:plain

かなり割愛しながら説明しているので、細かいCoded UI Testの記録方法を知りたい方は、私の過去記事を参照していただければと思います。Webシステムを対象にしてますがクライアントアプリケーションでも基本の操作は変わりませんので。

ninna2.hatenablog.com

テストコードが作成できたら、VSTSのGitリポジトリにPushします。とその前に、サンプルコードとテストコードのリポジトリは分けておくべきなので、新しいリポジトリ(CuitPrjにしました)を作成しておきます。テストコード格納用のリポジトリに、今回作成したCoded UI TestのコードをPushします。こんな感じですね。

f:id:ninna2:20170528225918j:plain

テストコードのビルド定義

テストコードに対するビルド定義を行っていきます。サンプルコードのビルド定義の作成とほぼ類似しているので割愛します。注意点は有効化したBuild Agentでビルドするようにすることぐらいですかね。

f:id:ninna2:20170528230130j:plain

アプリケーションとテストモジュールのリリース定義

サンプルアプリケーションとテストコードの準備ができたので、リリース定義を作成していきたいと思います。今回構成的には、Build Agentとは別にテストを実行するマシンを別途Azure上に作成しています。内部IPは、10.0.0.7になってます。Windows Server 2016で検証した残骸が残っているので台数が多くなってますが使うのは、下の2台のみです。テスト実行のマシンには、Windows Server 2012 R2 Datacenter を選択しました。DevTest Labsで雛形が用意されているものです。

f:id:ninna2:20170528231202j:plain

リリース定義を行なっていきます。"Build & Release"から"Releases"に進み、新しくリリース定義を作成します。テンプレートから定義を作成する必要がないので"Empty"で始めます。

リリース定義は4タスクで構成します。

  • Windows Machine File Copy(サンプルアプリケーションの配置)
  • Windows Machine File Copy(テストコードの配置)
  • Visual Studio Test Agent Deployment
  • Run Functional Test

全体設定と追加した4タスクの設定していきます。まずは、Run on agentを設定します。設定変更箇所は1箇所のみです。"Deployment queue"に Build Agentで有効化したもの を指定します。こうすることで、Build Agentが起点となり全てのタスクが動きます。

f:id:ninna2:20170528231826j:plain

サンプルアプリケーションの配置を行うための設定をします。Sourceには配置すべきアプリケーションを指定します。"MyCalculatorv1.exe"です。Machineには、Build Agentから見たときのアクセスIP を指定します。ログインユーザーとパスワードは、後で説明しますがVarablesで定義した変数で指定します。最後に、Distination Folderを今回のアプリケーションの配置先である “C:\drop\” と指定して完成です。

f:id:ninna2:20170528231844j:plain

テストコードの配置も、アプリケーションの配置とほぼ同じです。配置対象は、DLLです。また、“C:\test\” を配置先にしています。

f:id:ninna2:20170528231916j:plain

Visual Studio Test Agent Deploymentタスクもあまり迷うところはないかと思いますが、Version2.*を使ってみたのと、Run UI Tests というチェックボックスがあるのでそこをチェックするぐらいが注意点です。

f:id:ninna2:20170528231939j:plain

Run Functional Testタスクですが、Machineを指定するだけですので難しくないかと思います。

f:id:ninna2:20170528232002j:plain

最後に、“Variables” にユーザー名とパスワードを変数定義しておきます。こうすることで、$(myuser)と$(mypass)に値が入るようになります。パスワードは見られたくないので、横の鍵マークを押しておくと良いかと思います。

f:id:ninna2:20170528232327j:plain

リリースの定義がこれです完成しました。

リリース実行(テスト実行)

さて、実行してみます。実行は"+Release"をポチッと押すだけです。そうすると動き始めます。Test Agentの設定が思ったより時間がかかりますが設定があっていれば無事完了します。

f:id:ninna2:20170529015722j:plain

途中、テスト実行のVMを覗いているとちゃんとテストが実行されている様子がわかると思います。誰も触ってないのに勝手に動き出したってなります。

f:id:ninna2:20170529015909j:plain

駆け足でしたが、Visual Studio Team ServicesでCoded UI Testを動かすCI/CDパイプラインを作成してみました。基本的な組み方さえわかってしまえば、複数のサーバに展開してもいいし、Webアプリケーションのテスト自動化に使ってもいいし、色々考えられます。UIテストを継続的に実施するとハードルがVSTSを使うことで少しでも緩和されて生産性が向上するはずです。

細かい説明を割愛してますので過去記事も合わせてご参照ください。では!!

第一歩を踏み出そう「日本企業がシリコンバレーのスピードを身につける方法」(Rochelle Kopp 著)

時代の流れに取り残されないように行動するにはどうすればよいか。顧客の要望にいち早く応えるためにはどうすればよいか。知的労働者の生産性向上をどのように実現すれば良いか。このような課題を抱えている方が多いのではないでしょうか?そのような課題に対して、シリコンバレー企業の敏捷性を可能にしている マインドセットについて解説 し、取り入れるためにどうすれば良いかを示した示した本です。

続きを読む

ソフトウェア開発現場の生産性向上@de:code2017で感じたこと

f:id:ninna2:20170524233815j:plain

5/23・24でMicrosoftの開発者カンファレンスのde:code 2017に参加しました。目的はもちろん最新技術動向の把握にあるのですが、それと合わせてDevOpsとその言葉の裏にある「ソフトウェア開発の生産性向上」が裏テーマです。今回は、私が聞いて感じたことと日々感じていることと合わせて書いていこうと思いました。所属組織は関係なく個人的な意見ですのであしからず。

私が参加したDevOps系(生産性向上)のセッションは下記です。

  • DO08 『変わらない開発現場』を変えていくために〜エンプラ系レガシーSIerのためのDevOps再入門(MS赤間信幸さん)
  • SP05 日本企業の生産性を根本から改善する8つの習慣とその事例(Rochelle Koppさん & 米MS 牛尾剛さん)
  • DO09 獲れたてOSS × DevOps!自動化三昧を満喫セヨ(米MS牛尾剛さん)

米 VS 日 の生産性

まず、当たり前すぎるのですが、「仕事の総量 = 仕事の生産性 × 時間」(#DO08より)です。より多くの仕事をこなすには、時間を増やすか仕事の生産性を上げるかの 2択しかないわけです。昨今、世の中の働き方改革という名のもとで、残業禁止となり時間を増やすことが難しい現状になっています。では、同じ総量で早く帰らないといけない場合には、生産性を上げなければいけないわけです。改めて言われるとその通りと納得せざるを得ないです。

「アメリカと日本の生産性を比較すると100:62」(#SP05より)だそうです。そりゃ日本人が定時で帰れないわけです。では日本人は生産性が低いのか。日本は重要なこと以外に時間をかけすぎている、米国は本当に自分が付加価値を出せること以外にのみ集中するからそもそもの物量が違う、日本は5つに対して優先度を決めて4つぐらいまでやろうとする、米国では最優先の1つのみやる、だから生産性が低いように見える、重要な1に8割の価値があるから尚更そう見える、個人のパフォーマンスが一概に低いからだけではない、牛尾さんのセッションではそうおっしゃってました。

確かに物量は多い。現場では作業に追われているのが日常で、無駄な作業が多いように私も感じています。生産性向上の前に総量の削減が必要。概ねこの意見には賛同です。ただ1点、一見無駄なことなのかもしれないけれど、そこをやる日本の良さもあるのではないかと思う。勤勉に几帳面にやっていくその通り良さは必ずあるはず。作業量は減らすけれどその点忘れないようにしていきたいな。

個人のパフォーマンス

個人のパフォーマンスについては、米国のレベルを肌で感じたことがないので正直わからないのですが、現場を見ていてパフォーマンスが良いとは感じない。もちろんすごい方とも沢山出会ってきましたが、全体的なレベルを見ると心もとない感じがします。現場でアーキテクトとしてコードの品質チェックしていますが、どちらかというと不安になるレベルの方が多いです。

私個人としてはプログラマは高い専門性が求められる職業であると思っています。Rochelleさんもプログラマが他の業務にジョブローテーションされるのはおかしいと言い切ってました。私はこの点について、大学での教育(専門的な教育)と企業の採用(誰でもSEになれる風潮)に疑問を持ってます。この点について個人として出来ることは限られるので、現場にいるメンバでなんとかするしかないのが現状で、チーム全体の底上げをどうするかを現場レベルから考えないといけないです。

SIerのアーキテクトの役割

赤間さんのセッションでの、「開発技術の進化があれば、その恩恵により開発生産性をは改善されるはず」というのは私が日々思っていることを本当に代弁してくれたような言葉でした。SI業界にまだ10年ほどしか関わってませんが、開発のやり方は全く変わってません。これは、SIerとして反省すべき点だと思いました。もちろん個人としては色々なツールの導入や工夫をしてますが、組織全体として変わってきたかと言われればほぼ変わっていない。また、それに対して何も疑問に感じていないというのはいかがなものか。「日本のSI商習慣(多重請負構造)が問題」「SIerのプロパーが最新技術を知らない」(#DO08より)というのは実に的を得ている。アーキテクトは現場を改善していく責務があると再認識しました。

最新技術の恩恵をどう受けるのか

ソフトウェア開発のプラクティスとしてDevOpsが叫ばれていますが、日本にそのまま当てはまるとは個人的には思っていない。

Rochelleさん&牛尾さんは、DevOpsを適用するためには、欧米文化をインストールしていけば良いとはというアプローチ(8つの習慣)で、出来るところからチームで初めていくことを勧められていました。赤間さんは、DevOpsを支える色々な要素を取捨しながら取り込んでいけば良いとおっしゃっていました。やはり現場レベルから改善を繰り返していき少しずつ生産性を高める必要性があります。

その際に様々な開発技術の恩恵をいち早く受けるためには、「自動化しなくて済むようにする」つまり「巨人の肩に乗る」(#DO09より)という考え方も大切だと思いました。一生懸命仕組みを考えるというより、今の時代は「レールに素直に乗せて上げること」がアーキテクトの役割の1つなのかもしれないなと感じました。

牛尾さんのスライドです。

docs.com

さいごに

いろいろ書きました(あまりまとまっていないかもしれませんが・・・)が、DevOpsというのは手段の1つであり、導入する目的を考えないといけないことを再認識しました。今回de:codeに参加して、ソフトウェア開発の生産性向上をしたいと改めて思いましたし、出来ることから1つずつやっていき、理想形に近づけていくという地道なアプローチしかないこともわかりました。

使えるものは使っていく、VSTSやAzureなどは素晴らしいのでバンバン使っていきたいと思いました。使えるように説得するところからスタートかもしれませんが笑

VSTSでBuild Agentを設定してサンプルアプリケーションをビルドしてみる

f:id:ninna2:20170409020434j:plain:w360

Visual Studio Team Service(VSTS)は、“プライベートGit”としてチームで利用出来ますし、Visual Studioとの連携も強力です。また、Azureを用いれば、簡単に“CI/CD”を行うことも可能です。今回はVSTSBuild Agentを設定する方法を記載します。次回あたりにはCoded UI TestをVSTSから実行していきたいと思っており、そのための準備としてBuild Agentの設定をしました。ビルドサーバを独自のものを用意したいという場合には参考になると思います。

続きを読む

Azure上のVMにProxy経由でRDPする

組織に所属する限りProxyを経由しないとインターネットに出れないというのは当たり前ですね。パブリッククラウドがかなり発展してきている中で、少し不自由な時があるのが実情だと思います。セキュリティの関係で仕方ないと言えば仕方ないのですが、どうにかしたいのも事実です。Proxy配下のクライアントからAzure上のVirtual Machineにリモートデスクトップ(RDP)する方法はないものかと気になったので試してみました。

説明するがすごく難しく複雑なのですが、SSH Over HTTPで対象のサーバとSSHを確立して、SSHポート転送でRDPをフォワードするという方法でなんとかつなぐことが出来ました。

いやぁ、なんのこっちゃって感じですよね。とりあえず、絶対に忘れそうなので自分自身への備忘も兼ね方法をまとめておきます。同じことで悩んでる人の少しでも参考になればと思います。

続きを読む

Graph in SQL Server on Linuxで100万件データを試してみる

f:id:ninna2:20170504184530p:plain:w360

SQL Server 2017ではGraph形式のデータが扱えるようになりました。Graphデータがどのようなものかは、前回の投稿でやってみましたが、データ件数がそれほど多くなかったので、少し多めのデータ(とりあえず100万件)でどうなるのか試してみたいと思います。

続きを読む