認定スクラムマスター研修レポート

こんにちは！ Holmesの吾郷です。

少し前になりますが、 2019年1月から本格的に運用スタートしたスクラム開発を経て、 2020年1月から新チームのスクラムマスターを務めることになりました。

それにあたり、会社から認定スクラムマスター研修を受ける機会をいただき、 無事に認定スクラムマスター資格を取得できました。

スクラムについてはスクラムガイドを参考にしてください。 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

研修概要

いくつか研修を開催している団体がありますが、

今回は株式会社Odd-e Japanさんが開催する研修に参加しました。 www.odd-e.jp

講師は日本人で唯一の認定スクラムトレーナーの江端さんです。

研修で認めてもらえると試験の受験資格を獲得できます。

無事、試験に合格すると下記資格を取得できます。 www.scrumalliance.org

1日目

午前

　スクラムとはなんぞや、スクラムマスターに必要な要素・役割を学習しました。大まかに以下が印象に残っています。

• スクラムの目的とスクラムを通して得たい目的を区別すること
• スクラムマスターは、スクラムが適切かどうかを判断する（マスターとついてるだけに）
  • スクラム以外の方法論も知っている必要がある
• スクラムはプロジェクトの現状を把握するフレームワークである
• スクラムの世界では、人が言った言わないではなく、事実に基づく特定できる情報のみを扱う
• スクラムはチーム中心型組織である
• スクラムにおいては権利と責任が同居している
• スクラムマスターは安易に提案・遂行してはならない。
• スクラムマスターの五大スキル
  • Teaching
  • Facilitating
  • Mentoring
  • Coaching
  • Situationaling

気づき

　スクラムは、改善の為のフレームワークと思っていましたが、改善ができるかどうかは別物でした。
　また、スクラムマスターとなるには、まだまだ知識が足らないことに気づきました。前提として、別の開発手法を知っていることが大切で、さらに学問的知識（集団心理学、組織論）をしっかり学ぶべきだと感じました。
　冒頭でも書いてますが、開発チームの一員だった頃は、思ったことをすぐに提案してました。しかし、論理的となると一度自分の中で落とし込み、チームに効果的な提案をする必要があります。POとチームの両者の連携を促進する立場として、両者から信頼されていることはとても重要です。そのためにはいい加減な言動をしてはならないということです。

午後

午前で学んだことを使ったグループワークを行いました。 トレーナーから出されたお題に研修参加者から提案を行うというものです。

条件は二つ

• 発言は論理的であること
• NGワード（とりあえず・まずは・一旦）

気づき

これは本当に難しいお題でした。 発言時に論理的でなければ、トレーナーから指摘を受けます。頭の中で論理的な提案を考え続けます。
初日だったこともあり、基本的に指摘が多く出ていたように思います。 午後はほとんど発言できなかったと記憶しています。

お恥ずかしながらその日の振り返りも掲載します。

自分の意見をなかなか共有できなかった。

因果を捉え、説明できるようにする

固定観念に囚われ、柔軟な発想ができなかった。

2日目

午前

主にスクラムの構成要素について学習しました。大まかに以下が印象に残っています。

• Feedbackについて
  • 人とモノは分けて考える
  • 弱点/補強的であること
• PBI（Product Baclog Item）は一つ一つがプロダクトであること。（顧客に提供できる単位）

気づき

　自分も以前経験したことがあるのですが、スプリント毎に提供可能なプロダクトを作っていかないと、まとめてリリースする直前にリリーススプリントなるものを経験しないとならず、たくさんの不具合が出て大変なことになります。提供可能状態を維持し続けることの大切さは身に沁みて感じました。。。

午後

前日からのワークを引き続き継続して行いました。
結果としては提案の内容の決め型を決めることに終始していましたが、冒頭で発言できそこから議論が活性化したように感じ非常に嬉しかったです。

気づき

前日の夜から、練って練って練ってだした一言ですが、論理的であることの大切さを感じました。
また、参加者の方が、ボードや紙を用いて説明し始めたりと言葉のみではなく道具を使ったディスカッションも活発になりました。

２日目の最後には、トレーナーから、どういう戦略指標をもっているのか？という問いにハットさせられたことも覚えています。また、行動しないと評価されないという厳しいお言葉も参加者には投げかけられました。

3日目（最終日）

午前

見積もりとDONEの定義について学習しました。大まかに以下が印象に残っています。

• 相対見積もりは精度が高く、スクラムに適している（現状がわかるため）
• ベロシティは生産性指標ではない
• DONEとはProductを提供できる状態である
• スプリント毎の提供状態を作ることでVolatilityを下げるようにする

気づき

DONEの定義に関しては、例えばアプリケーションによっては推奨環境などをもともと設定している物があると思いますが、推奨環境という制限をかけていることはすべてのユーザに提供できる状態ではないことから、DONEの定義を満たしていないと判断になります。なるほど、、、となりました。つまるとこ、そういった不可避なUNDONEというのは存在するはずで世界中の企業がUNDONEが少しでもなくなるように動いているとのことです。 また、DONEの定義の学習の過程で、DONEの定義をできていると言える状態にもっとも近い企業はNetflixであるということを学びました。今度遊びに行ってみたい。。。！

午後

前日に引き続き、お題に対してどう決めていくかのディスカッションです。 ある程度、方向が決まっていき最後には決め方が決まりかけるところまではいけました。 結局、トレーナーに提案するところまではいけませんでした。

• 決める上での判断のための優先順位が必要であること

気づき

集団での合意を行う上では、個々の判断基準が異なると難しくなります。 今回自分たちは、議論をすすめる上での判断基準を設けずに走ってしまったことが低迷した原因の一つでした。

最後に

今回、エバッキーこと江端さんの研修を受けました。噂通り、へとへとになる研修でした。笑 ただ、非常に気づき、学びも多く、さらにトレーニングによって実践的に経験・理解することができたと思います。そんな成長する機会をいただけた会社に感謝すると共に、継続的にスクラムマスターとして成長していきたいと感じました。 次はCSPO，CSDも受けてみたい。。。。！！！！

Holmesはエンジニア・デザイナーを募集しています。
興味を持っていただけた方は、こちらからご連絡ください！

lab.holmescloud.com

lab.holmescloud.com

オンライン勉強会を運営してみて

こんにちは、id:c-terashima です

長野のエンジニアを盛り上げようと「長野Javaユーザグループ（通称：ながのJava）」を立ち上げ、3/25に第1回目の勉強会をオンラインで開催しました

nagano-java.connpass.com

オンラインでの開催ということもあり、県外の方も含め多くのエンジニアにご参加いただき感謝しております
この場をお借りして改めて御礼申し上げます
ありがとうございました！！
初めての勉強会運営・オンライン開催で反省や気付きがあったので、共有しつつ次回に活かしていきたいと思います

登壇者集め

connpassやTwitter、Facebookで開催告知や登壇者を募集したものの、なんの実績もない地方の勉強会に登壇してくれるエンジニアが現れるわけがありません
オフライン勉強会であれば、集まったメンバーで「もくもく会」や「○○を議題にワーク」みたいなことも可能ですが、オンライン勉強会だとなかなかそういう訳にもいかず。。
「登壇者は自分だけでは...」という不安を常に感じてました
他のJUG勉強会も事前にお願いしているそうなので事前準備をしっかりしようと反省しました

反省

• 登壇者は事前に見つけてからイベント公開すべし

発表者が寂しい

オフラインの勉強会であれば、目の前に聞いてくれている人がいて反応もあるのですが、オンラインだと

• 声が聞こえているのか
• スライドは見えているのか
• 深堀りする必要があるのか

が分かりにくく不安になります
顔が見えて相打ち等があるとだいぶ違うように思いますが、発表者以外がマイクをオンにしてしまうと声が被ってしまったりするので検討の余地がありそうです
YoutubeLiveで配信する勉強会もありますので色々試してみたいと思っています

反省

• 登壇者のみが音声ONにするとボッチになる

最後に

運営者としての反省・配信の反省点と上げてみましたが、配信についてはリモートワーク上のミーティングでも同じことが言えるかと思っています
この気付きを普段の仕事にも活かしていきたいです
反省が多かった初めての勉強会ですが、これにめげずにイベントを開催していきたいと思いますので興味がある方はぜひご参加ください

Holmesはエンジニア・デザイナーを募集しています 。
興味がある方はこちらからご連絡ください！

lab.holmescloud.com

lab.holmescloud.com

PS.

私の発表スライドも掲載しておきます^^;

speakerdeck.com

BEMを自社に適用させて運用する

こんにちは！Holmesでサーバーサイドエンジニアをしている平田です。

タイトルにもある通り、HolmesではBEMをベースにアレンジを加えて運用しています。
私は2020年1月からフロントエンドもがっつりやるようになったので、その際に勉強したBEMと自社でどのようにアレンジして運用しているかを紹介します。

BEMとは

BEMとは、より構造化されたCSS設計を行うための方法論の一つです。公式
BEMはBlock、Element、Modifierの頭文字をとったもので、”ベム”と呼びます。
BEMに則って開発することで、保守性・使用性・移植性の高いCSSコードを書くことができます。

以前、Holmesでは複数画面に渡って利用している3000行からなるCSSファイルを秘伝のタレのように継ぎ足し継ぎ足しで運用していたため、修正の際に毎回他の画面が崩れたり、!importantが乱用される状況になっていました。

Holmesでは2019年5月からBEM等を取り入れて改善を図ってきました。
BEMを導入することによって、画面固有のCSS、共通のCSSが記述・利用しやすくなったため、不要な考慮も少なく、開発スピードも向上しました。

BEMのルール

BEMはclassセレクタを利用します。
そうすることでCSSの優先度をBEMで記載した通りに統一することができます。

Block

Blockは独立した意味のある塊です。
Block名は小文字の英数字で記述し、単語はハイフンで区切ります。

• HTML

<div class="block"> ... </ div>

<div class="article"> ... </ div>

• CSS

.block { ... }

.article { ... }

Blockは他のBlockにネストすることができます。

<div class="block1">
  ...
  <div class="block2"> ... </ div>
</ div>

Element

ElementはBlockの中に記述されるもので、Blockと紐づくことで意味をなすものです。
Element名は小文字の英数字で記述し、単語はハイフンで区切ります。Blockとは__（アンダースコア２つ）で繋げます。
Elementは単体では利用できず、Blockの入れ子として利用します。

• HTML

<div class="block">
  ...
  <span class="block__element"> ... </ span>
</ div>

<div class="article">
  ...
  <span class="article__title"> ... </ span>
</ div>

• CSS

.block__element { ... }

.article__title { ... }

ElementのElementを記述することはできません。

• 誤

<span class="block__element__element"> ... </ span>

ただし、DOMツリー内でのネストはできます。

• 正

<div class="block">
  ...
  <div class="block__element1">
    ... 
    <span class="block__element2"> ... </ span>
  </ div>
</ div>

Modifier

Modifierは、BlockやElementに付随して、外観、動作、または状態を変更します。
Modifier名は小文字の英数字で記述し、単語はハイフンで区切ります。BlockやElementと_（アンダースコア１つ）で繋げます。
Modifierとしてプロパティーと値を表現する場合は、_（アンダースコア１つ）で紐づけます。color_red
また、Modifierは修飾子のため、単体では利用できず、非修飾要素（BlockやElement）とマルチクラスで記述します。

• HTML

<div class="block block_modifier">
  ...
  <span class="block__element block__element_modifier"> ... </ span>
</ div>

<div class="article article_size-big">
  ...
  <span class="article__title article__title_color_red"> ... </ span>
</ div>

• CSS

.block { ... }
.block .block_modifier { ... }
.block__element { ... }
.block__element .block__element_modifier { ... }

.article { ... }
.article .article_size_big { ... }
.article__title { ... }
.article__title .article__title_color_red { ... }

ファイル構造

Blockごとにファイルを分けます。
そうすることで、意味のある塊であるBlockの重複を防ぐことができるとともに、巨大なCSSファイルが出来上がるのを抑制できます。

Holmes流にアレンジしたBEM

SCSS

SCSSはSassというスタイルシート言語の構文の一つです。
SCSSを使うことで、BEMをより書きやすくなります。

• CSS

.block { ... }
.block .block_modifier { ... }
.block__element { ... }
.block__element .block__element_modifier { ... }

• SCSS

.block {
  ... 
  &_modifier { ... }
  &__element {
    ...
    &_modifier { ... }
  }
}

• CSS (SCSSの変換)

.block { ... }
.block_modifier { ... }
.block__element { ... }
.block__element_modifier { ... }

メリット

• 冗長な記述を減らせる
• 入れ子であることで親子関係がわかりやすい

デメリット

• Modifierをマルチクラスで設計するには工夫が必要
• 見難い

Holmesではこれらのメリット・デメリットを踏まえて下記のような運用を行っています。

記述ルールのアレンジ

Block

Block名は先頭が大文字、単語を繋げる際は先頭を大文字にして繋げる、アッパーキャメルケースで記述します。
理由はサードパーティのCSSとのコンフリクトを防ぐためで、開発スピードや崩れを防ぐための策です。 やってみるとHTMLでは大文字が視認し易く、よかったと思います。

.Block { ... }
.BlockList { ... }

Element

ElementはBlockの要素であることを明確にするため、Block配下として記述します。
Element名は先頭が子文字、単語を繋げる際は先頭を大文字にして繋げる、ローワーキャメルケースで記述します。 Blockとは本家同様__（アンダースコア２つ）で繋げます。 記述はやや冗長になりますが、視認性の高さとclassのネスト関係のスコープを優先しています。

• HTML

<div class="block">
  ...
  <span class="block__element"> ... </ span>
</ div>

• SCSS

.block {
  ...
  .block__element { ... }
}

• CSS (SCSSの変換)

.block { ... }
.block .block__element { ... }

Modifier

Modifierは先頭-（ハイフン１つ）にして、文字の先頭を子文字、単語を繋げる際は先頭を大文字にして繋げる、ローワーキャメルケースで記述します。
また、BlockやElementとは繋げた冗長な記述はせず、非修飾要素（BlockやElement）とマルチクラスで記述します。CSSでマルチクラスを保証します。

• HTML

<div class="block -modifier">
  ...
  <span class="block__element -modifier"> ... </ span>
</ div>

• SCSS

.Block {
  ...
  &.-modifier { ... }
  .Block__element {
    ...
    &.-modifier
  }
}

• CSS (SCSSの変換)

.Block { ... }
.Block.-modifier { ... }
.Block .Block__element { ... }
.Block .Block__element.-modifier { ... }

運用した結果

メリット

• 冗長な記述を減らせる
• HTMLやCSSでの視認性が上がった
• 親子関係で縛るのでスコープが明確になり、マークアップのルールも縛れる
• 既存のCSSの影響も最小限に抑えられて開発スピードが向上した

デメリット

• Blockの分け方や命名は開発者次第になっている
• Block__elementは冗長な記述になる
• マルチクラスになった場合、HTML上でModifierがどちらを修飾しているかわからない

このModifier運用のデメリットについて

上記でデメリットとして、「マルチクラスになった場合、HTML上でModifierがどちらを修飾しているかわからない」をあげました。
調べてみると、このようにModifier名を単体で書くことには否定の意見をちらほら見かけました。
個人的な考えとしては、適切なModifierであればどちらを修飾しているかは意識しなくて構わないと思っています。

理由

• セレクタの指定で縛っているので、記述しても適切なものにしか修飾されない
• 適切に設計していれば、どちらを修飾していようと適切な振る舞いをする

解決できていない問題

改修によってマルチクラスになっている片方を削除しなければならない場合は問題となります。
Modifierが修飾している方を消した場合、Modifierがあるにも関わらず、Modifierが効かないということが起こります。

これについては、それぞれのBlock設計時にModifierを考慮していないことに問題があるのではないかと思います。そもそも共通で使用するモジュールであれば、優先的にModifierをつける等の設計工夫ができます。
HTML側では下記のように、Modifierを被修飾classの次に書くなど、ルール化することでも極力問題を減らせそうです。

class="被修飾class Modifier 他class"

HolmesではBEMを使い始めてからModifier以外をマルチクラスにならないようにしているため、問題は今の所起こっていません。

おわりに

いかがでしたでしょうか。
BEMの表面的な部分とHolmesでどのようにアレンジして運用しているかを紹介してきました。
BEMを検索してみると、オリジナルから派生した色々な記法がBEMとして語られています。
序盤に説明したBEMは公式だと思われるものを参照していますが、間違いがあれば指摘していただければ幸いです。
Holmesで利用しているアレンジもどこかで同じものがあるかもしれませんし、皆さんも環境に合ったものを考えてみてください。

Holmesはエンジニア・デザイナーを募集しています 。
興味がある方はこちらからご連絡ください！

lab.holmescloud.com

lab.holmescloud.com

PythonでGmailAPIを使用してメールのタイトルと本文を取得してみた

初めまして、HolmesのNabeです。

今回はPythonからGmail APIを使用してアカウントにアクセスする事でメールのタイトルと本文を取得することができたので、その手順などを共有できればと思います。

環境

開発言語: Python3

ライブラリ: google-api-python-client · PyPI

GmailのAPI有効化

APIを使用するに当たって、GmailAPIを有効化する必要があります。APIキーが発行された状態は以下のようになります。

APIキーが発行された状態(ID・シークレットは加工済み)

画面上部の「JSONをダウンロード」からJSONファイルをダウンロードすると、接続に必要なファイルが生成されます。このファイルをプログラムと同じ階層に設置することでプログラムからAPIを使用することができます。今回のサンプルではcredentials.jsonというファイル名で使用しています。作成するファイルは全て同一ディレクトリに設置してください。

Pythonのコード記載例

ライブラリの準備

前提条件として、いくつかライブラリをインストールする必要があります。requirements.txtに下記のように記載します。

requirements.txt

google-api-python-client==1.7.11
httplib2==0.17.0
oauth2client==4.1.3

下記のコマンドを入力することで、インストールが実行されます。

pip install -r requirements.txt

接続・認証

接続するにあたって必要な認証は下記のコードで実装できます。

gmail_api.py

class GmailAPI:
    def __init__(self):
        # If modifying these scopes, delete the file token.json.
        self._SCOPES = "https://www.googleapis.com/auth/gmail.readonly"

    def connect_gmail(self):
        store = file.Storage("token.json")
        creds = store.get()
        if not creds or creds.invalid:
            flow = client.flow_from_clientsecrets("credentials.json", self._SCOPES)
            creds = tools.run_flow(flow, store)
        service = build("gmail", "v1", http=creds.authorize(Http()))

        return service

取得処理

取得処理は以下のようになります。 先ほど作成したGmailAPIクラスの中に追加で実装する形になります。

gmail_api.py

    def get_message_list(self, DateFrom, DateTo, MessageFrom, MessageTo):

        # APIに接続
        service = self.connect_gmail()

        MessageList = []

        query = ""
        # 検索用クエリを指定する
        if DateFrom != None and DateFrom != "":
            query += "After:" + DateFrom + " "
        if DateTo != None and DateTo != "":
            query += "Before:" + DateTo + " "
        if MessageFrom != None and MessageFrom != "":
            query += "From:" + MessageFrom + " "
        if MessageTo != None and MessageTo != "":
            query += "To:" + MessageTo + " "

        # メールIDの一覧を取得する(最大100件)
        messageIDlist = service.users().messages().list(userId="me", maxResults=100, q=query).execute()
        # 該当するメールが存在しない場合は、処理中断
        if messageIDlist["resultSizeEstimate"] == 0:
            print("Message is not found")
            return MessageList
        # メッセージIDを元に、メールの詳細情報を取得
        for message in messageIDlist["messages"]:
            row = {}
            row["ID"] = message["id"]
            MessageDetail = service.users().messages().get(userId="me", id=message["id"]).execute()
            for header in MessageDetail["payload"]["headers"]:
                # 日付、送信元、件名を取得する
                if header["name"] == "Date":
                    row["Date"] = header["value"]
                elif header["name"] == "From":
                    row["From"] = header["value"]
                elif header["name"] == "To":
                    row["To"] = header["value"]
                elif header["name"] == "Subject":
                    row["Subject"] = header["value"]
            MessageList.append(row)

        return MessageList

タイトルや本文の取得について

取得したデータはメールの情報が大量に入っているため、必要な情報を抜粋してくる必要があります。

メールのタイトル等は特定の場所にあるため決め打ちで取得が可能です。メール本文についてはペイロードの中身を探していく必要があり、メールがテキスト形式かHTML形式かで取得方法が大きく変わってくるので、形式に合わせた場所を参照する必要があります。取得処理のMessageList.append(row)の直前に下記のコードを追加します。

gmail_api.py

# HTMLメール本文を取得する
MessageDetail = service.users().messages().get(userId="me", id=message["id"], format="full").execute()
if MessageDetail["payload"]["mimeType"] == "multipart/alternative":
    for payload_parts in MessageDetail["payload"]["parts"]:
        if payload_parts["mimeType"] == "text/plain":
            for payload_header in payload_parts["headers"]:
                if payload_header["name"] == "Content-Type" and payload_header["value"].lower() == "text/plain; charset=utf-8":
                    row["Body"] = email.message_from_string(str(base64.urlsafe_b64decode(payload_parts["body"]["data"]), "utf-8")).get_payload()

感想

メールの本文の取得についてはメールの形式によって変わるので、どこに記載されているかはデータ構造をデバッグしながら確認したり、いくつかサイトを確認しながら探したため苦戦しましたが、実装自体は思ったより簡単にできたと思います。

参考サイト

キー発行手順は下記ページが参考になりました。

valmore.work

PythonでのAPI使用方法はこちらを参考にしています。

qiita.com

データ構造については下記ページ(英語)に記載されています。

developers.google.com

おわりに

Holmesはエンジニア・デザイナーを募集しています 興味がある方はこちらからご連絡ください！ lab.holmescloud.com lab.holmescloud.com

長野・東京間を繋ぐオンラインコミュニケーションで工夫していること

はじめましてHolmesデザイナーの越川です。 新型コロナウイルスの影響でリモートワークがどんどん拡がっているようですね。

遠隔作業の弊害として、一部のメンバーで決定したことがチーム全員に伝わっていなかったり、 すぐに確認をとりたいのに、チャットツール上だと中々マネージャーに気づいてもらえなかったりといったことがあげられるかと思います。

Holmesでは、長野拠点と東京拠点、またリモートのメンバーが常日頃オンラインでコミュニケーションをとって開発をしています。 チームメンバーが同じ空間にいない状況下でも、チームの生産性やチームワークを向上させるため、コミュニケーションの手段を日々試行錯誤しています。

今回は開発チームのコミュニケーションを支えるツールについて、その活用方法と合わせてご紹介いたします。 少しでも参考になれば幸いです。

※この記事の情報は2020/03/11時点のものです。

コミュニケーションにおいて心がけていること

開発チームがコミュニケーションにおいて心がけているポイントは

• 相手のことを知る リスペクトの気持ちを持って相手の話を傾聴する

• 情報格差をなくす 共通言語を用い、みんながわかるように可視化する

• 伝わりやすいコミュニケーション わかりやすく伝える、話し方に気を配る

ことです。これらをオンライン上で実現するために、以下のツールを活用しています。

Zoom　ー常時接続で気軽に会話できる状態に

ZoomはオンラインWeb会議ツールです。動作が軽く、通信環境が安定している上に、画質がいいです。デバイス環境に左右されず、機能も豊富なことが特徴です。

Holmesでは個人との対話を大切にしており、モニターにライブカメラをつけて常時接続を行っています。 モニターの前に立って話しかけると、リアルタイムで誰かが話したいメンバーに繋いでくれるため、すぐ目の前にいるかのような心理的距離感でコミュニケーションができます。 緊急時の相談や確認事項などもZoom上で画面共有し、確認しながら検討できるため、複雑な課題が発生している場合でもスピード感を持って開発を進めることができます。

miro　ー可視化＆共同作業におすすめ

オンラインホワイトボードツールです。ホワイトボードを使って実現できる様々なことをオンラインで叶えることができます。

Holmesではオンラインでのワークショップや、ユーザーストーリーの整理のために、miroを利用しています。 miroのポイントはオンラインで共同作業ができて、何より機能が豊富で使い勝手がいいことです。 考えをビジュアライズして可視化することができ、認識のすり合わせや整理がリアルタイムで可能になります。付箋を貼ったり、整理したり、紐付けたりなど、自由度高く操作できます。 ホワイトボードと比較して、リモートメンバーとの情報格差がなくなるのでおすすめです。

一方、タスクの進捗は社内に設置しているホワイトボードのカンバンで可視化しています。 miroの場合は能動的に情報を取りに行く必要がある一方、ふと周りをみた時に視界に入るホワイトボードの効力は絶大です。

他部署からも状況が把握できるように、このように管理しています。

Teams　ー関連情報タブが便利

Microsoft Teamsは、Microsoftが提供するビジネスチャットです。 この製品は、Office365の製品の一部として提供されています。

HolmesではコミュニケーションツールにTeamsを利用しています。 Teamsのポイントは添付ファイルやWiki、様々なアプリやWEBページがチャネル内のタブ上にまとまることです。

タブをどんどんカスタマイズしていけるので、そのチャネルで大切にしたいことを、チームが閲覧しやすい場所に置いておくことができます。 チャネル内の会話の中で添付したファイルも、ファイルタブからまとめて参照できます。 また、WordやExcelがTeams上で直編集できたりと、マイクロソフト製品との接続がとてもシームレスなので、Office系のサービスを利用している場合には非常に便利なのではないかと思います。

いかがでしたでしょうか。 チームの雰囲気や目的に合わせて是非これらのツールを活用してみてください！

Holmesはエンジニア・デザイナーを募集しています
興味がある方はこちらからご連絡ください！

lab.holmescloud.com

lab.holmescloud.com

開発者ブログ始めました！

はじめまして、Holmesのid:k-igaです。

Holmesについて

株式会社HolmesではホームズクラウドというSaaSを提供しています。
ホームズクラウドは、企業の契約業務全般を最適化する契約マネジメントシステムです。

lab.holmescloud.com

今回は初記事投稿というわけで、開発環境やツールを紹介します！

開発拠点

東京オフィスと上田オフィス(長野県)の各拠点でそれぞれチームを組んでおり、2拠点2チームで楽しくチャレンジングな日々を送っています。

開発手法

アジャイル開発手法の一つである、スクラムを採用しています。
プロジェクト管理ツールはGitLabを利用しており、日々のデイリースクラムは物理かんばんを見ながら行っております。
また、チャットツールはMicrosoft Teamsを採用しており、各スクラムチームごとにチャネルを作成してコミュニケーションを行っております。

開発環境

開発環境は特にルールがあるわけではなく、各個人がやりやすいエディタ／IDEを選択することができます。
希望者にはIntelliJ IDEAのライセンスを支給してもらえます。
開発PCはMacBook Proを使用しています。
　

フロントエンド

フロントエンドは Sass, jQuery, Thymeleafで構築、Yarn, webpack で構成管理を行っています。最近では BEM に基づいた CSS 整理を取り入れ、よりモダンな開発を試みています。
将来的には フレームワークやAltJsを選定し、導入も検討しております。新しいことを1から始められる魅力があります。

サーバサイド

サーバーサイドは Java8（Kotlin、Groovy) を使用し日々開発を行っています。最近ではユニットテストのカバー率向上に着手しており、TDD によるテストファーストな開発を行い Groovy + LocalStack + H2 を組み合わせ AWS Managed な環境に対応したテスト環境を整備しています。
ソース管理にはGitlabを利用しており、マージリクエストベースでソースレビューも行われる体制が整っています。
オープンソースの採用に積極的なカルチャーがあり、オープンソースへの貢献も目指しています。

デザインのツール

デザインチームはプロダクトのモック作成を Adobe XD, Illustrator, Photoshopを使用してデザインしています。
また、スクラムにおいて Miroでユーザーストーリーを整理し、ユーザーに本当に価値あるプロダクトは何かを常に考え続けています。
最近では Storybook で UI コンポーネントの整理に着手し、全社的なデザインの統一を行っています。

インフラと周辺ツール

インフラは AWS を使用しており、API も含めて AWS 上で全てのサービスを提供しています。
規模は小さいですが、使用しているサービス数は多く日々技術的なチャレンジとより安定した稼働を目標としています。
GitLab によるタスク管理から CI/CD まで統合して実行し、Issue Board によるタスク管理、GitLab Runner による CI/CD の自動化を行っています。
Autoscale Runner によるユニットテストの高速化/並列化だったり、開発環境から本番環境まで自動化されており、UIテスト自動化も Python Selenium で実施しています。

最後に

常に進化することを目指しているので、上記であげたツール/手法以外でもメンバー間でオススメがあればドンドン採用されていきます！

Holmesはエンジニア・デザイナーを募集しています
興味がある方はこちらからご連絡ください！

lab.holmescloud.com

lab.holmescloud.com