株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に
メルペイで一年間プログラミングしました: 柴田 芳樹 (Yoshiki Shibata)
2018年6月にメルペイで働き始めて、今年は2年目でした。ちょうど一年7か月働いたことになります。今年一年間は、Backendのマイクロサービスの開発で、ずっとGo言語とVimでプログラミングしていました。昨年は、5月は全く仕事をせずに休みだったのと、メルペイに入社してしばらくはAPI仕様ばかり書いていたので、振り返ってみると最後に一年間プログラミングした年は2008年だと思います。 リコーに勤務していた8年間（2009年9月〜2017年8月）では、現場のソフトウェアをレビューすることはあっても、自分でプログラミングすることはほとんどありませんでした。 一年間プログラミングし続けたと言っても、月曜日から木曜日までなので、40代の頃と比べると時間的には少なかったです。また、40代に行っていた複雑なマルチスレッドプログラミングと比べるとそれほど複雑なプログラミングは行っていないです。 基本的に
コミュニケーション力: 柴田 芳樹 (Yoshiki Shibata)
「ソフトウェアエンジニアの心得」の教育（講演）で1枚だけのスライドとして、以下の内容のものがあります。技術者間での議論において、自分の考えを、相手が理解できるように論理的に説明でき、相手が説明しようとしていることを、相手の立場になって理解できる。つまり、 相手が理解していないと感じた場合には、相手が理解できる内容・用語・比喩に切り替えて説明できる。 相手の説明をきちんと理解できない場合に、相手が何を言いたいのかを逆に質問して、正しくコミュニケーションを取るように努める。 エンジニアによっては、相手が何を聞いているのか全く理解しようとすることなく、同じ説明を繰り返す人がいます。もちろん、こちらとしては、質問を変えたりして内容を理解しようとするのですが、それでも、説明を切り替えたりすることなく、全く同じ説明を繰り返すのです。会議などでは、最後に、見かねて別の人が「彼（彼女）が言いたいことは、・
ソフトウェアエンジニアの成長カーブ（再掲載）：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事
一人前になるには10年: 柴田 芳樹 (Yoshiki Shibata)
「ソフトウェアエンジニアの心得」と題した話は、講演として行ったり、技術教育として企業向けに行ってきています。基本的には、拙著『プログラマー”まだまだ”現役続行』に沿っていますが、その中で「一人前になるには10年」ということで話をしています。該当部分を拙著から抜粋したのが次の部分です。 一人前になるには10年 ソフトウェア開発は創造活動であり、創造能力を高めるには、「より良くできないか」という問題意識を常に持ちながら、多くの経験を積んでいくことです。 リチャード・ガブリエルは、「ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する」とも述べています。 これは、「10年間ソフトウェア開発を経験した人が一人前である」という意味ではありません。実際の開発現場では、単に10年間を過ごしただけであり、一人前といえる経験・知識にはほど遠い人も多いのです。 デービッド・フーバーとアデワレ
悪いAPIは伝染していく（2）: 柴田 芳樹 (Yoshiki Shibata)
以前、「悪いAPIは伝染していく」という短い記事を書きました。 APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。 きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。 どんなAPIでも、最初のバージ
オープン・クローズドの原則（OCP：The Open-Closed Principle）: 柴田 芳樹 (Yoshiki Shibata)
Bertrand Meyerによるオープン・クローズドの原則（OCP：The Open-Closed Principle）は、クラスや関数を設計するだけでなく、アーキテクチャ（システム設計）においても重要な役割を果たします。1997年に出版されたBertrand Meyerの著書Object-Oriented Software Constructionで紹介されています。 ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いて（オープン：Open）いて、修正に対して閉じて（クローズド：Closed）いなければならない。 大規模なシステムにおいて、ある機能を追加しようとする場合に、既存のモジュール群を多数修正しなければならないのであれば、この原則に反していることになります。もし、追加される機能が小さなものであっても、既存のシステムを多数修正しなければならないとなると、シス
継続インテグレーションは強みではなくなった（2）: 柴田 芳樹 (Yoshiki Shibata)
短期間で、たとえば、1週間である機能を既存のシステムに追加するプロトタイプを行う場合、テスト駆動開発や継続的インテグレーションが実践されていることは、どこまでプロトタイプできるかに大きな影響を与えます。 継続的インテグレーションにより、開発者は常にビルドできる状態でプロトタイプに専念できる訳ですし、プロトタイプが終わったと宣言した時点でサーバによるビルドもできている訳です。自動テストが整備されていれば、ある機能のプロトタイプにより、他の部分が問題を起こさないかを早い段階で確認することができます。 もし、どちらも行われないとしたら、プロトタイプを行った開発者のPCでしかビルドできなかったり、システム全体をテストすると様々な問題が見つかったりします。プロトタイプであっても、さらに機能を拡張するために開発者を追加することは十分に考えられます。その場合に、プロトタイプを行った開発者のPCにしか環境
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
ソフトウェア開発組織が持つべきカルチャー 014: 柴田 芳樹 (Yoshiki Shibata)
知識教育だけではなく、良い行動パターンを促進する「技術の伝承と良い習慣の伝承」とも関連しますが、日本の企業でソフトウェア技術教育（特に新卒新人の技術教育）を担当している部門やグループは、何を教えたかということで教育体系をまとめようとする傾向があると思います。しかし、個々の教育コースの内容を見ると浅かったりします。 ソフトウェア技術というのは、毎年新しいものが登場し続けますので、すべてを教育コースで教えることはできません。そのため、ソフトウェアエンジニアに身に付けてもらうことは、知識だけではなく、継続して自発的に学び続けるということです。 たとえば、2000年から行っている「プログラミング言語Java教育」は、単にJava言語の知識を学ぶというだけではなく、膨大な自分の時間を使って専門書をきちんと学習する習慣を身に付けてもらうことも目的としてあります。実際、一年間の最後の成果発表会では、「学
Kindle Touchがやってきた: 柴田 芳樹 (Yoshiki Shibata)
注文したKindle Touchが届きました。初めてKindleを購入したのが一年半前です（「Kindleがやってきた」）。これで2台目のKindleとなります。 Kindle Touch, Wi-Fi, 6" E Ink Display - for international shipment 今までのKeyboardタイプのKindleよりは、キー入力も操作しやすいです。 Time誌を試しに購読してみることにしました。 通勤電車の中で、カバーストーリを読んでみて、従来のKindleより良い点は、辞書を引くときに、意味を知りたい単語をちょっと長めにタップし続けるとポップアップで意味が表示される点です。 Keyboardタイプと異なり、単語の選択が指で押すだけなので簡単です。 意味がポップアップで表示されるので、Keyboardタイプと異なり、ある程度きちんと表示されます。 標準は英英辞典
ソフトウェア開発組織が持つべきカルチャー 010: 柴田 芳樹 (Yoshiki Shibata)
ビッグバン・インテグレーションを避ける 組織におけるソフトウェア開発では、一人で行うことは少なく、プロトタイピングであっても、数名あるいは10名弱で行われることもあります。昔のソフトウェア開発であれば、各人の担当を決めて、各人が実装が終わった後に全部を結合するというビッグバン・インテグレーションが行われて、様々な問題に直面していました。たとえば、各人は開発がスケジュール通りだと常々報告していても、結合で多くの問題を抱えて、結果的にプロジェクトが遅れていくということもあります。 今日、複数名で行うプロトタイピングであっても、ソースコード管理、自動ビルド、自動テストなどを小さいながらも整備してから開発を行うべきです。そして、開発が進むに従って、必要に応じて環境を改善していくことが必要です。しかし、残念ながらチームリーダがそのような認識を持つこと無く、開発を進めている組織もあるのではないでしょう
ルンバ780: 柴田 芳樹 (Yoshiki Shibata)
先月、思い立ってヨドバシ町田店に行って「ルンバ780」を購入しました。いわゆる、掃除ロボットです。 http://www.irobot-jp.com/special/700series/ 掃除ロボットを買うのは、なんとなく無駄な気がずっとしていたのですが、買ってみて分かったのは「必需品」だということです。どういう意味で必需品かと言うと、洗濯機の登場により洗濯機が家庭にとっては必需品と同じぐらいです。つまり、それまで人手で行っていたことを機械が自動で行ってくれて、（主婦の）自由が時間が増加するということです。 従来の掃除機だと、どうしても人が掃除機を使って掃除をする必要があります。ルンバだと勝手に行ってくれます。その意味で、洗濯機と同じなのです。ルンバによる掃除が一時間かかっても、機械が自動的に行ってくれますの非常に楽です。 唯一掃除が上手くできない場所は、私の書斎です。床に本が積んであった
ソフトウェア開発が好きでないサラリーマンエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。 その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。 その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようにな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MacBook Airを購入: 柴田 芳樹 (Yoshiki Shibata)
ライブラリ、フレームワーク、アーキテクチャ設計：柴田 芳樹 (Yoshiki Shibata)：SSブログ
Jolt Awards: The Best Books: 柴田 芳樹 (Yoshiki Shibata)
コードレビューの視点 008: 柴田 芳樹 (Yoshiki Shibata)
プロセス中心ではなく、スキル中心（4）: 柴田 芳樹 (Yoshiki Shibata)
Kindle Touch: 柴田 芳樹 (Yoshiki Shibata)