先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
良い進捗報告のやり方 - 発声練習
まとめ 良い進捗報告とは、自分が行っている作業やプロジェクトを順調に進めるのに役立つ手助けが得られやすい報告である 教員にとって良い進捗報告 学生が行っている作業やプロジェクトが自分の研究のプロジェクトの一部であったり、研究室で取り組んでいるプロジェクトの場合とそうでない場合では教員にとって作業の進捗の意味がある程度変わる。前者の場合は、自分のプロジェクトの一環なので、作業やプロジェクトの進捗がそのまま自分のプロジェクトの進捗に反映されるので、より真剣に、場合によっては過剰に干渉して進捗状況を制御しようとする可能性がある。後者の場合は、学生が順調に卒業／修了できるかどうかが興味の焦点になるので、学生が援助を求めてきたならば援助しようという程度の干渉の可能性がある。ここいらへんは指導教員の性格による。 どちらの場合にしても、教員が知りたいのは「どこまで進んでいるか」と「援助は求められていない
楠 正憲（内閣官房 政府CIO 補佐官） 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた．筆者は 2020年4月から接触確認アプリの導入について，有志での議論に参加し，有識者会議のメンバとして，また途中から政府CIO補佐官として， 接触確認アプリの導入を支援してきた．本稿では接触確認アプリCOCOAの開発と運用について，どのような課題があったかについて振り返る． 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年（2020年）3月頃のことである．ちょうどシンガポールのTrace Togetherが話題となって，日本でも接触確認アプリをリリースできないかといった話題で，いくつかのコミュニティが盛り上がり始めた． Androidのシェアが高いシンガポールに対して，日本ではiPhoneのシェアが非常に高く，iP
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書 始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！ 1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。 これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜じゅ ごん｜note
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
プレゼンテーションのスライド資料を作る上で押さえておきたい基本をまとめました． 多分これがslideshare内で一番役に立つと思います． スライドの作り方を学んだことがない方、参考にどうぞ！ 2016.01.22 書籍発売 好評につき重版決定！！ http://book.impress.co.jp/books/1114101129 リニューアル増量版 http://www.slideshare.net/yutamorishige50/ss-41321443 2014.11.9アップロード！ 【連絡先等】 Yuta Morishige Webサイト: https://mocks.jp/ ※旧タイトル 【プレゼン】研究室発表のプレゼン資料の作り方【初心者用】
このブログは、僕がこれまでWebサービスを30くらい作ってきて、失敗したり成功したり色々体験していることをまとめています。 「Gumad β」は株式会社メーヴェの安宅（ディレクター）と杉本（エンジニア）の2人で、Gumroadの存在を知ってから9日間で作ったWebサービスです。作っている間にあったできごとや僕らの動きを公開したら、これから個人やベンチャーの人たちがWebサービスを作る人の（良い意味でも悪い意味でも）参考になるかもということで、少々こっ恥ずかしいですがブログに書き残しておこうと思います。 ちなみに、今回のシステム関連の話は「Gumadβで使ったgemまとめ」こちらに詳しく書かれています。 いまは「Gumad β」はミニWebサービス的な位置づけですが、もしGumroadやその周辺のサービスが盛り上がってくれば、面白い展開ができると考えており、ベンチャーらしく短期間でゲリラ的に
今回は残念なお知らせがあります。 5月末をもって、LingrとRejawの両サービスをシャットダウンすることになりました。いずれのサービスも、すでに新規サインアップは受付停止済み、5月15日までユーザデータのダウンロード依頼を受け付け、5月16日からは新規発言ができなくなり、5月末の完全停止までの間にデータをダウンロードしていただく段取りになります。 今まで支えてくださったユーザの皆さんには、このような結末になってしまい本当に申し訳なく思っています。シャットダウンという最終決定を下すまでには多少の猶予をいただき、営業譲渡などでサービスを存続させる方法も模索していたのですが、受け入れ先を見つけることができませんでした。 2005年の夏にインフォテリアの100%子会社として操業を開始した米国法人のインフォテリアUSAですが、こちらもサービスの終了を見届けた後、6月中に解散・撤収することとなりま
「自分でやったほうが早い病」と聞いて、「ああ......」と思い当たる人は少なくないはず。基本的に「できる人」だけれど、完璧を求めすぎるせいか人にまかせることができない。だから結局は自分ひとりで抱え込み、ときには自滅してしまう。そんなタイプ。 『自分でやった方が早い病』（小倉広著、星海社新書）が取り上げているのがまさにそういう人ですが、本書の見るべき点は、この病を乗り越えることで得られるものの大きさをきちんと示している点です。たとえばわかりやすいのが、「自分でやったほうが早い病」への15の処方箋。これらをクリアすれば、かなりの問題点を改善できるのではないでしょうか？ 1．まず痛い目に遭う（114ページ） 「自分でやったほうが早い病」の原因は利己主義であるため、徹底的に利己を貪り尽くし、痛い目に遭ってとことん問いつめられれば利己主義から利他主義に変われると著者は言います。 2．体質を改善しな
はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい
最初に、損益分岐点の説明からはじめよう。企業は、製品やサービスを売って売上を得る。しかし、世の中にタダの物はないので、そこには必ず費用（原価）が発生する。その費用が製品の販売数量に単純に比例する場合、企業は売上に比例した利益を得ることになる。この関係を図(a)に示す。横軸は、売上である。工場の視点から言うと、売上向上すなわち稼働率向上を意味するから、横軸は稼働率と見てもよい。縦軸は金額で、実線が売上高を、点線が費用を示す。費用は純粋に、売上高に比例する。これを変動費ともいう。売上に伴って、変動するからである。たとえば製品を作るのに必要な原材料の購入費がそうだ。あるいは、製品を加工するための外注費などもそうだ。 ところが、企業にはこれとは別に、売上高にまったく関係なく、固定的に発生する費用がふつうある。これを固定費という。その典型例は、設備機械の減価償却費である。あるいは、従業員の給料なども
履歴書でやってはならない10の間違い
あなたが書く履歴書には1つの目的がある。雇い主になる可能性のある会社に、自分がその求人にもっとも適した人間であると伝えることだ。ところが、明確なメッセージであるべきものの妨げになる可能性のある間違いが、あまりにも多くある。この記事では、履歴書の中で犯しやすい10の間違いを紹介する。 1．重点を置くところが間違っている これは、求職者にはもっともわかりにくい概念の1つかもしれないが、履歴書は自分のために作るものではない。履歴書を作り、書式を整え、整理するのは、あなたが募集している仕事に適しているかどうかを、人事担当者が判断しやすくするためだ。応募する仕事に応じて、自分の履歴書を整えることは大切だ。誓ってもいいが、あなたがその仕事に合っているかどうかを確認するために、履歴書を詳しく調べる人事担当者などいない。履歴書を読めば、そのことがはっきり分かるようにしなくてはならない。 例えば、プロジェク
デスマーチが起きる理由 - ３つの指標
Your system administrator has blocked your computer or device. Please contact the system administrator.
ヒューマンエラー 理論と対策
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
社内情報共有についての考え方 - An Epicurean
タイトルのようなエントリを社内に向けて書いたので、手直しして社外に放流するものである。 社内で情報共有フローやガイドライン整備などを進めている。ルールは少ないに越したことはないので「ルール作り」にはしたくなくて、考え方やガイドラインみたいなところに留めて、文化や共通言語を醸成していきたいとも考えている。 これは、今後組織が大きくなる上で、「スピードを落とさないため」に必要だと考えている。新しく入ってきた人が立ち上がりを早くパフォーマンスを発揮してもらえるようにしたい。 オンボーディングの整備は大事で、それもやっていかないといけない。でも今のフェーズではどうしても未整備の部分も多い。そういう荒地を楽しんで走破できる自走力があって、自分で決めて整備もできて、組織と一緒に成長してくれる人を採用していきたい。なので「自走しやすい環境」を整えたい。そのために必要だと考えている点が以下の3点です。 デ
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
2013年3月23日 Web関連記事, 便利ツール Web業界では次々に新しいサービスが開発され、それをあーだこーだと言い合うのがWeb屋の楽しみってもんです。現在私が住んでいるバンクーバーでも同様、Webサービスの話に花が咲きます。その中でサービス自体は前々からありますが、最近よく話題にでるなーというものを中心に紹介していきます！日本で何かWebサービスを作ろうとしている方のアイデアの種になるかも？ ↑私が10年以上利用している会計ソフト！ 1. Fiverr Fiverrは5ドルで誰かにサービスや商品を提供できるサイトです。誰でも簡単にアカウントを作成でき、5ドルで売りたいもの・5ドルで買いたい物を投稿できます。5ドルのうち1ドルがFiverrの収益になります。支払いはPaypalかクレジットカード。英語のみですが、同じ英語圏でも通貨の価値に差のある国では5ドルでもいい収入になるようで
ホーム > マンションの大規模修繕で取り回しやってたら、何故かslackで業者さんの業務改善までやることになってたでござるの巻 ぶち大変でした。 しんざきが住んでいるマンションでは、住人持ち回りで管理組合の役員が回ってきます。 実は先日まで、しんざきは管理組合の理事長でした。 それ自体は順番なのでしょうがないんですが、運が悪いことにたまたま大規模修繕実施の年であり、しんざきは色々な調整やら手配やらをすることになりました。 マンションの大規模修繕というのは、十年くらいに一度、壁の塗り直しやら傷んだ建物の修繕やらをやる作業です。 数百万から数千万くらいの結構な費用がかかる話で、日ごろ住民が納めている管理費用の中から、大規模修繕費用というものを積み立てています。 大きなお金が動く話ですので、色々な人が色々な希望を持ちますし、業者との折衝もしなくてはいけないですし、家庭によって熱意は違いますし、納
スタートアップやプロダクトの成功に必要な「アイデア×プロダクト×実行×チーム×運」の 5 つの項目について解説した概要のスライドです。急成長するプロダクトの初期に役立てていただければと思います。 プロダクトマネージャーやスタートアップの CEO の方向けにどうぞ。 ※ Japan Product Manager Conference 2016 の登壇資料ですRead less
文化庁のガイドラインをもとにした『アーティスト・スタッフのための契約ガイドブック』がWebで無料公開され、「素晴らしい」「勉強になる」などと話題になっています。音楽や舞台、美術や映像など、芸術分野で活動するフリーランスが安心して仕事をするために必要な、契約締結の要点を分かりやすく解説したものです。 アーティスト・スタッフのための契約ガイドブック 文化庁の「文化芸術分野の適正な契約関係構築に向けたガイドライン」を元に、契約における重要なポイントをまとめたガイドブック。依頼内容や報酬などについて取り決めが不十分なまま、口約束だけでプロジェクトが進みがちな文化芸術分野の現状に鑑みて、「なぜ契約が必要なのか」から説明されています。 受注側・発注側ともに安心してプロジェクトを進められるよう、適切な契約で取引の条件を明確に 前半は契約書の読み方や、各条項の重視すべきポイントを解説。例えば業務内容の条項
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
横に伸びる棒グラフのようなラインを使うことで作業の進捗状況や生産管理が行いやすくなっている表のことを「ガントチャート」と呼びますが、Googleカレンダーに登録している予定をガントチャート化して、一目でタスク管理できるのが「GANTTplanner」です。 GANTTplanner: Turn your Google Calendar into a Gantt chart https://www.ganttplanner.com/ Googleカレンダーからガントチャートを作るには「GET STARTED」をクリック。 GANTTplannerはGoogleカレンダーの情報をインポートするのでGoogleアカウントでのログインを求められます。Googleカレンダーの情報からガントチャートを作りたいアカウントでログインして、「承認する」をクリック。 GANTTplannerのトップページが開
PowerPoint歴23年、デザイナー歴20年、経営者として10年以上に渡って自社のマーケティングやセールスに深く関わり、提案書を作ったコンペでの勝率91%を誇る私の知見を余すことなく注ぎ込んだ、『最強の提案書を作る方法～伝わるストーリー・コピー・デザインの法則』というスライドを公開しました。 便宜上「提案書」としていますが、企画書、営業資料、ホワイトペーパー、社内文書など、人を動かすために作られるすべてのビジネス文書に応用できるはずです。 提案書のストーリー、コピー、デザインに関する、実践的かつ具体的なノウハウを詰め込んでいます。デザインについては、プロのデザイナーではなく一般のビジネスパーソンを対象とし、仕事の中で本当に必要な知識だけをまとめています。 約170ページある本スライドは、私が企業向けにこれまで20回以上行ってきた有料講座の配布資料を元に、公開用に仕上げたものです。スライ
今回は，Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品，つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが，ご参考になれば。 図は，一番上は「4つのステップ/3つのタスク/12の要素（第62回 持続可能なWebサイト開発を支える12の要素）」。その下は，人的配置をロール(役割)ごとに記述しています。その下は，大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が，「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基本的には，その流れの順で進んでいきます。その下は，それぞれのステージのアウトプットのイメージで，更にその下にはよく使うファイルアイ
「時は金なり(Time is Money)」という言葉にもあるように、職場などでさまざまな仕事を任されるようになり、それなりの立ち位置を占めるようになると、分単位で時間が惜しくなるようになる。また逆に「あれもしたい、これもすべき、もっと時間が欲しい」と自ら仕事を積極的にこなしたい人もいるだろう。しかし人に与えられた時間は1日につき24時間しかなく、さらには睡眠時間まで仕事にあてるわけにもいかない(24時間戦ったら体が持たない)。【AskMen.com】ではそのような「もっと時間を有効に活用したい」という人のニーズに応えるべく、「限られた時間を有効に使う、時間活用・管理術」を提示している。 1.TO DOリストを作成する いわゆる行動チェックリストの作成。しかも一度作って放置ではなく、必要があれば逐次更新する。そのためにもデジタル式の媒体(携帯電話など)の方が運用はしやすい。さらにできるだけ
情報処理技術者試験なんて何の役にも立ちません
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。 なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。 オブジェクト指向におけるカプセル化を説明したものはどれか。 同じ性質をもつ複数のオブジェクトを抽象化して，整理すること 基底クラスの性質を派生クラスに受け継がせることクラス間に共通する性質を抽出し，基底
はじめに 本文書は、Rubyによりコーディングを行う際の規約について述べる。 実際のプロジェクトに適用する際には、このコーディング規約をカスタ マイズして用いることを推奨する。 ソースコードの整形 インデント プログラムを読みやすくするため、インデントを適宜行う。インデント 幅は2とする。また、インデントにはスペースのみを使用し、タブは使用 しない。(環境によりタブ幅が異なるため。) 例: if x > 0 if y > 0 puts "x > 0 && y > 0" end end 一行の桁数 一行の桁数は最大80桁までとする。 空行 複数のクラスの区切には空行を挿入する。 例: class Foo ... end class Bar ... end 誤った例: class Foo ... end class Bar ... end また、クラス内の各構成要素の区切にも空行を挿入する。
あるＳＥのつぶやき: プロジェクト管理メモ
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門：ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践：ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次：ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次：ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス － ＠IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine：コーナー：実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
華｜汚部屋、片付けたから見て @hana__heya 衝撃の「汚部屋ビフォーアフター」はブログで大公開→hana-heya.com/dirty-room-bef…｜「汚部屋を脱出したお話」が本になりました→著書『片づけをプロジェクト管理してみたら汚部屋が生まれ変わった』｜今はすっきり片付いた部屋で一人暮らし満喫中 華｜汚部屋、片付けたから見て @hana__heya 「明日から三連休だから、バチクソ部屋片づける！！！」って友達が言うのでプロの汚部屋出身である私から 「3日以内に、人を呼べるくらいスッキリ片付いた部屋にする」 ためにやることをメモで送ったら超よろこばれました。 pic.twitter.com/bRLQgmPDVm 2023-11-02 06:54:00
1. 大規模 JavaScript その設計と実装と現実 株式会社Aiming ソフトウェアエンジニア 竹馬光太郎 2012/10/24@AimingStudy#6 12年10月24日水曜日 2. @mizchi / Koutaro Chikuba 2012/3/1- Aiming/Software Engineer * github https://github.com/mizchi * blog http://d.hatena.ne.jp/mizchi 12年10月24日水曜日
エンジニアを始めてから便利だったツールまとめ
概要 エンジニアになってから出会った便利ツール・アプリを備忘録としてまとめました。 ※WEB用ツール多め GUIツール・アプリ デスクトップ上で動作させるやつ。 Authy https://authy.com/ 2FAアプリ。Multi-Deviceという複数端末で使える機能があり、PCでログインする際の2FAをPCのみで完結できるので便利。 Hyper https://hyper.is/ コンソールアプリ。テーマ機能やプラグイン追加で自分の好みに環境を整えやすくて見た目がよい。 設定を.hyper.jsファイルで管理するので、gitにて設定管理ができて便利。 VSCode https://code.visualstudio.com/ 言わずもがなの高機能コードエディター。特に理由がなければ基本的にはプログラミングするならこれを使えばいいんじゃないかな。 豊富なプラグインや設定で、Hype
進捗ヤバいプロジェクトに直面した経験がある人なら（多分）楽しめるカードゲーム「Not My Fault!」 - 科学と非科学の迷宮
エンジニアがプロジェクトがオンスケであると嘘をつき続けるゲームは盛り上がった pic.twitter.com/aWkKIPtAAS— Yoshifumi Yamaguchi (@ymotongpoo) 2017年7月30日 @ryushi さんの主催で仲間内で集まってボードゲーム・カードゲームで盛り上がったのですが、その中で @tokoroten が持ってきた「Not My Fault!」というカードゲームが非常に衝撃的でした。 まず、背景設定がすごい。 残り30日で絶対に完成させなければいけないプロジェクトに、プレイヤー達はプロジェクトメンバーとして参加しています。 進捗は絶対に遅れてはいけません。 もし、プロジェクトの進捗が報告されていたよりも進んでいないとしたら？ それはもちろん、進捗を過大報告したヤツの責任です。 監査を入れて、そいつを追い詰めよう！ というのがゲームの設定です。
A interactive Git visualization tool to educate and challenge!
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
「なぜなぜ分析」は、品質管理や労働安全管理などの分野で、よく用いられる手法だ。発生した問題事象の根本原因を探るために、「なぜ？」「なぜ？」とくりかえして掘り下げていく。この問いかけを“5回はくりかえせ”と、よく指導しているため、別名「なぜなぜ5回」とも呼ばれる。元々、トヨタが発祥の地であり、トヨタ生産方式の普及とともに、他の業界や分野でも使われるようになった。 図は、トヨタ生産方式の生みの親である大野耐一氏の著書から一例をとって、図示したものだ。工場内のある生産機械が故障してとまったとき、「なぜ機械は止まったか？」の問いに、「オーバーロードがかかって、ヒューズが切れたからだ」と答えただけでは、じゃあヒューズを交換して再起動すればいい、という答えしか出てこない。 しかし、なぜオーバーロードがかかったのか？→ (2)軸受部の潤滑が十分でないからだ、とほりさげ、 さらに (3)潤滑ポンプが十分組
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
接触確認アプリCOCOAからの教訓｜情報処理学会・学会誌「情報処理」
特許庁の55億かけて頓挫したプロジェクトの報告書が面白い
上司が信用できない会社の内部統制 - slideshare
Webサービスを10日以内にリリースする方法をすべて書いたよ（「Gumad」編） - パパパパ
LingrとRejawサービス終了のお知らせ:Kenn's Clairvoyance
｢自分でやったほうが早い病｣への15の処方箋 | ライフハッカー［日本版］
工数見積もりのコツ - Qiita
とれるだけ仕事をとってはいけない : タイム・コンサルタントの日誌から
ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)
FINDJOB!終了のお知らせ | FINDJOB!
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
海外在住Web屋の私のまわりで最近話題の5つのWebサービス
マンションの大規模修繕で取り回しやってたら、何故かslackで業者さんの業務改善までやることになってたでござるの巻
ゼロからはじめるプロダクトマネージャー生活
無料公開された“契約ガイドブック”が話題に 芸術分野のフリーランス必読の内容に「素晴らしい」「勉強になる」
無料でGoogleカレンダーからガントチャートが作れる「GANTTplanner」
提案書の書き方、徹底解説～提案書のストーリー・コピー・デザインの基本法則【スライド付】 | knowledge / baigie
第65回 ［図解］Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング：ITpro
時間を有効に使うための14の時間管理術:Garbagenews.com
Rubyコーディング規約
明日から3連休だから部屋を片付ける！と思っている人へ…「3日以内に人を呼べるくらいの部屋にするためのメモ」が参考になる
大規模 JavaScript その設計と実装と現実
Learn Git Branching
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
なぜなぜ分析は、危険だ | タイム・コンサルタントの日誌から