エンジニアの仕事を小学 4 年生に伝える「しごと参観」を実施しました #Zaim｜Yuki Sumida
こんにちは、Zaim でアプリ開発チームのリーダーを担当している @y_sumida です。 先日「ホワイトハッカーになりたい！」という小学 4 年生の男の子と、その親御さんが春休みを利用して「しごと参観」に来社されたので、そのレポートです。 ※今回の企画は試験的に実施したものです。公式に「しごと参観」という制度があるわけではありません。また、オフィス内に立ち入るため、親御さんと NDA を結んだ上で実施しています。きっかけ来ていただいたのは、こちらの記事を書いている kobeni さんと記事に出てくる小学 4 年生の息子さん。 Zaim には kobeni さんと友人である社員がおり「職業エンジニアが普段どういう仕事をしているか見学させてもらえないか」という相談を受けたのが、きっかけです。 当時の Slack での様子 社内のパパママがあつまる育児チャンネルへの投稿がはじまりでした。 面
"誰も無理しない" リモートワークをチームで実現するための 5 個の原則 #Zaim｜kotomi
はじめにこんにちは、Zaim の綿島です。私の担当する経営企画のミッションのひとつに、スタッフのモチベーション向上のための環境構築などがあります。 その施策のひとつとして「リモートワーク（在宅勤務）」があり、これまでに何度か記事にしている通り、とっても好評です。Zaim では出社が基本スタンスですが、入社半年後の社員なら原則誰でもリモート利用 OK 。私も家事や子どもの通院のためにフル活用中です〜！ なんでリモートワークするの？具体的なメリットを挙げると… ・通勤時間が短縮できる ・通勤ストレスがない ・休憩を活用できる（家事、通院など） ・旅行や帰省のプランが立てやすいなどなどありますが、つまり！「場所と時間の自由度がめっちゃ高まって、スタッフの満足度が上がる」という一言につきます。往復の通勤時間のインパクトたるや…。 リモートワーク、問題はないの？とはいえそれは利用する側のメリットなん
成果を引き出すタスク管理術 - 失敗する原因と解決 #Zaim｜あき
「上手くいかない」 すごくがんばってるのに、なぜか上手くいかない。 やることはたくさんあるのに、何からやっていいのか、わからない。 ただモヤモヤと時間だけが過ぎていく、サービス開発最大の壁。 これを何度も繰り返してわかったことは 上手くいかないときは、そもそも「何をやったのか」を把握できていないことが多い、ということ。よく言われることですが、PDCA は現状把握からはじまります。適切にタスク管理すれば、現状把握ができるので、「失敗する原因」を特定しやすくなります。「失敗する原因」がわかれば、あとは、改善策を考えて粛々と PDCA を回すだけ。 成果を継続的にあげるには、タスク管理は必須。 今回は、ぼくが所属する Zaim デザインチームのタスク管理について書いてみたいと思います。 ちなみに Zaim のデザインチームは、データ検証 〜 仮説立案 〜 UI/UX への落とし込み、と広くやる
朝 6 時から働く超朝型エンジニアの一日 #Zaim｜watura
おはようございます。Zaim で iOS アプリ開発をしている watura です。今日は私の一癖ある働き方について紹介していきたいと思います。 Zaim では、始業時間をある範囲で自由に決められる制度があります。5 時から 10 時の間に業務を開始し、そこから 8 時間の勤務と 1 時間の休憩を入れるという勤務体系です。まるでフレックス制度のようですが、勤務時間自体は固定なのでフレックスではありません。 10 時ぴったりから始める人もいますし、9 時台や 8 時台に開始しますという人もいます。そんな中、私は 6 時台には出社して開始するという生活を 2015 年 11 月くらいから続けています。 以下、よく聞かれる質問に回答していきます。 6 時から働いたら何時まで仕事なの？15 時です。 仕事終わった後は何をしているの？ジムに行って筋トレしたり、手ごねパンを焼いたりしています。 16
ホワイトハッカーの手を借りてバグを修正！BugBounty のススメ #Zaim｜たかやま
どうもこんにちは。Zaim でユーザー事業部のマネージャーをしております高山です。どうも。えっとついこのまえ記事を書いた時と部署名が変わってますね。するどいですね（誰も気づかなそう）。そうなんです、なにやらいろいろ組織図が変わるという出来事があったのでした。あんまり関係ないですね。 今日は、半年くらい前から利用している BugBounty というサービスがめちゃくちゃいいんで紹介しにきました。 世界中の凄腕ハッカーが脆弱性を発見してくれるBugBounty は、サイバーセキュリティに関する事業を中心に展開しているスプラウト社が提供しています。サービス内容を端的にいうと「世界中の凄腕ハッカーに自社サービスの脆弱性を探してもらう」です。 自社サービスにセキュリティ上の欠陥は少ないに越したことはありません。しかし、社内のメンバーのみで対応するとしてもなかなか多くのリソースを割けないことや、そもそ
大規模サービス開発で起こりがちな「やり直し」が激減した私たちの仕様確認フロー #Zaim｜たかやま
こんにちは！Zaim でサービス開発部のマネージャをしている高山と言います。サービスの新規立ち上げやリニューアルなど大規模な開発をしていると、仕様の解釈に齟齬があったがために手戻りが発生してしまって困ったということはありませんか？ 私たちも相当苦労しており、ベストプラクティスを模索してきました。まだまだ改善すべき点はありますが、以下のような仕様確認（レビュー）フローにしてから「やり直し」が激減したので、そのやり方を紹介してみます。 仕様確認フローは大きく三段階ディレクターやデザイナーが仕様案を作成してからリリースまでのフローは、ざっくりと三段階に分かれます。 ① プロトタイプ α … 実装の方向性を定める ② プロトタイプ β … 開発を進められるようにする ③ RC … 製品品質を評価する 実装の方向性を決める「プロトタイプ α」まずはディレクターを兼ねたデザインチームが、目的を達成する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
