社内なら謝らなくて良いカルチャー
社内で仕事をしているとき、指摘や指導をすることがあるが、まだうちのカルチャーに慣れていない人は、すぐに「すいません」と謝る。でも、それは良くないよ、と言っている。 仕事の仕方や成果物に対しての指摘というのは、別に悪いことをしたからな訳ではないのだから、謝る必要などない。私に謝って欲しくて指摘している訳ではないのだ。 謝るってことは、私を向いて仕事をしていることになる。それは良くない。仕事はあくまでユーザやお客さまを向いてするものだ。社内の人に向いて仕事をするのではない。 だから指摘に対して謝る必要はない。良い仕事をしてもらいたい、成長してもらいたいから指摘をしているのだ。社長の顔色なんて見なくていい。良い仕事をすればいい。 同じチームにいて、良い仕事をして、成長していきたいというベクトルがあっているなら、謝ることなんてないのだ。そういうカルチャーの会社であり続けたいと思っている。 もちろん
Swiftでデバッグ出力（日時、メソッド名、行番号） - 定食屋おろポン
メソッド名と行番号 かつてObjective-Cではこのように書いていた時代があった。 NSLog(@"%s, %d", __PRETTY_FUNCTION__, __LINE__); 今日からはこう書ける！*1 println(__FUNCTION__, __LINE__) //=> (someFunction(), 60) Swiftのprintlnは、NSLogと違って現在時間が表示されない。 出力したければNSDateを使えばよい。 println(String(NSDate.date().description), __FUNCTION__, __LINE__) //=> (2014-06-04 13:34:18 +0000, someFunction()someFunction(), 63) 追記: 普通にNSLogも使えるので使えばよい。 特殊リテラルには以下があるので好きに
ネット上でのQ&Aサービスを作り方のコツを語ってみるよ
僕は、インターネット上のコミュニティサービスをたくさん作って15年くらい経ちますが、大ヒットは飛ばせないものの、全くダメで人がこないという失敗を避けるコツはつかめてきたかも、という感覚はあります。 で、そこで学んだことはいろいろあるのですが、その一つに、「Q&Aサービスの作り方」というものがあります。 Q&Aサービスとは、要はYahoo!知恵袋や、LINE Qみたいな総合型から、弁護士ドットコムのような専門性高いものなど、たくさんありますが、みなさんご存知の通り、質問者が質問をなげると、回答者が回答をくれるというものです。 僕の会社でも、何度かQ&Aサービスを立ち上げるというものをやったりしていました。この時のコツを紹介します。 質問者を集める！Q&Aサービスで一番大事なのが、質問者を集めるということです。 Q&Aサービスは、質問する人と、回答する人がマッチングするサービスなので、どちらか
一生プログラマであるということ | F's Garage
Web系やシステム系のエンジニアは、一生プログラムを書いていたいのだろうか。僕自身は、こういう言説をどう捉えていいのかよくわからない。むしろこういう言説は少しネガティブだ。 僕自身のキャリアは、もともと機械製造業の電気制御の設計で、現場で物を作る立場から、設計へと移動した流れ。その会社では大卒入社組は製造での経験を経て、設計職に行くパスになっていた。いわゆるテレビ東京とかが好きな意味での「ものづくりの現場仕事」ではなく、設計を通じて「製造部門や調達部門に指示を出す役割」である。 もちろん電気制御なのでプログラムは書くが「プログラマー」ではなくて、あくまでも「技術者」という枠組みで捉えている。 ハードもソフトも全部やるってことだけど、全部を自分で作れるわけじゃなくあくまでチーム戦。如何に人にお願いし、いいものを作ってもらうかというのも技術者の仕事だと思っている。外注さんにもお願いするし、パー
竹尾 宏道 | Supership Recruit
Supershipが最も大切にする価値観、 社員や候補者の皆さんに期待する 行動指針の解説および Supershipホールディングス 代表取締役社⻑CEOから皆さんへの メッセージをお届けします。
竹尾 宏道 | Supership Recruit
Supershipが最も大切にする価値観、 社員や候補者の皆さんに期待する 行動指針の解説および Supershipホールディングス 代表取締役社⻑CEOから皆さんへの メッセージをお届けします。
GitHubでコードを「公開しない」リスク？サイバーエージェント流、OSS時代の開発哲学 | SELECK
今回のソリューション：【GitHub（ギットハブ）】 〜「GitHub」でソースコードを社内・社外に公開し、オープンなコラボレーションを実現した事例〜 数々のサービスを生み出し続けるエンジニアリング集団、株式会社サイバーエージェント。そのエンジニアリング文化の中心には、「GitHub」を活用したオープンなコラボレーションがある。 同社ではプロダクトのソースコードは可能な限り全社公開すると同時に、 「スターインセンティブ制度」というリポジトリのスター数に応じたインセンティブを与える制度により、自身の書いたコードを社外へ公開することを推奨している。 ▼そもそもGitHubって何？という方はこちらの記事もどうぞ！ チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】 ソースコードを可能な限り公開していくという流れは、ITベンチャーのみならず世界的大企業にも派生
社名変更のお知らせ
Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
開発者のタスク管理をGitHubで行ったらうまくいった話 | DevelopersIO
はじめに こんにちは、6月からAndroidの開発を担当している荒川です。 この記事は以下の方を対象にしています。 リモートリポジトリにGitHubを使っている タスクや課題の管理を小〜中規模のプロジェクトで行っている 複数の開発タスクが並行して進むプロジェクトにアサインされている 開発者のみのタスク管理を主体的に行いたい タスク管理ツールを使っているがイマイチうまくいっていない この記事では、私が実践して良かった経験則を紹介します。誰でも真似すれば必ずうまく行くという保証はありません。この記事の読者の方が、担当しているプロジェクトに合わせてアレンジを加えるとより効果が増すかと思います。 開発者のタスク管理 モバイルアプリサービス部では、コミュニケーションツールにBacklogやTrello、Pivotal Trackerを用いている事を突撃！隣の開発環境 パート3【クラスメソッド編】の記
リジェクト日記: 番外編: App Storeで検索リジェクトをいただいた話
iOSはリリース前に審査がありますが、リリース後もいろいろなタイミングで事後審査が行われています。 よく言われてるのはランキング上位に来て目立ったタイミングで再審査されるパターンですが、特に売れてないアプリでもランダムで再審査されることもあります。 事後リジェクト事後リジェクトには大きく分けて２つのパターンがあります、 ①アプリがストアから削除される ②アプリは削除されないが検索とランキングから削除される 以前①の事後リジェクトされた時は告知とアプデの猶予をいただいたのですが、 2.25 ウォール狩りでもしてらっしゃるんですか？ 今回初めて②の検索リジェクトをされたのですが、全く告知等はなくいつの間にか消えてました、URL直打ちでしか表示されないので実質死んでるようなものなんですが。 告知がないので気付かない古いアプリだったので今回発見まで４日くらい見逃してしまいました、５０本くらい出して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type