サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
どの企業にも、必ず何名かは「人格に問題のあるビジネスパーソン」が存在していた。 人格に問題があるのなら、干されたり、追い出されたりするのだろう、と想像する方もいるだろうが、実はそうでもない。 彼らは様々な理由で存在を許されており、例えば、 ・経営陣である ・カネを稼げる ・上には従順である ・解雇規制の観点から追い出せない といった理由から、企業の中に生息している。 とはいえ、弊害も大きく、他の社員はいい迷惑をしており、 「そういう連中と共存するにはどうしたらよいのか」 という悩みを日々抱えながら、働くことになる。プロジェクトに入ってくる「問題児」 当然、コンサルティング会社も、プロジェクトに配置されているこのような人物を問題視していた。 というのも、「人格に問題がある人」が一人入ってくるだけでも、会議を妨害されたり、スケジュールに遅れが生じたり、他のメンバーの作業に支障が出るからだ。
TOPフォーカス気づけばFirefoxのコア開発者になっていた。「修正されないバグの報告」から始まった25年間【フォーカス】 Mozilla Firefox コア開発者 株式会社Birchillエンジニア 中野 雅之SIer企業のシステムエンジニアとして1999年にキャリアをスタート。2000年頃よりボランティアでMozillaプロジェクトに参画し、バグ報告を始める。2004年、有限責任中間法人Mozilla Japan（当時）に技術部国際化担当マネージャとして参画。Firefox・Geckoエンジンのフルタイム開発者となる。2019年より現職。 X:@d_toybox ブラウザ「Mozilla Firefox」を、根幹から支える日本人エンジニアがいます。Web技術開発を手がけるBirchill社のメンバーとして、Mozilla Corporationからの委託を受け、Firefoxの
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、同じエンジニアである妻から聞いた話なのですが、彼女の案件で「メンバー全員で公式ドキュメントを読みあわせる」という取り組みがあったそうです。 で、この方法「チーム全体にとって大きなメリットがあるんじゃないか？」と思ったので、共有させていただきます。 「誰も知らない」から「みんな知ってる」に 私は開発職なので、めずらしいことなのかそうではないのか判断がつかないのですが、その案件では、導入対象の製品について詳しい知識を持っているメンバーが一人もいなかったというのです。 誰もその製品をさわったことがなく、とりあえず強そうなメンバーを入れ
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
unsafe:本記事は、I AlmostGot Fired for ChoosingReact in Our Enterprise App（ https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c ） を原著者Razvan Dragomir氏の許可を得て翻訳したものです。 エンタープライズ アプリでReactを選択したら解雇されそうになった話Reactは我々の開発を楽にするはずだった。それどころか障害物が作成された。 Razvan Dragomir 2021.01.23 2018年の夏のことだった。私の上司Adrianから、カナダの大企業のCTOであるJamesとのSkypeミーティングに参加するよう頼まれた。 お互いを
ベイジでは大規模なウェブサイトのリニューアルプロジェクトが増えているため、社内でプロジェクトマネジメントのノウハウや知見を溜めようとしている。その一環として、社内でプロジェクトマネジメントの勉強会を行うことになり、企画担当者になったので、ChatGPTの力を借りることにした。 そうしたらそれなりの勉強会の企画のたたき台ができたので、ChatGPTとのやりとりをこの場を借りてみなさんに共有したいと思う。ChatGPTとのやりとり まずは企画の意図と条件をざっくりと依頼プロジェクトマネジメントを学ぶためにセッションを5回に分けて行いましょうという返答があった。また座学だけにならないよう、ロールプレイやQ&Aなどのインタラクションが促進されるコンテンツも提案してくれており、気が利いている。パワーポイントによるプレゼンテーションの構成を聞いてみる 1つひとつのセッションは粒度が粗かったため、
インディーゲームの大手FinjiのCEOが語る，開発チームと広報チームの協力体制を作るために必要なこと ライター：徳岡正肇 インディーゲームが大きな産業として発展し，大成功を収めるデベロッパの数も増えていくなか，「成功はしたがパブリッシャと揉めた」といったケースも珍しくなくなってきた。 制作者側と販売元のトラブルは，例えば出版業界のように，ゲームに限らず各業界で幾度となく繰り返されてきたものだ。しかし，トラブルが起こらないならそれに越したことはないし，起こったとしてもその原因がどこにあるかが見えれば，ファンを巻き込んだ大炎上にまで至らない可能性も高まる。 そんな，パブリッシャとデベロッパの衝突事案の防止や解消にも応用できる知見を得られるオンライン講演が，2023年6月に配信されたデジタルイベント「GDC Showcase2023」で行われた。 それは，「It's Better To Be
大阪・関西万博のパビリオン建設が大幅に遅れている。 労務費や物価の高騰など遅れの要因は一つではないが、根底にあるのは万博協会のマネジメント能力の欠如。 日本はオペレーションの高さを世界に誇ってきたが、その部分も劣化し始めているのかもしれない。 （植村 公一：インデックス代表取締役社長） 2025年国際博覧会（大阪・関西万博）のパビリオン建設が遅れているという報道が連日のようになされています。 私が代表を務めるインデックスは建設・インフラプロジェクトのプロジェクトマネジメントが本業であり、いくつかのパビリオン建設のプロジェクトマネジメントに実際に関わっているため、着工前に必要な建築基準法上の仮設建設物許可申請が進んでいないという話は少し前から聞いていました。 それでも、万博開催まで2年を切っている今、許可申請を出した国内パビリオンが全体の約3割に過ぎず、参加国・地域の海外館に至っては申請数が
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
こちらの記事は2022年時点の古い情報になります。最新の情報はこちらをご参照ください。Python向けレトロゲームエンジンPyxelのユーザーの皆様、こんにちは。 バージョン1.6からは、通常のサンプルとは別に2つのPyxel製ゲーム（以下の画像）もバンドルするようにしたのですが、楽しんでいただけていますでしょうか。 こちら、UK在住のスーパークリエイターAdamさん作のゲームなのですが、どちらも面白いだけでなく、歯応えも相当ありますので、クリアを目指すのであれば心してかかった方が良いと思います。私も動作確認のためにクリアまでプレイしたのですが、ものすごい時間がかかって、ほとんどゲームセンターCXのノリでした…。 昨年12月、Rust版コアエンジンを搭載した新バージョンのPyxelをリリースし、その後の不具合修正もひと段落して、やっと一息着くことができました。無事たくさんの方々に使ってい
blog.codinghorror.com Stack Overflow の共同創業者、あるいは「FizzBuzzテスト」を広く世に知らしめた（？）ことで知られる Jeff Atwood が、彼の世代にもっとも影響を与えた BASIC 時代の本を取り上げている。 それは1970年代に刊行された BASIC Computer Games だが、この本に掲載されたゲームを遊ぶために BASIC のコードを打ち込んだよねということで、日本でいうと1980年代のマイコンBASICマガジン（ベーマガ）に近い存在だろうか。 で、単にノスタルジーでこの昔の本を取り上げているのではなく、彼はこれに掲載されたゲームの BASIC のソースコードをJava やPython や C# など8つの現代のプログラミング言語に移植するプロジェクトを立ち上げている。github.com ライセンスは The Un
「オープンソース」は壊れているchristine.websiteのブログより。 または:お金を払わない限り、有用なソフトウェアを書かないのか? 最近、重要なJavaエコシステム・パッケージに大きな脆弱性が見つかりました。この脆弱性が完全に兵器化されると、攻撃者はLDAPサーバから取得した任意のコードを実行するよう、Javaサーバを強制することができます。 <マラ> もしこれがニュースで、あなたがJavaショップで働いているなら、残念ですが、あなたには2、3日が待っています。 私は、これが「オープンソース」ソフトウェアの主要なエコシステム問題の全ての完璧な縮図だと考えています。log4j2が、この問題の最悪のシナリオの1つの完璧な例であると思うので、このすべてについていくつか考えを持っています。この問題に関与したすべての人が、現実世界の問題に対する完全に妥当な解決策のためにこれらすべてを行ったことは完全に合理的であり、
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする EngineerEmpowermentプロジェクトの @Mahito です。 この記事は、NTT Communications Advent Calendar 2021 2日目の記事です。 今回は社内のソースコードをGitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。 背景 きっかけは「NeWork のソースコードが見たい」という私の思いつきでした。 これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。GitHub (Team plan) Git
ゲームディレクターとして動いていると、企画やできたもののフィードバックをよくする。そうすると必要なのは、UX（ユーザー体験）を言語化して説明をして納得をしてもらうことだ。一緒にやっているプランナーから、UXの分解・言語化をどうやっているのか？という質問が来たので、書いてみる。ゲームディレクターは、なぜUXの分解・言語化が必要なのだろうか？ これは簡単で、自分が感じていることを言語化できないとチームメンバーに伝えることができず、納得感を持って作ってもらうことができないためだ。「なんとなくダメ」とか、「理由は説明できないけどこうして」という指示は、繰り返せば繰り返すほどやらされる方はしんどくなっていく。当たろうが外れようが、何をやっているのかよくわからなくなってくる。主観ではなく、客観で伝えることができないと、チームは納得がしにくい。なので、ゲームディレクターにはUXの言語化能力がとても必要
開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？ というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ
Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト（一例）プロジェクト ライセンス Elastic SSPLと独自ライ
この記事で言いたいことは、まとめると以下のような内容になります。 ・「面倒くさくて複雑」といフローは、例外もあるものの、基本的には不適切であるか、そのフローが必要とされる前提の方がおかしい ・けれど世の中には、「面倒で複雑なフロー程正しいし価値がある」と考える人が案外多い ・「面倒くさい」と言える人は貴重なんだけど冷遇されがち ・不要なJOIN句は敵だし、JOIN句の使い回しなど絶対してはならない よろしくお願いします。 さて、言いたいことは最初に全部言ってしまいましたので、後はざっくばらんにいきましょう。 先日、Twitterでこんなことを呟きました。エンジニアをしていると「面倒くさいやり方は大抵間違っているか、あるいはそのやり方を必要としている前提の仕組みの方がおかしい」という思考は割と普通だと思うんだけど、どうも世間的には「面倒くさければ面倒くさい程正しい、ないし価値がある」と思っ
Endless road | During our roadtrip we turned off the highway… https://www.flickr.com/photos/98063470@N00/326044514GitHubリポジトリ Covid19Radar に対して起ったことがかなり特殊な状況だったため、開発を追い掛けていた視線からレポートをします。 この記事の著者について 代表作のない個人アプリ開発者(かなしい)Covid-19 Radar Japan の人ではないGAFAMやCode for Japan の人でもない 4/8Covid-19 Radarを発見するCovid-19 Radarとは、この時点ではシンガポールのTraceTogetherの日本版を目指した個人開発者 廣瀬一海さんのアプリのリポジトリ 4月にContact Tracing技術について
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
