Azure Boards に対する期待と実際の違い
Azure Boards は優れたツールだと思いますが、私が期待していた振る舞いと実際が違うという場合があります。 それらがどういうものなのかを列挙していきます。
該当する要望は Developer Community に載っている場合があります。実装予定の場合もあります。 これらの情報の所在がわかるものはリンクも載せておきます。 developercommunity.visualstudio.com
内容は2020年5月17日時点の Azure DevOps Services に対するもので、Azure DevOps Server に対するものではありません。
UIは英語のみ
Localization support for Team Services - Developer Community
「あれ？実はできない？」と最初に気づいたものがこれ。 難しい言葉は見当たらないので別に英語のみでもよいのですが、慣れない人はいそうに思えます。
同様にドキュメントにも日本語はありません。こっちのほうが量が多くてつらそう。 Azure DevOps documentation | Microsoft Docs
デフォルトでは Work item の ID が表示されない
Global work item column options - Developer Community
「●●の実装って終わったんだっけ？」 「えーと、123番じゃなくて145番の方の●●だよ」 のように会話で Work item の IDを挙げることは日常的だと思うのですが、 どういうわけかデフォルトでは ID が表示されません。 設定で表示させることはできます。
ただし、この設定はチームごとであり、organization 全体には効きません。 ID表示をデフォルトとし、organization 全体の設定を可能としてほしいところです。 Developer Community に同様の要望があるのですが、支持数が少なく Closed となっています。
Work item の期限が近付いたときに知らせる機能がない
Due date notification - Developer Community
Ability to set reminders on work items - Developer Community
Due Date の何日前になって Done じゃなかったら Assigned To の人にメールするというリマインダー機能がありません。 Planner にさえあるのに Azure Boards には無いのか！？と思うのですが無いものは無い。 デイリースクラムをやってれば必要ないんじゃない？ということなのでしょうか。
Work item の特定のステータスを遷移させることができるのは特定の権限を持つユーザーだけ、という機能がない
Allow specifying state transitions when using inheritance process - Developer Community
例えば、Closed にできるのはプロダクトオーナーだけにしたいという場合には欲しい機能ではないでしょうか。
これは 2020 Q2 実装予定であり、二段階に分けてリリースされるそうです。
Dan Hellem [MSFT] May 05 at 01:48 PM phase 1, state to state restrictions will be available for preview in our current sprint rollout. About 1-2 weeks. Phase 2, restrict transitions by group membership, is scheduled for 2 sprints out
Dan Hellem [MSFT] 4 days ago Phase 1 of this feature is rolling out to Azure DevOps service over the next 5-8 days. If you are interested in being part of the private preview, please email your org name to dahellem@microsoft.com.
複数の階層化された Work item をコピーする機能がない。
Work item template or clone including subtasks - Developer Community
ある親に対して決まった子の Work items があって、それをテンプレートとしたい場合には欲しい機能だと思います。
これは 2020 Q2 実装予定だそうです。
Work item から Pull Request を作る際にブランチ名を自動で決める機能がない
Set A Branch Names In Azure DevOps from work item - Developer Community
GitLab と JIRA+Bitbucket ではお馴染みの機能なのですが無いんです。 チームで決めた命名規則に自動的に沿うためには便利な機能だと思うのですが要望数は少ないです。
Work item を Markdown で編集できない
Add Markdown Support in Discussions - Developer Community
Repos では Markdown ファイル (.md) を扱えるのですが、Work item の編集では違います。 これも 意外と できないことです。 要望数は 170 を超えていますが、まだ New なので検討されていないようです。
Iteration の期間を GUI で設定する際、指定した期間を繰り返して設定することができない。
Auto create iterations or sprints - Developer Community
これをイテレーションごとに入力するのは面倒なんですよね。 カレンダーアプリだと繰り返しの予定を入れる機能があります。似た機能が欲しいところです。
Boards では Tag の色をつけられるが、他の画面ではつかない
Add colored tags to sprint board/backlog - Developer Community
Boards では Tag に色をつけられます。しかし、Work items, Backlogs, Sprints ではその色がつきません。 要望数は50を超えていますが未検討のようです。
ガントチャートがない
Gantt chart option in VSTS - Developer Community
機能も、実装予定もありません。
長期の計画を立てる機能としては Delivery Plans という拡張機能があります。 Work item 同士の依存関係を表現するには Depencency Tracker という拡張機能あります。
どうしてもガントチャートが欲しければ Microsoft Project を併用するのがよさそうです。
Test Case を Disabled にすることができない
使わない Work item type は Disabled にしてユーザーが迷わないようにしておきたいところですが、Test Case だけは Disabled にできません。 なぜなのでしょうね。
プロセステンプレートの編集にて Work item type をコピーできない、名前変更もできない
プロセステンプレートで用意されている Work item type の名前だけ変更したい、一部のフィールドだけ変更したい場合に コピーと名前変更ができると手間が少なくて済むのですが、できません。
Created Date が編集可能
Work item の State を変更した日付は自動的に記録されます。 どういうわけか Work item を作成した日だけは編集可能であり、他の状態になった日は編集不可能です。 記録を改ざんできるのでダメだと思います。 まぁ、改ざんといっても History には残るので照合はできますが、それも面倒ですよね。
おわりに
以上、私から見た意外とできないこと集でした。 これらができなくても十分採用に値すると思いますが、組織によってはクリティカルかもしれませんね。
また、Developer Community では Microsoft の方々がユーザーの要望に反応してくれますが、 彼らから見て要望の理由がわからなかったり、最後のコメントから90日過ぎると棄却されます。 なので、まずは欲しい機能があったら Vote する、無かったら新規に作る、要望の理由を詳細に書くということが貢献になると思います。
Azure Boards 入門時の Choose a process
Azure DevOps のプロジェクトマネジメント機能である Azure Boards では、要求、バグ、タスクなどのソフトウェアエンジニアリングで扱う項目を Work item という単位で扱うことができます。 Work item に相当する情報は、類似のツールで "チケット", "Issue" と呼ばれることがあります。 Azure Boards では、何という Work item を設けるかを定義し、どの画面で表示するのかを決めることができます。 この設定を工夫することによって Azure Boards を使う組織全体の活動効率向上が期待できます。
Azure Boards 入門時には、概要を理解した後に設定の工夫をすることになるでしょう。 その際に、私が思う最も理解しておくべきことが Choose a process というコンセプトです。 このコンセプトは Microsoft のドキュメントに書かれています。 これを理解できないと、同種のツールの経験があっても Azure Boards のことは何もわからないのではないかと思えるほどのコンセプトです。
何を理解すべきか順に説明します。
必ず4つの中から1つを選ぶことを理解する
Basic, Agile, Scrum, CMMI という4つのプロセステンプレートが用意されています。 プロセステンプレートによって用意されている Work item type が異なります。 Work item には State(状態) と Reason (状態遷移理由) があり、状態遷移もプロセステンプレートによって異なります。 テンプレートの内容をカスタマイズしたい場合は、カスタマイズの元をこれら4つから選んで継承し、新たなプロセスを作ります。 それぞれのプロセステンプレートを継承して my-basic, my-agile, my-scrum, my-cmmi を作ると次のような画面になります。
テンプレートを使わずにゼロから定義することはできません。
設定したい Work item type の名前やワークフローなどが既に頭にある方は恐らく面食らうことでしょう。私はそうでした。
カスタマイズするにしても必ず4つの中から選ばないといけないのです。
なので、実現したいプロセスに最も近いプロセステンプレートを選択することが有用になります。
Backlog level と Work item type と Work item 表示画面の関係を理解する
4つのプロセステンプレートの名前は Basic, Agile, Scrum, CMMI です。 選ぶ際に理解しておくべきことは、Backlog level と Work item type と Work item 表示画面の関係だと思います。
例えば Agile プロセステンプレートの場合、Work item type 同士の階層関係は以下のようになっています。
Boards 画面では、Feature を親として User Story を子とした表示か、または、User Story を親として Task を子とした表示かを選ぶことができます。Backlog level は Portfolio backlog または Requirement backlog です。
Backlogs 画面では 、Feature, User Story, Task の3階層をツリー形式で表示することができます。子を省略して Feature のみ、User Story のみの表示にすることもできます。Backlog level は Portfolio backlog または Requirement backlog です。
Sprints 画面では、User Story を親、Task を子とした表示ができます。Backlog level は Iteration backlog です。
このように、Work item の階層と Work item type と Work item 表示画面には関係があります。
Backlog level には、最上位の Portfolio backlog, 中位の Requirement backlog, 最下位の Iteration backlog の3階層があります。 Backlog level を3より増やすことはできません。各Work item 表示画面において扱える最大の階層数は3です。 親子関係の設定自体は何階層でも設定できますが、それがわかるようには表示されないのです。 例えば、Task の子に Task を設定することはできますが、Boards 画面でも Backlogs 画面でも Sprints 画面でも Task 同士の親子関係は表現されません。 なので、実現しようとしているプロセスにおける Work item type の階層数が3におさまるようにする必要があります。
3つの Backlog level に何の Work item type を当てはめるかの決定が必要であることを理解する
4つのプロセステンプレートにおける各 Backlog level に当てはめられている Work item type の名前は以下のようになっています。
- Basic では、Epic -> Issue -> Task
- Agile では、Feature -> User Story -> Task
- Scrum では、Feature -> Product Backlog Item -> Task
- CMMI では、Feature -> Requirement -> Task
Backlog level と Work item type の関係は設定することができます。以下は Agile を継承した my-agile での例です。
どれかがそのまま使えそうか、名前、フィールド、状態から考えてみましょう。 どれかが使えそうならさして悩むことはありません。
しかし、アジャイルプラクティスになじみがない場合は Epic, Feature, User Story, Product Backlog Item のどれもわからない、Requirement (要求) ならまだわかるが Requirement と呼ぶことは無いという場合もよくあるのではないでしょうか。 そのような場合は、Azure Boards を使おうとしている組織が扱う最上位の項目を何と呼ぶか、その項目と親とし Task を子とする項目を何と呼ぶか、組織における Task とは典型的には何かに向き合うことになると思います。 これは組織に Backlog level と Work item type という概念を初めて導入する機会になり得るため、熟慮すべき点だと思います。
また、Agile, Scrum, CMMI では Bug を Task と同列に扱うか、User Stocy, Product Backlog Item, Requirement と同列に扱うかを選択できます。 ここも一緒に考慮すべき点だと思います。 尚、この設定ではプロセステンプレートを設定する Organization Settings ではなく Project Settings にあり、迷いやすいのではないかと思います。
Epic, Feature などの用意された Work item type とは名前が異なるだけで内容自体は従来から組織で扱っているという場合は、既存の Work item type をリネームかコピーすればよいと思うかもしれません。 しかし、残念ながら Work item type のリネームとコピーは不可能です。 フィールドは既存のものと同じで名前が異なる Work item type を作るには、新規に Work item type を作り、同じフィールドを1つずつ作るしかないのです。
おわりに
以上、Azure Boards 入門時に、コンセプトの中から特に押さえておくべきと私が思う Choose a process について解説しました。 私は入門時に4つのテンプレートから必ず選ぶ、Backlog level は3階層までという点はなかなか理解できず苦労しました。 Azure Boards はググっても日本語情報が少ない印象です。 Azure Board を使い始める際に日本語で概要をつかむには以下の情報が有用だと思います。
合わせて本文も Azure Board 理解の一助となることを祈ります。
ヤンゴン旅行記
仕事でミャンマーのヤンゴンへ行きました。わずか2泊3日でしたが面白かったので仕事以外のことを記します。 まさか初めての海外出張先がミャンマーとは、何があるかわからないものです。
成田からヤンゴン国際空港へ片道約7時間。台湾が中間地点ってところでしょうか。ひまです。入国審査では一言も交わしませんでした。驚きしかありません。 空港には日本円からミャンマーの通貨であるチャットに両替できる店と、クレジットカードを入れてチャットを手に入れられるキャッシングのATMがありました。
ホテルとデパートの入り口では額にかざす非接触の機器で体温を測られました。 COVID-19 を警戒してなのでしょうか。 スタッフからは "96, fine." と言われて、何ちゅう体温やねんと思いきや、何秒かしてファーレンハイトであることに気づきました。 アメリカならまだしも、ミャンマーで使われているとは意外でした。
ヤンゴンの道路は車でいっぱいでクラクションが鳴りまくっていました。どのような時に鳴らしているのか最初は全くわかりませんでしたが、どうやら追い越しをするときには長く鳴らし、自分の存在を示したいときには短く何度か鳴らすようです。
そして、歩行者用の信号が全くありません。渡るには多少の勇気が必要です。6車線の真ん中を車線に沿って平然と歩いたり、渋滞中のドライバーに水や食べ物を売り歩く商人もいました。
初日はそんな光景に非常に驚きましたが2日目には慣れました。
ヤンゴンでの移動は Grab というタクシーアプリを使いました。 行きたい場所を指定すると、現在地に近いタクシーがやってきます。 支払いは事前に登録したクレジットカードで払う仕組みです。 料金は乗車前に決まり、渋滞して遅くなっても変わらないのがいいところです。 10回近く使ったところ、おおむね5分以内にやってくるのも素晴らしい。神アプリ。
ミャンマーの公用語はビルマ語。英語で書くと Burmese です。1日目に昼食をとった店のメニューはビルマ語で書かれていました。全く読めませんが、漢字のメニューがあったことと Google 翻訳の画像認識機能に助けられました。
2日目の昼食。てきとーに入った店で海鮮炒め麺を注文。これが旨味があってうまい。日本人万人向けと思える味でした。辛くありませんし。
辛いといえば、この写真にはありませんが、付け合わせのサラダがこの旅行の中で一番辛いものでした。伏兵すぎる。
ミャンマーで初のクラフトビールブルワリー Burbrit Brewery に行きました。
東南アジアのビールというと、シンハー、タイガーのような軽いものを思い浮かべていたのですがそうではなく、
ヴァイツェン、レッドエール、ポーターといった欧州の味でした。
店員の好意で醸造設備を少し見ることができました。メニューにはないフレーバーを試しているそうです。
こちらは Burbrit Brewery 近くの風景。首輪をしていない犬が何匹かいます。人懐っこい振る舞いでしたが、触れ合うのはやめておきました。
わずか2泊3日での印象ですが、ミャンマーの料理はタイ、中国、インドが合わさったような印象でした。 米の麺、長粒種の米、インドのようなカレー、わりと脂っこい炒め物、バクテーのような薬膳らしいスープ、海鮮由来の旨味、酸味と辛味のある薬味が特徴に思えました。
シュエダゴン・パゴダにも行ってみました。ヤンゴン市内にある巨大な寺院です。 外国人専用の受け付けで入場料10000チャットを払い、裸足で入場します。 敷地は広大で、どこもかしこも金色。日本の仏教とは全く違うようです。 場内には観光客だけではなく、地元の参拝者も多くいらっしゃるように見えました。 見回っている間にお経が延々とスピーカーから聞こえてきて、何かを再生しているのかと思いきや、生でした。 長いときは3日3晩通して読むそうです。それも修行なんでしょうか。
仏像や鐘などの展示物の横にはQRコードが掲示されていて、専用アプリで読むと解説ビデオを見ることができました。 フィンランドで戦車を展示している施設にもこんなのがあったっけなぁ。
こちらの仏教では水曜日を2つに分けた八曜日があり、自分の生まれた八曜日が重要とのこと。
曜日ごとに像があり、自分の八曜日の像に水をかけるのが参拝の作法だそうです。
像のどこにかけるか、何回かけるか、など聞いてみましたが、テキトーでいいとのことです。テキトー。
撮ってもらいました。夜になったら絶景だろうことは想像がついていたのですが、帰りの飛行機の都合上やむなく帰りました。
何も予定が無ければ瞑想したかったなあ。
JaSST'20 Tokyo RejectCon
勢いでブログ枠に参加登録していたイベントに参加しました。
なぜ「わかった」と返信したのか、今でも覚えていません。 「そういうこともあるか…」と勤務先から前向きに会場へ向かおうとした矢先、お気に入りのジャケットが派手に破けました。心も破けそうになりました。わかった
— Mass Kaneko (@masskaneko) January 29, 2020
主催の tsuemura さんとは彼がソフトウェアエンジニアになる前からの間柄です。 昔から変わらないなと思うのは物おじしないことで、イベント慣れしているという印象でした。 特に、「節度を守っての行動をお願い致します」とアナウンスした直後に 「今日は節分なので拍手の代わりに豆をまいても結構です」と述べて、節度とは一体何かわからなくなったのが最高でした。
以下、発表ごとの感想です。 私はモバイルと Web はよくわかりませんし、聞き飛ばしてしまった部分もあるので、変な理解をしているかもしれません。
note でのテスト自動化に関する取り組み
iOS アプリのテスト自動化のお話でした。 Web は毎営業日デプロイしているけど iOS アプリはそうでもなくて、リグレッションチェックを効率化したいとのことでした。 「5種投稿、会員登録、ログインくらいができれば」と言っていた覚えがあります。スモークテストなのかなと理解しました。 ツールにはサポートが早いことから magicpod を選んだとのことです。
QA部門にいる発表者と一人の iOS エンジニアが組み、週15分の定例会議を設け、毎日一回リリース版で実行という形で歩み、変更箇所に集中できるようになったことが良かったことだそうです。 はまりを解消するためにエンジニアを巻き込むのが大事とのことでした。 どのようなはまりなのか聞き逃してしまったのですが、iOS アプリ固有のテクニカルな何かだったのでしょうか。 Pull Request をトリガーに実行すると時間がかかるそうで、Android の方が早いそうです。
発表者の増原さんは #ソフトウェアテスト タグがついた note 記事を書くとQA部屋に流れてくる仕組みを作っているそうです。
サービス愛と職業愛があるなあという印象でした。
リベラル・アーツの世界〜Flow理論に学ぶレベルアップの鍵〜
冒頭で「ソフトウェアテスト一切関係ありません」とのたまってヤベェなと思いました。 お話は面白くて、個人のレベルアップに適した状態を "フロー体験とグッドビジネス (チクセントミハイ著)" を参照して語るものでした。 横軸に能力、縦軸に挑戦を設けたメンタルステート図では、不安、退屈、覚醒、コントロール…そして最も右上のフロー状態という領域があり、 フロー状態へ至る際のルートについて語られました。簡単に言えば、能力を上げるのと、挑戦的なことに手をつけるのと、どちらを先にするかということです。 挑戦ルート、能力ルート、という言葉が使われていました。
発表者は、テストコードを書いているときはコントロール領域にいて、以前は心配の領域にいたのではないかという自覚があるそうです。 メンタルステート図が頭にあると、そういった振り返りができそうです。
フロー体験という言葉は初めて聞きました。
「ゾーンというとわかるのではないか？スポーツの世界はゾーンになりやすいように設計されている」
という説明があり、そういえばゾーンであればどこかで聞いた気もしました。
ただ、私のイメージでは、スポーツにおけるゾーンというのは1秒が10秒に感じるような集中している状態であって、
技術者のレベルアップに適した状態とは時間単位がずいぶん違うのではないかという印象を受けました。
さて、これは RejectCon でしたよね。これはどうすれば Accept されるのだろうか…と考えると、
…という案が出てきました。いやはや。#JaSST_RejectCon
— Mass Kaneko (@masskaneko) February 3, 2020
同じ能力の人を同じ人数集めて、挑戦ルートと能力ルートに2分させて実験して、挑戦ルートの方が早く育つけどメンタル死ぬ人が多いみたいな鬼畜結果出してもう一度投稿しては
WebアプリケーションE2Eテスト自動化の3つの壁
WebアプリケーションE2Eテスト自動化3つの壁 - Speaker Deck
Web のことはちょっとしかわかりませんが (チョットじゃないぞ)、 何が理想と異なるのか、賢いツールがあるのか、わかりやすいお話でした。
実行速度の問題解決方法としてテストデータをAPIやコマンドで作るというところがよくわかりませんでした。 お話ではView A→B→C があるとき、B, C の前に Aを操作しなければならないとのことでした。 それはわかるのですが、View A に遷移することや、View A での操作をすることを "テストデータを作る" と言うのでしょうか。 また、それらの操作をするための API またはコマンドは備わっていることが普通なのかがわかりませんでした。 「そんなのないよ」という場合も結構あったり？と想像しました。
おそらくこれを含め、お話の最後で「E2EでなくてもいいテストをE2E環境でやっている」と述べられました。 例えば画面表示だけテストしたいときにサーバーサイドとの通信がいらないみたいな場合があって、 でもそうした部分的に動かす仕組みを作るのが難しいのかも、と想像しました。
また、Accept を狙うなら3つのうち1つの壁に絞って特定プロジェクトの改善事例とするか、 沢山の改善事例が3つの壁に当てはまるという話にするか、かなーと思いました。
プロダクト開発におけるアジャイルQA活動
JaSSTRejectConf - Speaker Deck
査読者からの Reject 理由が述べられていて、RejectCon らしい発表だと思いました。 健康を診るという例えは私が前々から意識しているので親近感がありました。 プロダクトまたは組織が今は動いているけど急病になるリスクを検知して手を打つということですね。 具体的なリスクの種別、見つける方法、対処方法を掘り下げると事例発表らしいのではないかと思いました。
なんかだんだん批評家っぽくなってきたぞ。
テスト？自動化？それよりもQA/QCの業務とは（仮）
JaSST'20 Tokyo RejectCon for Session - Speaker Deck
サービスが世に出て何年か経った組織によくある状態はこうなのかも、と想像させられたお話でした。 対ユーザーの活動よりも開発組織内の活動に焦点を当てていたので QA よりも QC のお話だと思いました。
Webサービス企業において Qが頭につく job が個々の開発チームに入るか俯瞰するかという話って どこかで聞いた覚えがあって、掘り当てると何か理解が進むかも。(LIFULL が俯瞰型でメルカリが入り込み型だったような？？)
ウォーターフォール（V字）開発でモブ設計してみた
週一回二時間30分交代とのことなので、ソロが中心で、力を入れる時にモブとしているようです。 見間違いでなければ、人数は開発3人、テスト4人と書いてありました。テストの人が多くありませんか？
本編とは関係ありませんが、そろそろVモデルに全く出会わないキャリアを歩んでいる方も珍しくないだろうなと想像しました。 生まれたときからスマホがあって、ガラケーを見たことがない、という感じで。どうなんでしょうね。
さいごに
発表者の皆様、運営、会場提供をしてくださった皆様、ありがとうございました。
RejectCon っぽくないけど面白かった！というのと、査読者コメントや採択率などの RejectCon っぽい話も聞きたかったというのと、両方ありました。
また、職業柄なのか、事例発表が IMRaD (Introduction – Method – Results – and – Discussion) の構成になっているかを無意識に期待するので、 そうでない構成が多かったセッションを聞いて、「別にそうじゃなくていいのよ」と言い聞かせたりしてました。
あと、ソフトウェアシンポジウムのプログラム実行委員長から論文出せって言われて、うっかり「ネタあります」と答えてしまいました。 さすがにブログ枠ありますに対して「わかった」と応えるのとはわけが違うと思うのですが、はてさて…。
ボーイング737におけるソフトウェア外注の結果
Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers
長い原文を私から見て要約/意訳するとこうなります。
- ボーイングは航空ソフトウェアの開発費を減らすためにオフショアを企業戦略として大々的に検討。H1B ビザで渡米している優秀な技術者に頼ると時給 $35 になるのを減らしたかった。
- 時給の安いインドのソフトウェア開発企業に外注することに決めた。中には時給 $9 の人も。
- ただし、この企業は航空ソフトウェアの開発経験がなかった。
- ボーイングはこのインド企業に、できるだけ上位の仕様を送り、より下位の仕事を任せるようにした。
- その結果、航空業界人から見れば自明な仕様の理解に 18 回もやりとりするなど、ボーイングの社員はより多くの監督作業をすることになった。
- 作られたソフトウェアは、ボーイングが培ってきた設計原則に違反していた。テストもろくにされなかった。
- 監督作業や彼らの誤りの修正を換算すると、安くしたはずの時給は $80 にもなっていた。
- ボーイングのベテランエンジニアは、「ボーイングの設計者の能力は時間と共に低下しているように見える」と語った。
- 結局、新製品の市場投入は 3年も遅れ、予算も数十億ドルオーバーした。
- ソフトウェアの欠陥によって、2018年10月と2019年3月に2件の墜落事故を起こし、346人が死亡した。
- 長年ボーイングの技術者を務め、2015年から CEO となった Dennis Muilenburg は「これまで外注していたソフトウェア開発を内製に戻す」と述べた。
私の知識と経験では、高品質なソフトウェアを開発するには、医者が持つような体系的知識とスキルに加え、数学者やアーティストのようなセンスが求められます。 ユーザビリティが重視されるゲームやモバイルアプリ、セーフティが重視される自動車や医療機器など、製品分野によって求められる品質は異なりますが、 ベースとなる知識・スキル・センスは同じです。重要なのは素人にはできないということです。
素人でも、高校までに文系でも概ね身につくであろう命題論理・述語論理をもとに要求仕様を自然言語で書き、簡単なループや条件分岐のあるコードを書くことは 見よう見まねで可能でしょう。しかし、それだけでは、影響範囲を局所化して再利用するための構造設計、高速なアルゴリズムの設計、システムの一部が故障しても継続稼働可能な信頼性、バグを狙い撃つテスト設計、 成果物間のトレーサビリティ確保、円滑なバリューストリームを実現するツールチェーン、ソフトウェアの特徴を考慮したプロジェクトマネジメントと品質保証といった、 高品質ソフトウェアに求められるエンジニアリングは到底実現できないことでしょう。
中には、工学や科学を専攻していなくとも、独学と実務経験をもとにソフトウェアエンジニアリングのスキルを身につける方々がいます。 大学でソフトウェアを学んだ人を追い抜くケースも見ますが、そう多いものではありません。
なので、企業は能力の高い人材を探したり、育つ仕組みを整備することが重要です。 そして、そのような人が自国に限られるのであれば、海外に活路を求めるというのは良策かと思います。 それはオフショアという呼び方かもしれませんし、その企業のグローバル開発拠点かもしれません。
逆に、人件費を下げたいだけがために経済発展途上国の企業に外注すると、自分の首を絞める結果となるのではないかと考えます。 ボーイングの件は、それを示す良例ではないでしょうか。
それは能力不足によることだけではありません。 オフショアに限らず外注の場合、要求仕様に基づくものさえ作れば売り上げることができるので、ユーザーにとって価値のないソフトウェアを作るリスクがあります。
外注か内製かについて、どのような条件であれば、どのようなバランスをとるのがビジネス上最適なのか。 それを工学的、統計的に示すには多くの実験をしなければなりません。
そのような工学的、統計的な判断を時間をかけて行うか、 センスや信念をもとに素早く定性的な判断をするかという概ねの二択があります。 企業にとっては前者を選択する余裕は無いと思います。 ボーイングはソフトウェアエンジニアリングにおけるセンスのない経営者が後者を選択して失敗したのではないかと想像しました。
さて、このブログがソフトウェア開発に携わる誰かの目に留まり、何らかの意思決定に影響するでしょうか。はてさて。
全身麻酔で親知らずを3本抜いた
親知らずを一度に3本抜くというのも、全身麻酔をするというのも、入院するというのも初めての体験だったので記しておきます。 これを書いているのは術後1ヵ月～2ヵ月です。結果から書くと手術はうまくいき、そこまで辛くはなく、やってよかったと思っています。
手術をした経緯は、親知らずの前の歯が痛んで近くの歯医者を受診したことに始まります。 その歯を治療をしたいのですが、後ろの親知らずを抜かないと治療ができないことがわかりました。
以前に1本だけ親知らずを抜いたことがあります。 そのとき、治療器具を奥に入れられると吐きそうになることがわかりました。嘔吐反射が一般人よりも強いらしいです。 当時は我慢を重ねてどうにかなったのですが、ものすごく辛くて同じ苦しみを耐えられるかわからなかったので、楽な方法がないか助けを求めました。 そういった場合、全身麻酔下で手術をするという手があるそうです。 全身麻酔をする際には泊りがけの入院になるとのこと。 そこで「そんな大掛かりなことをするなら残りの親知らずも全部抜いてください」とお願いし、大きな病院を紹介されました。
いきなり入院をするわけではなく、全身麻酔ができるかどうかを検査しました。 血液や心電図までとられたのですが、そういうものらしいです。 麻酔医から麻酔時に行うこと、検査の理由、リスクについて丁寧な説明を受けました。
この検査と説明を受けてから入院をするまでの間は2週間ほどだったでしょうか。 入院、全身麻酔、手術というのは初めてのことなので、予習でもしておこうと YouTube を見ることにしました。 世の中は YouTuber だらけなので "親知らず全部一気に抜いた" といったものがあるだろうと踏んで探したところありました。 あるもんですねえ。
全身麻酔で親知らず3本一気に抜いた結果・・・ - YouTube
私の場合、1日目は主に検査、2日目に入院、最後の3日目は午前中に退院するというスケジュールでした。
1日目：準備
10時ごろに病院へ。病室は個室で、ベッド、トイレ、クローゼット、貴重品入れがあります。 個室といってもホテルのように鍵つきのドアがあるわけではなく、入口にはカーテンがあるだけです。
食事は昼食と夕食の2回。 病院食はおいしくないものと知人からは聞いていましたが、意外とそうでもありませんでした。
この日は検温や血圧測定などの簡単な検査、麻酔医の問診、執刀医の問診、歯のクリーニングがありました。 それら以外は暇です。 術後何日かは満足に食事をとれなくなるだろうからと考え、 ちょうど YouTube で公式配信されていた孤独のグルメをずっとみていました。
2日目：手術
いよいよ手術当日。6時30分に起床。早い…早すぎる…といっても看護師が各病室を周るだけで、二度寝してよいとのことでした。 この日は朝食と昼食はなく、水を飲むこともできません。 水を飲めない代わりに点滴があります。たしか10時ごろに点滴の器具を腕に設置しました。 そして手術着に着替えました。見た目は完全に病人です。 私の番は前の手術が終わり次第だそうで、何時に始まるか決まっていませんでした。 結局10時ごろに準備ができてから手術が始まるまでに3時間くらい経ったでしょうか。とにかく暇でした。
手術のお呼びがかかったときには「待ってました！」という気持ちで手術室に向かいました。 自分で歩いて手術室に入り、自分で手術台に上がりました。 テレビドラマなどで見る患者はことごとく手術室に運ばれていたのでどこか新鮮でした。
手術台に上がると「これから麻酔薬を入れていきます」と告げられ「はぁい、おねがいします」と応えました。 その次の記憶は病室に戻されるときでした。その間のことは何も覚えていません。
病室に戻されるとき、おそらく2人か3人がかりでベッドに私の体を置こうとしていたのだと思います。 看護師らが私の体を動かす瞬間、私はタイミングを合わせて「せぇのッ…」と言ったのを覚えています。 看護師らが「運ばれる患者が "せぇのッ" って言うのは珍しいねえ」と言っていたのも覚えています。
ほか、ベッドに戻って直後のことはよく覚えていません。 手術が終わったこと、何やらマスクのようなものをつけていることだけわかりました。 しばらくすると思考がはっきりして、不快感が出てきました。 抜歯箇所の痛みはそれほど強くないのですが、口に血がたまっていたり、 喉にも血か淡がたまっている感覚がありました。 そして、それらを吐き出したいのですが、体がうまく動きませんでした。 あれこれどうにかしようとしているうちにシーツを真っ赤に汚してしまいました。 さらに、頭痛がして熱も出てきたので抗生物質を投与しました。 これが術後2時間後のことです。
さらに2時間ほど経つと夕食の時間となり、8時間ほど付き合った点滴も終了です。 この日は朝も昼も食べていないのですが食欲は全くありません。 術中に口をずっと開けていたせいなのか、口の端が切れていてかさぶたになっているので口が満足に開きません。 抜歯箇所は糸で縫ってあるそうなのですが、常に少しずつ出血しているので血の味がしています。 抜歯箇所が鋭く痛いわけではないのですが、常に鈍い痛みがあって口を動かしたくありません。 それでも食べないと治らないと考え、一口噛んで飲み込むごとに気力を振り絞り、完食しました。 前日と違って料理は全て細かく刻まれており、米は米でもおかゆでした。 健康であれば5分や10分で食べて終えてしまいそうな料理でしたが、このときは30分以上かかった覚えがあります。 看護師は完食したことに驚いていました。
食後は調子がよくなり、病室から出て休憩室でコーヒーを飲んだり、家族に手術が終わったことを連絡したりしました。
3日目：退院
この日も6時30分に起床し、朝食までの間しばし二度寝。 痛くて目が覚めるかもしれないと懸念していましたが杞憂に終わりました。
朝食は手術当日の夕食と同じく全く箸が進みません。 相変わらず口は開かないし、血の味がします。 料理も同じく細かく刻まれたり柔らかく煮込まれているのですが、噛んで飲み込むには時間がかかります。 バキという漫画とアニメの作品にて主人公が毒におかされたときの場面を思い出しました。 薬膳料理を「ウマくはないぞ」というセリフと共にふるまわれたり、 恋人に「食ってないじゃん！」と泣きながら叫ばれたりする場面を思い出すと、 食欲そのものは無いものの、治したいという気力が出てきて完食することができました。 病は気からというのはこういうことでしょうか。
朝食後、簡単な問診と直近の生活指導を受け、抜糸の予定日を決めたら退院です。 かかった金額は事前の検査も含めて約10万円でした。病室が個室ではなく相部屋であればもう少し安いでしょう。 虫歯になりやすい親知らずを一気に抜くことができ、その前の歯を磨きやすくなるのであれば安い金額だと思います。 抜歯された親知らずを見ると2本は割られていました。あごの骨を削り、歯を細かくしないと取れなかったそうです。 嘔吐反射のある自分には耐えられなかったのではないかと想像します。 退院後のダメージとして大きいものはありませんでしたが、退院して1週間ほどは集中力が続きませんでした。 それを差し引いても行って良かったと思っています。
さて、親知らずの抜歯は順調に進んだのですが、その前の歯は今でも治療しています。 早く親知らずを抜歯して治療を始めていれば、とほほ。
GitLab Meetup Tokyo #12: 2018年振り返り に参加しました
GitLab ユーザーなので GitLab のイベントに参加してみました。
上記イベントページの概要欄をみると、GitLab ってどんどん成長しているんですよね。 基本的には Git リポジトリホスティングシステムで Issue トラッキングと CI もできる奴、 昔で言えば Trac Lightning みたいな立ち位置かなー(伝わるのか？これ)、という認識だったのが…… Docker イメージを登録できたり、IDE を備えたり、「もうみんな Kubernetes クラスタあるよね」とばかりに Auto DevOps を出したり、 最近では Serverless なんてものまで出てきました。
本家ブログに We believe Kubernetes is the future. と書いてあるのを知り、 「あぁ…そっちに行ったんやなぁ…」という気持ちです。 GitHub および Circle CI, あとは Atlassian 製品のように役割別に製品を分けている同種のツールとは方向性が違うなぁと思わされました。
また、チームでコラボレーションをする環境というのは、幅広い業種や職種に関わるものなので どういった方々が来ているのか知りたくなったのも参加した理由です。 GitLab は Kubernetes が未来と信じる方向に進化しているそうですが、別にコンテナやサーバレス環境で動作する ソフトウェア以外の開発にも使えるので、Web システム以外の世界の方々も来るんじゃない？と思ったんですよ。
とまぁ、知らない機能も沢山あるし、どんな人が来るのか気になったので参加することにしました。
GitLabとKubernetesではじめるAuto DevOps
イベントが始まる30分前に Google カレンダーの通知がありました。 イベント会場まで1時間かかります。遅刻確定です。 アラームを何分前に鳴らすかはイベントによって変えておきましょう。 このブログもイベントが終わってから1ヵ月後に書いているので二重の意味で遅刻してしまいました。 しょんぼり。すみません。
"GitLabとKubernetesではじめるAuto DevOps" の途中から聴講し、ちょうど Auto DevOps のデモを行うところでした。 デモは Spring を使った簡単な Web アプリを変更する際にパイプラインに含まれる様々なジョブが実行され、 Merge Request の画面にも表示されるというものでした。 実際に使われたプロジェクトが今でも公開されており、パイプラインの詳細な実行結果を見ることができます。
デモで使われた sprint-app プロジェクトがあるグループ名は
イベント当日は demo-auto-devops という名前だったのですが、
今は cl-demo という名前に変わっています。
古い URL を開くと新しい URL にリダイレクトされ、
Group 'demo-auto-devops' was moved to 'cl-demo'. Please update any links and bookmarks that may still have the old path.
と表示されます。親切ですね。
Auto DevOps だけでなく Issue やラベルについても触れているのが丁寧だと思いました。 それもそのはず、発表者は日本で GitLab の正規販売代理店に勤めており、コントリビューションも行っている方でした。
LT
ここからは LT (ライトニングトークス) のお時間。 ライトニングといっても、稲妻のような速度で話すわけではありません。しみじみ。
GitLabソースにコントリビュートしてみて勉強になったこと
GitLab Summits 改め GitLab Contribute | GitLab の参加費用は 2499 USD ですが コントリビュートすると無料になるそうで、そのためにコントリビュートしたそうです。 オープンの Issues がたくさんあり、API の変更であれば UI が無いので簡単そうと考え、1つを選んだとのこと。
所要時間は GDK (GitLab Development Kit) のインストールに4時間、 最初のコーディングに1時間、1回あたりの CI パイプラインに3時間、 レビューとそれを受けての変更に10日。
レビューでは「ローカルで Rubocop を使おう」「TDD で書こう」「あそこのコードが参考になる」 といった助言を頂けた、誰かに頼まなくてもコメントをもらえたのがありがたかった、 テストコードが頼りになったとのことです。
自発的に Merge Request に参加する方がいるというのは良いチームですね。
API の変更であることと、Merge Request がクローズするまでに11日間要したことからすると、 該当する Merge Request は多分これですね。複数のレビュアーが助言している様が見られます。 1st contribution というラベルがあるのも面白いです。 もちろん CI パイプラインにある各ジョブの実行履歴も残っています。 開発手法を勉強する材料としても良さそうです。 gitlab.com
(仮) 独自パッチで進化させ過ぎたGitLabのOmnibus package移行
GitLab がバージョン4の頃から使っており、不足していた点を独自パッチで補っていたとのこと。 例えば公式では MySQL を使っていたのをパフォーマンスのために PostgreSQL にしたり、UI を変更したり。 独自パッチの数は 30 以上になっていたそうですが、公式 omnibus package が育つにつれ、 独自パッチをあてる利点や必要性が無くなっていったので omnibus package に移行したとのこと。
私も omnibus package を使ったことがあるのですが、初めて使ったときは既にバージョン8でしたし 独自パッチをあてるという発想はありませんでした。 もちろんソースからビルドするということもなく、Ubuntu にパッケージをインストールして gitlab.rb を書き換えて gitlab-ctl reconfigure を実行する程度のことしかしていなかったので、 別の世界のお話に聞こえました。
確か別の事例で「社内には Ruby on Rails の開発経験を持つエンジニアが多数いたから GitHub Enterprise を使わずとも GitLab (Community Edition!!!) でやっていけると判断した」 という趣旨のものがあったと記憶しているのですが、そういう企業でないとやっていけないのではないでしょうか。 というか、それだけできるなら本家にコントリビュートすれば良かったのでは、というのが感想です。 まぁ、今でこそ上述のようにコントリビュートしやすい土壌が整っているように見えますが、 バージョンが古かった時代は違ったのかもしれませんね。
GitLab-CI/CD+Pagesでポートフォリオを作ってみよう
ソフトウェアエンジニアの中には作品を集めたWebサイトをポートフォリオと呼んで公開する方がいます。 この発表ではそのサイトを GitLab を使って作ってみようというものです。 スライド自体も GitLab にある reStructed Text と Reveal.js を使って作っているようです。 GitLab-CI/CD Pagesでポートフォリオを作ろう
ポートフォリオはこちら。 Portfolio of attakei
Reveal.js はちらっと見たことがあるんですが reStructed Text で書けましたっけ…？ と思ったところ、どうやらそれを実現するものを作ったみたいです。すごい。 github.com
そういえばこのブログもこのイベント参加を機に Hugo + GitLab pages に移行しよう、 それが終わったらこのイベント参加エントリーを書こうと考えていたのですが、 見た目を考えたり、検索機能をどう実現するか調べたり、結局ブログサービスに戻したという文章を見たりして ずるずると1ヵ月経ってしまったので、先にこの文章を書くことにしました。とほほ。
スポンサーLT
スポンサーは Grooves 社です。 頻繁に勉強会のスポンサーをしているそうで「また出たな Forkwell」とツイートされるのが恒例になっているそうです。
なるほど。https://twitter.com/search?f=tweets&q=%E3%81%BE%E3%81%9F%E5%87%BA%E3%81%9F%E3%81%AAForkwell
私は Forkwell Jobs を以前から知っていたので「なるほどこの会社か！」と思いました。 Forkwell Jobs はソフトウェアエンジニア向けの求人サイトで、プロダクト、職務、開発環境などが エンジニア目線で書かれていると感じられます。 転職するわけではなくても、いろいろな会社の開発環境をざっと知ることができて面白いですよ。
ところで「また出たな Grooves」ではなく「また出たな Forkwell」なんですね。なんでだろ。
懇親会
ここからは懇親会。12月20日なので忘年会とも言えます。 料理はお寿司とピザ。私は Connpass などで参加するイベントの懇親会で寿司が出た場合もピザが出た場合も経験していますが、 寿司とピザの両方がそろっている場合は実は初めてかもしれません。お酒もあります。 きっとスポンサーの Grooves 社のおかげです。「ありがとう Forkwell」とツイートすべきだったのではないか…と思いながら乾杯しました。
こういったイベントでは友人がいることも多いのですが今回は知り合いは誰もいません。 あんまりお話は得意ではないのですが、せっかくなので初めての方々とお話しました。
話してみると色々な方がいらっしゃいました。 コンテナオーケストレーションは当たり前という環境の方、 LT であったような独自パッチを使っているという方、 インフラ運用に使っているスクリプトを管理するために GitLab を使い始めたという方、 Git をこれから始めるという方、会社のサーバーはほとんど Windows だけど Linux もあるという方、などなど。 業種は聞く限りは必ずしも Kubernetes やクラウドネイティブに技術的に縁がありそうな方々ばかりではなさそうに思えました。
社内SNSの投稿でこのイベントを知って参加したという方もいらっしゃいました。 で、それを投稿したのは私だと。えっ？？？そういうこともあるんですね。
「海外では Enterprise Edition を使うのは普通。日本ではあまり使われていない。」 という情報も得られました。 これを聞いたとき、JIRA と Redmine の海外と日本での違いを思い出しました。 Google トレンドでみると、海外では JIRA の方が検索キーワードとしての人気が圧倒的に高く、 日本では Redmine の方が高いそうです。なんなんでしょうね。
- 世界の JIRA vs Redmine https://trends.google.co.jp/trends/explore?q=JIRA,Redmine
- 日本の JIRA vs Redmine https://trends.google.co.jp/trends/explore?geo=JP&q=JIRA,Redmine
最後に。ラッキーなことに GitLab 帽子を手に入れることができました！
今は冬で実用性がありますし、友達に自慢することもできます。ありがとうございます。
以上、1ヵ月遅れのブログ枠でした。
