「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも

2018年10月4日、株式会社メルカリが主催するイベント「Mercari Tech Conf 2018」が開催されました。メルカリグループ各社が、今後目指す方向や、これから取り組む技術的なチャレンジなどを語るエンジニア向けカンファレンス。2度目の開催となる今回は「Evolution（変化）」をテーマに、エンジニアたちがメルカリの技術のこれからを語ります。プレゼンテーション「どうして僕らは決済処理をマイクロサービス化しようとしているのか」に登壇したのは、メルペイ、ソフトウェアエンジニアの斎藤祐一郎氏。現在開発中の金融サービス「メルペイ」において、リファクタリングではなくマイクロサービス化を選択した理由を解説します。講演資料はこちら 決済処理のマイクロサービス化における3つの課題 斎藤祐一郎氏（以下、斎藤）：マイクロサービス化の話題が盛り上がって、数年が経ちました。みなさまは、さまざまな論文や

はじめに とある企業で組み込み系ソフトエンジニアとして働いていますが「このままだと、将来ないかも？」と思えてくる場面に日々遭遇します。 今回は日本の組み込み業界の将来が不安になる、耳を疑った”上司の発言”をまとめてみました。 「最近の若いやつらは残業が足りない」 働き方改革が騒がれるこの時代に、そんなこと言う人いるの！？ と驚く方もいるかもしれないですが、いるんです。 そして、それがまかり通る現場の一番の問題は 「開発業務の効率化、スピードUPを図る文化が根付かない」ことだと私は思っています。 「時間が足りなければ残業でカバーすればOK！残業代も出るし、いいでしょ。」 という考え方では、どうすれば開発スピードが上がるか？無駄な作業はないか？自動化できることはないか？といった改善のアイデアは、なかなか出てきません。 残業を推進し次から次へと業務が積まれていくような現場では、改善のアクションの

プログラマーとしてすでに30年くらい仕事をしてきて、最近になって「ひょっとして？」と気がついたことが1つあります。大したことではありませんし、勉強の偏差値の話しとかが絡むので、読んだ人がイラッとくる内容かも知れないのですが、まあ、このブログは自分のために自分で好きなことを書くのがポリシーなので、忘れないうちに書いておきます。 受託開発でも製品開発でも同じなのですが、長年この仕事で気になっていたことの1つが「完璧さ」に関することです。技術的に難しくてできないとか性能が出ないとかではなく、「作り忘れた」「確認し忘れた」「渡し忘れた」「書き忘れた」など、単純なことです。 私はずっと「気合いが足りない」「配慮が足りない」「メモしておくなど忘れない工夫が足りない」「心がこめられていない」などの原因だと思っていたのですが、確かにそういう要因もあるものの、もっと根本的なことなのではないかと最近思いつきま

「カイゼンジャーニー」を一気に読んだ後で、もう一度、アジャイル開発とは何なのか、現時点で考えを整理しておく。 自分の中の暗黙知を整理するのにとても役立ったので、下記の記事をリンクしておく。 特に主張なし。 【１】アジャイル開発では「個人のパフォーマンスで駆動」されるので、チームワークや心理的安全を重視する。 一方、WF型開発では、プロジェクトの成功を「組織の力で担保」する。 となると、先日の冬季オリンピックで、日本女子がパシュートで金メダルを取った事例を振り返ると、日本人は組織の力を重視する方が好きなのか？ ならば、個人のパフォーマンスで駆動する開発プロセスを志向するアジャイル開発は、日本人の文化とは本来合わないものなのか？ アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート (引用開始) このプロジェクトでは“本物”の「スクラム」を実施し

2018-01-31自分たちにも優しい”デザインとは？こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、自分たち（開発者）にも使いやすいデザインはどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスのプロダクト基本理念が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させる

簡単にいうと「今がこれからの人生で一番若いんだから、今から何か行動するとよくなる可能性ってまだまだあるよ」的な感じです。 で、いろいろな反応を見させていただいたんですが、出てきた話として、「人生詰んだと思っちゃう人は、新しいことをするエネルギーが足りていないため、何も始められないのでは？」という指摘です。 これはその通りなんです。 「決断疲れ」というのがあり、何かを決断するには膨大なエネルギーが必要なため、1日にできる量は限界があるみたいな話があるのですが、新しいことをはじめるというのにも相当なエネルギーが必要です。「人生詰んだ」と思ってしまう人が、たくさんエネルギーがあるかというと・・・ないですよねえ。 僕の話をします。 僕は小さいころから運動神経もなく、手先も不器用で、勉強もできなくて、歌や楽器も下手で、、と言ったようなそんな感じで他の人と比べてもスペックはだいぶ低いというような印象が

主に若手のエンジニアに対して「意欲がない」と感じている人はいないだろうか？ 「俺の時は自分で勉強するしかなかった。だから自分で技術書を買って必死に勉強した。それに比べてあの若手はどうだ。自分で勉強はしない。現場に何年もいるというのに、あれも知らない。これも知らない…」 こうした不満はいわゆる技術力が高く、開発現場でも中心にいるようなエンジニアが抱くことが多いように見受けられる。 だが、果たしてこれは「意欲がない」という問題なのだろうか？ 総じて、「意欲の問題」と称されるものは機会や環境の問題であることも多い。もしあなたが、若手に対して同じような不満を抱いているのなら、少し考えを改める必要があるかもしれない。 任すことができないエンジニア 技術力が高いエンジニアは責任感も強い人が多い。こうした人は、若手に「仕事を任せる」といったことが苦手である。 確かにあなたの目線で見れば、未熟なエンジニア

営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン

最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか？ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。 海外企業のリーダーシップスタイルの変化 ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。