2020-10-23技術を使うための技術も大切というお話初めまして。CLINICS の開発を担当しているエンジニアの平山です。 （同姓ですが CTO ではございません） CLINICS の開発は「スモールチーム制」をとっておりまして、現在そのうちの１つをチームリードしています。 前職は長らく SIer に勤めていました。去年の 12 月にメドレーに JOIN して、間も無く１年経とうとしている。。と思うと、あっという間だったなぁという印象です。 さて、本日はメドレーで隔週開催している社内勉強会（TechLunch）において発表した内容についてご紹介させて頂ければと思います。 はじめに「技術を使うための技術」というテーマとなりますが、プロダクト開発をしていく上では欠かせない素養と考えています。メドレーに所属しているエンジニアの１人として、どのように日々課題と向き合っているのか。当テーマを通し
こんにちは、介護のほんねの開発担当エンジニア 兼 プロダーツプレイヤーの徐 聖博です。 メドレーでは定期的に技術勉強会を行っているのですが、この勉強会に参加するのはエンジニアばかりとは限りません。先日は非エンジニア向けにGitの勉強会を開催しました。エンジニアではないメンバーもGitを使えるようにすることは、プロダクトの高速開発に大きな効果があると僕たちは考えています。今回は、その思想の背景と、実際に行った勉強会の内容についてご紹介します。 一般的な開発フロー 実際にサービスをコードレベルで把握・修正する人は大抵の場合エンジニア（一部デザイナー）と呼ばれる人種です。 しかし、一般的に、「サービスの運営」と一言で言っても、そこに携わる人の役割は様々です。 サービスの規模にもよりますが、ディレクターやエンジニア・デザイナーはもとより法務や広報など様々な方のサポートによって一つのサービスが成り立
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
When I joined Buffer, one of the things I was most excited about was seeing how we can get a lot done with a distributed team. I knew that Buffer was specifically set up to work this way and I was curious about seeing that play out. It turns out, this is possible mostly because of the great tools we use. We’re continually testing and adding new ones to our arsenal to make sure we’re all on the sam
This post is long overdue; this isn’t a declaration of intent (any intent was long ago made real), just my reflection about my own path. I left the Python world a long time ago but I never took a chance to say goodbye. While I had moved on from Python years ago, I felt a certain attachment to it well past then, not quite admitting to myself that I wasn’t coming back. When my proposal for PyCon 201
2014-02-07 マネジメントで意識していたことを書いた エンジニア 考え方 ここ半年くらいはAmebaで一兵卒としてチョロチョロしてる自分ですが、最近色んなプロジェクトのアレコレを見ていて色々と思うところがあります。 半年くらい前までは自分もサービスを持ってたので、マネジメント・ディレクション周りで意識していたことを書きます。 教育と裁量 自分のチームには12新卒が2名いたんですが、全てを与えず、とにかく課題を与えて常に思考する癖をつけさせるようにしました。一人にはリリースコントロール（機能開発の主導、ブランチの運用、リリース作業）を、もう一人にはサービス間連携（関係者との調整含む）をと、割と重要なミッションを課しました。とにかく自己学習ではなかなか経験できない仕事は任せた方が良いかなと。 健康管理 風邪ひいてる、その兆候があるメンバーは基本的にさっさと帰らせました。あと、ちゃんとマ
3. CyberAgent Inc. Ameba Osaka manager Senior CopyPaste Programmer 大阪でソシャゲ作ってます。 前職はiPhone屋さん。 どちらかと言うとフロントの 人ではない ＼(^o^)／
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの？」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ！」「君自身が編み出
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
■大ソーシャルコーディング時代 GitHubの台頭により、ソースコードをオンライン上に共有するということが、たいへん簡単な時代になりました。 TwitterやFacebookなどを見ていると、毎日のようにエンジニアの書いたソースコードへのリンクを目にすることができます。 わたし自身、自分の書いたソースコードは、可能な限りたくさんの人に見せるべきだと考えています。 エンジニア同士、コードについてのノウハウを共有することはよりよいプロダクトを作る礎となりますし、なにより自分の成長を劇的に促進してくれるからです。 今回はこの、「コードを人に見せるということ」について考えてみたいと思います。 ■コードレビューが苦手だった 職業プログラマが、最初に自分の書いたコードを誰かに見せる機会というのは、おそらくコードレビューでしょう。 わたしが職業プログラマになって最初に書いたコードは、COBOLによるもの
3日、Twitterの日本オフィスにて、Twitterの技術に興味のあるエンジニアを対象にしたオープンセミナー「Twitter Tokyo Open House」が開催された。この日は昼過ぎから爆弾低気圧のために各交通機関ともに混乱していたが、会場には多くのエンジニアが訪れた。 やっぱりバックエンドを支えるエンジニアは “バルス”を話題にするよね…… SNSが日々の生活に定着して久しい。2011年11月にニールセン・ネットレイティングスが発表したプレスリリースによれば、日本の場合、PCからTwitterへのアクセスは1455万人、Facebookへは1131万人となっている。これらに未集計のスマートフォンやケータイなどからのアクセス数を合算すれば、この数値以上の人々がSNSサービスを利用しているというのは容易に想像できよう。 Twitterの基幹システムのエンジニアであるRob Benso
「ご趣味は？」と聞かれて「Lispをdisることですね（ｷﾘｯ」と答えてしまい、 合コン開始4秒で蚊帳の外に放り出されるあんちべです、こんばんは。 今から長い文章を書く。 結論だけさっさと言っちゃうと 「まぁ、初めのうちは、あんまり『○○は使えない』とかdisらない方が良いよ」の一言だ。 さぁ、それで話しはおしまい。もし暇だったら続きも読んで欲しい。 （あと、この文章はたった一人のために書いた。 ちょっと妙に聞こえるところもあるだろうけど、そこは聞き流して欲しい） 私はよくいろんなものを嫌いだ嫌いだとdisる。 にわかベイジアンが嫌い（話すと長くなる）、Javaが嫌い（JVMは愛してる）、Perlが嫌い、 MavenとかCVSとかが嫌い、アジャイルアジャイル言ってる人が嫌い（アジャイルが嫌いなわけじゃないよ）… 言い出したらキリがない！毎日新しいdisりの種が沸いてくるんだ！ 何度か様々な
酒粕みそ焼豚 美味しい酒粕の時期ですね。 今年も豚かたロースのブロックで焼豚を作りました。800gを2等分に。 お肉をコーティングしたのは、酒粕、味噌150gずつ、すりおろしにんにく3片、味醂半カップ、醤油小1を合わせたものです（味噌の味、粘りに合わせ、分量は調整）緩いと流れ…
2. 2009年下期 オープンソース技術を利用したモビリティ マネジメント基盤の開発 Saturday, March 10, 12
実家の6畳の部屋で仕事をしています。調子のいい時には朝5時とか6時に起きて、 顔を洗ったらすぐにその日のスケジュールを立てて30分ほどの読書をします。 その後、情報収集と最近では毎日5000字ほどの書き物をします。 すると午前中が終わるので、隣のばあちゃんちに向かいます。 ばあちゃんちの応接を親父が改造してオフィスにしてるそこへ、です。 親父は最近自炊に凝っていて昼飯をごちそうしてくれるのです。 腹が一杯になると1時間ちょっとベッドで昼寝をして、スッキリした頭で午後の作業に向かいます。 午後の作業はプログラミングをすることが多く、ここ数ヶ月はiPhoneアプリの開発をしています。 夜になると集中が切れるので好きなアニメを見たり、音楽を聴いたりなるべくリラックスするように心がけてます。 これはとある僕のとある一日をなぞったものですが、数年で築いてきたワークスタイルを端的に表すものです。 最近
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く