実際に作った機能が使われない、想定された使い方をされなかったというのを目の当たりにした時に「全てを事前に計画して一度に届けるやり方」に意味があるんだろうか?って疑問を覚えたんだよなぁ
posted at 18:04:09
ツイートの記録を停止しています
このアカウントはTwitter APIの仕様変更の影響でツイートの記録を停止しています。
記録を再開するには、Twilogにログインしてください。
Stats | Twitter歴 5,817日(2008/04/26より) |
ツイート数 62,845(10.8件/日) |
表示するツイート :
実際に作った機能が使われない、想定された使い方をされなかったというのを目の当たりにした時に「全てを事前に計画して一度に届けるやり方」に意味があるんだろうか?って疑問を覚えたんだよなぁ
posted at 18:04:09
ヤクの毛を刈る作業になっていた。やっと戻って来れた。
posted at 18:02:01
個人個人の良さやこれから身につけて欲しいところも観察したり対話したりしながら、一方でチームとしてどうあるべきか、組織としてどんな課題があるかの視座の上げ下げを毎日していると色々と気づくことはあるわな。
posted at 17:44:03
バリューストリームマップでもいいけど、そこまで大規模でなくても自分がコードをPRして、フィードバックが返ってくるまでの時間を計測してみると良いと思う。それが(もしかしたら)ムダな待ち時間の1つかもしれないから。
posted at 17:20:54
朝から「アジャイルなふるまい」とはってのを色々考えている
posted at 09:09:25
上司が部下に話しかけた時に部下がどう思うか?って大事。威圧を感じたり、叱責される、評価されると感じると有益な情報は隠される。一方、助けるために来た、傾聴の姿勢があると課題や困っていることなど、よくないことを未然に防ぐことができる情報などを得られる。
posted at 08:59:53
ちゃんと説明すれば、それなりに判断することができてリソースも投下することになるから、技術負債を片付ける活動だったり、新たな技術的な強みを手に入れる活動ができやすくなると思う。リソースない中でゲリラ的にやるのは持続可能性は低いので。
posted at 07:18:52
エンジニアは技術の詳細が分からない経営陣に対し、ビジネス面のメリット/デメリットを説明する責任があると思う。というのもそれがないとリソースをどこに集中投下すべきか、他のビジネス課題との優先順の比較ができないから。
posted at 07:17:12
もう1つは簡単に言うと「この人(トップの人)も間違える、正解を知っているわけじゃないんだ」と思えるかと、トップの人がうまくいかないことを認めるかどうかかな。
posted at 07:16:39
1つは採用でその組織にこれまでなかった色の人、またこれまでのトップより優れた人に来てもらえるかどうか。
posted at 07:16:11
組織の偉い人やトップレベルの上限が組織全体の限界になってしまうと、中期的に見たら組織の成長の鈍化を招くよなぁ。これをどうやって行くかなんだけど…。
posted at 07:15:04
朝のレビュー業、終わり。色々考えさせられる本だわ、これ。
posted at 05:29:26
おはようございます。今日で7
月終わりか。
posted at 03:31:31
IOS関係の諸々のサイトをまとめたサイトかな? iOS Stash – Visual directory of app development-related tools http://iosstash.io/ @iosstashさんから
posted at 21:23:25
途中までは読んだ ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | プログラミング | POSTD http://postd.cc/getting-started-with-tdd-in-react/… @POSTDccさんから
posted at 21:22:17
レガシーコードをなんとかしていく時に道筋と道標は大事だと思う。テストゼロからイチに進むための戦略と戦術 by @nabedge #java #jenkins http://www.slideshare.net/nabedge/ss-62418262… @SlideShareさんから
posted at 20:35:28
現場でよく悩むような話が出ていた Spring Boot で Boot した後に作る Web アプリケーション基盤/spring-boot-application-infrastructure https://speakerdeck.com/sinsengumi/spring-boot-application-infrastructure…
posted at 20:27:26
今さらながらパラパラと見てみた JJUG CCC 2016 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く (id:chiheisen / @YujiSoftware) http://d.hatena.ne.jp/chiheisen/20160521/1463833254…
posted at 19:53:01
もう吉羽さんのこの資料で全て語られている気がする 【資料公開】強いチームの作り方(デブサミ2016版) http://www.ryuzee.com/contents/blog/7078… @ryuzeeさんから
posted at 19:50:08
この前もDeployerの記事をみたなぁ 小規模PHPアプリケーションをDeployerでサッとデプロイする話 - Connehito開発者ブログ http://tech.connehito.com/entry/2016/07/28/170858…
posted at 14:02:37
この指標は面白い 「面倒くさくない」という指標 - 心のうち - http://go.shr.lc/2aDpTF2
posted at 14:00:43
経験上、夜遅くに議論したことって後でまた形を変えて進化して湧き出てくるので楽しみ。
posted at 10:59:01
ホントは待たなくていいのに待ってしまっていることを見えるようにできれば、あとはやるだけだと思う
posted at 10:57:51
zeplin便利そう Prottとsketchとzeplinのススメ http://www.slideshare.net/asamieee7/prottsketchzeplin… @SlideShareさんから
posted at 09:37:17
Stream、わりと自由に作れそう。Watchしたいものだけを絞れそう。 #Jasper
posted at 09:32:24
「つらみの共有」って面白い。これちゃんと話せるチームってどれほどいるかな 少数精鋭で効率的によりよいサービスをつくるには / designer x engineer https://speakerdeck.com/kiyoe/designer-x-engineer…
posted at 09:23:24
自分にとって興味があるか分からなければ議論に入らないし、「入ると迷惑かな?」とか思うとそれも入らない。
posted at 08:31:15
オープンな議論をするための仕組みに興味がある Slackにおける組織的なUXデザインプロセス http://uxmilk.jp/46205 @uxmilkmanさんから
posted at 08:30:26
若手は読むと良いと思う 新卒エンジニア向けに品質の話をした, Asakusa.rb 第368回 - HsbtDiary(2016-07-26) - http://go.shr.lc/2aERv9g
posted at 08:27:26
というか目標はあるけど、それでどうなるの?という結果がないと計測できないし、戦略も立てられないし。
posted at 08:25:03
OKR の考え方自体は別に珍しいことでもないんじゃないかな。普通に目標設定と管理をすればこうなるだろうし。 Googleも採用!目標管理「OKR」の運用を驚くほど簡単にする「COVE」の使い方 https://seleck.cc/note/seleck_howto/article/65…
posted at 08:23:56
【「自分なり」に頑張って「KPIをPDCA」している組織と個人には罪悪感がない】罪悪感がないってのはよく分かる。思い返すと何人かゼロワンの人を思い出す。 強い組織の「隠れキーマン」について - LiB-log http://yosuke-lib.hatenablog.com/entry/2016/07/25/162529…
posted at 08:20:20
Jasper、パフォーマンスがどうかなぁ。最初だからかけっこう重いかも。
posted at 08:14:29
便利そうなので、ちょっと使ってみよう。Jasper - The Issue Reader for GitHub - http://go.shr.lc/2aCUjqG
posted at 08:13:52
そう"度合い"だよなあ Making Software Development Agile With Ruby by @kakutani #agile #kanrk02 http://www.slideshare.net/kakutani/making-software-development-agile-with-ruby/61… @SlideShareさんから
posted at 07:46:18
基調講演のスライド良かった PHPカンファレンス関西2016 スライドリンク集 #phpkansai - お?意外といけるやん! http://ikkitang1211.hatenablog.jp/entry/2016/07/16/145657…
posted at 07:43:26
チームの生産力が上がっているのかインフレが起きているのかは観察する必要があると思う Mike Cohn氏が見積もりのインフレを防ぐ方法を説明 https://www.infoq.com/jp/news/2016/07/estimate-inflation#.V5vaJSeI9sQ.twitter…
posted at 07:35:46
面白いタイトルやなと思ったら、川島さんだった システムエンジニアのエレベータの乗り方 by @kawasima on @Qiita http://qiita.com/kawasima/items/4ac35fc43a2eac5f5d0b…
posted at 07:31:44
手にとって読んでみようと思って忘れていた本 33歳でアーリーリタイヤしたエンジニアが「技術力以外」の大切さを説く理由~『SOFT SKILLS』著者に聞く - エンジニアtype | 転職@type http://type.jp/et/feature/1498 @Etype_magさんから
posted at 07:29:38
こんなのあった。黙々と日報を書いたり見れたりするサービスかな 日報 - http://go.shr.lc/2aDyvrC
posted at 22:42:20
鈴木雄介/Yusuke SUZUKI@yusuke_arclamp
9/16のデブサミ関西にて基調講演をさせていただきます。「クラウドの発展とデベロッパーの役割について」 http://event.shoeisha.jp/devsumi/20160916/… #devsumi
Retweeted by yoh nakamura
retweeted at 22:36:32
こういう戦略的なのがまとまっているのはありがたい 【シート付】どんなにニッチな人材でも獲得するピンポイント採用の極意 | HR NOTE [HRノート] https://hcm-jinjer.com/media/contents/contents-1894/…
posted at 22:20:56
短期的、繰り返し的な進捗管理という意味のマネージャー業ならそれでも良いんだけど、ビジネスや業務を成功させることにも重きを置いているマネージャー業はこのパターンだとなかなか難しいと思う(だからそこはプロパーがカバーするのが良いと思う)
posted at 21:36:49
こういうアウトソースもありか “エンジニア35才定年説に挑戦する” 開発チームのマネジメント https://speakerdeck.com/jsoizo/enzinia35cai-ding-nian-shuo-nitiao-zhan-suru-kai-fa-timufalsemanezimento…
posted at 21:35:44
こういう事例から何かヒントを見つけたい UberやAirbnbは最初の1,000ユーザーをどうやって獲得したのか? | http://Fashionsnap.com http://www.fashionsnap.com/the-posts/2016-07-26/first1000/… @fashionsnapさんから
posted at 21:33:26
こういうめちゃくちゃ便利そうな制度を体験するとなかなか(制度という意味では)他を考えることができないのでは?
posted at 21:16:21
②エンジニアコンシェルジュって便利そう 「エンジニアFA権」「エンジニアコンシェルジュ」など計8つのオリジナル人事制度 社内エンジニアの活力を引き出す新制度パッケージ「ENERGY(エナジー)」を導入 株式会社サイバーエージェント http://go.shr.lc/2aBqRBs
posted at 21:15:28
少しずつやることをやって、課題をやっつけていけば改善される。難しいのはやり続けることと、効果を見えるようにすることだと思う。
posted at 18:37:10
Hootsuite。バージョンアップしたら余計なワンクッションをはさまないとツイートできないようになった。なにか設定を見落としているのかな
posted at 18:19:00
夏サミでの改善話聞きたかったな。今度呑みながら聞かせてもらおう
posted at 18:17:14
ほんと一進一退なんだけど少しずつ良くなっていると思う。もう少しだけ支援すれば良さそうかな
posted at 18:15:43
サービス・システムの課題の発見と改善を支援する「カイゼンギルド」の提供を開始 | GuildWorks -ギルドワークス- https://guildworks.jp/news/item.html?id=42… #guildworks
posted at 15:48:06
ハブ型をうまくやるには相手の関心事や腕前を見極めるスキル、どう組み合わせると良さそうかとかを想像するスキルがいりそう。 一歩踏み出し、働き方を選ぶためには。ハブ型人材活用のススメ。 | WORK SWITCH http://workswitch-ibs.inte.co.jp/hub-workstyle/
posted at 08:23:36
えらくシンプルな印象 PHPプロジェクトを簡単にデプロイするならDeployerがお薦め — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something - http://go.shr.lc/2azZrMg
posted at 08:19:02
mini spec。ちょっと考えたけど、スクラムから計画MTGでPOがユーザーストーリーやKPIを伝えたりして、開発チームと残りの部分を作っていくようなイメージが良さそうかな。
posted at 08:10:37
「mini spec」か。ちょっと取り入れてみようかな。 ペロリ流 開発要件のまとめ方 - peroli Developer's Blog http://tech.pero.li/entry/2016/07/22/141228…
posted at 08:09:11
たまに見なおして、いい話だと再び思う。大変やと思うけどね。 絶望と最後の希望 by @sato_ryu #comunity #rakutentech http://www.slideshare.net/satoryu/20141024-rtcpreevent2014-tatssato-40689454… @SlideShareさんから
posted at 07:45:13
やっと半分レビューした。内容も面白いからついつい色々考えてしまう。
posted at 07:41:14
惜しむらくは一番やりたかったタスクまでたどり着かなかったこと。続きは夜かな。
posted at 07:06:31
朝から6ポモドーロほど消化できて面倒ないくつかのタスクを片付けた。
posted at 07:05:21
5時前だけど明るくなってきた
posted at 04:49:31
継続的に何かを積み上げていくってのは日々のドタバタの中で置き去りにされがちだけど、後々効いてくるもんだよなぁ
posted at 04:47:53
そっか、今週で7月も終わりか。
posted at 04:05:51
@witch_doktor ご無理なさらず〜
posted at 03:59:25
だいたい1日の計画づくりって10〜20分あればできる。
posted at 03:41:49
おはようございます。寝苦しさで目が覚めた
posted at 03:12:44