エンジニアリングによる 4 つの育児支援で育児も KAIZEN する

Kaizen Platformのアプリケーションエンジニアの大迫です。

Kaizen Platformは「21世紀の新しい雇用と働き方を創出する」プラットフォームを作る事をビジョンとして揚げています。 そういった新しい働き方を作っていくため、まずは我々自身がそのような新しい働き方をドッグフーディングしようということで、創業期から様々な努力を積み重ね「自由と責任」をもった上で、一人一人が最大限にパフォーマンスを出せるような新しい働き方に挑戦しています

私自身も3歳と0歳の子育てをしながら子育てをしている妻を支援しながら働いていますが、リモートワークなどによって、柔軟に働くことができるKaizen Platformの環境のおかげでとても助かっています。 本ブログでは会社で取り組んでる内容に関することが多いですが、たまには趣旨を変えて、この投稿では、新しい働き方に挑戦するかたわらで、我が家でやっている妻の子育て支援のうちエンジニアリング的な要素があるものを4つ紹介していきます。


1. 読み聞かせ支援

毎日妻が寝る前に絵本を読み聞かせしてくれていますが、たまに疲れて眠ってしまった時でも私が代わりに読んであげなくても良いように、タブレットに読んでもらう事にしました。

作り方

自動再生プログラムを Chrome Extensionとして作成しました。 https://github.com/kissrobber/audio_auto_play_chrome_extension

素材としてこちらのサイトを利用させていただいています。 http://hukumusume.com/douwa/index.html

使い方

Chrome ExtensionなのでChromeにインストールして利用します。 我が家ではKindle Fire HDで実行したかったのですが、Chrome MobileはExtensionが動かないようなので、Yandex browserというChromiumベースのブラウザを使う事で対応しました。

  • いろんなお話を順番に読んであげる場合
  • ひとつのお話を繰り返し読んであげる場合

2. Asana + Apple Watch + Siri + IFTTT によるTODO管理

子供は突然予期しないErrorをraiseしてきます。 また、子供を世話している時のマルチスレッド制御はうまく回りません。たとえば妻が何かあるタスクを実行中でも、子供は躊躇なく優先度が最高に設定された新しいスレッドを生成してきます。 そしてそのスレッドが終了する頃にはもともと何かやってたわからなくなってしまう...というような事をくり返しているとどんどん余計な仕事が増えていって悪循環に陥ってしまってました。

AsanaとApple WatchをIFTTTで連携して妻のタスク管理を支援する事にしました。

設定内容

  1. Asanaに家族用のWorkspaceを作成し、'TODO'と'買い物'というProjectを作成します。家族のTODO管理であればFreeプランでも十分だと思います。
  2. iPhoneのリマインダーというアプリに「やることリスト」と「買い物リスト」という二つのリストを作ります。 リストへの追加はSiriに「体操服に名札をつけるをやる事リストへ追加」とか「歯磨き粉を買い物リストに追加」とかお願いすればOKです。
  3. IFTTTで、リマインダーのリストに登録されたらAsanaの対応するProjectにタスクを追加して自分にアサインするように設定します。

使い方

これは我が家ではものすごく効果がありました。

最初はAsanaだけ準備して、妻に必ずタスク登録するように言っていましたがなかなかうまく回りませんでした。 妻自身は忘れないようにTODOに登録するという事を意識していても、子供が泣き始めたら一旦待たせておいてiPhoneを起動して中断した作業をTODOに登録...など現実的に難しいという事に気がつきました。

Apple Watchなら両手が塞がってても大丈夫なので子供が泣いたらすぐに対応しながらでも、割り込まれたタスクをTODOに追加できます。 外出先でも、ベビーカーを押しながらでも思いついたらすぐにTODO登録できるようになります。

そして無事Asanaでタスクを家族でシェアする事ができるようになり生活が改善されました


3. バウンサーを自動で揺らす


Homemade Automatic Baby Bouncer - Arduino

一人目の娘が常にバウンサーを揺らしていないと泣く子だったのでArduinoの勉強も兼ねてバウンサーを揺らす装置を作りました。

なおこの様子はアルジャジーラで放送されました。 (11分過ぎに5秒ほど登場します) https://www.aljazeera.com/programmes/rebelgeeks/2015/11/technology-maker-movement-151109094029782.html

作り方

https://github.com/kissrobber/Automatic-Baby-Bouncer (この程度の制御であればArduinoを使う必要ないというツッコミは無しでお願いします)


4. 「ねぇアンパンマン」でGoogle Assistantを起動する

Google Homeでも十分子供のおもちゃになってくれると思いますが、 我が家では Snowboy を使ってアンパンマンに喋らせる事にしました。

作り方

私はGoogle AIY Voice Kit を使ってますが、提供されているimageは使わずに、 https://github.com/shivasiddharth/GassistPi を使っているためRaspberry Piがあれば大丈夫です。

  1. https://github.com/shivasiddharth/GassistPi のREADMEを参考に設定をします
  2. https://github.com/Kitt-AI/snowboy のREADMEを参考にSnowboyの設定をします
  3. SnowboyとGassitPiのサンプルコード等を参考にして適当に連携するコードを書きます。 参考に私が使ってる連携部分のコードの一部を載せときます。

gist3facfde95674f8ba00ccd073c12486f3

その他の活用

Google Assistantの起動以外でも自由にプログラム書けるので、普通にRaspberry Piの電子工作をすれば、声でおもちゃを動かしたり等色々できると思います。

上の子が一人でトイレに行けるようにトイレの電球を人感センサー付きの電球に交換していますが(スイッチに手が届かないので)、 https://github.com/shivasiddharth/GassistPi はHueの制御もサポートしているようなので、アンパンマンにお願いして電気をつけてもらうなども簡単にできそうです。


あとがき

今回は 4 つの事例を紹介させていただきましたが、仕事で様々な KAIZEN をするのに加えて、家庭内の育児も継続して KAIZEN していきたいと思います。

GraphQLを使ったAPI仕様中心開発の導入とその効果の紹介

Kaizen Platformでフロントエンド開発をやっているlacoです。

新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。

API仕様中心開発

API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。

JSON Schema Centralized Design // Speaker Deck

Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関係は避けなければなりません。

そこで、フロントエンドとバックエンドが分業を始める前に先んじてAPI仕様を定義し、そのAPI仕様を中心に分業を行おうと考えました。バックエンドはAPI仕様を満たすようなAPIを実装し、フロントエンドはAPI仕様に準拠したレスポンスが得られることを前提に実装します。これをKaizen PlatformにおけるAPI仕様中心開発と定義づけました。

API仕様中心開発において達成したい目的は次の2つです。

  • フロントエンド/バックエンドがスムーズに協働・分業するための Living なAPI仕様を定義すること
  • 仕様と実装が乖離しないAPIドキュメンテーションを維持すること

f:id:kaizenplatform:20180607174359p:plain

これらを実現するために、次のものを用意する必要がありました。

  • API仕様を明確に定義するためのフォーマット
  • 記述したAPI仕様を管理・閲覧できる場
  • 記述したAPI仕様をフロントエンド/バックエンドの実装から参照する仕組み

GraphQLによるAPI仕様定義

今回のAPI仕様中心開発においては、API仕様を定義するフォーマットとしてGraphQL Schemaを採用しました。 その理由は次のとおりです。

  • モデル定義とエンドポイント定義が書きやすく読みやすい言語であったため
  • GraphQLスキーマからのドキュメントHTML生成が容易であった
  • 実装もGraphQLにすることで、コード生成やバリデーションなど、API仕様を実装から参照する仕組みが構築しやすかった

このテーマについては、GraphQL Meetup Tokyo #5で議題に挙げさせていただいて、有意義な議論ができました。

書きやすく読みやすい言語

現状、API仕様を定義するための言語・フォーマットとしてはOpen API Spec (Swagger)などの選択肢もありましたが、次のような理由でGraphQL Schemaを採用しました。

  • SwaggerのJSONは複雑で手書きしにくい
  • TypeScriptの型定義ファイルだけではモデルの定義しかできない
  • GraphQLのスキーマ言語はAPIサーバーのための専用言語なので、ユースケースがマッチしている

今回の開発手法においては、API仕様はフロントエンドとバックエンドが実装前に検討して定義するものなので、手書きしやすさを重視した選定となっています。

f:id:kaizenplatform:20180607174440p:plain (GraphQL Schemaの例)

ドキュメントHTML生成

GraphQL Schemaはgraphdocのようなツールで簡単にドキュメンテーション可能でした。 CIでドキュメンテーション生成を自動化できたため、メンテナンスするのは手書きのGraphQL Schemaファイルだけでした。

f:id:kaizenplatform:20180607174502p:plain

(自動生成されるAPIドキュメンテーションの一部)

参考:

API仕様を実装から参照する仕組み

GraphQLを実装にも使うことで、実装がAPI仕様に準拠していることを機械的に保証することができました。 バックエンドでは実装から生成されたGraphQL Schemaとの差分をチェックし、フロントエンドではGraphQL Schemaから生成したTypeScript型定義ファイルを利用して型の整合性を担保しました。

結果として、GraphQL SchemaをAPI仕様のフォーマットとして採用したアプリケーションの構成は、次のような形になりました。

f:id:kaizenplatform:20180607174527p:plain

この開発手法において、API仕様のフォーマットの重要なポイントは次の2つです。

  • 書きやすさ
    • メンテナンスが面倒にならないこと
    • チームメンバーが誰でもメンテナンスできること
  • 読みやすさ
    • あいまいさがないこと
    • チームメンバーが誰でもAPI仕様を理解できること

バックエンドがAPI仕様の更新をスキップして実装しはじめた瞬間に崩壊するので、 API仕様中心開発の成功はバックエンドのメンバーの貢献にかかっているといっても過言ではありません。 そのため、API仕様が更新しやすいこと、面倒くさくならないことが極めて重要です。

開発フローについて

API仕様中心開発の具体的な進め方は、次のような流れになりました。

  1. 担当(誰でも良い)が要件を満たすためのAPI仕様の変更プルリクエストを投げる
  2. チームメンバーでレビューし、合意が取れたところでmergeする
  3. merge後にフロントエンド、バックエンドが実装をおこない、実装が揃ったらリリース可能となる

f:id:kaizenplatform:20180608095524p:plain

このワークフローを実行したなかで、次の点への注意が必要だとわかりました。

API仕様のバグはそこそこ発生する

仕様に合意したものの、実際に実装しはじめるとAPI仕様に問題があったり、よりよい仕様があることがわかったりするケースが少なくありませんでした。 原因はGraphQLへの理解の不足や、アプリケーションのユースケース定義の漏れなど様々でした。 そうした場合も、その変更をふたたびAPI仕様リポジトリに提案し、合意をもって修正しました。

ここで重要なのは、こまめな(できれば毎日)コミュニケーションで、早くお互いの不満や問題意識を共有することです。分担後の互いの実装状況や困っていることを共有することで、API仕様の問題に早く気づくことができました。

現在の実装が準拠しているスキーマの版をわかるようにしておく

dev環境やQA環境、本番環境で、そのデプロイのバージョンが準拠している仕様のリビジョンは追えるようにしておく必要があります。 互換性のないAPI仕様の変更があったときには、フロントエンドとバックエンドのデプロイの時差によるダウンタイムについて考慮が必要でした。

API仕様中心開発の効果

ここまで紹介したKaizen PlatformのAPI仕様中心開発を実際に導入し、次のような効果がありました。

恩恵

  • バックエンド実装にブロッキングされずフロントエンドを実装できた

当初の目的どおり、バックエンドのAPI実装を待たずにフロントエンドの実装を進められました。 リクエストとレスポンスの仕様が決まっているため、正しいモックを実装しやすく、バックエンドAPIが実装できたあとにはモックから差し替えるだけでほとんどリリース可能な状態になっていました。

  • チーム内でAPIについてのコミュニケーションが楽だった

フロントエンドにもバックエンドにも依存しない独立したAPI仕様が共通言語として機能したため、 リクエストやレスポンスの型についてのコミュニケーションが円滑に進みました。

  • GraphQL Schemaからの型生成により、型安全なGraphQLクライアント実装ができた

apollo-codegenを使って生成したTypeScript型定義ファイルのおかげで、型安全なGraphQLクライアント実装ができました。 実際にリクエストするクエリに対応したレスポンス型が生成されるため、フィールドの有無や型について悩むことがなくなりました。 GraphQLのNullableの情報もTypeScriptに変換されるため、strictNullChecksの恩恵も受けられたのが非常に良かったです。

課題

  • API仕様にバグ(考慮漏れ)があると両方に影響する

API仕様中心開発はバックエンドとフロントエンド間での依存関係はないものの、双方がAPI仕様に依存します。 そのため、先述のとおりAPI仕様にバグがあると両方の実装に影響してしまいます。 なるべく手戻りを避けるためには、API仕様をバリデーションするような仕組み、API仕様のユニットテストなども視野にいれる必要があるかもしれません。

  • API仕様に準拠してフロントエンドを書いてもバックエンドに漏れがあると壊れる

当然ですが、API仕様中心開発はフロントエンドとバックエンドの双方が仕様に準拠して実装しているという約束の下に分業を効率化しています。 そのためバックエンドの実装がAPI仕様からずれているとフロントエンドとしてはどちらに合わせるべきか悩むことになってしまいます。 我々のチームでは、サーバー実装がAPI仕様に準拠していることをチェックする仕組みを作って解決しましたが、将来的にはバックエンドもGraphQL Schemaから生成されたソースコードを使うようになると良いかもしれません。

まとめ

チームのほぼ全員がAPI仕様中心開発もGraphQLも未経験でしたが、最初に目的を明確にしたことで、軸をブレさせずに試行錯誤しながら進めることができました。 チーム内でGraphQLの知見も深まりましたし、今後の開発においても採用するモチベーションが高まりました。

効率的な協働・分業のワークフローの追求のため、今後もこのAPI仕様中心開発をベースに改善を続けていこうと考えています。

フロントエンドエンジニアとデザイナーでの合同合宿を開催しました in 京都

こんにちは。Kaizen PlatformでデザイナーをしているKosukeです。先日、京都で当社のフロントエンジニアとデザイナーが集い、合同合宿を行いました。メンバーが福岡、大阪、東京に住んでいるので、中間地点の京都での開催となりました。

開催場所

京都駅からバスで数分のところにある京都リサーチパークという場所で行いました。

www.krp.co.jp

開催に至った背景

先日、当社のウェブサイトのリニューアルと共にKAIZEN TEAM for Xというサービスを発表しましたが、プロダクトとしても大きな変革を迎えようとしています。この変革に立ち向かうためには、プロダクトチームの中でも特に密な連携が求められるフロントエンドエンジニアとデザイナーの間でのスムースな協業が必要不可欠です。また、リモートワークなど新しい働き方を実践する当社では、開発やデザインのプロセスにおいてもさらなる飛躍が必要です。チームとしての協業体制を整えて、今後の開発を加速させていくためにどう動いていくかの目線合わせを合宿という場で改めて行いました。

f:id:kaizenplatform:20180531153801j:plain

何を話したか

まず現状の整理と目指す先を決めた上で、具体的にどう協業していくかのプランを練りました。具体的なアジェンダは以下です。

Part 1 現状の整理と目指す先を定める

  • プロダクト成長フェーズにより変化するUX要件の整理
  • Kaizenの提供サービスにおける必要不可欠な要素(UX/UI要件)を定義する
  • 現状のフロントエンド & UX/UI 設計進行の整理

Part2 協業のアクションプランの制定

  • 現状の体制で最も最適な業務分掌について
  • 協業の進め方・スムースな協業のための準備
  • Material Theme Editor を利用したスタイルガイドラインの更新と Theme ファイルの作成

合宿の内容

f:id:kaizenplatform:20180531161448j:plain

過去や進行中のプロジェクトを振り返り、特にフロントエンドとデザイン間で上手く進行できなかった例についてその原因を深掘りしました。(例えば、あるプロジェクトでは仕様がなかなか固まらずに後戻りが多発、別のプロジェクトでは度重なる仕様の考慮漏れやペルソナが定まらない問題などが発生していました。) 特に総意があったのは、誰の何を解決しようとしているのかという部分が曖昧になって進んでしまうことで、後の工程でデザインや仕様が着地するのに必要以上に時間がかかってしまっているということでした。

f:id:kaizenplatform:20180531162952j:plain

各開発プロジェクトのフロントエンドとUX/UI設計進行のおいて決める必要がある事項と依存関係について、具体的なタスクレベルで洗い出して、チームの総意としました。今後はまず各プロジェクトでフロントエンドエンジニアとデザイナーのメンバーが主導で実践し、磨きをかけていくことになります。

↓は合宿の議論を元にProduct設計原則として当社フロントエンドエンジニアのlaco氏がまとめてくれたもの。

f:id:kaizenplatform:20180531162834p:plain

まとめ

今回はあえて各メンバーの中間地点をとって遠隔で開催することをしました。場所を変えて議論をすることで、具体的な普段の業務からは少し離れた視点で、良いプロダクトを作るためにいかに協業していくかをざっくばらんに話すことができました。特に既存のプロジェクトにおけるデザイン工程については白熱した議論となりました。

f:id:kaizenplatform:20180531160909j:plain

これをきっかけに今後はより密な連携をすることで、より良いプロダクトを作っていくことを各メンバーが心に決めた一日でした。

おまけ

f:id:kaizenplatform:20180531161019j:plain 京都リサーチパークの近くでランチをしたお店。新鮮な魚を美味しくいただきました。

Rails でイベントの処理数や処理時間を計測して Datadog や Mackerel で監視する

Kaizen Platform で Product Manager / Engineering Group Manager をしている @takus です。

Kaizen Platform では多くのアプリケーションで Ruby on Rails を採用しています。Rails には Active Support の Instrumentation 機能というものがあり、これを利用するとアプリケーション内でのイベント処理数や処理時間を計測して Datadog や Mackerel といった監視システムに送ることが簡単にできるので、その話を紹介したいと思います。

TL;DR

  • Rails でイベント処理数や処理時間を計測して監視システムに送りたい
  • Active Support の Instrumentation 機能を使うと簡単にできる
  • 試しに Delayed::Job の Job 処理数と処理時間を計測して可視化してみた
続きを読む

木曜午後に「ミーティングしませんDay」を試験導入して、組織としてまとまった時間を作っている話

Kaizen Platform でプロダクトマネージャーをしている Kawabe です。 社内で「ミーティングしませんDay」(以下、MtgしませんDay) という制度を試験導入してみたのでその話について紹介したいと思います。

TL;DR

  • 社内での非同期時間の生産性を向上するために「MtgしませんDay」を試験導入した
  • 木曜午後のみ、社内 MTG の開催Slack で相手に即時の応答を求めること を非推奨とした
  • 生産性が倍増(当社比)、社内アンケート結果も好評だったので継続して実施中

「MtgしませんDay」誕生の背景

組織の時間を有効に使うには、大きく3つの打ち手があります。 スタートアップにとって最も貴重な資源である「時間」を有効活用するため、Kaizen Platform では日々の仕事の進め方を改善して、生産的に働けるように努力をしています。

f:id:kaizenplatform:20180518003359p:plain:w640

  • 同期時間を減らす
    • ミーティングを減らしたり、参加人数を絞ることが該当します。
  • 同期時間の質を上げる
    • ミーティングの建付けを再整備したり、準備をしっかりおこなうといったことが該当します
  • 非同期時間の質を上げる
    • 今回の施策はコレです

今回は 非同期時間の質を上げる ために、まとまった時間を捻出するための取り組みを考えましたが、はじめに、まとまった時間を捻出することがなぜ大事な理由について紹介します。

まとまった時間を捻出することがなぜ大事か?

何かをしている最中に割り込みが入ることは、皆さんが思っている以上に生産性を阻害します。


生産性の高い企業とは、どんな企業かより引用

生産性の高い企業は仕事への割り込みを最小にする

ピーター・ドラッカーが指摘するように「時間は大きなまとまりにする必要がある」。 「報告書の作成に6時間から8時間を要するとする。しかし1日に2回、15分ずつを3週間充てても無駄である。得られるものはいたずら書きにすぎない。ドアに鍵をかけ、電話線を抜き、まとめて数時間取り組んで初めて、下書きの手前のもの、つまりゼロ業案が得られる。時間は大きなまとまりにする必要がある。小さなまとまりでは、いかに合計が多くとも役に立たない」

「人のために時間を数分使うことは、まったく非生産的である。何かを伝えるためにはまとまった時間が必要である。計画や方向づけや仕事振りについて、部下と15分で話せると思っていても、勝手にそう思っているというだけのことである。肝心なことを分からせ、影響を与えたいのであれば、一時間を必要とする」

この事実に関して、まったく無頓着な上司やマネジャーが数多くいることを私たちはよく知っている。

  • 上司が部下に対して、作業中に遠慮なく話しかける
  • 予定にない会議を頻繁に繰り返す
  • メールに対して即時の返信を求める
  • メールや掲示板で済むことを電話や会議で行う

仕事への割り込みを極力小さくしなければ、生産性の向上は見込めない。


社内 Qiita:Team の投稿より引用

ですので、プロダクト開発においてはより価値の高い製品に昇華させるには、表面上の工数の見積もりよりも、時間的な幅があったほうが絶対によいし、日々の仕事のサイクルの中でも会議が断続的に行われて割り込まれるようなことはなるべくさけて、まとまった時間を確保できるようにする、ということはすごく大切なことだと思っています。

エンジニア行動指針の中に

非同期に働く。フロー状態の同僚を邪魔しない

という一文を入れたのは上記のようなことを強く意識しています。

自分にまとまった時間を作るだけでなく、相手がまとまった時間を確保できるように配慮する。それが結果的に組織的なまとまった時間につながると思います。これを達成するには、ただ単に相手の邪魔をしないということだけでなく、人にちょっと聞けばわかりそうなことも一端ぐっと堪えて飲み込んでまずは自分自身で解決することを考えてみる、という態度を是とする必要があります。同時に、高い目標について皆でそれを確認しながら、それについて慌てずじっくり考え続ける、ということも大切です。

こういう考え方を大事にするチーム、組織、会社にしていきたい、そうであってほしいなと思います。


ということで、まとまった時間を捻出するために「Mtgをしない時間帯」を試験導入することにしました。 初期フェーズでは、開発部においてミーティングを招集することが多いプロダクトマネージャー同士で実施していましたが、2 人では困難なので組織的に取り組んだのが今回の施策が生まれた背景です。 とはいえ全てのミーティングを禁止にすると業務に支障がでる可能性もあるので、あくまで「非推奨」としています。

「MtgしませんDay」の過ごし方ガイドライン

対象は木曜日の 13:00~18:00 の時間帯とします

  • 社内 MTG は基本的には入れない
    • 障害対応など、やらなきゃいけないものはやる
    • 他に時間がどうしてもとれない場合はやる
  • 社外 MTG は OK (お客様は最優先、採用面接も優先)
    • ただし積極的にはその時間を狙わない。他時間の選択肢があるなら、そうする。
  • 相手に即時の応答を求めない
    • Slack に即レスしなくても怒らない
    • イヤホンをしている人には直接話しかけず、Slack する

この時間にやるのを推奨すること

  • 中長期の戦略策定
  • ドキュメンテーション、言語化作業
  • 分析作業
  • など

予め、この時間にやることを計画しておくと良いです。

この時間にやるのは非推奨なこと

貴重な「まとまった時間」を有効に使うことが目的なので、短時間でできる単純作業は避けましょう。 例えば経費精算などの事務作業などが該当するかと思います。

「MtgしませんDay」 アンケート結果の抜粋

f:id:kaizenplatform:20180518010350p:plain:w640

  • 総括
    • 取り組みへの評価は、概ね良い印象
    • 割り込みはあったものの、木曜日の時間の使い方は 7 割の人が変化があったようです
    • 元々ミーティングが少ないエンジニアと比較すると、カスタマーサクセスにより変化が大きいようです
  • より良い取り組みにしていくためには?
    • 期間中は極力 Slack も使わないようにする (この結果からガイドラインが更新されました)
    • 全社的な取り組みにする
  • 参考までに時間の使い方の工夫についても聞いてみた

最後に、現場の声として、同じくプロダクトマネージャーとして働いている takus の発言を引用させていただきます。

まとめ

自分にまとまった時間を作るだけでなく、相手がまとまった時間を確保できるように配慮する。 それが結果的に組織的なまとまった時間につながり、よりよい仕事の成果に繋がるのではないかと思います。