運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第11回 日誌をつける | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
情報革命時代における多様性の共存とエンジニアのキャリア、評価について
2013/04/23に株式会社ぐるなび様で開催した「We energize us - 明日の現場を高揚させるプラクティス - ( http://devlove.doorkeeper.jp/events/3511 )」で発表した内容です。 「We energize us」では現場に活力を与えるプラクティスのパタン化「Energize Pattern」の創造を目指しています。興味のある方は是非Facebookグループ「We energize us - 全速前進アクション共有 ( https://www.facebook.com/groups/571206772891343/ )」にご参加下さい。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/20130423-number-devlove-zhi-c
優秀なエンジニアと優秀なチーム、日本企業が欲しいのはどっち？
連載目次 本連載のテーマは「チームリーダーシップスキルの向上」です。では、そもそも、なぜチームで仕事をしなければならないのでしょうか？ 今回は経営者の視点に立って、企業にとってのチームの有用性を考えます。 メンバーは個人の成果を優先しがち ITエンジニアの仕事は、設計やプログラミング作業を始める時点でモジュール分割がきちんとなされ、自分の分担が明確になっていることが多いものです。スケジュールがはっきりして仕様もしっかりしているので（例外もありますが……）、きちんと計画的にこなしていけば、仕事は一人でやれるという認識が強くなりがちです。そうなると、「仕事の成果は自分の成果」で、自分の成果を上げるためには人に邪魔されないようにバリアーを張らねば、といった極端な考えに陥る人も出てきます。 しかし、メンバーが個性を発揮し、自主的に生き生きと仕事をするためには、チームを活性化させることが必要です。そ
デザインスプリントとブルーボトルのプロトタイピング（翻訳）
本記事は、最近日本にも上陸したBlue Bottle Coffeeが行ったデザインスプリントについての翻訳記事である。（オリジナル）。デザインスプリントとは、Googleの投資部門Google Venturesが投資先に行うデザインワークショップ。Googleはオンラインでの売り上げが伸び悩むBLUE BOTTLE COFFEEと彼らのエージェンシーに対し、一週間のデザイン／プロトタイピングワークショップを行い、大きな成果を出した。以下、そのプロセスとなる。 BLUE BOTTLE COFFEE 私たちはブルーボトルコーヒーの新しいサイトデザインを手伝い、売り上げと滞在時間を伸ばしました。 ブルーボトルは美しいカフェと精緻なコーヒーにより、熱狂的なファンを生み出しました。しかし彼らのサイトは、そのブランドを表現しきれず、ウェブによる売り上げは全体利益のたった10%でした。 チャレンジ ブル
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
iOSアプリのプロビジョニング周りを図にしてみる - Qiita
きっかけ iOSアプリ公開の壁となっているプロビジョニング周りですが、ハマりまくったので覚えている内に図にしました。 難しくしてる理由 難しくしているのは、この辺が理由ではないかと思います。 iOS Developerサイトでの画面・操作手順がしょっちゅう変わる Xcodeも、バージョンによって画面・操作手順が変わる ということで、書籍やWebでのノウハウがすぐに古くなってしまいます。ググるといろんな情報が出てきてしまい、かえって混乱します。 また、開発時のiOSデバイスはXcode側である程度自動的にやってくれるのですが、それがかえって分からなくしているような気がします。 概念図 ということで、結局、概念を理解してしまうのがいいのではないかと思い、図にしてみました。 （より厳密に実行端末が判断されるAd Hoc配布をベースに記述） ざっくり手順（※個別の操作は省略） 鍵ペア（秘密鍵／公開
エンジニアと非エンジニアの境界 - ワザノバ | wazanova
http://techcrunch.com/2015/01/01/everyone-in-management-is-a-programmer/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 この先、ソフトウェアの力でビジネスの競争力に格段の差がついてくる産業がどんどん増えてくることに備えて、プログラミング教育の必須化の議論も盛んですが、その必須化の是非はさておき、将来的には社会人になるうえで、ある程度コードを理解できる素養があることがもっと当然のことになってくるのではないかと期待してます。 そうなると、今の世の中の人が漠然と持っている、「エンジニア」と「非エンジニア」という言葉から連想してしまう偏見、両極端なイメージは、いずれの側に属する人々にとっても将来はもっと不利益になるかと。相互理解が必要です
Xcodeコメントの基本 - Toyship.org
これはiOS Advent Calendar 2014の12日目の記事です。 年の瀬もだんだん押しせまってきました。 年末年始のお休みの後に、「あれ、このメソッドどんな目的で作ったんだっけ？こっちのメソッドとの関係はどうだったんだっけ……」など無駄に悩まないために、このあたりでソースコードのコメントを見直してみましょう。 Xcodeでのコメント そもそもソースコードにコメントを書いた方がいいかどうかは長い議論がありまして……。 コメントによりコードの理解は深まるので、あったほうがいいという意見もありますが、コメントを書いたあとにコードを変更してしまうと、コメントとコードの内容が違ってしまい、かえってバグを生んでしまうためコメントを強制するのは害悪だ、という考え方もあります。 また、適切な命名規則を守ればソースコードを読むだけで理解できるという考え方もあります。 実際には、プロジェクトのライ
伸びるのは、「必死」にやる人ではなく「夢中」でやる人
ケニア・ナッツ・カンパニー創業者、オーガニック・ソリューションズ代表取締役社長。1939年生まれ。宮城県志津川町（現・南三陸町）で幼少期をすごす。1963年、東京外国語大学インド・パキスタン語学科を卒業後、アフリカ独立運動の父、クワメ・エンクルマに憧れて日本人初の留学生としてガーナ大学で学び、修了後はケニア・東レ・ミルズに現地職員として入社。31歳で退職し妻子を連れて日本に一時帰国。「やっぱり、アフリカで何かやりたい」と決意し、32歳で単身ケニアに戻り、鉛筆工場、製材工場、ビニールシート工場など、小規模なビジネスを次々と立ち上げ、うち一つを最終的にケニア・ナッツ・カンパニーとして世界5大マカダミアナッツ・カンパニーに成長させる。2008年に同社をタダ同然でケニア人パートナーに譲渡したのちは、微生物を活用した公衆衛生・肥料事業をケニア、ルワンダで展開。 アフリカで25万人の生活を変えた日本人
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
ゲーム開発を知らずにゲームが作れるか 島国大和のド畜生
・2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
ヤフーとリクルートはなにが違う？ 各社組織体制の違いに見る、イノベーションへの構え
ヤフー・川邊健太郎氏、コロプラ・千葉功太郎氏、グリー・田中良和氏の3者が集まり、「イノベーション」をテーマにディスカッション。組織体制、現場への権限移譲など、真の破壊的イノベーションを起こすための会社のあり方について意見を交わした。（IVS 2014 Springより） イノベーションとは、痛みを伴う破壊的なもの 岡島悦子氏（以下、岡島）：毎回私は経営パネルのモデレーターをやらしていただいているのですが、今回の全体会パネルは、小林さんから「変革力」というテーマ以外、何も言われてませんで。今日はIVSを代表する経営者三名の方に、変革力というテーマ、特に英語のタイトルにもなっている「Big Companies Do Innovation」というテーマで伺っていこうと思っています。 先日あるカンファレンスで、パネリストの小泉進次郎さんから「Innovationって日本語では何て意味でしょうね」と
その著作物の利用、できます －入場無料のイベント・上映、写り込み、企画・研究－
1週間のご無沙汰でした。遂にこの連載も10回目、折り返し点まで来ました。おめでとう自分！ありがとう自分！ さて、著作権者の許可が要らない例外規定として、「個人的な複製」「引用」「教育目的の利用」を見て来ましたが、今回はもっと積極的に既存の作品を活用できる場合をご紹介しましょう。 非営利目的の上演・演奏など（38条） 公表作品の非営利での上演・演奏・上映・口述は、一定の条件を充たせば許可・支払なくできます。意外と知られていませんが、著作権法では最重要の例外規定のひとつでしょう。文化が普及する上で、この例外規定の役割は決して小さくありません。 では、充たすべき条件とは何か。3つです。 「（1）非営利目的であること」「（2）観客などから料金を受け取らないこと」「（3）実演家・口述者にギャラを払わないこと」、です。これを全部充たせば、たとえば学園祭のバンドで好きなアーティストの曲を演奏できます。ブ
igaiga diary - スパイスライフで働くエンジニアが嬉しく思っている9つのこと
_ スパイスライフで働くエンジニアが嬉しく思っている9つのこと スパイスライフに入社してから半年ほどが経ち、私が入った当時2人(邦明率100%の頃)だったエンジニアも現在社員だけで7人、フリーランスの方をあわせて9人にまで増えました。 どうやって集まったのかを考えてみると、Rails寺子屋や邦明.rbなどのなんらかのコミュニティ活動で知り合った人がほとんどです。エンジニアの採用が難しいこの時代にいい人達に集まってもらえて、コミュニティへの感謝の想いは強まるばかりです。かつては私がコミュニティに育ててもらっていたのが、今はひっぱる側として、人の成長を通じてコミュニティに貢献できていると良いなと思っています（もちろん、私も今でも成長させてもらっています）。 さて、スパイスライフのエンジニアはどのような生態で生息しているのでしょうか。部長の職権を振りかざして「エンジニアの働き易い環境つくり」を進
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
なぜデザイナーはボタンをあと3ピクセル左に寄せるべきなのか？
by Ugo Cristofori デザイナーにとってデザインのディテールは非常に気になるところですが、デザイナー以外には違いがあまり伝わらず「ボタンを3ピクセル動かすだけで製品が改良されるの？」と言われたりします。しかし、プロダクトデザイナーとしてGoogle Venturesで働いているBraden Kowitzさんは「それでもデザイナーは細部にこだわるべき」として、細部までこだわるべき理由と、他の人たちにそれをどう伝えるべきかのテクニックについて語っています。 Why you should move that button 3px to the left | Google Ventures http://www.gv.com/lib/design-details ◆デザインは外見のためだけに行うのではない by Bytemarks ・ディテールを適切にすると信頼感が増す 顧客がオンラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「MBAでは、八ッ橋は売れません」320年つづく老舗和菓子店が教えてくれた"京都の商い"
ソニー、マクドナルド…不振企業の「仮説」を疑え - 日本経済新聞
「Windows Management Framework 5.0」プレビュー版が登場、「PowerShell 5.0」も