冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Adaptive Code 第2版を読んだ

長澤さんよりご恵投いただきました(厳正なる抽選の上)。多謝。

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

Adaptive Code ~ C#実践開発手法 第2版 (マイクロソフト関連書)

3行所感

所感

本の内容をなぞるだけのレビューは大嫌いなので、ここは読みながら私が感じたことを書いてみたいと思います。

コードは書いた瞬間から鮮度が落ちていくもので、それに抗う必要がある

致し方ないことですよね。プロダクトが未来永劫同じ使われ方をして、同じニーズにこたえ続けるわけではなく、ユーザや市場も変化し続けているわけです。そのため、プロダクトが果たさなければならない役割も変化し続ける。

で、これも仕方のないことですが、コード自体はリリースしたタイミングを起点に次のリリースまでどんどん鮮度が落ちていきます。書き逃げのようなプロダクトならともかく、ユーザとともに育っていくつもりのプロダクトなら、この変化に対応しないといけないわけです。本書ではこの変化に対応しやすいコードのことを「Adaptive Code(適応的なコード)」と称しているわけです。

そして、これにどうやって抗うのか、ということが書いてあります。中でも重要なポイントは以下の3点だと思いました。

  • 適時にリリースできるようにする
  • コードの上でも抽象と具象を分ける
  • 抽象ベースに依存関係を作りやすい構成にする

デリバリーフレームワークという言葉と構成に感じる強い意志

「Adaptive Code」というタイトルながら、本書の頭1/3くらいは「デリバリーフレームワーク」と表現された開発プロセス(Scrumとカンバン)と、コードの配置の仕方について力を入れて書かれています。いうなれば兵站に相当するようなことなわけですが、具体的なコーディングテクニックの前にやるべきこと、考えることについて目を向けており、章立てから非常に強い意志を感じる構成です。個人的にはやっぱりカンバンが好きだなあ、と思いました。

それはそうと「デリバリーフレームワーク」というのは良い表現ですね。コードもデリバリーも適応的にいくべきだ、という思いを感じる表現です。著者がカンバンを成熟したチームのためのフレームワークと表現しているのは、カンバンの方がよりシンプルでかつ適応的であると考えているのでしょう。

ただ、カンバンのところにある「サービスクラス」と「SLA」の例えは、ちょっと唐突な感じがしました。このところは理解するのに少し時間がかかったというか、まだちゃんと理解できているか怪しいところです。

すべてはインターフェイスのために(違

Javaを使い始めのころは、インターフェイスの利点をよくわかっていませんでした。そのころに入った案件では、結構うまくインターフェイスを利用していたのですが、「どうせ実装クラス出てくるのにぶっちゃけ邪魔だなー」としか。それからデザインパターンを知り、インターフェイスを使って柔軟性を確保する方法を知り、今となってはインターフェイスの恩恵を受けないことなど考えられないくらいです。

で、本書では、段階的にその利点を感じながら使いどころを抑えていくためのサンプルとコーディングテクニックにあふれています。それはもう、インターフェイスを使いやすくするために各種パターンやコーディングテクニックがあるのだ、と言わんばかり(あくまで「言わんばかり」ですよ)。

まとめ

長澤さん、ありがとうございます。とても良い本でした。

初学者の段階からすべてを把握することは厳しいかもしれませんが、備えておくべき資質になると思うので、早いうちから読んでいく本だと思います。また、C Sharpに限らず(第2版は原題から外されている模様)、オブジェクト指向言語を扱ってコードを書いている人には有用な本だと思います。

オープンセミナー2018@広島でお話ししようと思っていたこと

まず初めに、オファーいただいた後も数々の準備・公式サイトでの告知などお手数かけていただきながら、直前に参加できなくなってしまったこと残念に思います。運営の皆様には直前でご迷惑をおかけしました。致し方ないこととは言え、私も当日に向けて積み上げてきたものがありますので、同様に残念です。いずれ、ブラッシュアップしてどこかでお話できるといいな、と思ってます。

妻の退院当日に片付けをしながらTwitterを見ていましたが非常に濃い内容だったようで、私もその場に行って他の方のお話しも聞きたかったところです。

togetter.com

今回、それなりに準備をしてきたということもあり、そのままお蔵入りというのも勿体無い話だなあ、と感じました。そこで、どういうことを話そうとしていたか、ブログに要点をまとめたいと思います。

一番言いたかったこと

「これをやれば必ずチームがよくなる」方法はないので、チームに合わせて考えるのが唯一の解になります、という身もふたもないお話し。

これは、それぞれ置かれた状況が異なる複数のチームでマネジメントをした経験の中で、同じことが同じように効果があった訳ではなかったという背景に基づいています。それを踏まえて、実際にやった取り組みの具体例よりも、理由に遡ってから少しそれを抽象化して実施に繋げるためのどんなアプローチをしたか、を主題としました。そのメタファーとして取り上げていたのはグラウンドキーパーです。実際にスライドに書いたアプローチは以下です。

  • チームへの仕事の入り方をコントロールする
  • チームの仕事の仕方を確立する
  • イレギュラーに気付きやすい良いグラウンドにする

まあ、もう少し言葉を洗練させたかったな、とは思いますが、抽象化したアプローチとして正確さを損なわないレベル、と言うことで。

良かった点

スライドやスクリプトを作っていく中で、今回オファーいただいてよかったな、と感じたこと。

複数のチームでやってきたことを抽象化するきっかけになった

今の会社に入ってから3チーム、プライベートでも少し似たような入り方をしているので1チーム、それぞれでやってきたことを抽象化して共通項を見つけていくきっかけになりました。少し時間がたっているからこそ、冷静に思い返して理由や背景について整理できる、という側面もあったと思います。

この辺りは、最近チームに関するブログが減っている理由にもなっていて、チームで取り組んだ話をしようと思うと、チームが置かれている状況だとか、歩みとか、そういったものへの言及が避けて通れないよな、となっている訳です。そうなると書かなきゃいけないことや書く上で考慮しないといけないことが増えてきます。すべての取り組みは背景が諸々あって、まずはこれを選んでいる、という状態なわけです。

で、こういったものを記述すること自体は有益なことだと思うので、適した言葉がないかなあ、と探してはいるわけです。で、たどり着く結論は大体パタン・ランゲージ。結局そこに行き着くのかよ、パタンのメンテナンスしんどいから一人でやるようなもんじゃないよなあ、とかなってなかなか踏み出せず、といった状況です。

過去のスライドから自分にとって普遍的なことを見つけた

これも収穫でした。できてないときもあるけど、軌道修正するのに必要な言葉が書いてあります。過去の自分すごい。

具体的には以下2枚。これが他の人に響くかどうかは別として、自分の中では常に気をつけたいことです。自分に言い聞かせるためにも、定番的に入れ込んで行こうかな、と思いました。

f:id:mao_instantlife:20180307203739p:plain

f:id:mao_instantlife:20180307203751p:plain

反省点

当然、今冷静に読み返してみると反省点も多々あります。

詰め込みすぎた

上記の一番言いたかったことの他にも、ドメイン知識ないところからマネージャとして入っていることとか、自分の考える良いチームの定義みたいなことなんかもスライドに入っていました。今思うととてもじゃないけど、30分に収まりそうにないですね。もっと伝わらない部分を覚悟の上で話題を絞り込めば良かったと思います。

言い訳がましく言ってしまうと、広島でお話しするのが初めてなので、自分の背景について知ってもらおうと考えて色々と書きすぎたのだと思っています。

タイトルミスった

プロジェクトXのないチームを目指したマネージャが取り組んだこと」じゃなくて、もっと色々あったよなあ、とは。「グラウンドキーパー的マネジメント」とか端的な表現でも良かったのではないか、とも思います。

上記の詰め込みすぎ、のところにもかかる訳ですが、トピックを分離すると「ドメイン知識ゼロから始めるチームビルディング」と言うタイトルも出てきそうです。このように、スライド見ながら複数のタイトルが切り出せそうなこと自体が話題が絞り込めてない証拠ですよね。

タックマンモデルなどチームのモデルについてもう少し触れればよかった

上記詰め込みすぎ、に矛盾するように見えますが、トピックが絞り込まれていればもっとこの辺のモデルの背景に触れることは可能だったように思います。元スライドでは、自分の背景と理由が中心でしたから。

抽象化が足りない

これはもう少し言葉を洗練させれば改善していくのではないかと思います。今回オファーいただいてからすべてのスクリプトを起こしたので、流れも含めて準備を結構突貫でやってしまったところがあるかもしれません。表現の質という意味では、自分にとって定番な表現タームというか、そういうものを作ってしまってもいいのかもしれないです。

その後

TLを追いかけながら触発されて、チームギークを速攻ポチったわけなんですが、理由や背景の面で近いところに至っていたのか、と思うようなことがいくつもありました。今回中途半端な表現になってしまったところなんかを、この本とも絡めてブラッシュアップして、どこかでリベンジしたい。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

t.co

2018/2に読んだ本

ようやく、シュバルツバースから脱出しました。

なお、妻が入院してしまったので、オープンセミナー広島@2018の登壇はキャンセルさせて頂きました。残念です。準備は割としていたし、その後にチームギークを読みはじめて、テーマ的にもう少しブラッシュアップできそうだったので、なんとかして機会を作りたいな、とは思っています。

先月読んだ本

印象的な本

フィクション系

まあ、ARMSはともかくとして。

クジラの子らは砂上に歌う」が、ガッツリ物語が動きだした感があっていいですね。泥クジラの面々が幸せになってほしいものです。

ちょっと意外だったのは「不滅のあなたへ」の展開ですね。あらすじ的なものを読んでいた限りは梶尾真治の「エマノン」シリーズ的な予測をしていたのですが、若干違う模様。とっかかり的にはよくある展開感を拭えなかったので、続刊を手に取るかどうかは少し微妙。

一番収穫だったのは「ユートロニカのこちら側」です。この作品で描かれているのは、ディストピアでもユートピアでもなく、もうすでにその辺に転がっている緩やかな変化の行き着く先でもあるわけで、SNSの炎上芸人の末路を見ているような気分にもなってきます。ただ、これに描かれているほど人間って反抗するのかな、とも思って、少し楽天的な結論に感じたのは私だけでしょうかね。

ユートロニカのこちら側 (ハヤカワ文庫JA)

ユートロニカのこちら側 (ハヤカワ文庫JA)

ノンフィクション系

ファシリテーショングラフィック」は買います。自分でも買います。

新潮45 薬害でっちあげ」は子宮頸がんワクチンに関するものです。でっち上げのやり口が整理して書かれていて、非常に参考になります。

Scalaをはじめよう」は、Scalaもくもく会で教えて貰った本。復習するにはいい本でした。別の言語は習得していて、これからScalaと言う人には良い本なのではないかと思います。

近況整理

最終更新日(2018/2/22)

基本情報

今までのキャリア

プログラマ

個人的な志向としては、バックエンドとモデル層、アーキテクチャがきれいなことに惹かれるタイプで、フロントエンドは得意ではないです。RDBMS層はFirebird/Oracle/MySQL/SQL Serverなど現場にすでに導入されたものに合わせて利用していたので、一つの製品特性に特化するというより、クエリやアプリケーションレベルでのパフォーマンス向上のアプローチが多かったです。

  • Delphiでのwin32ネイティブアプリ保守開発
    • 自社オリジナルハードとのTCP/IP接続あり(シェイクハンドから)
    • エンディアンの変換など
    • 一人開発なので、サービスエンジニアチームと連携して保守体制を構築
      • ドキュメントの整備
      • 全国のサービスエンジニアへの連絡体制構築
      • 保守体制の整備
  • 派遣、客先常駐(Java他,オープン系)
  • イントラ系システム構築
    • データ連携基盤(HULFT,DataStageなど)が中心
    • Web系の開発でリーダー、イテレーティブな開発を推進(東京のビジネスチームと岡山の開発チームで)
  • パッケージ/サービス開発
    • REST API開発(Spring framework)
    • データ連携バッチ(Java)
      • データタイプとテーブル以外は固定になるケースが多いので、型クラスっぽいアプローチでETLのようなDSLを作った
  • 個人

マネージャ

  • OEM開発チームの立て直し
    • チームの役割整理
    • ふりかえりを通じた継続的な開発プロセスの改善
    • テスト/レビュー体制の構築
    • カンバンの導入
    • それらが円滑に進むような案件スケジュールの調整
  • ゼロからのプロダクト開発チーム立ち上げ
    • ビジネスサイドとプロダクトの方向性の検討、初期コンセプト策定、ロードマップの合意
    • デザイン会社とのやりとり、デザインの検討
    • 開発範囲の検討と仕様の策定
    • データ連携部分の実装
    • リリースを踏まえたアーキテクチャ検討
    • 受入テスト、リリースノート作成
  • 既存チームの交通整理
    • 外部チームとのやり取りの一元化
    • パッケージバージョンアップとカスタマイズのスケジューリング

これからやりたいこと

起業じゃないの?という話もあるんですが、自分の中で起業がやりたいことにつながらない気がしているので、当面はそのつもりないです。

Manager as a Service

これからのマネージャの強みは、様々な現場の様々なケースに対応できることだと思います。そのため、一つの会社/チームにすべてのリソースを割り振るのではなく、サービスとしてマネージャを共有してもらい、並行して走る他の現場の様々な問題を抽象化して各現場に生かすスタイルを模索したいです。

そのため、フルコミットするまで必要としていないけど、マネジメントで悩みを抱えているチームをスポットで支えるということもやってみたいと思っています。ゆくゆくはエンジニアチーム以外のマネジメントもできるようにしていきたいです。

フルリモートマネージャ

これからエンジニアに限らず、様々な業種でリモートワークが選択できるようになるはずです。そうなると、基本的にチーム全体が1つのサイトにそろっていないことを前提としたマネジメントが求められます。そのような状況の中で、マネージャの専門性というのもこれから変わっていくのではないかと思います。

具体的には、

  • リモートでのコミュニケーション促進
  • フロー/ストック情報の取り扱い
  • リモートを前提とした可視化のための環境整備

があげられると思います。

エンジニアが価値を出せる組織づくり

速く言えば、プロ野球GMと呼ばれるポジションとグランドキーパーを併せ持ったようなポジションです。現場のニーズに合わせて採用計画を立てて実施、エンジニアが価値を出すことに集中して、それを周りから理解してもらえるようなエンジニア組織のあり方を模索したいです。

やりたくないこと

  • 勤務体系に柔軟性のない働き方
  • メンバーを信頼しない働き方

2018/1に読んだ本

時のオカリナ 3D」は片がついて、次はEXPERTモードでシュバルツバースラスト。

今月はオープンセミナー広島の準備を始めたところなので、数は少ないですね。来月まではこんなペースかと。実は私、登壇することになっております。

osh.connpass.com

先月読んだ本

印象的な本

フィクション

今月は該当なしですね。アニメで見たものの再読ですし。

来月には楽しみにしてたこれを読むのでこれが入ってくるかなあ、とは思いますが。

ユートロニカのこちら側 (ハヤカワ文庫JA)

ユートロニカのこちら側 (ハヤカワ文庫JA)

ノンフィクション

とにかくこれが面白かったです。

本来は専門書(看護系の学生向け?)なので、門外漢が楽しむとかちゃんとした読み方ではないのでしょうが。

ドクターGとか大好きなんですよ。事象から小さなヒントを見つけてロジックを組み立てていくやり方が気持ちいいんですよね。ケースとしてのクリティカル度合いが違うことが多いですが、システムトラブルに対応している時なんかを思い出します。アプローチの面では同じかと。

こちらもよかったですね。

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

借りて読んだのですが、身になることは多かったです。国だけじゃなくて、企業文化とか業界的なものも考えておいたほうがいいかも。