2018 3月

XRテクノロジーの分野で発奮するアイデアクラウド・チームマネージャーに独自の開発体制について訊く

名古屋市中区に本社を構えるアイデアクラウド。スタートはWeb制作会社なのですが、現在の主力事業はXR(VR、AR、MRなどの技術を一括りにしてXRと表現します)など、動画系の新しいテクノロジーを使った事業。常に新しいテクノロジーの早期導入を意識して事業を展開していると語られるその現場の開発に興味を覚え、チームマネージャーの長屋さんにお話を伺いました。

XR事業に踏み出すまで

まず御社の事業についてのご紹介をいただけますか？

当社はあくまでWeb制作会社として始まっている会社ですから、受託案件も引き続きあります。その一方で、ARやVRなどXRテクノロジーに力を入れ始めているということになります。

独自アプリもリリースされているようですが

PERS ARというアプリは、Googleが開発したTangoを採用した空間検知型ARです。

現実の空間を測定して、深度認識を行ないスペースを把握し、従来までのARと異なりマーカーによるオブジェクト描画・設置ではなく、平面となる場所を判定して、そこにテーブルやイス・ベットをはじめとしたさまざまな3Dオブジェクトを自由に配置することが可能となるすぐれものです。

空間に対してオブジェクトが設置されているため、端末を実際に近づけたり回り込んだりすることで、オブジェクトの大きさや角度が変わり、あたかも現実世界に設置したような体験を提供することができます。

Tangoは、米グーグル（Google）内にある、先端テクノロジーの研究開発部門「ATAP」（Advanced Technology And Projects）が取り組んでいるプロジェクトです。モバイル端末に3Dの空間把握能力を持たせ、活用できるようにすることが目的とされています。

それはすごい！　イベントやショールーム施設などで活躍しそうですね。

はい、おかげさまで問い合わせも多くいただいています。弊社は現在特にAR事業に注力しているのですが、この分野ではトップランナーであろうという会社全体の意思でもあります。これまで、プロジェクションマッピングとVRに関しては東京に遅れをとってしまったという感覚がどうしてもありますから。

PERS ARについて
GoogleのTango自体は、Google側での開発が終了しているため、現在、それに代わる、Googleの「AR Core」とAppleの「AR Kit」という技術を使ったアプリ 「Okeru AR」を東京支社で開発し、既にリリースしています。
■Okeru AR
https://a-r-tech.net/okeruar/
■デモ動画
https://www.youtube.com/watch?v=V_W4cd0LhNs&feature=youtu.be

私もいま活動拠点は東京なので、名古屋と東京におけるビジネスでの温度差は実感しています。

感覚的に、新技術の場合は東京で一通り行き渡ったなという段階でようやく名古屋で話題にできるというサイクルかと思います。

それでも、新技術は競合が少ないですし、早く取り組めば取り組むほど会社のブランドとしても強くなります。プロジェクションマッピングの場合、名古屋は一周遅れで取りかかったと思っています。VRは半周遅れです。

そんな状況を目の当たりしして、ARの分野ではNEWテクノロジーをいち早く取り入れ、名古屋にいながらも東京のスピード感で仕事できるようにしていきたい、というのが現在の姿勢です。

そのスピード感というのは、まさに今回お話をお聞きしたい開発スタイルにつながっていくと思います

さすが、いい流れですね〜

さまざまな人材が集う会社

その前に少し、弊社の風土みたいなところもお話したほうがよいかなと思います。

それはぜひ。

弊社はクリエイティブ企業としては少し珍しく、社員の退社時刻が早い。18時頃には大半の社員が退社し、22時を過ぎるとほぼ誰もいません。また、社員には既婚女性が多く、ご家族やお子さんがいるわけなので早く家に帰りたい人が多い。

これまでお話を伺ってきている他の会社さんでも、「退社時間が早い」とおっしゃるところが多いです。生産性と退社時間は比例しますね。

つまり、退社時間を早くするということは、社員一人ひとりの生産性が高くないと実現できないわけですからね。

もうひとつ、時間で稼ぐのではなく、作ったモノの価値で社会に認められる状態、つまりブランド化するということですが、自分たちの価値を上げていく仕事をしていく必要があります。
その点で、新技術は収益性が高いことが既に実感できていますので、アイデアクラウドの戦略としてそこに力を入れていくということです。

XR事業というと、2020年東京オリンピックに関しての需要もまだまだ読み切れない分野ですしね。それはともかく、特徴的な会社カルチャーもありますか？

どっぷり中に入っていると、あまりわからないところもありますが、やはりベンチャーなんで中途入社者ばかりの企業ですから、だからこその文化はできているかなと思います。

もったいつけずに言うと、ユニークな人材が多いと思います。

お、それはどういうことなのでしょう？

これは既にクライアントさんにも公開している情報なので、言っちゃいますが、私自身ももともとは「蕎麦屋」だったんですよ。実は、弊社は飲食事業からのキャリアチェンジ組が多いですね。

それは驚きです！　では、長屋さんは相当勉強されたということなんですね。

実は、転職時の記憶を遡ると、一番最初は入社を断られているんですよ。

最先端ならではの面白さ

思わぬ爆弾発言が飛び出しましたが、本題に進めましょうか

はい、開発スタイルの話題に。AR事業などの注力分野に限って言うと、チームとしては３人から５人で構成しています。言ってしまえば、「なんちゃってアジャイル」だとは思いますね。

具体的なツールってどんなものをお使いなんですか

コミュニケーションは、チャットワークですね。タスク管理、というかチケット管理は、独自開発したTrello クローンを使っています。

独自開発？

もともとTrelloを使っていたのですが、「これはいらないな」というものが増えてきて、だったら自分たちの使いやすいものを作ってしまおう、となって、いまではその独自のTrello風ツールをメインに使うようになったということです。

コード管理は何かこれと決めていますか

Git だったりまちまちです。

チャットワークのタスク機能は使われていますか

使うこともあります。その場合、いわゆるかんばん管理とは別の状態で生まれるタスクというルールが自然とできているのだと思います。

ほかには？

アイデアクラウドでは作業効率化を常に追い求めていて、「これが上手くできたらいいのに・・」ということを日々改善しながら仕事をしています。

作業環境で言うと、まぁ珍しいことではないですが、ディスプレイをデスクに２台置き、デュアルディスプレイにして作業してもらっています。作業はメインディスプレイ、原稿や管理ツールなどはサブディスプレイにするなど、各人の使い方はいろいろのようです。

ただ、そういう思考で仕事をしていれば、課題提案をする、それをどう解決するか考える、試してみる、解決を図るというグッドサイクルが生まれます。先ほどのお話ではないですが、そういうカルチャーが育まれて入るかと思っています。

ところで、お蕎麦を打っていたという話ももっとお伺いしたい気がしますが、さすがにそれはちょっと趣旨に反するので、開発面で困っていることをお聞きしたいです

困っていることというと、「採用」でしょうか。弊社のプロダクトは基本的にすべて内製化しています。
スピード重視という上でも優秀な仲間が増えていくのは嬉しいです。

いま取り組んでいるものは、いま世の中に無いものです。
日本語のドキュメントやサンプルは存在しない状態から、自分たちでコードを書き上げなければなりません。

やったことがないからできないのではなく、できないかもしれないがやってみる気概のある方たちと出会いたいですね。

飲食事業からの新しい仲間も歓迎だ、と。

はい、もちろん。

最後に、もともとWeb制作会社だからこそいまに引き継がれているスタイルってなにかありますか

う〜ん、それはつまりエクセルで管理してます、みたいな話ですかね？　受託案件ではやはりいまでもそれが通用していますね。

やっぱり。今日はありがとうございました。

取材を終えて

未来を創る仕事、と言い切ること。
新しいものづくりをする困難さは、まさにいま私たちも直面しているところですので、お話の中でいくつも共感ポイントがありました。

実はそのために、随分脱線しながらのお話になりましたが、紙面にはその脱線の様子は割愛しております。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

よいチームの文化とは？　理想のチームは幻想か？ 第3回

どのようなチームにも、必ず文化というものがあります。それはチームが目指すべき、あるべき姿へ向かう行動習慣なのか、会社の文化を素直に反映したものなのか、いずれにせよ人間が集まる最小単位であっても、10チームあれば10通りの、100チームあれば100通りの文化があると言っても過言ではないでしょう。
チームのメンバーとして成果を上げるには、そのチームが持つ文化を理解することが重要です。言い換えれば、チームの文化をスポイルして成果を上げようとしても、正当な評価に繋がることは残念ながらあまりないと言わざるを得ません。

そもそもチームの文化とは何なのか

そもそもチームの文化とは何なのか、を理解しないことには話が始まりません。例えば、あるプロダクトが社名よりも有名で、そこで働く誰もがそのプロダクトの存在意義を理解しているような会社に勤めていれば、チームの文化を理解するのは容易いでしょう。なぜなら、目指すゴールがほぼ一致した認識だからです。

しかし、そのような会社は誰もが知っている有名企業で、あたかもIT業界の大部分を占めるかのように見られがちですが、単純に企業数で見るとほんの一握りでしかありません。大部分の企業は、プロダクトごと、機能別にチームを構成したり、SIerなどの業種では、顧客ごとにチームを構成したりしていることでしょう。

チームの構成方法や期待のされ方に違いはあるとは言え、チームの文化とは、
•チームの存在意義、目標・目的を行動習慣として体現したもの
•チームを構成するメンバー全員が「あるべき姿」としてもつ共通認識
•望ましくないことがおきた場合に取る行動と評価基準
これらの3要素に収斂されると言ってよいでしょう。これらの、チームの文化を構成する要素は、チームに期待される役割から由来することもあれば、メンバーの個性が文化として自然発生し固定化されるケースもあります。

なぜチームの文化を理解するべきなのか

私が属したチームのほとんどは、チームのあるべき姿が最初からできていたわけではなく、ましてや最初からチームの文化を懇切丁寧に教わったことがありませんでした。これをよしとするかは別として、チームの文化を理解するために、こちらから理解しようとする姿勢が暗に求められていた(勝手にそうしていただけかも知れませんが)ように思います。
私も若い頃はチームの文化を理解せずに(私自身のスキルが足りていなかったのもありますが)、チームが目指す方向とは別のベクトルを向いていながら「なぜこんなに頑張っても評価されないのだ」と勘違いしたこともありましたが、先ほど挙げたチームの文化3要素を理解していれば、チームにとっては貴重な戦力を保持でき、メンバーの立場としても、もっとも効率よく自らのスキルを発揮することができたかも知れません。

チームメンバーにとって、チームの文化を理解するということは、チームの戦力として貢献するための最短距離である、という考え方をしてみると、チームに馴染むためのストレスが幾分緩和されるのではないでしょうか。勿論、この考え方がすべてというわけではありませんが、少なくとも目的を達成するまでの過程において遠回りを強いられる、というリスクは少なくて済むでしょう。
一方、チームリーダーにとって、新しくジョインしたメンバーのスキルを早期に発揮してもらうためには、チームの文化を正しく理解し、あるいはチームの文化をリードし、これをはっきり示さねばなりません。

よいチームの文化とは

チームの文化と一口に言っても、よいチームの文化と、残念なチームの文化は大きく異なります。よいチームと残念なチームの文化を比較すると、以下の表のようになる傾向があるのではないでしょうか。

※よいチーム（左）、残念なチーム（右）になります。

意思決定のプロセス	トップダウンであってもボトムアップであっても、意思決定のプロセスに透明性がありメンバーが納得するまでのコストを惜しまない。	トップダウンであることが多く、意思決定のプロセスが不透明であり、メンバーが納得するかどうかは二の次である。
メンバー間のリスペクトや信頼	ある	ない
失敗に対する態度や非のあるメンバーへの批判	メソッドやナレッジを共有することが当たり前にできており、常に改善されている。	一度作ったドキュメントは改版されないか、そもそもドキュメント化されない。
疑問や改善提案	疑問を持つことが否定されないか、または推奨されており、どうやって解決したかがチームで共有される。	疑問をもつことそのものが悪であり、決まった手順に従順であることのみが求められる。
例外発生時	例外に対してチーム一丸となって対処し、健全な解決を図り、再発防止策が正しく共有される。	例外そのものが悪である、という考えで、時には隠蔽されることもある。
マネージャーとメンバーの関係	マネージャーはメンバーのバリューを最大化するため喜んで黒子になる。	支配と従属
チームのルール	公平な判断基準を設けるためにあり、目的が明確である。	前例踏襲またはルールのためのルールであり、忖度が求められる。
目標の持ち方	メンバー全員がチームのために自身のバリューを最大化する。	チームでありながらメンバーの目標に一貫性がない。

よいチームと残念なチームの対比を挙げてみましたが、すべての項目において必ずしも二極化しているとは限らず、改善提案ができる余地があるなら、そのチームはよいチームに化ける可能性はあります。

チームリーダーは常にこうしたよい文化を保てるか気を配る必要があります。勿論、常に気を配り続けるのは現実的ではないので、ある程度タスクに落とし込めたら、その執行をメンバーに委ね、フィードバックを受けて改善する仕組みを作ってしまえばよいのです。

あわせて読みたい…「最高のチームの共通点とは何か？最先端の企業で実施されている５つのポイント」

チームの文化に疑問が生じたら

どんなチームであっても、完璧なまでに理想のチームであり続ける保証はありません。筆者が経験した最高のチームは、ハイスキルなメンバーが集まり高い理想を持ち、言わば「背中を預けられる関係」でした。しかし、チームとして上手くいっていたにもかかわらず、会社の方針と相いれずに次々とメンバーが退職し、チームの生産性とクォリティが維持できず、その後チームが空中分解・・・という結果に終わってしまいました。

ここまで大きな話ではないにしても、チームの文化や行動習慣などに疑問が生じるケースもあるのではないでしょうか。こうした状況で個人が組織と対立することはよくある話ですが、いきなり「対立」に持っていくことは得策ではありません。理由を挙げますと、

•「対立」から入ると、決着の付け方が勝負ごとになってしまい、禍根しか残さず、その後の人間関係が不健全なままである
•「組織のここが受け入れられない」と「組織そのものに属することが苦痛である」を混同しがちであり、感情や面子を落とし所にしてしまいかねず、本来改善すべき点が置き去りになりかねない
•本来「外向き」に振り向けるべき思考やリソースが内向きかつネガティブになり、生産性を大きく阻害する

このように、誰にとっても不幸な結果になってしまいます。これを防ぐには、前回取り上げた「アサーションスキル」が役立ちますので、チームの文化に疑問を投げかける際には、アサーティブな関係を維持することを心がけてください。こうすることで、改善提案も前向きな提案として受け入れられやすくなり、感情のわだかまりを一切残さないことが可能になります。

チームメンバー全員が能動的に動くための方法のひとつとして「ホラクラシー組織マネジメント」を検討してみませんか？

事例紹介：某企業のIT機器大規模リプレースプロジェクト（全国展開作業）の場合

全国に支社を持つとある大企業で、全国的にIT機器（PC・サーバー等）のリプレースが予定され、あるITソリューション企業に対して導入支援を依頼しました。全国の約200支社に対して、3000台を超える機器の入れ替え（リプレース）作業を行なう大規模更改プロジェクトが立ち上がりました。

経過、あるいは原因：懸案事項はメンバーの受動的な姿勢

現在使用中であるIT機器のリース満了日が決まっていることから、リプレースの時期も早くから決まっていました。しかし、クライアントの方針がなかなか定まらず、決定事項が覆るという状況に陥り、全体のスケジュールも徐々に遅延していきました。

ただでさえ急いでリカバリーをしなくてはいけない中、プロジェクト内では、新たな課題に悩まされていました。それは、プロジェクトメンバーの中に受動的なメンバーが多く、能動的に動けるメンバーが少なかったという点です。モチベーションの違いからか、遅くまで残業するメンバーと定時でさっさと帰宅してしまうメンバーに二分されてしまっていました。このままでは、残業するメンバーからは不公平感が強まり、チーム全体のモチベーションに大きな影響を及ぼしてしまいます。

知識化する：メンバーが能動的に動くために、ホラクラシー組織を導入する

ホラクラシー組織とは

このチームの問題点は、スケジュールの遅延よりもむしろ、能動的に動けないメンバーが多いことです。受動的なメンバーに「能動的に行動してください」と指導して改善されるものかというと、非常に難しいといえます。そこで、このプロジェクトではこの状況を打破するために「ホラクラシー組織マネジメント（自己組織型プロジェクト管理）」を導入しました。

ホラクラシー組織とは、トップダウンで命令が行われるヒエラルキー組織とは異なり、プロジェクト内でいくつかの小さなチームを結成し、各チームが自主的に関わりあってプロジェクトを組織するものです。ヒエラルキー組織が上から下に命令を下すのに対し、ホラクラシー組織は「自律したサークル」のように人間関係を並列の関係に置き換え、各担当に役割を果たすための責任を持たせています（参考：https://nulab-inc.com/ja/blog/nulab/project-management-and-team-building/）。ホラクラシー組織の考え方は、2007年にアメリカのソフトウェア会社の創始者であるBrian Robertson（以下ブライアン）氏により提唱されました。それが靴の通信販売会社のザッポスに取り入れられたことで注目を集め、今ではAirbnbやEvernoteといったシリコンバレーの複数の企業が導入しています。日本でも、ITベンチャーを中心に導入されている企業がいくつかあるそうです。

プロジェクトにホラクラシー組織マネジメントを導入した結果

このプロジェクトにホラクラシー組織マネジメントを導入し、上長はチームに権限を委譲しました。各作業工程の管理や決定等は基本的にチーム内で行います。上長の承認を得るのではなくチーム単位で決定していくため、メンバー間でコミュニケーションをとり調整を進めることが不可欠となります。プロジェクトチームの個々のメンバーに、その役割に応じた意思決定権が与えられたため、今まで受け身であったメンバーも自分の頭で考え、自律的に行動するきっかけとなりました。そして、上司と部下がよりフラットな階層で議論できる状況も合わせて作りました。すると、ひとりひとりの発言が活発になり、チームワークも円滑になっていきました。上長承認というステータスがなくなった分の必要な工程が減り、決定事項もよりスムーズに進み、遅延していたスケジュールを取り戻すことができました。

あわせて読みたい…「自ら考え行動できる組織作り」に関する記事はこちら

社会性と広がり：プロジェクトを成功に導くホラクラシー組織の特徴とは

プロジェクトメンバーにはひとりひとりに様々な考え方や価値観があるので、プロジェクトにおいて目標を達成することは決して容易ではありません。そのため、チーム全体でひとつの目標を達成するためには、共通認識と高いマインドが必要です。ホラクラシー組織の中では、メンバーは常にプロジェクトやチームの問題を意識し、その解決策を他のメンバーとともに考えています。このことが、共通認識を共有できているかを常に確認し、また常に高いマインドを保つことにつながっているのではないでしょうか。ホラクラシー型組織で重要なのは、部長や課長といった肩書きではなく「役割」そのものです。自ら考え判断する能力が問われます。

この組織上ではプロジェクトリーダーというポジションもあくまで「役割」であり、フラットな関係です。決定権のある上司がいないことによって、判断に迷うメンバーがでてくるのでは？と思う方もいらっしゃるかもしれません。それは上司がいないから迷うのではなく、判断する知識や能力をまだ備えていない、というだけだと考えられます。その場合はわからないメンバーが無理に判断せず、わかるメンバーに相談するという点に尽きるということです。従って上司という固定化された役割はここでは必要ないと考えます。

タスク管理アプリを再評価する〜2018年最新版

仕事の効率化を図るためのタスク管理がますます重要になっています。現在、タスク管理を行なえるツールが増え、どのツールが企業にとって管理しやすいものなのか不明瞭なので、その打開策としてのヒントを与えられるようにタスク管理アプリの再評価を行なっていきましょう。新年度を迎えるにあたって、情報を更新しました。

そもそもどんなツールがいいのだろうか？

具体的なツールを紹介する前に、押さえておきたいポイントをいくつかまとめてみました。

使いやすくシンプルである

まず、使う人が使いやすいか、これが一番重要です。
使い方を覚えるのにマニュアルを熟読しなければならないような、複雑なツールはかえって業務が非効率化されてしまう危険があります。
誰にでも簡単に使えるような、シンプルでわかりやすいツールが望ましいですね。

複数人で共有できる

アナログ手帳などでは、情報をチーム全体で共有できません。関係者へ逐一報告する手間なども増えてきます。
その点、Web上で管理できるツールなら、作業内容や進捗状況を共有できるため、細かい報告などの手間もなく、業務の効率化がはかれます。

モバイルデバイスに対応している

スマートフォンやタブレットなど、モバイル端末からも管理できることは業務効率化においてたいへん重要です。いつでも、どこにいても確認・登録ができるツールはもはや必須アイテムです。プライベートも充実し、気持ちに余裕も生まれ、より効率的に業務ができるかもしれません。

セキュリティや保護機能が万全である

組織で共有するのなら、セキュリティ面やデータ保護の配慮は必須です。通信がSSLなどで暗号化されているか、不正なアクセスから守られる構造になっているか、データのバックアップは定期的に行なわれているかなども必ずチェックしましょう。

タスク管理のための便利なツール

実際に多くの企業で使われ高評価を得ている使いやすいツールや新たに公開したツール、またその特徴をご紹介します。特徴を比較して、ニーズに合ったツール選びの参考にしてください。

コミュニケーション促進と進捗度の見える化なら「Teamhack(チームハック)」

Teamhackではタスクやドキュメントごとにチャット機能がついており、メンバー一人ひとりやチームでの進捗度をグラフで簡単に見ることができます。
また無料でのお試し版を体験することができ、容量10GBのビジネスプランでは、1ユーザーあたり、月額1200円、年間契約割引で月額1000円です。
メモや会議の議事録もタスクやドキュメントでプロジェクトごとに管理ができるので、タスク管理に加えて、コミュニケーションを活性化させるツールとしてうってつけではないでしょうか。

≪特徴≫

• タスク・ドキュメント毎にチャット機能を搭載
• タイムトラッキング機能で進捗度の確認が簡単にできる
• メンバーごとに納期やスピードなどの分析ができる
• タスクの達成率によってランキングがつけられる
• 無料でのお試しができる

≪ここに注目！！≫
プロジェクトやタスクを新しく作ることが簡単にできます。タイムトラッキング機能で進捗度を図れます。タスク・ドキュメント毎にチャット機能がついていて、コメントも見やすいのが強みだといえます。

株式会社カタリストシステム:TeamHack

完全フリー・オープンソース「Redmine（レッドマイン）」

インストールすることによって、無料で自由にカスタマイズできる進捗管理・情報共有のためのソフトウェア「Redmine」。
やるべき課題の内容や担当者、期限などを「チケット」として登録し、進捗状況を管理します。
インストール型で、自社サーバーでの運用になるため、セキュリティ面で安心できることが大きなメリットといえるでしょう。モバイル専用アプリ「RedminePM」を端末にインストールすることによって、無料でありながら、スマホやタブレットでも使用できるという優れものです。

≪特徴≫

• インストール型、オープンソースの無料ソフトウェア
• 各課題を「チケット」登録して管理できる
• 登録したチケットは、一覧・ガントチャート・カレンダー・ロードマップなどさまざまな形式で表示できる
• ニュース画面で、メンバー全員へ一斉通知できる
• Wiki画面で、手順やメモなどを共有できる

≪ここに注目！！≫
チケットを追加するのに少し手間がかかるものの、優先度や進捗度をすぐに確認できる。追加したチケットは色々な形式で表示できるので、自分のお気に入りの形式で管理可能なのでおススメです。

またサーバー不要、維持管理不要のクラウド型「MyRedmine（マイレッドマイン）」もあり、こちらは有料ですが、オープンソースで利用できます。解約後もデータが活用できる環境を構築できます。

ファーエンドテクノロジー株式会社：Redmine

初心者にも分かりやすく使いやすい「Jooto（ジョートー）」

課題ごとにプロジェクトボードというメインとなる管理画面を作成し、細かいタスク管理やメンバーとの情報共有ができる「Jooto」は、ダウンロードやインストール不要のクラウド型ツールです。
操作が直感型で分かりやすく、ITに不慣れな人でも簡単に使えるのがおススメポイント。
プランは、プロジェクトボード2個、ユーザー2名までなら無料、15個のボードとユーザー15名までのベーシックプランで月額1,780円となっています。
Windows・Mac・iPadなどのメジャーな端末にも対応可能になりました。

≪特徴≫

• 各課題をカード形式で管理
• ドラック・ドロップなどの簡単な操作でファイルをアップロードしたり並べ替えしたりできる
• メモや付箋感覚で、把握しやすく見やすいユーザーインターフェース
• プロジェクトボードをｃｓｖファイルにエクスポートできる
• EvernoteやSlack、Chatworkへのエクスポート機能も備わっている

≪ここに注目！！≫
プロジェクトごとにボードを作ることが可能で、優先度やメンバーの指定など誰でも簡単に扱えることが強みです。タスクごとにコメントができますが、コメント数が多くなると少し見えづらい印象を受けました。

株式会社 PR TIMES：Jooto

コミュニケーション機能が充実「backlog（バックログ）」

絵文字やスターを使った「いいね」機能、キャラクターアイコンなど、ビジネスの場でも楽しくコミュニケーションをはかれる「backlog」。
ストレージ30GB・プロジェクト数100・ユーザー無制限で月額9,800円のスタンダードプラン以上であれば、ガントチャートの作成や、期限までの作業量をグラフで把握できるバーンダウンチャートで、進捗状況の視覚化がはかれます。
またメモや会議の議事録を共有できるWiki画面なども完備、まさに課題管理に必要な機能が集約されているうえに、チームのコミュニケーションも促進させる万能ツールだといえるでしょう。

≪特徴≫

• 絵文字や「いいね」などのコミュニケーション機能が充実
• 開始日・期限・マイルストーン（節目）などを入力することで作業計画や進捗状況が一目瞭然
• 議事録やメモを共有できるWiki画面あり
• 30日間無料のお試し期間あり

≪ここに注目！！≫
フリープランを利用してみましたが、慣れるまでに少し時間がかかりました。慣れてさえしまえばWikiやガントチャートも使用できるので非常に万能なツールだと言えます。

株式会社ヌーラボ：backlog

Excelの使い勝手で管理したいなら「GSuite（ジースイート 旧GoogleApps）」

アカウントがあれば無料で使えるGoogleのツールを利用している人は多いと思います。
Gmailや文書作成のドキュメント、表計算のスプレッドシート、ファイルを保存・共有できるドライブ、カレンダーから音声ビデオ通話、サイト作成に至るまで、ありとあらゆるビジネスに役立つツールがあり、無料版でも十分な機能を備えています。

有料版である「Gsuite」では、さらに独自ドメインのビジネスメールを使うことができます。
また、電話やメールによる24時間365日サポートがあり、専用画面でユーザー管理やセキュリティ管理を行うこともできるため、組織で使うのであれば有料版の「GSuite」がおススメ。
容量30GBのベーシックプランなら1ユーザーあたり、月額600円、年額6,000円。容量無制限のビジネスプランなら月額1,200円、年額14,400円です。
Googleカレンダー内にタスク機能もあるようですが、どちらかというと、使い慣れたExcelで課題管理したいため、スプレッドシートを共有して課題管理に利用している人が多いようです。

≪特徴≫

• ExcelタイプのGoogleスプレッドシートで管理・共有できるため、利用法をイチから覚えなくてよい
• Googleドライブでフォルダも共有できる
• Googleサイトで簡単にチームのサイトを作成し共有できる
• 社名などの入った独自ドメインをGmailで使える
• 24時間365日サポートあり
• 14日間の無料お試し期間あり

≪ここに注目！！≫
独自ドメインを使えるのもすごく魅力的で、2018年1月より、HTMLやJavascriptも埋め込めるようになったため、使える幅が広くなりました。

Google Inc.：GSuite

これからのツールに期待すること

TeamHackersでは、さまざまなシステム開発企業やWeb制作会社を訪ね、主にアジャイルやスクラム開発などチーム体制の開発スタイルについてのインタビューを行なっていますが、どの会社も複数のツールを組み合わせて自分たちにとっての最適化を図っていることがわかります。したがって、タスク管理やコミュニケーションなど1つのツールでまとまったものが理想形であるとも言えます。
さらに、エンジニア系ではない人も対応できるようにシンプルであることが望まれます。

2017年度版、過去の記事を見たい方はこちら：https://teamhackers.io/issues-management-tools

慣れない環境でも、生産性を落とさずに仕事をするには？

早いものでもう3月も終わりに近づき、まもなく新年度の4月がやってきます。人事異動、転職などで新しい環境や職場となった人も多いかと思いますが、どのような環境であっても、仕事の生産性を落とすことなく、結果を出し続けたいものですね。
ここでは、どんな環境においても、仕事の生産性に影響を与えずに仕事をすすめていくためのコツをご紹介していきます。

空調に影響を受ける生産性

筆者が以前勤務していたアパレル系の会社は、外注先として、インドに工場を持っていました。刺繍などの加工を依頼すると、たまに納期が問題になったこともあったようです。インドに生産指示書を持って出張に出るのは営業の役割でしたが、出張帰りの営業は、「インドは暑すぎて、納期なんて守っていられなくなるのもわかる」と話していたものです。

これは極端な例ですが、新しい勤務先や環境の空調や湿度がうまく調整されていないと、仕事に集中できないことがあります。そして、それが原因で生産性までも下げてしまうこともあるのです。
もし、空調が自分にフィットしていないと感じたら、新しいオフィスや環境で、勝手に空調の温度や湿度をチェックしていると白い目で見られるのではないか、と気にせずに、一度自分の目で確認してみましょう。

環境省では、冷暖房を冬20度、夏28度に設定することを推奨していますが、この設定は、環境に配慮してエネルギー消費量を抑えるための設定であり、実際に職場でこの温度設定だと、仕事効率に影響がでる場合もありえます。

オフィス空調28度設定というのは、クールビズをすすめる企業にも多く見受けられますが、実際のところは、日本の蒸し暑い夏のオフィスでは大変暑く、汗が出てのどがかわき、快適とはいえないため、生産性もダウンしてしまうとよく話を聞きます。また冬には、過剰な暖房で空気が乾燥し、マスクが手放せないという人も多くいることでしょう。

仕事が捗る環境に整えよう

効率よく仕事を進め、生産性をアップさせるために最適な温度や湿度は何度なのでしょうか？
２０１７年、東京都市大学環境学部、環境創生学科 リジャル ホム・バハドゥル教授らの研究チームは、オフィスにおける冷暖房などのエネルギー消費量削減を目指し、東京・横浜のオフィスビル11棟を対象とした、温熱環境の実測と社員の快適感の調査を行ないました。これにより季節ごとの快適温度を明らかにし、快適温度と外気温度の関係から適応モデルを開発されました。

それによると、オフィスの平均快適温度は冷暖房非使用時で25.0度、冷房使用時で25.4度、暖房使用時で24.3度であったと発表されています。
参考URL： https://www.tcu.ac.jp/news/newsrelease/20170515-8449/

現実的にも、空調25度前後が快適であると考えられますが、湿度の増減により、不快度が変わってくる場合もあります。湿度は、一般的に、45～60%を保てると良いでといわれます。寒い冬は、乾燥が激しく、湿度も下がりがちです。湿度が低いと、寒く感じやすくなります。また、乾燥が、かぜなどのウィルスの繁殖を促進してしまう可能性もあります。

そして、夏には湿度が高いと、空調がどんなに低く設定されていても、暑く感じてしまいます。そのため不快指数やあがり、仕事効率も落ちてしまいます。見落としがちな湿度管理、新しい職場はどうなっているのか確認し、もし快適でないのであれば、自分でできる範囲で快適に近づけるようにしましょう。

オフィスには、温湿度計を導入してもらい、温度や湿度を確認できればベターですが、個人で対策をするならば、冬には加湿を心がけてUSBケーブルで電源を取れる加湿器を使用したり、コップに水を入れてデスクに置き、湿度を保ちましょう。夏であれば、除湿器をおいてみることをおすすめします。

空調を快適に保って生産性に支障をきたさないようにすることは、デスクワーク中心のビジネスパーソンには特に覚えておいてほしいポイントです。

相容れない職場文化が存在する場合、どう生産性を保つか

職場でつねに音楽やラジオがかかっている、など、その職場特有の文化が存在し、それにどうしても慣れることができずに気が散ってしまう場合にはどうすべきでしょうか。
本来であれば、そのような文化があることを入社する以前に知っていられればよいのですが、何事も現場に入らないとわかりません。

一度、自分には合わないとわかっていても、その文化に浸かって、自分がどう感じるのかを体感してみましょう。意外に知らなかった自分を発見できるかもしれません。体感したけれど、どうしても自分に相容れないと実感したら、それも学びのひとつです。苦手な文化も割り切って、仕事は仕事として自分を見失わないようにしてください。

以下、新しい環境に触れるときのアドバイスです。

デスクの整理をする

筆者が大手商社に新人として入社したとき、まず上司から言われたのは、自分のデスクをすっきりと整理整頓することでした。自分のデスクの上もすっきりとせず、把握できないのであれば、膨大な仕事を管理するのも難しい、という考えからきたアドバイスでした。そのため、デスクをいつもきれいに保つようになり、自然と仕事やスケジュール管理も身に付くというメリットもありました。

もしあなたが新しい環境で、生産性がなかなかあがらない、と感じたら、デスク周りをいちど整理整頓してみてください。探しものをしていて時間をとられる、といった無駄も減らすことができますし、きれいなデスクで、スケジュール調整も仕事もはかどることでしょう。

情報収集活動を行なう

新しい環境では、いつもの自分らしい仕事ができるようになるまでに、様々な情報収集が必要かもしれません。仕事をふる相手は誰なのかを知ったり、陰のボスが誰なのかを知ったり、ランチタイムに短い時間でおいしいものを食べられるのはどの店なのかを同僚に聞いたりなど、必要な情報はたくさんあります。それらがそろうまでは落ち着かないかもしれません。周りの同僚たちと、可能なかぎりランチを一緒にとったりし、情報収集を心がけてみてください。きっと周りの人を知れば、落ち着かない心の緊張をゆるめていけることでしょう。

時間に余裕を持って行動する

新しい環境に足を踏み入れたとき、最初のうちはすべてにおいて、以前の環境に比べ時間がかかってしまうことでしょう。コピー機の使い方しかり、入室方法すら違って戸惑ったりすることもあるでしょう。

新しい環境のあらゆることの確認が必要です。ひとつひとつにきちんと対応できるようにするためにも、時間に余裕を持って行動するよう心がけましょう。時簡に余裕があれば、心にもゆとりをもって行動できます。スケジュールも、新しい環境に慣れるまで、想定外のことが起きる可能性も加味してバッファを持たせて管理しておきましょう。

マインドフルネスを意識する

新しい環境に入ったときには、周りの人たちからどう見られているのか気になるかもしれません。しかし、そのようなよけいなことを考えながら仕事をするのは効率が悪く、生産性もあがりません。自分がいますべき、ひとつの仕事に集中する「マインドフルネス」を意識して、仕事をしましょう。

周囲の目を気にすることなく集中力を発揮すれば、生産性も保てますし、生産性の高さから、おのずと評価も向上させていくことができるでしょう。

問題解決を図れる人材づくりに必要な知識

私たちの周りでは、プロジェクト内外に関わらずさまざまな問題が起こります。
問題が起こったときに「もっとうまく解決したい！」と思うことはありませんか？
またそれと同時に、問題が起こらないようにするにはどうすればいいか気になりませんか？
「これをやると問題が解決する！」という魔法はありませんが、問題を極力起こらないようにして、ストレスを減らしたいというのは万人に共通する思いなのではないでしょうか。
今回は、問題が起こったときに解決に向けて進むことができるのはどういう人材なのか、そしてどうすれば次々と起こる問題を減らせるのかを考えてみましょう。

最終目標とマイルストーンの認識合わせをする

「問題を解決する」と一口にいっても、「問題を解決した状態」はケースによって異なります。あなたは今起こっている問題に対して、「問題が解決した状態」がどのようなものか明確に言えますか？
例えば、システム開発において「ある機能で想定通りの動きをしていない」というトラブルが発生したとします。
・想定通りの動きをしない直接の原因を明確にして、修正することが「問題解決」である
・根本的な原因は何だったのかを調べ、再発防止策を考えることが「問題解決」である

どちらも正しいと言えますが、どの状態を目指しているのかをクライアントと認識合わせしておく必要があります。
そうでないと、目指しているゴールに到達するまでのスケジュール感やスピード感が異なるものとなり、「思ったよりゆっくりしていて、なかなか解決しないな」とクライアントに思われている、という状態に陥ることもあるからです。

また、最終目標を認識合わせすると同時に、途中のマイルストーンも共有しておくとよいでしょう。
そうしておくことで、途中報告をするタイミングがわかりやすくなり、相手との認識相違に気づきやすくなるからです。

また、ひとつ問題が起こると「解決しなければ」という思いでいっぱいになり、迷走してしまうプロジェクトも少なくありません。そうなると焦りや情報の錯そうなどから、さらに新たな問題を引き起こすことにもなりかねません。目標がはっきりしていると、やるべき事ややらなくてもいい事が明確になります。

クライアントだけでなく、プロジェクトのメンバーとも認識合わせしておくことで、作業に対する重要度やスピード感への意識も変わってきます。

多面的に考える

人は多くの経験があるほど多面的な見方ができる反面、成功体験があると「自分のやり方がベストだ」と凝り固まってしまうことがあります。また、過去に同様な問題を解決した経験がある場合などは特に「前と同じ方法で解決できる」と思いがちです。
少し立ち止まって、本当にこの方法で解決できるのかを考えてみるようにしましょう。
また、上司や身近なリーダーなど複数で考えることで自然と「多面的な考え」が出ることもあります。ひとりですべてやるのではなく、周囲を巻き込むことで自然と多面的な考えを出すようにするのもいいでしょう。

順序立てて作業する

ひとつ問題が起こると、いろんな作業が発生します。
例えばシステム開発の場面において、納品したシステムが想定と異なる動きをすることがわかったとします。そうすると、まず異なる動きをしている直接の原因は何かを調べる、影響範囲を調べる、過去に誤ったアウトプットを出していないか、クライアントに金銭的な損失を出していないかを調べる・・・。どれもが大切で、「なる早で（なるべく早く）」と言われがちなことです。
すべての作業を素早くできればいいですが、あなた1人ではすべてを同時に行うことはできないですし、あなただけではわからない事柄もあるでしょう。
もちろん、プロジェクトメンバーで分担することもできますが、気づいたものから手当たり次第に担当を割り振って作業していませんか？

ここで大切なのは、「順番立てて作業する」ということです。落ち着いて、作業に関連性や依存はないかを含めて洗い出し、作業の順番を考えてみましょう。この順番を考えるのに何日も必要というわけではないはずです。

また、その洗い出した作業が問題解決のゴールにたどり着くのに必要な作業かどうかも見極める必要があります。作業を始める前に少しの時間を取って作業の要否や順番を考えてみると、後の作業が思いの外スムーズになり、問題解決までの時間も削減できるはずです。

「今ここ」を共有する

問題がなかなか解決せずにクライアントが怒り出す、上司から注意される、ということもよく聞かれます。
これはクライアントや上司が「どういう状況かわからない」ことに不安になったりイライラするからです。
人は自分の置かれている状況や方向性がわからないと不安になります。
あなたは「今（プロジェクトや発生した問題は）こういう状況です」ということを周囲と共有していますか？
ビジネスの場においては、周囲を不安にさせてもいいことは１つもありません。

よく言う「報・連・相」は、新人だけに向けられたものではありません。すべての人に必要なスキルなのです。
もちろん、プロジェクトを管理する立場であれば、単純に「今ここ」を報告するだけでなく、今後はどうなる予定なのか、スケジュール状況はどうなのか、といったことも合わせて伝えた方が相手により一層安心感を与えることができるでしょう。
問題が早く解決することが望ましいですが、現状報告をして相手と共有することも大切です。

相手の立場で「相手目線で」考える

「プロジェクト」という枠にとらわれず考えると、人間関係のトラブルが一番多いのではないでしょうか。
「相手によかれと思ってやったことが、相手が不快な気分になった」
「プロジェクトのトラブル対応をしていたのに、クライアントが余計に怒ってしまった」
これらは、相手のことを思って行動しているのに、自分が思っていた結果（相手が喜ぶ、トラブルが解決してクライアントから感謝される）にならず、問題が解決していません。

これらは、相手のことを思ってると言いつつ、「自分目線での行動」になってしまっているのが問題解決できていない理由のひとつです。子供の頃に「相手のことを思って行動しましょう」ということを周りの大人に言われた人も多いのではないでしょうか。ただ、これは「自分目線での行動」だと意味がないのです。
相手の立場で考えてみることが必要です。

また、あなたは周りの人と「目的を共有」していますか？
例えば、上司に「クライアントに提出する今回のトラブル報告書を作成してほしい」と頼まれたとします。
ここであなたはどうしますか？

　・まずはトラブルの事象や経緯がわかるような報告書を出し、再発防止については後で報告する
　・トラブルを引き起こした根本原因を調査し、チームで再発防止策を検討してから報告書を作成する
といったことが考えられます。

ここで、何のためにクライアントに報告書を提出するのかという目的を上司と共有できていなければ、ただ「提出する」というノルマを行なっただけで、クライアントや上司の真の目的は達成できず、問題は解決していません。
なぜかと言うと、あなたが作った報告書では相手が満足しないこともあるからです。
せっかく作った報告書にダメ出しされてやり直すより、一度で相手を満足させたいですよね。
何のために自分は作業を依頼されているのかを相手と共有すると、あなたの行動も変わってくるはずです。行動が変わるだけでなく、無駄な行動もなくなります。お互い喜ばしいWin-Winの状態です。
何かを成し遂げようとしたり、依頼されたときには「何のためにそれをやるのか」という目的を相手と共有することが大切だということを覚えておいてください。

チームに溶け込むためには、会話のキャッチボールが欠かせない

前回は、既存のチームへジョインする事例から考察してみましたが、今回は日常業務での習慣づけという観点で考察してみたいと思います。
チーム内のコミュニケーションはおおよそ「リーダーや他メンバーからの指示、お願いごと」「自ら行なう報告・連絡・相談」がほとんどを占めますが、こうした日常のコミュニケーションで「会話のキャッチボール」を意識するだけで、チームの生産性や雰囲気(居心地)に差が出るものです。

開発現場における会話のキャッチボールとは

私がいくつかかかわった開発現場のチームでは、思い返すと大なり小なり「よいチーム」「ダメだったチーム」がありましたが、その差が何だったのだろうと振り返れば、メンバーのスキルやPMやPLのリーダーシップの力量に傾向があったわけではなく、「会話のキャッチボールができていたか」がチームの成否を左右していました。
よいチームで行われていた会話のキャッチボールがどのようなものか、を分析してみると、

・相手への敬意をお互いに持っている
・仕事の依頼や報告・連絡・相談には必ず期限と品質の共有が伴う習慣ができている
・何かしらのトラブルがあったとき、「誰が」ではなく「何が」いけなかったのかにフォーカスした議論を行なう

これらの傾向が多く、生産性の高さに繋がっていたように思います。
今回は、よいチームの中で行われていたコミュニケーションを「会話のキャッチボール」という観点から掘り下げてみたいと思います。

事例紹介 : 相手への敬意をお互いに持つということ

ここで述べる「相手への敬意をお互いに持つ」というのはフォーマルなお話ではなく、会話の最中は相手の方を向く、返事をする、相手の会話を遮らないということを意味します。
作業中の割り込みで話しかけられたとしても、画面を見ながら相手を見ない会話はあまり褒められたものではありません。会話でのコミュニケーションなのだから音声だけ伝わればよい、と思われるかも知れませんが、アメリカの心理学者 アルバート・メラビアン氏によると、対面コミュニケーションにおいて基本的に「言語」「声のトーン(聴覚)」「ボディランゲージ(視覚)」の3つの要素があり、メッセージに込められた意味や内容の伝達の際に占める割合は、

言語 : 7%
声のトーン : 38%
ボディランゲージ : 55%

と分析しています。

つまり、対面で相手を見ずに会話すると、93％もの情報が欠落してしまうことになってしまうのですね。
やはり、人と人との会話ですので、相手を見ずに会話するのは気持ちがよくないものですが、こうした数字に現れると非常に納得すると思いませんか？

もちろん、作業に集中しているのに毎回手を止める必要はなく、「今集中しているので後でもいいですか？」という断りを入れて構いません。
しかし、必ず相手の方を向くのは最低限の敬意でもあり、「あなたの話を聞きたくないのではなく、今集中しているのです」という非言語情報を正確に伝える目的も含んでいます。
また、すべての情報を必ず対面で音声化すればよい、というわけではなく、情報量が多い場合はメールやチャット等で先に情報を提示し、対面で「今よろしいですか？先ほどメールした件ですが～」と声をかければよいのです。

私が経験した中で、こうした対面のやり取りができているチームは、メンバー間での尊敬の念が大きく、結果として生産性も非常に高くなり、プロジェクトを離れた後も付き合いが続くほどにもなったことすらありました。

よいチームができる要因 : 仕事の依頼や報告・連絡・相談には必ず期限と品質の共有が伴う習慣ができている

先に取り上げた事例のように、よいチームでは対面でのコミュニケーションでストレスを感じることがなく、相手への尊敬の念が高い傾向にありました。また、同時に、非言語コミュニケーションへの依存度が低い傾向にあったので、思い込みによるコミュニケーションの行き違いが少なく、結果的に手戻りが少ない、生産性の高いチームとして機能していたのです。

日本語はよく「行間を読む」「品詞が曖昧な言葉の真意を汲む」「察する」という行動を無意識のうちに求められがちですが、エンジニアの中にはこうした行動が苦手という話をよく耳にします。
上司からこのような会話で仕事を依頼されることはよくあると思います。

上司「○○さん、あの仕事やっといて」
○○「はいわかりました」

この会話に出てくる「あの仕事」がルーチンワークであり、どの程度の工数でどういった成果を求められているのかが事前に共有でき、実行結果が予測できていれば、このまま着手して「終わりました」の報告で問題ないでしょう。しかし、

・イレギュラーな仕事 または前提条件によっては成果がすぐに出るかわからない仕事である
・他タスクとの優先順位づけに判断が必要である
・仕事のゴールが明確でないか、条件によってゴールが異なることが予想される

など、仕事の依頼者と自分の認識が一致していない(と予想される)場合は、どのような成果がいつまでに求められているのか、確認する必要があります。先ほどの会話を続けてシミュレーションしてみましょう。

上司「○○さん、あの仕事やっといて」
○○「わかりました。いつまでに出来ていればよいですか？」
上司「なる早でお願いしたいのだけど、いつまでに出来そう？」
○○「今仕掛中のタスクが今日いっぱいで終わりますので、明日の着手になります。恐らく～～という結果になるとは思いますが、途中経過を確認していただきたいので、2～3日後のどこかでレビューしていただけますか？」
上司「わかりました。どうもありがとう。」

いかがでしたでしょうか。この会話のやり取りでしたら、締め切り直前になって「こんなはずじゃなかった」と頭を抱えることはなさそうですね。依頼された仕事の実行結果が予測できない、あるいは実行結果に予測のブレがおきそうな場合、早い段階で軌道修正する機会を作ることが大切なのです。

もし、(自分の思い込みで)完成直前に確認を求めても、ギリギリになって「スタート地点で間違っていた」となれば、プロジェクト全体のスケジュールに影響を及ぼすなど、手戻りの工数が本来の工数の数倍になることすらあり得ます。新しい仕事に着手したら早い段階で軌道修正する機会を作ることを、私は「早めに小さく間違う」と呼んでいますが、早めに小さく間違っておけば、その後のリカバリ稼働は少なく、期限内に最小限の工数で仕事を終わらせることが可能になります。
チームのメンバーになって時間が経つと、いわゆる「あうんの呼吸」が成り立つこともありますが、チームにジョインしたばかりの段階では、あうんの呼吸がすぐに成り立つとは限りません。ジョインしたばかりのチームでタスクを任されるようになったら、「早めに小さく間違う」を意識してみてください。こうすることで、大きな失敗を未然に防ぐことができるので、試してみる価値はあると言えましょう。

よいコミュニケーションへ改善する方法

私が経験した限りにおいて、という経験則で恐縮ですが、チーム内でのコミュニケーションが上手くいかず、非常に険悪な状態だった時期も経験したのですが、当時のチームリーダーが優秀な方で、いくつかの方法で改善したことがありました。その中でいくつか、効果があった方法をご紹介します。
何かしらのトラブルがあったとき、「誰が」ではなく「何が」いけなかったのかにフォーカスした議論を行なう

開発現場において、バグの発生やオペレーションミスなどは避けて通れません。また、要件定義や営業上のいわゆる戦略レベルでの失敗すらあり得ます。こうした失敗が表面化した際、最初に「誰がやったのか」という声が上がるチームは、残念ながらあまりよくないチームに多い傾向がありました。チームリーダーが字義通りに「まず誰が失敗したのかを確認して本人にヒアリングしたい」と思っていたとしても、日本語では誰かを詰問するために「誰がやったのか」という言い方をする伝統があるため、本人が萎縮してしまい、本質的な解決までのコストが跳ね上がってしまいます。

こちらはチームリーダー向けの解決手法なのですが、よい文化を持つ組織を目指すのであれば、事実確認をしたい場合、まず「何があった」のかを聞くべきであって、最初に「誰が」にフォーカスしてはいけません。

また、複数の当事者がいる場合、「別々にヒアリングを行なう」というプロセスを必ず行ってください。当事者間でお互いに言いにくいこともある場合、そこに遠慮が発生することで本当の原因を見過ごしてしまうというリスクを減らすため、これは外せないプロセスなのです。

感情よりも事実で判断する

人間は感情の動物です。ゆえに何かしらのトラブルがあったときは、大抵感情が高ぶるものですが、感情に感情をぶつけても良い結果を生むことはほとんどありません。ゆえにトラブルがおきた場合、事実で判断するのが肝要です。

とは言え、まったく感情を無視した解決というのも、メンバー間に禍根を残すことになりかねず、これもまた褒められたものではありません。

感情は冷めないうちに吐き出してもらう

こちらもチームリーダー向けの解決手法なのですが、トラブル発生時のヒアリングにおいて、当事者から話を聞くことは最初に行うプロセスです。トラブルそのものの対処は最優先ですが、当事者の感情は冷めないうちに吐き出してもらうことをおすすめします。

人間は大なり小なり認知の歪みを持つものなので、時間が経つにつれ、メンバー間のマイナスの感情で事実を捻じ曲げて報告することもあり得るからです。個別のヒアリングにおいて話したいだけ話してもらい、その間は口を挟まないようにしましょう。そして、必ず事実と感情の切り分けを行い、「誰が」ではなく「何が」原因だったのかを着地点とするのです。

会話のキャッチボールを知識化する : アサーションスキルの習得

ピラミッド型の組織や文化では、下位の者が上位者を敬う自己表現法で会話を行うのが一般的ですが、これが行き過ぎるといわゆる「ご機嫌伺い」になってしまい、下位の者の自己犠牲精神に依存してしまう危険性があります。

自己犠牲の精神が必要以上のレベルを超えると、事実よりも感情を優先してしまい、問題解決の本質から遠ざかってしまいます。自己も相手も大切にする表現方法「アサーションスキル」を習得することで、自己犠牲の精神に頼らず会話のキャッチボールで問題の本質を解決することが可能になります。

アサーションスキルとは、英語の動詞「assert」からきていますが、assertという単語は「断言する」「(力強く)主張する」「力説する」と日本語に訳されます。しかし、これは決して力技で自己主張を押し通すということではなく、お互いの考えや立場を尊重しながら主張をしっかり伝えるという考え方なのです。

アサーションスキルの詳細については、いずれ回を追って触れてみたいと思いますが、人材開発を行う企業がアサーショントレーニングを行っていたりしますので、興味がある方は調べてみることをおすすめします。こうしたコミュニケーション方法の原理原則を知ることで、お互いの考えや立場を尊重したコミュニケーションを行い、よいチーム文化が醸成されることが期待できるでしょう。

理想のチームは幻想か？ チームにおける自らのポジションを確立しよう

みなさん、こんにちは。今回より「理想のチームは幻想か？」と題しまして、チームビルディングに関しての考察を行なっていきたいと思います。本稿では主に以下のような方々を対象としております。
・チームの生産性を上げたいリーダー、PM、プロジェクトオーナーの方々
・チームの戦力として貢献したい開発メンバーの方々
・普段は個人開発を行なっているが、複数名のメンバーからなるプロジェクトへアサインされたフリーランスエンジニアの方々
既存のチームにジョインしたら真っ先にやることは何か？ チームの戦力として認めて貰うには何をすればよいか？
この時期は新たな事業年度が始まり、プロジェクトのメンバーチェンジが多いこともありますので、今回は、すでにプロジェクトとして成立しているチームへ新たに参画するメンバーの方がチームへ溶け込む方法について書いてみたいと思います。

既存メンバーはあなたに興味を持っている

プロジェクトへアサインされたら、最初に自己紹介をすることになるでしょう。オンサイト開発であれば朝会などで、リモート開発であればメールやチャットなどで自己紹介を行なうことになるかと思いますが、必ず大前提として抑えておきたいのは「既存メンバーは全員、あなたに興味がある」ということです。

たとえ、他人に興味がなさそうに見えるメンバーがいたとしても、それはあなたに興味がないのではなく、「静かにあなたのことを観察している」と思っていれば間違いありません。

これを踏まえ、自己紹介は簡潔に次の要素を盛り込んで行ないましょう。

●プロジェクトへアサインされた経緯
　・どんなスキルを買われたのか
　・自分のスキルのうち、直接プロジェクトに関係するものに関する経験
●自分のスキル、学習経験
　・熟練者であれば、どんなスキルを何年程度経験してきたか
　・未経験者または経験年数が浅い場合、どんなスキルをどの程度学習してきたのか
●その他、趣味や休日の過ごし方など

対面で自己紹介をする場合は、
既存メンバーを前に発表することになるかと思います。エンジニアの方はこうした場に苦手意識を持つ方が少なくないことは承知ですが、最初に自己紹介のステップを乗り越えることで、その後の仕事のしやすさは断然違います。対面での自己紹介で心がけるポイントをいくつか取り上げてみたいと思います。

目線は後ろの方にいるメンバーへ

まず、目線を後ろの方にいるメンバーへ向ける理由ですが、うつむいて話をしても声は通りません。声が通る、ということと大きな声を出す、ということを混同する方が意外と多いのですが、地声が小さい人でも、目線を後ろの方にいるメンバーへ向けるだけで、案外声が通るようになります。最初にお辞儀をしたあとに、軽く全体を見渡してから、そのまま目線を後ろの方にいるメンバーへ向ければOKです。

ゆっくりと少し大きめの声で話す

次に、ゆっくりと少し大きめの声で話すように心がけましょう。声の大きさまで気を回す余裕がなければ、「ゆっくり話す」だけ心がければ充分です。早口になると、どうしても声が小さくなってしまいますので、ゆっくり話すことと、先ほど述べた「目線を後ろの方にいるメンバーへ向ける」ことの組み合わせで、ごく自然に声が通るようになります。

締めの言葉は、チームに１日も早く溶け込みたいという意思表示

最後に、締めの言葉ですが、チームに１日も早く溶け込みたいという意思表示をしましょう。
あなたが熟練のエンジニアであっても、それほど経験のないエンジニアであっても、いまこの瞬間に既存のメンバーがあなたに期待していることはただ１つ、一緒のチームでやっていけるかどうか、これしかありません。

スキル的な意味で、という理由も勿論ありますが、人と人とが一緒に仕事をするという意味において一緒にやっていけるかどうか、こちらの方が余程重要です。ともに苦労を乗り越え、チームとしての成功を経験した仲間は、ときに一生の付き合いとなることだってあります。これを踏まえ、「私はこのチームに貢献したい」という意思表示だけは絶対に忘れないようにしましょう。

最初のインプットこそがプロジェクト参画の成否を決める

自己紹介も終わり、席についたらPCのセットアップなど環境整備をすることになりますが、最初のインプットこそがプロジェクト参画の成否を決める、と言っても過言ではありません。まず思いつくのがプロジェクトの資料、日々の報告方法、アラートの上げ方など、プロジェクト内のお作法にかかわるものになりますが、既存メンバーは大抵忙しく、あなたにフルタイムで構ってあげられるほどの余力はありません。

ですので、最初にあなたがインプットするべき項目を以下の3つに絞りましょう。(ここでは、プロジェクトのリソースにアクセスするために必要なアカウント作成ができている、あるいは手配済みであることを前提とします)

・プロジェクトの資料はどこにあるのか
・まず手を付けるべきルーチンワークは何か
・例外が発生した場合のアラートの上げ方

先ほども述べたように、既存メンバーは大抵忙しいので、コーディング規約やセキュリティ上のルールなど手取り足取り教えてくれないものと思いましょう。逆に言えば、初日からフルコミットを求められるケースは稀ですので、プロジェクトの資料は自学自習でインプットすることを暗に求められるものだと思って差し支えないでしょう。

一方で、いつまでもインプットだけすれば良い、というものでもありませんので、アラートメールの確認などのルーチンワークを積極的に巻き取る姿勢を見せましょう。ここで、なにか例外が発生した場合に誰にどのタイミングで報告すればよいか、を必ずセットで質問するようにしてください。

以上が初日のインプットでやるべき最低限の内容ですが、ここであなたのプロジェクト参画成否を決定づける、秘策をプレゼントします。これを守ることで、あなたが不当に低い評価を下されることを防ぐ確率がグンと上がります。それは何か、と言いますと・・・

同じ質問を複数のメンバーにする

たったこれだけです。
もちろん、誰かに聞いたそばで別の人にオウム返しで同じ質問をするのはいけません。しかし、最初に教えてくれた人がどんなに熟練のエンジニアであっても、教えることが上手な人とは限りません。ですので、最初に教えてくれた人が言ったことの答えあわせを、時間をおいてそれとなく他のメンバーに聞くクセをつけましょう。

ここで「誰に何を聞いても同じクォリティの答えが返ってくる」ことがわかれば、良いプロジェクトにアサインされたと思ってよいでしょう(誰に何を聞いてもオウム返ししか返ってこない、とは別の意味です。念のため)。

プロジェクトのメンバーに興味を持つ

プロジェクト参画初日は、メンバー全員でランチへ行く(プロジェクトの予算でご馳走になることもあるでしょう)こともあるかと思います。初日の朝会で既存メンバーの自己紹介があっても、一度にすべてのメンバーを覚えるのは大変です。そこで、ランチのタイミングでメンバーの性格や興味を知るのは非常に有用です。

もしあなたがそのプロジェクトで腕試しをしたい、という意志があれば、好きなプログラミング言語の話題や流行りの開発手法などの話題を振ってみてもよいでしょう。ただし、批判的な話の持っていきかたは絶対にNGです。同様に、好き嫌いの分かれる話題としてエディタの話題(vim vs emacs)なども避けたほうがよいでしょう。

ここで大事なのは、あなたがプロジェクトメンバーの人となりに興味を持っていることをチームに示すことです。もちろん、聞かれたことに答えることは大事ですが、これは必要十分が満たされていればOKです。

1日の終わりに

ここまで読み進めた方は、プロジェクト参画初日はお互いに相手を観察する日であると気づいていただけたかと思います。プロジェクトによっては、1日の終わりに夕会などでその日の振り返りを行うこともあるかと思いますが、プロジェクトリーダーにその日の進捗を報告しましょう。

初日はインプットで1日を終えるケースが多いかと思いますので、アウトプットの質や量を報告しにくいかと思いますが、誰からどんなインプットがあったのか、最初に行った(あるいは明日から行う)ルーチンワークは何だったのかを報告し、今日は他にすることがないかを確認してから帰りましょう。
プロジェクトリーダーが定時間際に会議に入ってしまうと帰るタイミングを逃してしまいますので、昼間のうちにプロジェクトリーダーの予定を確認するのを忘れずに。

いかがでしたでしょうか。プロジェクト参画初日は誰しも大なり小なり緊張するものです。特に、1人で他社へ常駐するなど、周囲に誰も助けてくれる人がいないケースもあるかと思いますが、こうした方々に少しでも本来の実力を発揮していただける一助となれば幸いです。

次回も「チームにおける自らのポジションを確立しよう」について、具体的なノウハウを語っていきます。
お楽しみに。

最新テクノロジーの開発現場では、スクラム開発がどう活かされているか〜「業務チャットボット作成サービス」開発

「チャットボット」という言葉を広く見かけるようになっています。これが広がるきっかけは、やはりAI（人工知能）がビジネスに活用できるようになってきたと喧伝され始めたことによります。
クラウド技術の発達により、大量のデータを安価に収集し、解析することができるようになったため、AIをビジネスに利用できるようになりました。
そのAIの活用方法の一つでもある「チャットボット」ですが、今回お話を伺ったのは、DialogPlayというSaaS型の業務チャットボット作成サービス（TIS株式会社）のプロダクトオーナーの白石さんです。

「業務チャットボット作成サービス」DialogPlay とは

「チャットボット」そのものにも興味がありまして、今日はどんなお話が伺えるかと楽しみでした。本日はよろしくお願いします。

こちらこそよろしくお願いします。お役に立てるお話ができればよいですが

DialogPlay は、そもそもどのような経緯で開発が進んだのですか

TISは、グループ全体で約２万人の従業員を抱えるシステムインテグレーターです。したがって、その仕事のほとんどは受託開発なわけですが、獲得した新規技術の中からサービスを開発してやっていこうという機運がおそらくどのSIerにもあると思います。そうした流れの中でタイミングよくこのチャットボットが生まれるに至ったということです。

ということは、もともと白石さんはAIに携わる仕事をなさっていたわけですか

はい、金融系の事業部で受託開発のメンバーだったのですが、言語処理や機械学習をやりたくてR&D部門に異動をしました。またその前提条件としては、新規事業開発に取り組んでみたかったからです。「戦略技術センター」で獲得した技術をベースにして、新しいサービスを開発して事業化をするというミッションが与えられました。

いまは、DialogPlay のプロダクトオーナーとなっています。

では、最初にこれはどのようなサービスなのかということを簡単にお話いただけますか

DialogPlayは、コールセンターやBPOのオペレーター業務、セールス／アフターサービスの問合せや情報提供などの業務に活用できるチャットボットを簡単に作成・運用できる、法人向けのSaaS型プラットフォームになります。あるサービスの問い合わせ窓口として人間に代わって対話できるチャットボットの対話シナリオの作成やメンテナンスが、機械学習技術や自然言語処理などの専門知識のない方々でも、簡単な操作・手順で行なえるという点が特徴です。

LINEやWebサイトへの埋め込みもかんたんに実装できます。

開発のスタートはいつからなのですか？

このプロジェクトが属するAIサービス事業部は現在３０名を越える所帯にもなっているのですが、始まりというと昨年の春ですかね。ちょっとあいまいなお返事になるのも、そもそもこの開発の基盤となる研究は既に存在をしていて、メンバーは６名くらいいましたかね、私がそれをDialogPlayの開発に引き継いでサービス化を進めることになったのがそれくらいの時期ということなんです。

５月にはベータサービスが始まり、昨年の１２月１９日に正式リリースというと、かなり早い開発ペースですよね？　開発期間としては、つまり約１年

１年半くらいですね。

それを支えたのが、「スクラム開発」であったと。という話だと収まりがよいのですが、いかがでしょう？

スクラム導入当初は、揺り戻しもあった

先に、改めてもともとの経緯をお話しましょうか。

金融系の事業部での大規模開発の際、これは受託開発の案件なわけですが、初めてアジャイル型を採用することになりました。大手リース会社様の開発だったのですが、クライアントさんから「今回はアジャイル開発でいこうよ」と声が掛かったのですが、いま振り返っても珍しいことだったなと思います。
ただ、内実は、いま思うと、あれは「アジャイル」になってはいなかったなぁ、とつくづく思いますけれども。

そんな様子ですから、「アジャイル開発なんてやめろ」的な圧力もあちこちから発生したり、悩みも深まってくると有志の間で『アジャイルサムライ』の読書会をしたり勉強会が活発に行なわれるようになりました。もちろん、私もそのメンバーで。
で、今回のDialogPlayの礎ができていた、ということなんですね。その頃からの経験の蓄積が現在進めているDialogPlayをやることになって活きてきたと実感しています。
でも、はじめて見ると、、、

うまくスクラムが回らない、みたいな話なのでしょうか

開発当初は、それまでにメンバーがしていた開発を引き継ぐ状態で始まっているものですから、体制を変えたと言ってもおそらくマインドまで変わらなかったと思うんです。そのためか、計画通りに進めるということがほぼできていない状態でした。

それぞれのタスクは、もちろんメンバーの一人ひとりが相当に頑張って消化していたと思うのですが、それがプロダクトの成長につながっていなかった。その先の見通しも私自身ができていなかった。だから、メンバーとプロダクトオーナーの間の温度感というか意識の差はだいぶあったのだと思います。
開発当初だと特に、これも作りたい、こうしたらどうだろう、あれも作るべきだ、、、などプライベートのさなかにも発想が湧いてきてワクワクしっぱなしでしたから。

スクラムマスターは白石さんが担っていたことになりますか

メンバーにも良い候補はいましたし、一時的にはチーム外のメンバーに掛け持ちで、スクラムマスターとして手伝ってもらったタイミングもありました。
しかし、片手間で、スポット参加して、なんとかできるほどスクラムは甘くはないので、当然、上手く行きませんでした。
スクラムマスターとしてスクラムチームをより良くしたいという、誰よりも強い想いを持っていなければ務まらない役割だと感じました。

スクラム開発がうまくいくための工夫と努力

ようやくスクラムがまわり始めたなと思えるようになったきっかけはあったんですか

一言で言うと、「全員でスクラムを意識するようにした」ことですね。先ほどお伝えしたように、外部コーチを招いて３時間の講習を進めたり。スクラムガイドにある言葉が、チームの共通語になってきたと思えた時に、ようやく、でしたかね。

また、パートナー会社のメンバーも同じ熱量で開発に臨めるように周辺環境を考えることも大事でした。彼らにも、講習に参加してもらいました。

「スクラム」の型にはまる、はめた、という感じなのでしょうか。少し使用されているツールや具体的な方法を伺っていきたいのですが、Trelloをお使いだということです。

最初からTrelloでしたね。一つには、ツールに関して必要以上にリソースをかけたくなかったということもあります。scrum for trello というChrome拡張も十分使えるなと感じたので。それを使いました。

そのリソース配分というのは、私自身の問題でもありまして、プロダクトオーナー兼スクラムマスターとして、このプロジェクトのスクラムマスターとしてのどこまでエネルギー使うかはかなり悩んだところではあります。先もお伝えしましたが、スクラム開発って相当な熱量がスクラムマスターになければならないんですよ。
私の場合、プロダクトオーナーとして新規事業の旗振り役というミッションもありましたので、現実的にスクラムマスターの時間は少しショートにせざるを得ない。だから、メンバーが自主的に開発できる仕組みが必要でした。

ちなみに、Trelloの使い方を教えていただけますか？

Trelloはかなりカオスになってます。Trelloをひらくと結構な圧迫感がありますね。

目的ごとに、「ボード」「リスト」があります。「リスト」は粒度を細かく分けるようになっていきましたね。
スプリント計画では、スプリント計画バックログを作成しましょう。ちなみに、この時に、ストーリーポイント（フィボナッチ数）もチームリーダーが付与しています。
担当者作業が開始したら、「仕掛中」リストに移動させましょう
作業終了したら、「スプリントレビュー」に移動して、スプリントレビューMtgのときに順番に確認していきましょう
プロダクトオーナーのレビューを経たらチケットを終了させましょう
など、誰が見ても解るようになってきたのではないかと思います。

Trelloのかんばんはうまく回っていると実感しています。

課題感を感じていることもあります。
ROIの優先付でプロダクトバックログを並べ替えしましょう、と考えると、Trello 単体では優先度の紐づけが困難です。
別途、スプレッドシートで別のプロダクトバックログを作成してその優先度を示したものを知らせる必要があって、そうすると２重タスクにもなって負担増になりますから、そこまでの管理はできないという。

こういう時、他の方々はどうしてるんだろうってつくづく思います。

先ほど少し、ストーリーポイントのお話が出ました。このポイントというのは、「難易度」なのか「作業時間」なのか「エンジニアスキル」なのか、という尺度も表現できるのではと考えるのですが

それで言うと、「作業量」ということだと解釈しています。ストーリーポイントについては、プランニングポーカーを使ったりということはしていないので、リーダーが肌感覚で設定している状態です。
ストーリーポイントについては、正確にベロシティを計測できるのがベストなんですが、そこもできてはいないですね。

これが、自分たちのスクラム開発だとまずは言いたい

この半年くらいでチームも拡大して、スクラムマスターが新たに加わっているんですよ。彼は、大阪拠点にいます。あ、前後してしまうのですが、東京と大阪の２拠点で、このプロジェクトは動いています。

２拠点ということは、コミュニケーションレベルの問題ということが想像されます。

コミュニケーションも然りですが、大阪メンバーはスクラムのことを知らないメンバーが複数いたので知識レベルのギャップが大きかったです。それが、スクラムマスターが加わったことで大幅改善できています。この拠点間の物理的な距離は埋められませんから、東京のスクラムマスターは一部自分が兼任するつもりで割り切っています。

スクラムミーティングはどうされています？

リモートで映像も繋いでやっていますね。スプリントレビュー、振り返り、スクラム計画ミーティングと、一気に４時間くらいやりますね。２週間ごとに４時間ミーティングがある感じです。課題検討会というのも２週ごとにやっていますが、これはチームリーダーなどメンバーを限定して開催します。

スプリントレビューは結構盛り上がってみんな楽しんでますよ。スプリントレビューは実際に動かして確認します。で、これはそもそも不具合が見つかって当たり前という認識もあるのですが、６週ごとのリリースは極めて大事に考えています。

ミーティング、そもそも時間かかりますからね。みなさん、発言はされますか

それは確かに課題と思っているところがありまして、一部参加者に発言が偏る傾向もあります。ただ、自分たちがいいものを作っているという誇りを持ってほしいので、こういうところの工夫も他のみなさんどうしているんだろう？

既に公開されているプロダクトなわけなので、ユーザーの声のフィードバックもあるのではないですか

そうですね。そこが難しくて「外部との折衝はプロダクトオーナーがやるべき」「開発者はチケットに専念すべき」みたいな、スクラム開発の考え方があるじゃないですか。メンバーは、「プロダクトバックログ」を見て、プロダクトオーナーと話をしていればよい、みたいな。もちろん、そのほうがノイズが生まれないわけですが。

少し付け加えると、「プロダクトバックログ」も更新すべきことが多々現れるのですが、スプリント期間中には更新しないというルールにしています。これも、主要機能とそれ以外の機能というカタチで分けていて、主要機能のリリースは必達で、と伝えています。
また、開発時には、このスプリントでどうなりたいかというビジョンを丁寧に伝えることには気をつけています。

ちなみに、今後さらに開発強化される機能としてはどのような方針があるのでしょう

このプロダクトは「チャットボット」です。競合プロダクトも登場してきていますので、その動きももちろん注視しています。私としては、対話分析などの方向性を見ていますね。まずは、企業担当者さんが簡単に自分たちの望むシナリオで回答する「チャットボット」を作成できるという利点を認知させていきたいです。

目標としては、唯一無二のサービスにしていきたいですね

お話を戻しますが、朝会・夕会はされていると思います。こちらはいかがですか

朝会・夕会で、毎日の課題整理をしようということはうまくできているのではないでしょうか。夕会まだはいらないんじゃないか、って声もありましたが、というのも、開発者同士は背中合わせで仕事をしていたるする環境になっているので、それなりに普段から口頭のコミュニケーションができているという実感もあります。

だから、以外とチャットコミュニケーションの比重が少ないのはこのプロジェクトの特徴かもしれないです。
少しまとめると、ドキュメント管理はdocbaseでコミュニケーションはE-mailやSlackです。大阪メンバーとはSlackが多いですね。

振り返りにはKPT手法を取り入れられていますよね

方法そのものはいろいろ変化をつけながら、いまここ、という感じでもあります。振り返りの方法そのものも変化していますよ。１０分くらいで、「Keep」「Problem」「Try」それぞれを書き出してもらって、順番に発表をしてもらいます。

その際に、「Try」は自発的なもの優先するということと、みなでやるものは２つくらいまでにすること、というルールをお願いしました。埋没するものはあまり意味がありませんからね。
振り返りについては、Timelineを採用したこともあります。あのときはこうだったね、ああだったねとこれも話が膨らみました。メンバーのマインドを上げるにはいいかな。ただ、履歴を整理するのはそれなりに大変でしたね。

いま、このスクラム手法の改善に手を入れるとしたらどこに？

自社プロダクトでもあるので、甘えたくなる気持ちもなくはないのですが、先ほどもお伝えした通り、６週ごとのリリースは守るべきだと考えています。スクラム開発の場合、スプリントごとの開発優先で考えてしまうと、リリースの概念が吹き飛んでしまうことが気になっています。

これでうまくリリーススケジュールが約束できれば問題ないのですが。そこで、ベロシティ（生産性）ということを考えると、リリースの直前のスプリントと時期の離れたスプリントとでは明らかにベロシティが違うということが把握できています。これをうまくできるようにするには、Trelloじゃないのかな、と悩んでいるところなんですね。

取材を終えて

まさに、旬のテクノロジーでもある自然言語処理や機械学習。
ですが、驚いたことに「それでも人集めには大変だった」というお話でした。
今回のDialogPlayの要求技術は非常に高く、react-redux + AWSということで、もともと「エンジニアのモチベーションに繋がるだろう」と考えていたものの、ハードルが高すぎて「難しい」「わからない」という言葉が相次いだそうです。

この新しい技術習得を楽しめる人じゃないと無理だとわかった、ということでした。
もうひとつ、DialogPlayはすでにサービス提供が始まっていますが、「いいものを作る」ことと「売れるものを作る」ことは違う、ということを開発メンバーに伝える難しさもとても印象的でした。
私たちも、いま「TeamHack」というサービスの開発を進めていますから同じ心境でもあります。
貴重なお話をどうもありがとうございました。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

ラボ型開発における開発スタイルをアイエンターさんに伺いました

システムソリューションからデザイン、マーケティングなどトータルでサポートする「IT総合コンサルティング企業」として展開する株式会社アイエンター。
スマートデバイス・IoT・Webサイトなど精力的に手掛けられ、今回のお話でも早速「スマートスピーカー」の話題が出てきました。
今後も新しいテクノロジーを追求し、お客さまに喜んでもらえる提案・コンサルティングができる”ITのプロフェッショナル”。
開発を進める阿部さん、風間さんをお訪ねしました。

昨年くらいからラボ型開発が増えています

御社とは、「スマホ研究会」でお世話になっております。本日はよろしくお願い致します。

もともと弊社は受託案件の多い事業体でもありますので、お役に立つお話ができるかと心配しております。ここ最近の傾向として、ラボ型開発が増えてきていまして、そのお話を進めさせていただければと思っています。

はい、ラボ型開発についてはこれまで伺ってきていない分野なので、ぜひ。

ラボ型開発の場合は、クライアントからの要望に応じてチームを組んで開発を進めることが基本です。その場合、スクラム開発あるいはアジャイル型の開発を要望されることはほとんどなく、基本的にはウォーターフォールに近しいスタイルになっています(小刻みな、反復型のWF)。もちろんそれも、ケースバイケースではあるのですが、、、

その場合、スケジュールもクライアントさんの希望に沿ってということになりますか

マスタースケジュールはクライアントさん要望に沿ってきちんと用意して、開発内部ではうまく進められるように機能ごとなどにスケジュールを切って管理するというのが社内的には定番手法となっていますね。
割り込みタスクなどが発生しても、個別スケジュールをうまく調整できるようにするのは、プロジェクトを進める上で必要かなと思います。

もうひとつ、ラボ型開発で大きなポイントなのは生産性についての担保を契約時にしているということ。クライアントとの約束でもあるので、その点は重要ですね。

開発規模の大小とか、チーム構成とかどのようなものが多いんでしょうか

規模の大きいものでは、２０名強のメンバーでスマホとWebと任されているプロジェクトがありますね。このプロジェクトに関してはスクラムっぽいスタイルではありますね。全体的には、３〜６人で進めているプロジェクトが多いかもしれません。

もう少しラボ型開発のことを説明すると、必要なスキルを持ったエンジニアを必要な人数、必要な期間、クライアントさんの専属チームとして契約する開発モデル。つまり、クライアントさんが作成した仕様書通りに開発するプロジェクト型開発（請負型開発）とは違って、準委任委託を受けて仕様を固めていくステップから始めたり、サービスにに必要な一部システムを切り出したうえで必要なシステムを開発していく体制を築き、時に仕様を適宜変更するなどクライアントの要求に合わせて、柔軟に開発を行なえることが特徴です。

つい最近では、スマートスピーカーを活用したアプリ開発という案件が決まったばかりです。

それは旬ですね。それも詳しく伺いたい気がしますが、ラボ型開発ではその各チームのプロジェクト管理というのは、ずばりどのようにされているのでしょうか

キーマンと呼んでいる役割を持つリーダーがいて、他のメンバーの進捗やタスクをRedmineで管理しているというのが決まったスタイルですね。キーマンは、クライアントとの折衝も行ないます。

そのチームのキーマンというのは、各プロジェクトの専任なのですか？　それとも掛け持ちされる場合があるのですか？

それは完全に専任担当にしていますね。おそらくそうしないと、プロジェクト進行に影響がでます。

各メンバーのアサインはどのようにされるのですか

そこの方法そのものは従来の請負型と大きな差異はないように思います。が、今回ラボ型開発にしたことで、「もっと違う方法があるのではないか？」という
エンジニア自身ののめり込み度というか積極性を喚起できるのではないかと感じています。

というのも、ラボ型開発ではエンジニアもクライアントと直接やりとりをし、サービス提供の目的を共有されることがメリットであるとも言えます。仮に直接やり取りの機会がなくとも、キーマンを通して目的共有できる体制は大切にしていますので。

では、開発期間はいかがですか

スマホの場合だと早いものは２ヶ月、Webも含めて概ね半年くらいではないでしょうか

PMOが開発の交通整理をするようになって

もうひとつ、弊社の開発全体に言えることなのですが、「品質管理」セクションを設けています。これは、プロジェクト横断的に、各プロジェクトの進行の不具合を発見して改善を行なうPMOと言えばわかりやすいでしょうか。受託開発では、「管理定着型PMO」と呼んでいます。

このときは、定期的な会議を行ない、タスクリストを共有して問題発見・改善を進めていました。現在は、週次にPMOがヒアリングを行なって問題発見・改善ができるように指導をするという体制になっています。というのも、ラボ型開発の場合、プロジェクトごとの要件がそれぞれ異なるので平均化できないということがわかっているためです。

その場合の、コミュニケーションはやはり対面ミーティングになるのですか？

「Microsoft Teams」というチャットツールを使っています。

また、管理ツールとしては、Redmineを使っていますので、これのプラグイン機能を利用して、「チェックリスト」をエクスポートして項目を１つずつつぶしていくというような作業をしていますね。また、彼らには各プロジェクトのチケット管理が共有されているので、動いていないチケットがすぐに分かるように体制化できています。

何かアラートを発見したら、即キーマンに連絡を取って改善を促すということになりますね。

さらに、 この「品質管理」という点から大きな問題を抱えているのが、先ほども少し申し上げましたが、やはり取り扱う開発分野が広いということで、あるプロジェクトでは「デザイン」だけ、他のプロジェクトでは「要件定義」から担うことになりました、、、と決めごとがまちまちで管理側からすると非常に標準化しづらい。「ラベル」にしろ「ステイタス」にしろ「トラッカー」と言ったほうがいいのかな、それを個別に設定せざるを得なかったりします。

お話を聞く限り、御社のプロジェクトにはいまや欠かせない役割となっているのではないかと感じられるのですが、この仕組みを導入して変化を感じられたのはどんなところですか

まず第一に言えるのは、「キーマン」の負担が減ったということです。具体的に、稼働時間がかなり減ったというデータが表れました。それでも、導入当初はかなり面倒がられたりしたんですよね。

それはやはり、PMOの方々が優秀だということなのではないでしょうか。 そのPMOはいま何人いるのですか？

３人で動いています。が、彼らの機能が属人化してしまう、単純に彼ら自身の能力に依存してしまうということから、それを標準化する方法というのを模索している最中です。現在は、上記に紹介した「チェックリスト」を事業分野別だったり、ケースを想定して用意するということを進めてもらっています。

各ツールの使われ方を解説します

では、キーマンが各メンバーとどのようにコミュニケーションを進めるか、チームメンバーをまとめているか、というところを私からお話しましょう。

進捗はすべて、さきほどもお話が出ましたがRedmineで一括管理します。メンバー管理で重要なことがありまして、それは弊社の各拠点、遠隔地もありますので、そうしたリモートメンバーも少なくないということです。

ミーティングスペースには、Webカメラを搭載したモニタが設置され、どこでもHangoutで「顔を見ながら」リモート会議ができる環境にしています。リモート会議の進め方は皆うまくなってきているのではないでしょうか。

進捗は、Redmine一択ということですが、プロジェクトごとに、メンバーの経験も力量も異なってくるかと思うのですが、その生産性だったり、各メンバーのスキルの管理だったりという点では、どのようにされているのでしょう

Redmine のチケットに「開始日」と「終了日」を必ず記載するようにして、その進捗を追いかけていくという方法になります。

ということは、そのチケット発券時に「○○なら、これくらいでこのタスクを終えられるだろう」という判断をしているということですよね。つまり、そこはリーダーの力量に依存する理解で大丈夫ですか

Redmine では、ガントチャートを表示させてそれを追いかけていきますね。その点では、ある特定個人によって頭を切り替えるというようなことはなくて、ある程度割り切ってこの方法にしているということになるかもしれません。早く終わった、あぁやはり遅れちゃったか、というようなことはえてして発生しますし。そこはガントチャートの進捗から判断して、個別にコミュニケーションを取っていくことだと思います。

なるほど、シンプルですね。「鉄は熱いうちに打て」ではないですが、問題はその時々に都度解決を図っているということですね。Redmineですが、御社独自でカスタマイズはされていますか

そういう使い方は、現状していないですね。ですが、チケット発券時にはクライアントと共有しているExcelベースのスプレッドシートをRedmine APIを活用して同期させてチケット化するという方法を取っています。

それは、なかなか大変ですね。やはり、顧客側はどうしてもExcelになっちゃいますねぇ。ガントチャート管理の場合、スケジュールが遅れたりするケースが想像もできるのですが、その場合はどのように管理されるんですか

それも、Excelを変更して、インポートですね。運用コストがかからないようにするには、やはりそれしかないかと。

お話をしながら思い出しましたけど、Redmineのプラグインは時々利用するケースが発生しますね。アジャイルプラグインを使ったプロジェクトもありました。

私も、思い出したのですが、最近始めたばかりのもので、プラグインの「ナレッジベース」というものがあります。これを活用して、クライアントさんとの情報共有を進めてるという動きもあります。確定した情報と作業チケットの関連がわかりやすくなって、これはいいかなと思っています。

チケット発券のルールというのも、全社的に統一されている状態で運用されてますか、それとも個別プロジェクトによってリーダーに委ねている状態ですか

「品質管理」の点からも、統一しようという動きはありますが、現状は「統一」とまではいかないですね。今後は、きちんと全社ルールを定めていこうという機運はあります。

ツールに関して、ちょっとまとめると、プロジェクト管理の旗艦としてはRedmine、Teamsではコミュニケーション機能が主で、Office 365との連携ができるので、ドキュメントのリアルタイム編集などにも用いられる。ソース管理は、Gitlabということですね。リモート会議には、Hangoutが使われる。

付け加えると、UX/UI設計にはProttを使いますね。

今後の展望は

今日はラボ型開発のことを中心に伺っていますが、最近ならではの開発傾向ってありますか、あるいは注目技術など

スマホの場合だと、ネイティブアプリがまだ主要ではありますが、今後この流れにも変化が起きそうです。Webベースでの新しい試みも増えてきています。当然、クライアントさんのニーズに合わせて提案をして、ということになりますね。

コミュニケーションのあり方もまだまだ改善の余地はあるのかと思っていますが、お伝えした通りリモートメンバーも多いので、全員が顔を合わせて定期的にミーティングをするということができにくい状態でもあります。一丸となって取り組んでいることは、

– Teamsを使ったコミュニケーションで共有漏れが発生しないように心掛けること
– 必要に応じて、顔を見て話ができるようにすること
– 共有ドキュメントは、Redmineのwikiに残すこと
とまとめられるのかと思います。

率直に言って、ラボ型開発を進めていく過程でのクライアントさんからの反応はどうですか

「品質管理」体制としてのPMO機能も含めて、こういう新しい体制でチームを作ります、というような説明はきちんとして契約に臨むので、好意的に進めていただいている実感があります。

コストコントロールもしやすいですしね。

開発のドキュメントは残るものなんですか？

実際は、クライアント要件によりますね。もちろん、簡単なドキュメントはWikiに残したりしていますから。ただ、この点もやはり共通化・標準化が必要なポイントかなと考えていまして、それも検討しているところなんですね。やはり、プロジェクトごと個別対応でとしてしますと、場合によってはクライアントに対して不誠実なことになってはいけませんから。

直近では、ドキュメントの「ひな形」化ということにも取り組んでいますが、何度もお伝えしてますように取扱領域が広いためにこの「ひな形」がうまく収まるかどうか非常に懸念もある状態なんです。
あとは、さきほどご紹介したRedmineのプラグイン「ナレッジベース」ですね。

エンジニアの成長機会を会社の仕組みとして作っているという試みは何かありますか

R＆DグループはQiitaを書いてますね。ブランディングの一環としても重要だと感じていますので。

取材を終えて

会社に到着して目に飛び込んできたのが、エレベータを包むように壁一面に書かれていた社員のみなさんの「夢」でした。
社員一人ひとりの夢を叶えることができる会社でありたい！と考えるこの会社の一面を表していると印象づけられました。
例えば、「シリコンバレーで働きたい」「世界的に有名なエンジニアとプロジェクトを担当したい」など会社を通して実現できることであれば何でもいいのだそうです。
ほかにも、「笑顔の絶えない毎日」「宇宙旅行」「素敵な家庭を築く」などの夢も。

一人ひとりの生活も人生も豊かになるよう、またその夢を実現することで会社を発展させていく・・・そんな会社。

考えてみれば、経験を重ねるということは夢を奪われていくことなのかもしれないと思いました。今回お話を伺ったお二人は既にベテランの領域のエンジニアでいらっしゃいます。お話をしながら考えたのは、優れたプロジェクトチームは目標を共有しているものだ、という事実でした。
その目標を夢と言い換えてもいいのかもしれません。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。