私がSmartHRに入社して一ヶ月が過ぎました - SmartHR Tech Blog
俺だ、kinoppydだ。今日はお前にSmartHRで働くということはどんな感じなのかを伝えに来た。 このエントリは、なにか悪い力によって書かれました。 ただしいエントリは下のリンクを参照して下さい。 tech.smarthr.jp SmartHRという会社 社会の役に立つものを作っている。そういう認識をしておけばだいたい間違っていない。 紙、好きか？ 俺は好きだ。紙の質感は指に心地良いし、何より紙にはだいたい有益な情報が書いてある。俺は情報も好きだ。 だがしかし、それが年末調整や入社手続きなどの書類になると、話は別だ。俺は途端に紙が大嫌いになる。 何故か。必要ないからだ。必要ないだろ？ 今の時代、政府だっていーがぶとか、でじたるとらんすふぉーめーしょんとかいうやつで、紙じゃなくても手続きできるようになってるんだ。 ペーパーレス。最高じゃないか。俺は紙が好きではあるが、紙を右から左に送った
自分の給料を自分で決める「雰囲気給与」制度がうまくいく理由 | スタートアップに学ぶ組織の処方箋 | ダイヤモンド・オンライン
スタートアップに学ぶ組織の処方箋 成長するスタートアップには、ユニークな組織づくりや人事制度がある。ほんの少しの工夫をすることで、会社のカルチャーが変わり、社員が働きやすくなる。スタートアップの組織づくりを支える制度を紹介していく。 バックナンバー一覧 上司との面談や他者評価も一切なし。月に1度のミーティングで今月分の頑張りから自分の給与を自己申告し支払われる、珍しいモデル「雰囲気給与」。この一風変わった人事制度を創業時から取り入れているのが、スタートアップ企業のクラウドネイティブだ。一見、成立しなさそうな制度だが、実態をみると社員のパフォーマンスは上がっている。その裏には、人間の集団心理を突いた狙いがあった。（ダイヤモンド編集部 塙 花梨） 情報システム部門のコンサルティングを手掛けるクラウドネイティブの社員の給与は、テレビ会議を通して毎月（年12回）実施される全社員ミーティングで決まる
もう「公開鍵送ってください」というやり取りは不要だった - Qiita
GitHubに登録している鍵ペアの公開鍵は公開されてる 実は、GitHubに登録している鍵ペアの公開鍵は公開されてるのです。 GitHubのユーザーページのURLの後ろに「.keys」をつけると、その人の公開鍵文字列がDLできます。 アカウントがy-tsuzakiなら https://github.com/y-tsuzaki.keys です URLにアクセスすると公開鍵の文字列が表示されます。 このURLを使うことで、 GitHubユーザーには、わざわざメールやチャットで「公開鍵送ってください」と言わなくていいのです。 これは捗りますね。 authorized_keysに設定する方法 追記する方法 コメントで教えてもらいました。 @grohiro さん @ktooi さん ありがとうございます！
新入社員との1on1で使っている質問リストを公開します - 宮田昇始のブログ
SmartHR社の会議室名はemojiです 新入社員と1on1をしています 入社して2ヶ月が経過した全社員と1on1を実施しています。 一般的な1on1と同様に、コーチング的な効果を期待していますが、組織課題の早期発見の役割も果たしています。 また、この1on1実施後は、社長にも気軽に話かけやすくなるみたいで、組織内の心理的安全性を高めることにも少しは寄与しているかもしれません。 （実は、私自身かなりの人見知りで、私からも話しかけやすくなるので助かっています。） 質問リストを公開します 天気 この2ヶ月、SmartHRで働いてみた感じを天気で言い表すと、晴れ or 雨 or 曇 のどれですか？ 降水確率でいうと何％くらいですか？ その理由 その天気の理由はなんですか？ 降水確率が○%の理由はなんですか？ 入社前後のギャップ 入社前後でギャップはありましたか？ 良いギャップ、悪いギャップ、両
リードエンジニアを３ヶ月やって得た開発マネジメントに関する教訓 - seri::diary
ここ３ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実
No Estimate 見積もりしない開発手法 - Qiita
この記事は、.NetRocksの1160話 No Estimates with Woody Zuillの書き取りと、日本語訳です。2015年7月2日放送。 使ったもの (tools used)：Express Scribe & Music to Code by 翻訳にあたってCarl Franklin氏の了承は頂きました。 リスナーの投稿とか、CarlとRichardのBetter Know Frameworkは飛ばして、ゲストインタビューのみ。 日本語化してない、英語音声書き取りメモは、まんまここにおいてます。 太字は訳者が、声の大きさとかスピードから、特に強調されていると思ったところです。これは主観なので、そう感じない人がいたらごめんなさい。 Carl Franklin（以下C）Woody は30年以上プログラミングやっていて、ハンター・インダストリーでアジャイル手法のコーチやアプリケ
週刊Railsウォッチ（20191008後編）Ruby 2.7のInteger#[]でバイナリチェック、rubyzip gemは強力、13KBのJavaScriptゲームほか｜TechRacho by BPS株式会社
2019.10.08 週刊Railsウォッチ（20191008後編）Ruby 2.7のInteger#[]でバイナリチェック、rubyzip gemは強力、13KBのJavaScriptゲームほか こんにちは、hachi8833です。今夜のノーベル賞は物理学賞ですね。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください 今回も第15回公開つっつき会を元にお送りします。 ⚓Ruby ⚓Ruby 2.7でInteger#[]にrangeを扱う機能が追加（Ruby Weeklyより） 訂正（2019/10/09）: 見出しに「にrangeを扱う機能」を追加しました
![週刊Railsウォッチ（20191008後編）Ruby 2.7のInteger#[]でバイナリチェック、rubyzip gemは強力、13KBのJavaScriptゲームほか｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/e261e6d74656a4bb6568a00ee1851e326ee9dc1b/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2019%2F10%2Frailswatch_20191008_eyecatch.png)
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
プログラミングで一番難しいのは「見積もり」だと思う - Qiita
前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか？」だ。厳しいところだと「何日に納品してくれるのか？」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか？ 見
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
