@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「プログラマーとお仕事をするということ」を読んだ

impression

エンジニア以外の人と話をするときに、気にすれば良いことの気づきを得れるかもと思い読んでみた。

目次は以下

第1章：イントロダクション
第2章：なぜソフトウェア開発は建築と似ていないのか
第3章：アジャイル
第4章：彼らは一日中なにをしているのか？
第5章：緑の大きなチェックマーク
第6章：ジャーゴンの謎を解く
第7章：プログラマーを採用するには
第8章：プログラマーの心を占めるもの
第9章：プログラマーを上機嫌に保つ
第10章：すべてが悪くなるとき

ソフトウェアの開発手法、一般的な用語の説明、採用の仕方、エンジニアの生態までと幅広く書いてある。
たしかにビジネス側の人が知っていてくれれば話すときに楽かなと思う。話をするときに同じ言葉が使えるというのはすごい楽だし伝わりやすいと思う(どこかの会社の英語化をディスってるわけじゃない

ただ全体的にエンジニアを持ち上げすぎている感じはした。物を作るというのはたしかに必要なことだ。
しかし、

  • なにを作るか決める
  • 作る人、リソースを確保する
  • リサーチして改善案を考える
  • お金を調達する

などもとても必要なことだ。
社内でもたまにプロダクトを作って満足している人を見かける。
それをユーザに使ってもらうために、お金を稼いでくる人たちがいることを忘れてる人が多いと思う。
自分たちが作ったものを宣伝してくれたり、トラブルが起きたときに対応をしてくれている人達がいるのだ。
そこら辺を忘れると納期を気にしなくなったり、自分たちの使いたいものを使ってお金に糸目をつけずに開発をしてしまうなどのことが起きてしまう。

ビジネスの人もエンジニアも両方いないとできないことのほうが多いのだから、話をする時間を増やしていくのが一番なのかなと思う。どちらが偉いとかではなくどちらも必要なのだから仲良くするだけで問題ないはずだ。
相手が何を考えているのかなど考えたところでエスパーでもなければ分からないのだから、とりあえず話しかけれるという関係が出来上がっているのが一番良いと思う。

まとめ

  • プログラマーとお仕事をするということを読んだ
  • ビジネスの人がエンジニアをどう思っているのかを知るために読むのも面白いのではと思った
  • まず、話しかけやすい場をつくることをしてみようと思った

プログラマーとお仕事をするということ [ Patrick Gleeson ]

プログラマーとお仕事をするということ [ Patrick Gleeson ]

プログラマーとお仕事をするということ【電子書籍】[ PatrickGleeson ]

プログラマーとお仕事をするということ【電子書籍】[ PatrickGleeson ]

201806 振り返り

retrospect

久しぶりに勉強会に行った。他の会社なり他の人なりが楽しそうに様々なことを試しているのを聞くのは自分もやろうというやる気が出るので適度に勉強会には参加しようと思う。
コンテナ周りやオーケストレーションをよく触っているけどまだ自分の中でもどうすれば良いのか悩むことが多いのでそのへんのベストプラクティスをもっと追求していきたい。あとはデータの収集をどうにか綺麗にしたい。

来月はもっと本読んで僕もなにか勉強した共有しようと。

べんきょうかい

microserviceの話ってことだったので申し込んでみた。
サービスディスカバリとかログどうしてるとか聞きたかったけどインフラよりの話はなかったな。
次はインフラの人もいるともっと話ができるかなと思った。
相変わらず人見知りが発動してしまった。

ほん

仕事の関係でマニュアルを読むことが多かったので、技術書を読む気力が起きなかった。
ベースキャンプのしごとの仕方は面白かったので、取り入れれそうなことをチームメンバと試していってみよう。
部屋の写真をたくさん見たので今の部屋を綺麗に整えていきたい。まずは本を減らすことが必須になるけど。

えいが

日本語の映画のみになったのは久しぶりな気がする。
映画見てから原作を読む事が多いんだけど、このパターンだと登場人物の想像ができなくなってちょっと悲しいなと気がついた。

201805 振り返り

retrospect

今月はもう終わりなのかと思ったほど時間がすぎるのが早かった気がする．．．
kubernetes上でシステムを動かすことにして、ローリングアップデートとかログ周りとか気になることが多い。この辺知見のある人達とお話したいなー。

先月参加したJapan Container Days v18.04で応募したら、おうちkubernetesセットをサイバーエージェントさんからいただけました。ありがとうございます!!
少しづつ組み立てて遊ぼうと。
おうちkubernetesについてはこちら

ほん

今月は疲れていたので漫画と小説多め。
６月以降はまた積読の技術書読んでいこうと思う。

えいが

GODZILLAが３部作みたいだけど本当に次で終わるのかな。
まだ見れてないアヴェンジャーズをやってるうちに観に行かなければ。

ぶろぐ

最近は技術そのものというよりも、開発手法とか思想とかについての本を読むことが増えた気がする。
もう少し手を動かして遊びたくなってきたのでまた何かの技術について本を読みながら触ってみる時間を増やしていきたい。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「リーン開発の本質」を読んだ

impression

結局なんだっけって思うことが多いのでリーン開発の本質を読んでみた。

リーン開発の本質 ソフトウエア開発に活かす7つの原則 [ メアリー・ポッペンディーク ]

リーン開発の本質 ソフトウエア開発に活かす7つの原則 [ メアリー・ポッペンディーク ]

リーンソフトウェア開発の原則として7つのことが書いてあった。
本書ではこの原則の説明が事例と一緒に豊富に書かれていた。

原則1 : ムダをなくす(Eliminate Waste)
原則2 : 品質を作り込む(Build Quality In)
原則3 : 知識を作り出す(Create Knowledge)
原則4 : 決定を遅らせる(Defer Commitment)
原則5 : 速く提供する(Deliver Fast)
原則6 : 人を尊重する(Respect People)
原則7 : 全体を最適化する(Optimize the Whole)

ムダの定義

チームが行う活動の中で、顧客に価値を提供するために役に立っていないものを「ムダ」と定義し分類されている。

未完成の作業のムダ
余分な機能のムダ
再学習のムダ
引き継ぎのムダ
タスク切り替えのムダ
遅れのムダ
欠陥のムダ

開発者にとってのムダとはなんだろうと考えてみた。
最も大きなムダは技術的負債なのでは無いかと思う。
古代遺跡のようなアーキテクチャ、古文書のような手順書、暗号文のようなコード。どれをとっても機能追加や新規開発にとって邪魔になるものであると思う。
技術的負債を減らすことで、開発速度の加速もバグの埋め込み減少もできるのではないかと思う。開発者にとってのムダの削除とはナニハトモアレ技術負債を無くすことなのではないかと。

最後にリーン開発を行うための10個の「ロードマップ」と21個の「やってみること」が書いてある。定期的にチェックをしてみようと思う。

「Infrastructure as Code」を読んだ

impression devops infrastructure

Effective DevOpsを読んだ。
その中で４つの要素が必要なものと書いてあり、そのうちのツールについて勉強しようと思いたって積読になっていたInfrastructure as Codeを読んだ。

Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス [ Kief Morris ]

Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス [ Kief Morris ]

インフラをコードで管理することができる。コードで管理できればソフトウェア開発のプラクティスをインフラにも適用できる。プラクティスとは以下のもの。

  • ヴァージョン管理
  • テストの導入
  • CI/CDの導入

クラウドやオートメーションツールの普及によりインフラに変更を加えることが簡単になったため、コンピュータリソースのテンプレートや設定ファイルでインフラを管理するようになった。ツールを使うことで手作業を減らしミスを減らしていく。
また、マイクロサービスのような新しいアーキテクチャが標準になってきたことにより、必要なサーバ構成も変わっていく。アプリケーションの変更に付随してインフラも変更を余儀なくされることが多々ある。

  • 大きく変更させるのではなく小さい変更を適度に繰り返す
  • モニタリングの設定、確認
  • 高速なフィードバックに対する対応
  • 継続的なテスト

強く納得したのは以上のことだった。これらは、アプリケーション開発では当たり前の事のように言われていることだなと感じた。(できているかはともかく…

まとめ

Infrastructure as Codeとはインフラ、アプリケーションと関係なくリードタイムを短くすることを目的とした手法を考えて実行していくこと、またそのようなことができるチームを作っていくことなのだと思った。
今後どのようなアーキテクチャやツールが標準になっていくかは分からないが、すぐに対応できるようにインフラもアプリケーションも細々と勉強し続けようと思う。

おまけ

ちょうど本を読み出す前に監訳の@gosukenatorさんの書斎についての記事を読んだ。その中でブックストッパーが紹介されており、本を開きながら書く際にとても役に立った。便利便利。

201804 振り返り

retrospect

気がついたら36歳になってました。ほしいものリストから沢山のお祝いを頂きました。
送ってくださった皆様本当にありがとうございます。直接くださった方も同じくありがとうございました。何かのタイミングでお返しができればと考えています。

自分の市場価値を知るために転職ドラフトを試してみました。
８社からお話をいただき、最高金額750万円、平均665万円でした。今の自分の値段が分かったので外の人と話をできればなと思います。是非色々な会社の人と話をしてみたいなー。

べんきょうかい

コンテナの勉強のため１日カンファレンスに参加してきた。
コンテナというよりはKubernetesの勉強会かと思うほどKubernetesについての発表が多かったけど面白かった。
ログ周りとかイメージの作成についてとかチームメンバーでもう少し話し合ってみようと思った。

ほん

積読になっている技術書を少しずつだけど読みはじめた。自分は本を読む時に絵として理解できないとあまり覚えれないので読むのに時間がかかってしまう。部屋の本を減らすためにもちょっとずつでも毎日読み続けるようにしよう。
あとは睡眠時間を少し削ってみるか。
TOEICの勉強法についての本を何冊か読んだ。文法、単語、発音の基礎をやり時間をかけて苦手科目を埋めていくしか無いんだろうな (あたりまえ...

えいが

今回のコナンは警察の説明がたくさん出ていて子供が理解するのが大変そうだなと思った。
いぬやしきの飛行映像が綺麗だった。また、CGの勉強してみようかな。

ぶろぐ

自分の中であまり理解できてないDevOpsについて学ぼうと思って読んだ本と、コンテナの勉強しに行った勉強会についてブログ書いた。
コンテナでの標準的な決まり事とかベストプラクティスとか色んな人と話し合ってみたい。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

Japan Container Days v18.04 に参加してきた

impression container conference

ベルサール神田で行われたJapan Container Days v18.04に参加してきた。

mesos + marathonを使用してコンテナ化したアプリの運用を２年ほどしてきたのだがまだまだ勉強不足だなと感じることが多々あるため詳しい方とお話できればなと思って参加しようと思った。

参加してきたセッションは以下

あれ？Kubernetesって名前ばっかり見える。
イベントの名前なんでしたっけ？と思うほどKubernetesの話ばかりだった。
Kubernetesを知らないなんて...って言われてしまうほどスタンダードになったんだろうなと。

一部の発表を除いてどの発表もすでに数年以上運用をしている人たちの発表ばっかりだったのでとても生々しい話が聞けたし、自分で構築運用をしていくうえで考えなければいけないことが分かった気がした。

いろいろ学ぶことが多かったけど今回自分の中に残ったのは

  • 必要なものがあったら自分達で開発して置き換え
  • 開発するためにソースコード、基準を学んでおく
  • 担当する箇所によって学ぶべき事柄は変わる

書くと当たり前なことだけど、自分ではできてないなと思いながら話を聞いていた。OSSなのだから足りない機能は自分で開発して取り込んでもらうこともできる。開発するための定義については公開されている (ex. OCI、 CRI)ことさえ守れば問題ない。

また3つ目については、アプリエンジニアは要件を出してDockerfileを書くことでコンテナを作れるまで行う、SREが要件通りに実行できる環境を構築するというメルカリの事例を聞いた内容からの感想。アプリエンジニアは自分のできるアプリケーションを作成するのとシェルスクリプト感覚でDockerfileを書いて終わり。気がついたらコンテナがKubernetes上で動いていて要件が達成されていた。
これはチームとしての働き方として理想だなと思った。チームが目的を共有していてメンバーが自分のやるべきことをやることで最短で結果を出す。アプリエンジニアはKubernetesについて詳しくなる必要がないし、SREの方はコンテナを要望通りに動かす環境構築に集中すれば良い。

個人的に面白かった発表は、Container Networking Deep DiveとDockerだけじゃないコンテナruntime徹底比較!、Istioと共にマイクロサービスに立ち向かえ!。最初はネットワーク、次はruntimeをいろいろ検証してみたっていう話。インフラ周りの実証結果を見るのが楽しかったし自分でもあれこれ試してみたいと思った。
最後はマイクロサービスとの戦い方。Istioが思っていたよりもできることが多かった。資料は読んでみたけど試したことまだないから検証導入していきたいなと思った。発表資料の中にIstioを始めるまでのロードマップがあったので試してみよう。

まとめ

きっとコンテナを直接どうこうということはないんだろうなと思った。コンテナを運用するためのオーケストレーションだったりコンテナを見つけるためのサービスメッシュだったりコンテナをどう隠して運用できるかの話にすすんでいるだろうな。このままだとおいてかれてしまうから勉強しなくては。いろいろ刺激的な1日だった。

他にも面白そうなコンテンツばかりだったから帰ったら資料探してみようと。

宣伝

Kubernetesについて自分なりのまとめを作っているので宜しければ