クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

mini_racerを剪定してbundle installの時間を97%短縮した話

こんにちは。crowdworks.jpで不正利用対策チームのエンジニアをしている得能(yoshi_10_11)です。 今回は先日取り組んだmini_racerのgemを剪定した話をします。

mini_racerってなんだっけ

mini_racerはRubyからJavaScriptを実行するのに利用されるgemです。JavaScriptのV8 エンジンを使って実行できる環境を提供します。 Ruby on Railsにおいてはアセットパイプライン環境においてJavaScriptコードを処理するために利用されます。

https://github.com/rubyjs/mini_racer

Ruby on Rails 5くらいの時代にはrails newで生成したGemfileにmini_racerが含まれているなど利用機会が多いgemではありました。 しかし、Webpackerが採用され始めたあたりからJavaScriptの実行環境にNode.jsが選択されることとなり、Gemfileからもmini_racerの記述が消えました。

Ruby on Railsで利用するJavaScriptの実行環境を選択する役目を持つExecJSというgemが今もmini_racerに対応しているので、最新のRuby on Rails環境でもmini_racerは利用可能です。

続きを読む

AIを活用して業務効率化を図る話

はじめに

こんにちは。プロダクト本部に所属しているエンジニアの孫です。 誰が、何の業務に、何時間使ったのかを可視化できるクラウド工数管理・プロジェクト管理ツール「クラウドログ」の開発を担当しております。

今回は、私が実際にAIを利用して作業をスムーズに進めた経験について紹介いたします。 日々の業務でどのようにAIを活用しているかを説明し、AI利用で初心者の方々の参考になれば幸いです。

続きを読む

マネージャーとデリゲーションポーカーをしたら権限レベルの認識が揃えられた話

はじめに

こんにちは、クラウドワークスのエンジニアをしている尾上です。

普段は、クラウドワークス テッククラウドワークス エージェントの開発業務をメインで行なっています。

今回は、マネージャーとデリゲーションポーカーを実施し権限レベルの認識を揃えた話をしていきたいと思います。

デリゲーションポーカーとは

デリゲーションポーカーは、マネージャーとチームメンバー間で意思決定の権限委譲(デリゲーション)について明確にし、共通理解を得るための対話型のワークショップやゲームです。

意思決定の委譲レベルを7段階に分け、それぞれのレベルに対応するカードを使用します。会議中に具体的な決定事項について、管理者とチームメンバーがそれぞれが望む委譲の度合い(どこまで決定を任せるか、または自ら決定するか)を示しながら、最適な委譲方法を探り合うという流れになります。

以下、デリゲーションポーカーにおける7段階のステップの定義です。

■ レベル1:Tell(指示・命令) ・管理者側が一方的に意思決定し、チームはその決定に従って実行する。 ・情報提供や相談はなく、決定はトップダウンである。

■ レベル2:Sell(説得) ・管理者が決定を下すが、その理由や背景をチームに丁寧に説明し、理解と納得を求める。 ・決定自体は変わらないが、チームの納得感を高めるプロセスが加わる。

■ レベル3:Consult(相談) ・管理者は最終的な判断権を持つが、意思決定前にチームメンバーから意見や情報を求める。 ・チームの意見を参考にしつつも、決定の主導権は管理者にある。

■ レベル4:Agree(合意) ・管理者とチームが対等な立場で話し合い、共通の認識のもとで合意形成する。 ・意思決定は共同作業となり、双方の納得と責任共有が図られる。

■ レベル5:Advise(助言) ・チーム側が主体的に意思決定を行うが、その際に管理者は助言や意見を提供する。 ・最終的な決定はチームに委ねられるが、管理者の経験や知見が参考情報として活用される。

■ レベル6:Inquire(報告・確認) ・チームに決定権を委ね、実際の意思決定はチーム側に任せる。しかし、決定後に管理者は結果の説明や報告を求める。 ・管理者は決定過程に介入せず、実施後の状況把握を重視する。

■ レベル7:Delegate(完全委任) ・意思決定のすべての権限をチームに委ね、管理者は全く介入しない。 ・チームが独自に決定し、その実行および結果に対して全責任を負う形となる。

デリゲーションポーカーを実施した背景

私は、マネージャー登用に向けてできることからマネージャー業務に触れています。

その中でできるようになったこと・まだできないこと、そしてマネージャーになる上でできるべきであることの認識をデリゲーションポーカーを通して上長であるマネージャー達と認識を揃えるのがいいのではないかと提案をいただきました。

デリゲーションポーカーを実施する主な目的は以下の3つを定義しました。

  • 尾上のマネージャー登用を見据えた準備として、権限委譲を進める必要がある
  • デリゲーションポーカーを通じて、どのタスク・意思決定に対して、どのレベルの権限を付与するかを合意形成する
  • 最終的に、尾上自身の裁量で行えるタスクの範囲を広げ、責任感と成長機会を提供する

デリゲーションポーカーの進め方

マネージャー業務を行う上でマネージャーになった時にはどのレベルに達しているべきなのかをデリゲーションポーカーを通じて確認しました。

確認したトピックは以下のものです(一部抜粋)

  • メンバーの体調管理
  • SprintBacklogの進捗管理
  • チーム目標の決定
  • ロードマップの決定

進め方としては、1つのトピックに対して各々が現時点での思う権限レベルのカードを提示します。全員のカードのレベルが一致すればその権限が現在のレベルであり、一致しなかった場合はなぜそのレベルなのかを話し合った後にもう一度カードを提示し一致するまでこれを繰り返していきました。

実際にデリゲーションポーカーを実施した中で意見が一致しなかった時のお話をしたいと思います。

  • 一致しなかったトピック

    • チーム編成の決定(トピック概要: チーム内の役割分担や構成メンバーを見直し、最適な体制を構築する)
  • 一致しなかったことで何を話し合ったか

    • それぞれカードを出した人がなぜそのレベルにしたのか自分の意見を言いました。 私はレベル3を出し、「チームの状況やタスクの優先度を鑑みた上で各チームのMgrや上長と相談するのがいいと思う」という意見をしました。 また、別のMgrはレベル4を出し、「Mgr間で合意が取れていれば問題ないと思う」という意見も出てきました。 各々の意見を聞いた上で、再度カードを提出した結果このトピックのレベルは4という結果になりました。

デリゲーションポーカーを実施してみて

デリゲーションポーカーを通して、以下のことを考えることができました。

  • マネージャーに自分は何を期待されているのか
  • マネージャーになる上で何ができていることが理想な形なのか
  • 今の自分ができることで権限はどこまで持っているのか

特に、権限に関しては自分が考えていることと上司が考えていることの相違があった場合に人的ミスを誘発すると考えるため認識を揃えることができたのは良かったと思いました。 今後もできることを増やしていく中で権限レベルはポイントになってくると思うため、定期的に実施していきたいです。

最後に

クラウドワークスではエンジニアを募集しています。興味のある方は以下のリンクからご応募ください。

herp.careers

DDD未経験が約1年DDDに触れて感じた理想と現実

はじめに

こんにちは、@momo-0826です。

約1年程前からクラウドリンクスで主にバックエンドを中心とした開発業務に携わっています。

クラウドリンクスではDDDを使用した開発が行われているのですが、DDD未経験だった私が約1年程DDDに触れて感じた自分なりの感想を書いていこうと思います。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.