毎年11月11日は「ポッキー＆プリッツの日」！ ポッキーとプリッツの形が数字の1と似ていることから、 平成11年（1999年）11月11日の "1"が6個並ぶおめでたい日にスタートしました。 第1回の記念日として認定され20年以上が経ちました。 お客さまへの感謝の気持ちを込めて、毎年キャンペーンを実施しています。
11月11日は、ポッキー＆プリッツの日｜グリコ
毎年11月11日は「ポッキー＆プリッツの日」！ ポッキーとプリッツの形が数字の1と似ていることから、 平成11年（1999年）11月11日の "1"が6個並ぶおめでたい日にスタートしました。 第1回の記念日として認定され20年以上が経ちました。 お客さまへの感謝の気持ちを込めて、毎年キャンペーンを実施しています。
エンジニア立ち居振舞い: ミスを個人のせいにしない - だいくしー(@daiksy)のはてなブログ
お題「エンジニア立ち居振舞い」 エンジニアという仕事にミスはつきものである。 あってはならないことだけど、自分が障害の原因を作り込んでしまったり、データベースに対するオペレーションをミスってデータが消えてしまったり、そういうミスをしたことがないエンジニアはたぶんいないだろう。 個人の書いたコードや、オペレーションが起因で発生したエラーは、当然個人の責任になってしまうのだが、それを過度に責めるのはよくない。 ミスが続いて、萎縮してしまうことにより、柔軟な発想が失われたり、さらなるミスを誘発してしまうからだ。 ミスがつきものの職業であるからこそ、ミスに寛容になろうとすることで、品質を向上できることがある。 ミスを個人のせいにしないという状況は、責任を分散できる体制を作ることで実現できる。 コードは必ず第三者がレビューする、危険な操作は必ずペアで実施する、などだ。 こうすることで、個人ではなく、
エンジニア立ち居振舞い：文系マインドもロジックの内。 - そらを自由に飛びたいな
お題「エンジニア立ち居振舞い」 割と昔から気を付けてる所。 自動化を推進する立場だと、「やる気でカバー！」とか「根性デバッグ」を低く見積もりがちだけど、自動化するまではそういう人たちに頼らざるをえない。 織田信長や豊臣秀吉をリスペクトできて、旧世代の遺物をリスペクトできない理由はなんぞや。秘伝のタレ作りはNGだけど、作らざるをえなかった事情を考慮して作った人をリスペクトしよう。 その方が、商売まるく収まりやすい気がする。という経験則。
エンジニア立ち居振舞い : オンラインコミュニケーションに少しの気遣い - もやもやエンジニア
お題「エンジニア立ち居振舞い」 ということで普段自分が気をつけてることでも書いてみます。 今でこそコミュニケーションはSlackやQiita Teamなどのツールを使い、レビューはGitHubの上でPull Requestを送ってそこにコメントするという開発スタイルになっていますが、自分のエンジニア歴の中ではここ3年くらいの出来事です。 そこで昔を振り返って今と比べてみると、開発を進める上で、オンラインでのテキストコミュニケーションが格段に増えたと思うんですよね。すぐ近くの席にいるのにSlack上で盛り上がったりするのもよくある光景になりました。 で、気づいたことがあって、テキストのコメントは不思議と受け取る人によってはキツめにとられることがあるんですよね。実体験としては、ある問題に対してチャット上ですごい厳しいことを言っている人がいて、このままだと荒れそうだから直接話に行ったら意外と揉め
エンジニア立ち居振舞い「自分の担当範囲を意識する」 - マルシテイア
お題「エンジニア立ち居振舞い」 僕は今のチームでフロントエンド担当ということになっている。 一応肩書は「アプリケーションエンジニア」だしサーバー側のコードもガンガン書くけど、他のエンジニアとの立ち位置を考えると自然と担当範囲が決まってくる感じだ。 担当範囲の決め方 うちの会社ではWebサービス開発を行うエンジニアを「アプリケーションエンジニア」として一律に扱っているが、その実メンバー毎になんとなく担当範囲が存在する。 担当範囲は、個人的な嗜好、経緯、あとはチーム内での分担で決まる。 僕の場合は、フロントが好きということもあったし、チームに入ってすぐフロントのタスクをゴリゴリ進めた結果、すんなり現在のポジションに落ち着いた。 チーム内で一番JS書ける必要はなくて、チーム内での比較優位で決まることもある。 今のチームでもう2年以上も働いていて、その割に知らない仕様とか沢山でてくるけど、それらを
エンジニア立ち居振舞い：論理的に考える - えいのうにっき
ひとでくんさんが作ってくれた お題「エンジニア立ち居振舞い」。ぼくはセールスエンジニア...、、あっ、エンジニアじゃんってことで考えてみた。 常に物事を論理的に考え、捉えるようにする 僕のいまの仕事のうちのひとつに、ユーザーさんからの技術的な問い合わせに対する受け答えをする「テクニカルサポート」というものがあって。 hatenacorp.jp ご意見やご要望、動作不良など、日々さまざまなお問い合わせをいただくのだけど、特に「なぜかうまく動かない」といったお問い合わせは、僕の目から見ても「なぜうまく動かないのかわからない」ということも多くて。 特に、起きてる現象に対しての「ひと目見ただけでの時点での感想」は、ユーザーの方が抱くものと殆ど同じだったりする。 ただそこからがやはり大事だと思っていて、 目の前で起こっている事象が起きる原因としては、どういったものが考えられるか。 原因と思われるもの
エンジニア立ち居振舞い：なんでもかんでも技術で解決しない - 文字っぽいの。
お題「エンジニア立ち居振舞い」 面白そうなので便乗する。 だいたい表題通りで、エンジニアはエンジニアリングができてしまうので、エンジニアリング（技術）で解決できる or できないの視点で見がち。 自動化とかスケールするかとかの話も好きなので、自動化できてかつスケールするような仕組みを、新機能を作り始める初期から考えることが多い。 例えば、「今日のおすすめ10選」という毎日更新される機能を実装しようとなった時に、「じゃあLIKEが付いた順と更新日時でいい感じに計算して、バッチ処理でもしましょう。」となる。 ただ、その機能を実装するためには工数がかかるし、そもそも「今日のおすすめ10選」によってKPIにどのくらいの影響があるか分からない。 わからないのにそこに工数を割いてしまうと「なんかすごい時間かかって疲れて作った機能だけどユーザには全然使われない。」という不幸を産んでしまう。 これは正解で
弁護士ドットコムが実践する、チームで仕事をするために大事な6つのポイント〜エンジニア編〜 | 弁護士ドットコム株式会社
弁護士ドットコムは、世界中の人達が「生きる知恵＝知的情報」をより自由に活用できる社会を創り、人々が幸せに暮らせる社会を創造するため、「専門家をもっと身近に」という理念のもと、法律相談や弁護士検索が無料でできるポータルサイト「弁護士ドットコム」や、税務相談ができるポータルサイト「税理士ドットコム」といったインターネットメディアを運営しています。 2015年10月には新しく、「法律（Legal）」×「IT（情報技術）」を駆使した「LegalTech」事業の展開を始め、Web完結型クラウド契約サービス「クラウドサイン」をリリースしました。 今回は、弁護士ドットコムのサービスを支えるエンジニアたちが、どのような体制で仕事を進めているのか、ご紹介したいと思います。チーム体制だけでなく、働く環境や仕事に対するマインドなど含めて、まとめてみました！ 1Product=1Team（に近づける）弁護士ドッ
スケールする会社を支える開発組織のマネジメント
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
エンジニア立ち居振舞い：サービスを使い倒す - あんパン
ひとでくんさんが お題「エンジニア立ち居振舞い」 を作っていたので参加します。 toBなサービスを開発しているとなかなか難しいかもしれません。幸いなことに今自分が携わっているプロダクトはどちらかというとtoC寄りなので成り立っています。 サービスを使い倒す おそらくどのエンジニアも自分が携わっているプロダクトに少なからず愛着を抱いていると思います。嫌いなプロダクトに携わるのではモチベーションが保たないはずです。また、プロダクトが好きなので自ずとドッグフーディング*1をされている方も多いと思います。 しかし、自分がいちユーザであるWebサービスなどでは作業が単純化しがち、特定の機能を使いがちになります。例えばブログサービスであれば、毎日PCから書くだけ、購読しているブログの新着記事を読むだけなど。もちろんこれでも良いといえば良いのですが、自分はなるべく意識的にいろんな機能を使うようにしていま
エンジニア立ち居振舞い: プルリクエストは全部見る - 平常運転
お題「エンジニア立ち居振舞い」 だいたいタイトルが全て。GitHub (or GitHub Enterprise) で仕事をしているので、コードに誰かが何か変更を加えようとするときはプルリクエストを出すことになる。普段仕事をするとき、仕事のリポジトリに誰かがプルリクエストが submit したらそれを全部一旦眺めるようにしている。眺めると言っても実際にコードレビューを全部僕がしている訳ではなくて、コードベースのどの辺を変えようとしているのか、どう変えようとしているかとかをなんとなく把握しておこうとしている。そのまま本当にレビューすることもあるし、ざっと見るだけのこともある。 把握しておくと何かと便利で、他の人のタスクと競合しそうなプルリクエストを見つけたときに「こっちとぶつかりそうですね」とコメントしておいたり、なんだかたいへんそうなプルリクエストを見つけたときに「ちょっと相談しませんか」
エンジニア立ち居振舞い: 属人性を減らす - 詩と創作・思索のひろば
お題「エンジニア立ち居振舞い」 おもしろそうなお題なので乗ってみる。自分は今は技術組織のとりまとめをしているけど、会社の古めのプロダクトの面倒を見る仕事もしてきた。時を経てサービスに携わる人が変遷し、コードの歴史も重層的で一筋縄ではいかないことが多い。仕事で触れるプロジェクトが多いので、ひとつのプロジェクトに関する知識を深めづらい面もある。 属人性を減らす さまざまなタスクを通じてプロダクトに触れるうちにだんだんと自分の中に知識がついてきて、用件を聞いたときに「あ、それならあのプロジェクトのあのへんのコードだな」、というアタリがつけられるようになってくる。この地図や勘といったものは正直なところ外部化しづらく、ある程度を超えると個々人の中で養っていくしかないものだけれど、日々の仕事において、属人性を減らすように努力することはできる。 普段からやっていることは以下のようなところ。 作業ログを残
エンジニアの立ち振舞: 出来ない時でも代価案を出す - @Konboi memo
お題「エンジニア立ち居振舞い」 はじめに エンジニアの立ち居振舞いについての知見を集めていきたい というお題があって面白そうなので乗っかってみる 今回は出来ない時でも代価案を出すについて 代価案を出す エンジニアをやっているとディレクターから 〇〇みたいなのできない？ ××使って△△みたいなことやりたいんだけど と依頼を受けることがある｡ 調べて実現可能なことなら「できますね」と答えられるのだが､公開されているAPIの制限だったりで技術的に困難なことがあることが少なからずある そういう時は 「できないですね」で終わるのでは無く 「〇〇みたいなことはできないですけど､ ♢♢ぐらいならできますよ」 「××を使っては難しいですけど､□□を使ってなら△△は実現できると思います」 と必ず代価案を提示するようにしている｡ 理由としては 本来実現したい事は質問の内容が全てではない事が多い ディレクターが
エンジニアの立ち居振る舞い: ボトルネックを作らないように - skozawa's blog
お題「エンジニア立ち居振舞い」 僕が意識しているエンジニアの立ち居振る舞いは、チーム開発におけるボトルネックをなるべく発生させないようにすること。 エンジニア、デザイナー、企画、ディレクターなどがいるチームで開発していると、エンジニアリングやサービス仕様の側面で困りごとが発生することがある。 例えば、 チームのエンジニアが仕様や設計について困っている。 チームのエンジニアがレビュー待ちでタスクが進めづらくなっている。 デザイナーの開発環境でエラーがでたり、gitの操作で困っている。 企画、ディレクターなどがエンジニアリングに関して相談がある。 比較的チームに長く在籍していて、サービス仕様などに詳しいということもあるけど、こういったエンジニアリングにおける困りごとをなるべくすばやく解決できるようにして、待ち時間を短く、チームの開発効率を上げようとしている。あとは、一人でできるタスクよりも複数
エンジニア立ち居振舞い: 分かりやすく依頼する・説明する - $shibayu36->blog;
お題「エンジニア立ち居振舞い」というお題を id:hitode909 くんが作っていたので書いてみる。 コードを書く以外にいろいろとしているのだけど、その中の一つとして「分かりやすく依頼する・説明する」ということに時間を割いているので紹介。 エンジニアとしてものづくりをしていると、いろんな人とのコミュニケーションが発生する。例えば、デザイナにデザインを依頼する、ディレクターに状況を報告する、他エンジニアにレビューを依頼する、他エンジニアにコードの意図を説明するなど。 この時、相手が空気を読まなくとも文章の意図やお願いしたいことをすぐに理解できるように、できる限り分かりやすく文章を書くように心がけている。自分のことだけを考えていると、自分の時間がもったいなくて、さっと雑に書いてしまいがちだ。しかし、結局成果というのはチームで作るもので、チーム全体で一番時間を使わないようにしたい。そう考えると
お題「エンジニア立ち居振舞い」 - はてなブログ
マイお題はユーザーが作ったオリジナルのお題です。このお題をネタに他のユーザーも記事を書くことができます。ブログのネタ探しや、ブログを書くきっかけにご利用ください。マイお題の使い方はこちら
なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog;
最近以下のようにコーチングや人間の学習モデルの勉強をしている。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; 「リファクタリング・ウェットウェア」を再読した - $shibayu36->blog; 「コーチングのすべて」という本を今読んでいる そこで、自分の考えをまとめるためにも、なぜ最近コーチングや人間の学習モデルの勉強をしているか書いてみようと思う。 最近、株式会社はてなという会社で、シニアエンジニアというポジションに付いた。シニアエンジニアは、数人のエンジニアのメンターとして、目標設定・1on1面談・評価などを行うポジションだ。また、社内のエンジニアの一つのロールモデルとなれるような態度を求められる。 このポジションになった時に、まず初めに考えたことは、このポジションとして求められていることは何なのかということだった。考えた結果、数人のエンジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア立ち居振舞い : 常に問題意識を持つ - Takuji->find;