的な関数に渡して実行してもらうじゃないかなと思います。使っているthread_poolのバージョンはまだ対応していないようです。関する使い方が分かったらまた更新します。以上、よろしくお願いいたします。Rustの創始者を含むコニュニティの方々が執筆するRust仕様の本です。出てきましたので、Rustの勉強ならばそっちが一番おすすめです。カルチャーTweetこんにちは!SPEEDA開発チームの岩見です。この記事では私たちSPEEDA開発チームの中でも特徴的な文化のひとつとなっている、ふりかえりについてご紹介します。以下のような方々のお役に立つことを願っています。色々なふりかえりの運用、実例が知りたい方SPEEDA開発チームにおけるふりかえり私たちSPEEDA開発チームでは、プロジェクト単位の少人数のチームに分かれ、それぞれがエクストリームプログラミング(通称XP)をベースとしたアジャイル開発を行なっています。私たちは短い開発サイクル(イテレーション)を継続的に繰り返す中で、プロダクトとチームでの開発をインクリメンタルに改善、洗練させていくことを目指しています。した中で、私たちはイテレーション(多くの場合1週間が1イテレーションに相当します)の終わりに、ふりかえりを必ず実施しています。ふりかえりの中では、イテレーションの開発を振り返って、次のイテレーションでの自分たちの開発を改善する為のアクションを一つ設定します。アクションの数を絞っているのは、数が多すぎても一つ一つのアクションに対する精度が落ちてしまうリスクがあるためです。短いイテレーションの中でより本質的なアクションを実施する為に、ふりかえりの時間の中で問題の洗い出し、深掘りを集中的に行うようにしています。して決まったアクションをチームで実行しながら、私たちはプロダクトとチームでの開発プロセスを日々進化させています。私たちがふりかえりのためのミーティングを行う際には、一つの決め事が存在します。それは、自分たちの所属しているチームの外側から、一人のメンバーにファシリテーターとして参加してもらうことです。イテレーションのふりかえりであれば、自分たちのプロジェクトチーム以外のエンジニアにファシリテーターとして参加してもらいます。このエンジニアの中には、Webアプリケーションエンジニア、テストエンジニア、データサイエンティストといった多様なロールのメンバーが含まれています。ファシリテーターの選出には、偏りや重複が出ないように、シフトを組んで回す形をとっています。そのため、チーム内のエンジニアは、おおよそ1ヶ月に一度、どこかのチームのふりかえりをファシリテーションすることになっています。SPEEDA開発チームにおけるファシリテーターの役割ではファシリテーターは何をしているのか、というと、以下のような役割を担っています。議論しやすい場の設定ユーザベースの六本木オフィスにはラウンジと呼ばれる社内ミーティング用の広めのスペースがあります。ファシリテーターはそこにホワイトボードと人数分の椅子をセットし、参加者が議論ができるようなスペースを作ります。その際には、椅子の配置をメンバーの顔が全員見えるように、かつホワイトボードが見やすいように、ホワイトボードを囲むような形で椅子を設営します。議論しやすい場作りは、ふりかえりの最中にも行われます。あるメンバーがあまり議論に参加できていなければ、ファシリテーターがそのメンバーに発言を促したり、議論が脇道にそれてきた際には、議論の進行をメンバー全員で確認したり、と言ったことを行います。した場作りによって、参加者がより議論をしやすい場面を作るのが、ファシリテーターの役割の一つです。アクティビティの選定を含めた全体の進行ファシリテーターは、ふりかえりたいテーマに合わせてアクティビティの選定や、タイムスケジュールの設定、タイムキープを行います。SPEEDA開発チームのふりかえりでは、KPTとよばれるメジャーな手法以外にも様々なアクティビティが用いられています。イテレーションで起こったことを満遍なくふりかえりたい場合にはタイムライン*1、各メンバーが思っていることや感情に着目してみたいときにはチームレーダー*2や喜怒哀*3、と言った具合に選出を変えていきます。ファシリテーターの好みとセンスに応じてどのような手法を用いるかが決められるので、参加者は毎回新鮮な気持ちでふりかえりに臨むことができています。Retrospectivesを参考にして選んだりしています。アジャイル・レトロスペクティブズは、私たち開発チームのメンバーの教科書のようなものになっており、私もファシリテーションを行う際に読み返したりしています。ファシリテーターを置くメリットチームの外側からファシリテーターを招くことで、以下のようなメリットを実感しています。ファシリテーターが他のチームへの理解を深めることができるSPEEDA開発チームでは、定期的にプロジェクトチーム間での入れ替えを行なっています。これは、プロジェクトに関する知識、技術を特定個人に偏らせないようにするための施策です。ファシリテーターとして他のチームのふりかえりに参加することで、他のチームの現在の状況を高い解像度で知ることができます。結果、いつでもチームメンバーの入れ替えを行うことができるようになっている状況を作り出す一因となっています。ファシリテーターが問題を構造的・俯瞰的にとらえる能力が高まるファシリテーターには、チームで議論されている問題を俯瞰してとらえることが求められます。議論の進行に合わせて、参加者に様々なアクションを促し、より良い解決策に導く必要があるためです。ファシリテーションは問題を構造的、俯瞰的にとらえる絶好の機会となっています。チームのメンバーが議論に集中することができるこれはチームメンバーの視点から見たメリットなのですが、ファシリテーターを別途置くことで、参加者が残り時間などに気を取られず、議論に集中することができるようになります。結果、短い時間の中でも、腰を据えた議論ができるようになり、より効果的なアクションが打てるようになります。さいごに私たちはふりかえりを定期的に実施していますが、同時に「ふりかえりに甘えてはいけない」ということもチーム内で話しています。これは、ふりかえりの場を設定しているからと言って、チームの問題や改善策について議論する場をそこだけに限定してはいけない、という意図からきているものです。私達のチームでは直接的な対話を重視して仕事をしており、何かチームで議論、改善するべき事項が出た際には、そのタイミングで議論をするようにしています。この文化とふりかえりの両輪で、チームとしてより良い姿を目指して日々開発を行なっています。私たちが目指すチームの姿は、CTO林の以下の記事で紹介しています。onlineそれでは良いふりかえりライフを!*1:時系列に沿って、チームで起こったことや、チームメンバーが感じたことを付箋に書き、貼り出すアクティビティです。一定期間内での時間、因果関係に沿ったデータを収集するのに適しています。Valuesを用いたことがあります。)をレーダー上で表し、各チームメンバーがどのように評価するかを5点満点などでプロットします。その後、プロットされた点数を元に、何故そう思ったかをディスカッションしていきます。*3:その名の通り、「喜ばしいこと」「怒りを覚えたこと」「哀しかったこと」という軸でデータを収集します。チームメンバーの感情面に着目するアクティビティです。プロダクト開発チームの板倉です。kotlin)のセットアップについて書きました。Blog今回は、実際にアプリのテストをどう書くのかについて書いていこうと思います。Activityを選択してプロジェクトを作成したアプリを例にテストを書いていきます。今回はプロジェクト作成時に作られたコードをそのまま使用しています。Stepまずは、画面表示までScenarioを書いていこうと思います。アプリを起動すると何が表示されるのかをStepに記述します。Stepの実装を書いていくStepに記述した文章はアノテーションに記述します。ダブルクオートで囲んだ部分はパラメータになりますので、メソッドに引数として定義します。1つ目のStepを例に実装すると以下のような形になります。{}メソッドの中に操作や検証を記述していきます。操作や検証をするにはセレクタを使用して要素を取得して行います。Specに記載した内容を実装すると以下のようになります。xpathは避けたほうがいいです。そのままのコードを使ったので、開発する際はidを設定するなど工夫が必要だと思います。true}この実装をする上で、ヘッダのタイトルのセレクタを記述する際に困りました。いったときに使えるツールを紹介します。DesktopAppiumはGUIツールが公開されています。このツールはインスペクターだけでなく、Appiumサーバーの起動も行えます。左側に表示しているアプリ上でヘッダのタイトルをクリックすると、中央のAppSourceに表示されたソースから要素がハイライトされ、右側には要素の情報を見ることができます。今回はツールバーをid指定で取得し、その要素からclassNameを指定して取得するセレクタを使用してタイトルの要素を取得することにしました。IOSDriverなど)が提供されているので、思ってた以上に簡単にテストを書くことができました。今回試したのはアプリに表示されている要素の取得と検証のみだったので、ネイティブ特有の機能を使う場合どのような実装が必要なのかは調べてみようと思います。プロダクト開発チームの板倉です。前回書いた時はNewsPicksの開発をしていましたが、今はSPEEDAの開発をしてます。SPEEDAのプロダクトチームでは、以下の記事のようにE2EをGaugeとKotlinを使って書くことが多いです。Blog今回は、NewsPicksでアプリ開発をやっていたこともあり、モバイルアプリではE2Eをどうやるのかなということで調べてみました。環境構築appiumのインストールとテストプロジェクトの準備について説明します。アプリ開発に関する環境構築については割愛します。appiumnpmを使ってインストールします。appiumプロジェクトMavenやGradleプロジェクトを作成したのち、以下の依存関係を追加します。java-client作成したプロジェクトでコマンドを実行してgaugeプロジェクトに必要なファイルを展開します。java実行後のプロジェクトは以下のようなディレクトリ構造になります。これでプロジェクトのセットアップは完了です。appiumのセットアップappiumを使ってアプリを操作する際は、SeleniumのRemoteDriverを通して行うことになります。DriverにCapabilitiesを指定する必要があり、Androidでは最低限以下の2項目を設定することでテストを行うことができます。/Users/user/workspace/project/test-app.apkこちらにもあるようにAndroidではdeviceNameが設定しても無視されるようです(2019.7.31時点)。Appiumコードで書くとこんな感じです。エミュレータは起動しておく必要があります。次回は今回は環境構築まで書いてみました。次回は実際にアプリをテストするコードを書いてみたいと思います!さいごにプロダクトチームは一緒にSPEEDAを開発する仲間を募集しています!プロダクトチームってどんな感じなの?という疑問に対しては、以下の記事が参考になるかと思います!journal.uzabase.com少しでも興味のある方はご連絡お待ちしております!!!使う技術は自分たちで決める。プラクティスを大きく取り入れて日々の開発を進めています。開発チームに参加してみて、ユニークだなと感じたことがいくつもありました。つのことについて紹介します。開発チームのユニークな文化を紹介することです。開発チームの現在のフェーズに固有の部分も少なからずあると思っており、これを読まれた方の組織やチームで、ここに書かれているようなことをただちに実践することを勧めるものではありません。開発チームは、開発を担う機能エリアごとに、数名程度の小さなチームに分かれています。(以後、この「小さなチーム」のことを単に「チーム」と呼ぶことにします)日々の開発(スタンドアップや見積もり、ふりかえり等を含む)はこのチームごとに行うのですが、このチームのメンバーは、数ヶ月に一度入れ替えを行っています。*1個人的には、チームのメンバーがお互いの個性やチームの文化・慣習を知り、チームとして安定してパフォーマンスを出せるようになるには時間がかかるため、頻繁な入れ替えは避ける方がよいと考えていました。チームメンバーを安定させず、メンバーが「流れる」ようにするのでしょうか?今のところ、私は以下の理由があると考えています。製品全体についての知識、および文化を共同所有するため。できるようになることが目的。「さまざまなものが流れる」文化があるため。開発チームでは多くのものを安定させず、常に流れる状態に置いている。「流れる」ことが定常状態であるため、メンバーの入れ替えもそのうちの一つにすぎず、チーム・メンバーのいずれも入れ替えにすばやく適応できる。見ると、「やる理由」と「できる理由」は表裏一体になっています。メンバーを入れ替えることによって知識や文化が撹拌され、それによってさらに入れ替えがやりやすくなる、という正のフィードバックの関係です。開発チームでは、ドキュメントを用いることがかなり稀です。アジャイルソフトウェア開発宣言では「包括的なドキュメントよりも個人と対話を」価値とする、と言われていますが、これほどまで対話(特に口頭での会話)に重きを置くソフトウェア開発組織はかなり珍しいのではないかと思います。アジャイルソフトウェア開発宣言でも「ドキュメントは不要」とまでは言っていない、とはよく言われることで、個人的にも、安定して開発を進めるためには必要十分な量のドキュメントを書いた方がよいと考えていました。ドキュメントを「最少限」と言い切れるほどのレベルにまで減らすのでしょうか?現在の私の理解では、以下の理由があると考えています。ドキュメントを減らせば、会話せざるを得ないため。本末転倒にも見えるが、知識が「流れる」ために必要な仕掛けと言える。知識は撹拌されており、また常に会話する文化があるため。製品についての知識や文化は常に流動し、撹拌されている。常時ペアプログラミングを行なっていてペア間の会話は絶えないほか、他ペアや他チームからの割り込みも奨励されており、「質問されたらすぐに答える」ことが徹底されている。お気付きのように、ここにも正のフィードバックがあります。ドキュメントを減らせば会話が増え、会話が増えれば、さらにドキュメントを減らせるようになります。「属人化を防ぐためにドキュメントを残す」と言われますが、私たちのチームでは、いわば知識が「チーム全体に属人化(属チーム化?)」したような状態といえます。開発チームでは、「担当者を明確にしない」ことがよくあります。チームでのふりかえりを行なった際は次週に取り組むアクションを決めますが、私が初めてチームでのふりかえりに参加したとき、アクションの担当者を決めずにふりかえりが終わったことに驚きました。「ちゃんと決めておかないと、みんな忘れてしまったらどうするの?」と思ったのですね。当たり前といえば当たり前ですが、誰かが覚えているのですね。アクションは次週にきちんと行われました。いえ、一般論としてはアクションの担当者を決める方が確実です。私が初めて会ったチームのふりかえりのファシリテーターだったら、「誰か担当者になってくれますか?」と聞くと思います。開発チームでは、普通なら担当者を決めるであろう場面で、あえて決めない、とすることが多くあります。これはなぜでしょうか?私の考えでは、以下が理由です。「活動の最小単位」をチームとし、何らかのタスクが個人に帰属することを防ぐため。何かを個人のタスクとしてしまうと、そのプロセスについての知識と、責任が個人に紐づいてしまう。ならないよう、万事を個人ではなくチームの関心事にとどめるために、担当者を決めない。いつでも活動の最小単位をチームとしており、そうすることに慣れているから。普段からそうする訓練をしているから。:)チーム全体でこれを意識していると、不思議と補い合うようになります。失敗することも時にはありますが、その都度会話して対応します(ただし、できる限り「担当者を決める」以外の方法で)。2」では「知識」や「文化」が流れていましたが、ここでは「担当」が流れています。開発チームでは多くのものが「流れて」います。私の個人的な感覚では、「ほとんど全てが流れている」と言ってもいいように思います。他にも、今回は紹介しなかったペアプログラミングのやり方や、ミーティングの進め方、製品のデザイン等々、多くの場面が「流れ」の中にあるように感じます。ソフトウェアサービスなので、その開発チームにあって流れは重要です。そのため、「流れ」はそれ自体として目的の一つになりえます。一方で、「流れ」は究極の目的ではないはずです。プロダクトチーム(開発チームもここに属する)のミッションは「技術力で、ビジネスをリードする」です。すれば、この「流れ」の文化はそれを支えるものであるはずだし、そうあるべきです。林が掲げている「最高の開発チームをつくる」は、「流れ」によって支えられる大きな目標の一つなのでしょう。月足らずですが、これからもチームで仕事をしていく中でこの流れの文化の究極の意義を見つけ出し、発展させていくことを楽しみにしています!*1:ちなみに入れ替えを行うこと自体は半ばルール化されていますが、誰が入れ替わるかはメンバー自身の意思によって決まります*2:もしかしたら、チームの中を「漂っている」と言った方がより的確かもしれません。つのことTweetもっと読むコメントを書く次のページプロフィール『経済情報で、世界を変える』をミッションに、企業・業界情報プラットフォーム「SPEEDA」やソーシャル経済ニュース「NewsPicks」、ABMを強力にサポートする「FORCAS」、スタートアップの情報収集を圧倒的効率化「entrepedia」などを提供する株式会社ユーザベースの技術チームブログです。多国通貨」をハンズオンしたら快適で楽しかったGo言語でオブジェクト指向プログラミングの基本(型編)月別アーカイブ検索@Uzabase_Techさんのツイートスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。