2022.05.21 Scrum Fest Niigata 2022 Main Hall 10:00-10:45 Proposal https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16425
[Slackbot大全]25種類の事例・ツールを一挙紹介! botで業務を効率化しよう【2018夏】 あの企業は一体どんなSlackbotを活用しているの?そんな疑問に答えるべく、20社のSlackbot活用事例を聞いてみました。バラエティに富んだ回答に、開発のヒントがあるかも!? すでに多くの企業やチームに導入されているビジネスチャットツール、Slack。2017年9月には日本法人Slack Japanが立ち上がり、同年11月には日本語対応を開始するなど国内での本格展開をスタートしています。 Slackの魅力の1つに、拡張性が挙げられます。さまざまなbotを自作することで、利用者のニーズに応じた機能を追加でき、日々の業務をサポートしてくれます。2017年春に本誌が実施した調査でも、多くの企業が個性豊かなbotを作っていたことが分かります。本稿ではSlackを活用している企業や団体に再びア
5分だけダッシュというタスク管理テクニックを知るだけで仕事が鬼効率化できる 2015年12月11日投稿 2020年3月8日更新 カテゴリ:タスク・スケジュール管理 著者: jMatsuzaki 私の愛しいアップルパイへ 一匹の蝶のはばたきが巡り巡って地球の裏側で竜巻を引き起こすかのように、ほんの些細なことだと思っていたことが偉大な成果を上げることってありませんでしょうか。 かような問いかけについて私がいつも思い出すのは「5分だけダッシュ」の効用です。その名の通りたった5分間だけの時間管理テクニックですが、これは仕事を効率的かつ効果的に進めるうえで特に大きな効果を上げるものだと感じています。 これを知らないのは大きな損失ですから、あなたにもお伝えしておきます。 5分だけダッシュとは? 5分だけダッシュを簡単に説明するとこういうことです。 「タスクを先送りするときは、そのタスクを5分だけ実行し
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
前回までのあらすじ ボトムアップ型業務改善の代表格であるトヨタ式カイゼンが多くのIT企業に適用できないことを悟って絶望するmegamouth。錆びた斧を交換できない木こりはやはり愚昧なのだろうか?それとも我々はトタン屋根の上の猫のように日が傾くことをただ念じるべきなのだろうか?(どうでもいい) 一人で始める業務改善。その狂気 まず、本エントリは末端IT土方が一人で業務改善を行おうとすると、どのような事が起こるのか、というおかしな話をしようとしている。大げさでなく、業務改善をたった一人で行うというのは、山に篭ったランボーが、襲い来る警官たちを全員サバイバルナイフとブービートラップで惨殺するような話である。この孤独な戦いには何の支援も期待できないし、あなたのサービス残業時間は確実に増加するし、精神的な負荷も大きい。にも関わらず、成功してもあなたが正当に評価されるかはわからない。経営者のガレージ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この2つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか?いくつかの事例を通じてだんだん見えてきたことは1つのことをこなすための「物量」が違うということです。
Joel Spolsky / Fujimoto訳 2009年3月1日 月曜 優れたプログラムマネージャを持つことは本当に良いソフトウェアを作るための秘訣の一つだ。あなたのところには多分いないだろう。こういう人はほとんどのチームにはいないからだ。 チャールズ・シモニーはWYSIWYGなワープロを共同開発した頭のきれるプログラマで、マーサ・スチュワートとデートし、さらにマイクロソフトの株式で10億ドル儲けて宇宙へ行った男であり、また巨大なソフトウェアチームの人月の神話問題を、最上位の関数を書く超一流の上級プログラマを一人置いて、低いレベルの関数を必要に応じて下級の単純労働プログラマのチームに書かせることで解決しようとした最初の人でもあった。彼らはこの最上位の関数を書くプログラマのポジションをプログラムマネージャと呼んだ。シモニーは確かに頭が良かったけど、このアイデアはそれほどでもなかった。誰も
(これは、『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』に寄稿した原稿の草稿を元に、XP本完全新訳版に合わせて加筆修正したものです。なんで完成稿ではなく草稿を元にしたかというと、草稿の方が長かったため短くまとめたものが完成稿になったからです。完成稿の方は『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』をどうぞ。) エクストリームプログラミング 作者:ベック,ケント,アンドレス,シンシア発売日: 2015/06/26メディア: 単行本 コンピュータ書を読むのが好きだ。だから「誰かに贈りたい本」と言われると、たくさんの本が思い浮かぶ。 たとえば君の問題が「プログラミングのスキル向上に思い悩んでいる」という話であれば、『Code Complete』辺りを勧めるだろう。プログラミング技術の本を10冊あげろと言われれば20冊くらいあげるかもしれない。 け
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
こんにちは。安達です。今年も引き続き、張り切って行きたいと思います。 さて、突然ですがみなさんは「プロジェクトマネージャー」を目指してますか? もちろん、ひと口にプロジェクトマネージャーと言ってもさまざまな方がいます。 大規模な業務システム構築のプロジェクトもあれば、ECサイトやWebサービス構築プロジェクトもあります。LSIのチップ制御ソフトウェア開発もあれば、スマートフォンのゲームアプリ開発もあります。 ただ、共通して必要とされるスキルが、「プロジェクトマネジメント」だということは、みなさんも意見が一致するのではないでしょうか。 しかしそうはいっても、プロジェクトマネージャーになってから独学でプロジェクトマネジメントをゼロから学ぶのはとても非効率です。もちろん会社でOJTをするなり、体系的なプロジェクトマネジメントのマニュアルがあるならば、さしあたっての問題はないでしょう。 でも、ある
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
本エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます!リクエストまだまだお待ちしております! 後編 を公開しました 私たち、Y Combinatorがアドバイスする最も一般的なことの1つに、「スケールしないことをしよう」というのがあります。創業予備軍の多くが、スタートアップは上手くいくかいかないかのどちらかだと考えています。会社を立ち上げ、ものを提供する、そしてそれが良いものであれば、おのずと売れます。しかし、需要がなければ結果はその逆になります。 ^(1) とは言え、意外とスタートアップは上手くいくものです。なぜなら、創業者がそうさせるからです。自分たちの力だけで成長するスタートアップはほんの一握りかもしれませんが、大抵は後押しするような力が働きます。良い例が、車のエンジンをスタートさせる役目をするクランクです。エンジンがスタートしてしまえば、エンジンは回り続けま
あいさつ はてなブログでは初のエントリーです。 こんばんは、野球でPythonなガジェット*1の人です。 最近、私も年齢だけ無駄に「中堅」になったせいか、 仕事もプライベートも自分より若いエンジニアとコミュニケーションをとることが増えました。 みんな意識が高い人達がおおく、勉強会とか日曜プログラミングとか何とか、 前向きな話題が多くて、話をしていてすごく楽しくなります。 自分が楽しすぎて喋りすぎて「聖域*2」になってないか心配なぐらいです(汗) そんな話をしているうちに、自分のエピソードを思い出したのでちょっと書いてみたいと思います。 理解できる本を読んで、沢山読んで、キーマンをみつけること 初心者プログラマ向けの本の選び方 - Togetterまとめ いきなり引用で恐縮ですが(笑)、結城浩さんのつぶやきまとめ、これはすごくいいこと言ってると思いました。 自分が理解できる本を選んで、それを
コードのスニペット管理にSnippiを利用していたのですが、何故かTwitterアカウント連携ができなくなってしまい、こつこつ貯めていたコードが見られなくなってしまいました。 バックアップでNotefileに取ってあったため事なきは得たのですが、コードスニペット管理の方法としてはいかんせん使いにくい。 なんかいい方法あんめえかと思って探したところ、GitHubアカウントがあれば無料で使用できるスニペット管理ツールGistBoxが良さげだったので試してみたところ非常に快適でしたのでシェア。 参考:GistをメーラーのようなUIで管理する「GistBox」がいい感じ | REFLECTDESIGN メーラーのようなUI 使用はGistBoxでログインするか、Chromeアプリから。UIは一緒です。 私はChromeアプリを使用することにしました。 GistBox – Chrome ウェブストア
Macのデスクトップのアイコンを整理整頓するショートカットキー command + option + 1 - 名前でソート command + option + 2 - 種類でソート command + option + 3 - 最後に開いた日でソート command + option + 4 - 追加日でソート command + option + 5 - 変更日でソート command + option + 6 - サイズでソート command + option + 7 - タグでソート command + option + 0 - なし まぁ基本は名前順でソートできる「command + option + 1 」だけでも覚えておくと便利じゃないですかね。 ちなみに、デスクトップだけじゃなく、他のFinderウインドウでもこのショートカットキーを使ってアイコンを整理整頓することが可能
Ruby on Rails(オープンソースのフレームワーク)の作者であり、37Signals(米のウェブアプリ開発会社)のパートナーでもあるDavid Heinemeier Hansson (デビッド ヘイメール ハンソン、通称DHH) が2008年にStartup Schoolで語ったスピーチを翻訳&書き起こし。 Ycombinator(米のベンチャーキャピタル)が主催するこのスタートアップスクールで、「ベンチャー・キャピタルからお金をもらって次のFacebookを狙うのをやめよう!」とアンチ・スタートアップ、アンチ・ベンチャーキャピタルを主張し、人が本当に幸せになれる生き方について説いた、非常に興味深いプレゼンです。 ※この記事は「TURN YOUR IDEAS INTO REALITY.」からの寄稿です。見出し等一部編集してあります。 なお、この翻訳を書くにあたって筆者がDHH氏にツ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く