この記事は、株式会社エス・エム・エス Advent Calendar 2025の12/12を開く記事です。 – 採用活動をしていると、「VPoE (Vice president of engineering) になりたい」というキャリアを聞くことがある。一般的に、エンジニアリング・マネージャー (以下、EM) の上位互換として認識されているようで、雑に括ると「経営に近い EM」としてのイメージがあり、「なんか裁量大きそう」「待遇良さそう」という印象があるのだろう。 ChatGPT 曰く、VPoE は「組織全体」「技術戦略」「経営との接続」あたりがキーワードらしい。およそ世間のイメージもそんなところだろう。ではこれで実際の VPoE の活動がわかるかというと、なんとなくわかった気になっているだけで実際のところは曖昧なままだ。 EM の仕事すらまだ明確な定義がない中で、さらに雲をつかむような話だが、この記事では VPoE の仕事をもう少し掘り下げて解説し、EM のキャリアパスが見えるようにしたい。 ここからは、VPoE というまだ見えない仕事については解説せず、EM の仕事を解説していく中で VPoE の仕事と呼ばれているものの姿を解き明かしたい。 環境を整えるのが EM の仕事？ よくマネージャーの仕事は「アウトプットを最大化すること」「成果を最大化すること」だと言われる。マネージャーの一種である EM の仕事も同じ仕事の定義に乗っかってもよさそうだ。では、成果を最大化するためにやる仕事というのはどのような活動だろうか？ 開発チームのパフォーマンスを上げるためにやることを考えてみよう。たとえば、以下のようなものが挙がるだろう。 開発プロセスの詰まりを解消する 情報流通の整備をする 調整をする 個々の問題解消のファシリテーションをする 技術基盤を整える 1on1 どれも悪くないように思える。実際に EM がやっている仕事だし、誰かがやる必要のある大切な仕事だ。では、これらを全部やるのが良い EM と言えるだろうか？ 問題は、これが組織の成果を最大化する活動なのかである。 課題の解決が EM の仕事 課題の解決をいろいろやるのが EM の仕事なのは間違いがない。「いろいろやる」の解決の仕方も、対症療法的に目の前の問題を解決することもあれば、仕組みづくりをしていくことで解決をしていくこともある。 では、課題とはなにか？　課題は、TODOリストではない。計画ではない。現象ではない。課題は、組織の成果を生み出す上での機会や、問題となっている阻害要因のことだ。 EM をやっていると、「あんなことがあった」「こんなことがあった」「あれをしてほしい」「これをしてほしい」とあらゆる問題が人づてにやってくる。 これらへすべて対処をしていると、あっという間に自分の時間が埋まっていく。そのため、一般的に EM はそうして集まった現象のそれぞれに対して、問題構造の分析をして、組織が解くべき課題を抽出するという過程を踏む。このときの判断基準が、「組織の成果に大きく貢献する問題はなにか？」だ。 こうして抽出された課題を解くのが EM の仕事になる。 課題のイシュー度を考える 次に考えるべきは、課題のイシュー度だ。イシュー度という言葉は、「イシューからはじめよ」で解説された言葉で、「自分のおかれた局面でこの問題に答えを出す必要性の高さ」を指す。その問題を解くと価値が高いということだ。イメージがしやすければ、最初は緊急度と重要度で分類して重要度の高い問題をイメージしてもいい。 抽出された課題に対してすべてを解いていくことは難しいため、優先順序を付けることになる。このときに判断基準となるのがイシュー度だ。 優れた EM が組織の成果に対してより大きなインパクトを残せる人だとすると、それはイシュー度の高い課題を見出し、質の高い解決をすることができる人だと言える。

外部委託して開発をするかというときにエンジニアリングマネージャーが考えていること 「外注して開発しましょう」それは通常は善意と共に、突然やってくる。 開発組織が忙しいことはわかっている。だから、手を煩わせず事業の成長をつくりたい。 あなたは、その相談を受けたエンジニアリングマネージャー (以下、EM) だ。さあ、何を考え、どのように回答するだろう？ この記事では、内製の開発組織の EM が外部委託しての開発を検討するときにどのようなことを考えるのか、とくにその単発での開発に限らず組織への影響をどのように考えるのか、そしていつ外部委託を活用すべきでどのようなときには利用することが問題となるのかを説明する。 想定読者としては、もちろん EM をやっている人や EM を将来やってみたい人を想定しているが、もしかしたら事業責任者や開発者経験の少ないプロダクトマネージャーの役にも立つかもしれない。 外部委託しての開発の可否について話す前に、まず開発組織の開発実施可否についてどのように考えるかを説明し、その中で実現手段として外部委託して開発をするということへどのように考えるかを説明する。 内製組織の投資判断 開発の投資判断は相対評価による優先順序付けが基本 投資判断をするというときに最も一般的な判断のやり方はROIによる判断だろう。それを実施するコストに対して得るものを計算して、得られるものがコストを上回ると想定できるのなら、やる価値があると考える。 これは開発リソースが無限に調達できるという仮定に立てば有効な考え方だ。しかし通常開発組織が置かれている状況はそうではない。常にやりたいことは自分たちのキャパシティを超えて存在している。そのため、そこには取捨選択が発生し、限られた中でなにをするのかを考えることが求められる。 こうした中で判断をしていくときに有効なのは、個々の妥当性の判断よりも生み出す価値の相対的な比較になる。全部やれるならやればよいが、そうではない。社内の開発能力というのは限界があり、その有限の中で相対的により効果的で価値のあることへ投資をしていく必要がある。なにかを選択した瞬間に比較すべきは人件費でなく、同時に捨てた別の機会なのだ。 保有するソフトウェア資産の数を少なく保つことが集中投資を実現する そして、相対評価をするときには新しく施策として開始するものだけを考えるわけではなく、今保有しているソフトウェア資産を持ち続けるコストというのを中心に考えている。 現代のインターネットサービスの開発を前提にすると、作りきりで終わりという開発はほぼ存在しない。ソフトウェアの開発を継続するときには、そのソフトウェアについて熟知している体制が必要になる。ソフトウェアという資産と同時に、そのソフトウェアを開発することができるドメインの理解や開発資産の理解がある人やチームというのも組織能力を構成するコアの資産になる。この点は資産として見えにくいので、よく見過ごされるが組織にとってのケイパビリティとしてかなり重要な要素になっている。 保有しているソフトウェア資産を持ち続けるために必要なコストには、ソフトウェアを維持できるチームを継続することであったり、ソフトウェア自体を時間の経過に対して更新し続けることが含まれている。 そのため、保有するソフトウェア資産の数が増えることは組織のケイパビリティにとっては能力を分散させる要素が増えることを意味する。選択と集中というのはここでも重要で、重要なことを前に進めるためには開発組織のケイパビリティを集中的に投資したいと EM は考えるが保有するソフトウェア資産が増えることはこれに逆行する。 外部委託をして開発をすることをどう解釈するか 通常、ビジネスの視点から見るとソフトウェアの開発という行為は人件費・業務委託費と交換でプロダクト・ソフトウェアが手に入る取引に見える。外部委託もケイパビリティの選択肢の一つであることに間違いはない。ただ、そこで得られるものに対して、重要なものを毀損するかもしれないリスクをゼロに見込んでしまう。すると、残るのは得られるものだけだから、合理的に「あり」だろうという結論になりやすい。 さて、前段で説明した内製開発組織のロジックの中ではどのように考えるのだろうか。人件費・業務委託費と交換でプロダクト・ソフトウェアが手に入る取引であることに間違いはない。 それはつまり将来の保有するソフトウェア資産が増えることを意味する。保有するソフトウェア資産の数が増えることは開発組織にとってはケイパビリティの分散につながるのであった。ここで問題になるのは、将来のケイパビリティの投資の分散を踏まえてもやるくらいに重要な開発なのかだ。 開発組織の投資判断は相対比較だと説明をした。今外部委託で開発をしようとしているものははたしてその最重要グループに入っているだろうか。ここで、冒頭の外部委託をしたいよくある背景へ戻ろう。 「外注して開発しましょう」それは通常は善意と共に、突然やってくる。 開発組織が忙しいことはわかっている。だから、手を煩わせず事業の成長をつくりたい。 内製の開発組織を持ちながらあえて外部委託して開発をしたいという場合、それは内製組織を投入して開発をしたい中心の案件ではないことが多い。 ここがもっとも重要な点になる。この記事のテーマに反して、実は重要なことは外部委託をしての開発の是非ではない。重要なのは、本当に重要だと評価をしていない施策を実行することの是非なのだ。そのため、最初に EM が聞き返すべきは「それは本当に重要なのか」「重要なのだとしたら、他の何とトレードオフで優先できるのか」であり、最初の回答は「重要なのであれば、内製組織での投資を含めてどのように実現できるかを検討する」となる。 そこで二の足を踏むような施策を無理に手を出すことは保有するソフトウェア資産が増え、将来のケイパビリティの分散へつながる。やめよう。 ここまでが原則で考えたときに EM が外部委託の相談をされたときに頭で考えることだ。もちろん、個別の事情や状況というものは存在し、この前提の上で都度考えていくことになる。 詳細のトピックについての補足 続きの記事では、よくある疑問や反論を取り上げて内製組織を投資するには至らない場合に外部委託で実現をトライするときに起きる問題について細かな補足をしていく。 たとえば、「レビューや契約でガードをすることで問題を避けることができるか」や「寿命を限定するなど、ソフトウェア資産をいずれ捨てるなら問題はないか」といったトピックについて説明をする。 最後にここまで読んでもらうとわかると思うが、外部委託で開発をすること自体に是非はない。良い開発会社とうまく開発をやっていくのなら、外部委託であってもよいソフトウェア開発をすることはできるし、そうでない場合には問題も起きるというだけの話だ。

さて、ここは自分のブログなので自分語りであれなんであれ、好きなことを書いていいのだ。なんという自由。自由は素晴らしい。その自由の前にはこれが株式会社エス・エム・エス Advent Calendar の一部 (12/18 の回) であることなど些細なことである。 2024年を迎えて2月になると、今の会社へ入社をして10年目に突入する。これまで転職が多く、長く同じところにいるイメージが少ないからだろうか、「なぜ今の会社にいるのか・続けられるのか」という質問を度々受ける。プライベートで会った知人にも聞かれるし、カジュアル面談のような場でも聞かれる。 決まって答えているのは「上司に不満がない状態でいられるから。そして、その行き着く先である経営に不満がない状態でいられるから」である (本題ではないので説明はしない。気になる人は直接聞いてください) のだが、もう少しその内訳を考えてみた。で、その中で思考様式の相性の良さというものに気づいたので、思考様式の種類について説明してみたい。 思考様式に種類があるということへ自覚的でなかったときには、それを知性 (≒知的能力) と同一視していた。知性というのは一般に有無で表され、「知性がある ( または、ない)」という扱いをするものだと考えていた。あくまでそれは知性という同じカテゴリのものの中でのレベルの違いであり、専門分野の違いによる事前知識を抜きにすれば優劣がつくものだと考えていた気がする (優劣をつけたいと思ったことはなかったと思うが、「すごいなー」と思う裏には知性の優秀さへのリスペクトがあったと思うし、何かしら人へ不満を持ったときにそれを相手の知性の不足と (今思えば安易に) 結論付けていたことは正直に言って幾度となくあったと思う)。 一般に頭の良さとされやすい情報処理能力の高さ それを顕著に感じていたのは前職のディー・エヌ・エーの在籍時で、あの会社はそれはそれは皆頭がよかった (それを私は知性が高いと感じていた)。ミーティングに30分参加をしていたとして、そのうち20分の会話が理解をするのが精一杯で、ラスト10分に自分の理解のための確認をして、ミーティング後に自身の理解不足を埋めるというようなことはざらにあった。これは別に周囲が不親切なわけでなく、とにかく会話のスピードが速いのだ。そして、その会話の一言で皆が理解するコンテキストが多い。それはコンピューターサイエンスの基礎知識であったり、社内固有の事情であったり、最新のトレンドであったり多岐にわたるが、1を聞いて20も30も文脈を含んで話が先へ進むので、理解が追いつかない。しかし、圧倒的に情報処理能力が高い人達が集まり、そんなスピードで物事が決定していくので、そこを引っ張る優秀な人たちによって尋常じゃないスピードで仕事が進んでいく。そんな会社だった。2年も居ればそのスタイルにも慣れたが、それでも自分の知性の不足を感じることが多い会社だった。 今はそれは知性の不足ではなく思考様式の違いを含んだギャップでもあったと認識ができる。「情報処理能力」と表現をしたが、あれはまさに情報処理能力の高さだった。瞬間に流れる情報に対して、そこから受け取る情報量を最大化して、それを高速に処理をして高い専門性から論理的に結論を導き出して進めていく。その処理量が多ければ多いだけ仕事は大量に進む。あのときの体験は、思考様式としては情報処理性能を重視したものだったと言える。 思考様式の3つのサンプル 今は自分の思考様式の特徴へもう少し自覚的なため、大量高速情報処理だけが思考の優秀さではないということを知っている。そして、自分の強みが別の場所にあることもわかった。ここでは、他にどんな思考様式があるのかを自分の特徴・思考の癖だと考えているものを例に挙げていこう。なお、思考様式はそれぞれ共存し得るのでどれかが近いから、他のなにかがまったくできないというようなものではない。考え方の特徴的な習慣をカテゴリーに分類しているだけだ。 問題解決型思考 問題解決型思考とはなにかというと、2023年の今でもこのエントリーを紹介するのが説明として一番しっくり来る。「圧倒的に生産性の高い人（サイエンティスト）の研究スタイル」にあるような思考様式だ。思考の特徴を安宅さんが整理しているのでそのままに並べると、 まずイシューありき 仮説ドリブン アウトプットドリブン メッセージドリブン となる。ここでとくにこの思考様式の優秀さというのが表れるのは「ちなみにこの白黒を付けるという姿勢がどの程度あるか、どのようなことに白黒つけようとするのかで、経営課題の場合、problem solverとしての質はほぼ規定される。」という文章によく表現されている。なにをイシューとみなすかという課題設定能力が優れていることが問題解決型思考の優秀さになる (この点で情報処理能力と独立している)。 この課題設定能力 (イシューの見極め) は、同じ安宅さんの HBR への寄稿「知性の核心は知覚にある」からの引用ではこのように説明されている (『イシューからはじめよ』の「よいイシューの3条件」よりも良い整理だと思う)。 イシューを見極めるということは、①答えを出すことにインパクトがあり、②答えが出せ、③明確かつ力強く人に伝えうる、問いを立てるということだ。 一つの事物からの多層的な思考 情報処理能力の高さを一つの思考様式の優秀さとするのならば、この一つの事物からの多層的な思考というのはそれとトレードオフの関係にある思考様式になる。これも言語化にあたっては安宅さんのブログから「噛みしめることを大切にしよう」の助けを借りたい。読んでもらった前提で、追加で解説をしていく。 世の中の情報を解析するステップとして、なにかを見たり体験したりしたときに、その情報を構文解析のように解釈可能な単位に分解し、意味解析をして個々へ意味づけをしていくとしたら、この思考様式は意味づけのプロセスにおける見解や選択肢の多さを特徴としている。たとえば、「チームがリリースを延期した」という一つの出来事にあたっときに、どんなことを考えるか。ぱっと考えつくところとしては、「延期の影響はどこに出るのか」「原因はなにか」「次の打ち手はなにか」「チームの受けとめ方やモチベーションはどうか」あたりだろうか。人によっては「謝罪」「防衛」などが浮かぶかもしれない。この辺は経験からの思考のパターンがあって、出てくるところだろう。 ここで多層的な思考と呼んでいる思考様式は、ここからもう一段も二段も考えを巡らせることを指している。先ほどの考えに加えて、「原因はなにか」に対してなぜなぜ分析で考えを深めていったり、「チームがリリースを延期する前に支援することはできなかったのはなぜか」「それは組織文化の問題に起因するのではないか」「組織がそのような課題を持つとしたら、なにができるか」といった方向へ考えを発展させたりする。あるいは、「リリースを延期する前にそのような不確実性を解消しておけなかったのはなぜか」「開発プランの設計でケアできなかったのはなぜか」「開発プロセスの理解はチームでそろっていたか」などプロセスとの側面で発展させることもできるだろう。同じように採用時の人材要件へ考えを発展させることもできたりする。 このように「一つの事物からの多層的な思考」はいくらでもあり得た可能性を広げることができるので、現実とつなぐためにはどこかで収束させることが必要になる。高速に情報処理をするにはトレードオフが発生する傾向はあるが、それでもこの思考様式が強い人は一つの事象から物事を理解する学習能力が強い傾向があり、使いこなすことができれば優れた特性と言える。 割りきらず複雑なままに扱う ロジカルに考えるというのは、現実をモデル化する中で情報を切り捨てる側面を持っている。そうしないと、論理的に議論をすることができないため、本来は様々なノイズを含んだ現実を単純化する。「割りきらず複雑なまま扱う思考」はそこで切り捨てるようなものも含めて、本当に評価が必要なときまではホールドしておき、極力複数の変数の相互作用による演算結果の違いが表れるのを遅延させるような思考様式だ。現実は複雑なので、なるべくそこから逃げずに考える。これもまた、情報処理能力の高さとはトレードオフの関係にある。なぜかというと、たとえば時間軸での変化の影響であったり、個人・チーム・組織・他組織といった人への計算しにくい影響であったり、そういった答えの出しにくいものを「なかったこと」にせず、常に影響しあう可能性として考え続けるからだ。そのために必要なのは脳みそのCPUでなくメモリーであり、一部の変数を変えたときの影響をシミュレーションし続けながら、最適解を探り続けるような頭の使い方が求められる。 さらに難しいのは、現実世界ではどこかでは割りきらないと (ある程度モデル化して判断において取り扱える程度に単純化しないと) 判断ができなかったり、少なくとも他者への説明ができなくなるので、複雑なままでは判断の役に立たずモデル化する必要がある点だ。脳内シミュレーションだけで終わらせず、ある程度の段階で評価をしてやる必要がある。その意味で、遅延評価的だ。 思考様式の種類は自身の価値観や気持ちよさに大きく影響している ここまでで、情報処理型と3つのサンプルで合わせて4つの思考様式を説明してみた。私が言語化できていないだけで、他にも様々な思考様式があるはずだ。これらはあくまで思考の特徴であって、どれかだけを使っているということはなく、組み合わせて思考をしている。ここで重要なのは、これらの思考様式の違いに人による得意不得意があり、それは能力や技術に依存をしていることに加えて、自身の価値観や気持ちよさにも大きく影響をしているという点だ。 冒頭の「なぜ今の会社にいるのか・続けられるのか」の話で言えば、私は現職のエス・エム・エスの思考様式と相性がよかったと感じている。これまで自身でもあまり自覚していなかった思考的な特徴を「良いもの」として評価してくれたのは、この会社が初めてだった (というか、思考的な特徴を良いにしろ悪いにしろ、言及されたこと自体も初だった)。思考様式は生来の習慣である場合もあるし、価値観から選択し身につけたものである場合もあるが、それが環境によっても後押しをされるというのは良い体験だった。 世の中に求められる思考様式の種類は画一的ではない 人やチーム、会社のような組織として見たときに、同質性が高いほうが働きやすさにもつながるし、一方で多様性はその組織の選択肢の多さになるので強さにもつながる。この思考様式の違いにおける自身のやりやすさや気持ちよさ、価値観からどういった組織へ所属すると快適かというのが違ってくるということを知っておくだけで、少し人生が過ごしやすくなる。思考様式の違いでもトレードオフという言葉が何度か出現している通り、思考様式はあくまで特徴の違いであって、どれかが最強の思考というようなものではない。解こうとしている問題や局面によって適した思考様式は違ってくる。違いがあるということを知ること。そして、自身の特徴にあった場がきっとどこかにあるということを知っておくことは、様々な場面で選択肢を広げることになると思う。

個人の Wiki に 2009 年に参加したトークセッションのメモ書きが残っていた。2019年の今読むとまた面白いのでブログの記事として公開してみる。トークセッション自体は 2009 年に行われたものだ。 パターン、Wiki、XP ーー 時を超えた創造の原則 20090710:トークセッション「時を超えた創造の原則」参加報告。 『パターン、Wiki、XP』という本の刊行を記念したトークセッションへ参加してきました。これらの源流に建築家クリストファー・アレグザンダーの思想と思考と哲学を見出し、ソフトウェア開発との接点を探るという内容でした。 構成は 『パターン、Wiki、XP』の概要説明 (江渡浩一郎さん) XP とアレグザンダーについてのトークセッション (かくたにさん、懸田さん) の二部構成。 『パターン、Wiki、XP』について。 Wiki qwikweb の開発者 機能拡張をするときに機能を追加したのに悪くなることがある.なぜだろう？と考えた Wiki の本質を強化する機能は良い機能である しかし Wiki の本質って何ですか？ パターン デザインパターンで何だろう？ アレグザンダーのパターンランゲージを元にしたと紹介されるけど、全然違う 一番最初のパターンの論文 (ケント・ベックとワード・カニンハムの書いた論文) を読んでみた。おもしろい！ そこにあった言葉。「コンピュータユーザーは自分自身のプログラムを書くべきなのである」 つまり、本来目指したのは「使う人間のためのパターン」 使う人間が自分のほしいものを表現し実現するためのパターンランゲージを志向していた。 XP クライアントと開発現場の関係を根本から見直す必要がある オンサイト顧客のような開発に参加するクライアントという関係を築くためには、いついつまでに何を作りますよ。それで支払はいくら発生しますよ。というコミットメントの関係ではむずかしい。 その関係性自体を変えるよう切り込まないと本質的な解決にならない Wiki, XP, パターンはあるものでつながっている。それは問題意識。顧客との関係性という問題意識でつながっている。Wiki はパターンや XP の土台になるもの。 クリストファー・アレグザンダー 初期と後期で全然言っていることが違う 「形の合成に関するノート」(1964) デザインするという行為を数学的な問題に落とし込む 「都市はツリーではない」(1965) 自然都市と人工都市の二項対立 「オレゴン大学の実験」(1975) 利用者参加の建築へ舵を切る 「パターンランゲージ」(1977) 建築は要求条件が多すぎてデザインしきれない 利用者が建築の設計を自分たちで参加できないか 「時を超えた建築の道」(1979) パターンランゲージの背景を解説した理論書 「無名の質」 自然都市に表れるような言葉で表現できないけれど何かよいというような質 形を科学することの本質的困難性 量や長さを科学することは比較的たやすい 一方、形を科学することはむずかしい 中谷宇吉郎「科学の方法」(1958) 雪の結晶(という形)を科学した人 パターンは形を科学の対象とすることに挑戦している。(形の要求の再現性にトライしているという意味。) トークセッション。テーマはXPとソフトウェア開発。 パターンに「それに従えば成功する正解の型」というイメージがついてしまった。

『オブジェクト指向入門』という本がある。今は第2版が出版されていて、原則・コンセプトをテーマにしたものと方法論・実践をテーマにした二分冊になっている。この本はオブジェクト指向によるソフトウェア構築 (Object-Oriented Software Construction) とはなにかについて、緻密に基礎の基礎から話を積み上げ、その全体像を描き出す他にない名著だ。ぼくはまつもとゆきひろさんが推薦する本として最優先に挙げていたのを見て当時出ていた第一版の翻訳を買って読んだ。 最近になって必要があって読み返して驚いたのだけど、今でも自分の設計の指針となっているベースはとことんこの本の内容だった。技法ではなく、設計をするというときに考える思考の観点はこの本からもらったもので、その観点を実現するにはどんなことを理解し考えないといけないかをその後学んで実践し続けてきたのだということに気付くことができた。ソフトウェアを設計するということができるようになるために、方法論を理解しその実践を通して設計ができている状態を目指しているような人にこそ読んでみてほしい本だ。 この本は丁寧に理論が構築されているので、いきなり美味しいところから入ったりはしない。最初はソフトウェアの品質から始まる。 工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。 自分の設計の指針となっているベースと書いた内容は第 3 章にある。ここでは、モジュール性をテーマにその 5 つの基準 (criteria)、5 つの規則 (rule)、そして 5 つの原則 (principle) が説明される。 5 つの基準 基準は「モジュール性がある」と呼ぶときに満たしている必要がある基準を挙げている。 分解しやすさ (Decomposability) 組み合わせやすさ (Composability) 分かりやすさ (Understandability) 連続性 (Continuity) 保護性 (Protection) 5 つの規則 これらを保証するために守らなければならない 5 つの規則というのが規則として挙げられているもので、これが「設計の指針となるベース」として設計のことを考えるときに常に頭の中で考えている観点そのものだった。 直接的な写像 (Direct Mapping) 少ないインタフェース (Few Interfaces) 小さいインタフェース (弱い結び付き) (Small Interfaces (weak coupling)) 明示的なインタフェース (Explicit Interfaces) 情報隠蔽 (Information Hiding) 直接的な写像 ソフトウェアシステムというものは何らかの問題領域の必要に対処しようとする。ある問題領域を記述する良いモデルがある場合、ソフトウェアによって提供される解決手法の構造と、モデルとして表現される問題の構造の間の写像 (マッピング) を、明快に保つことが望ましいことに気づくはずだ。このことから次の第 1 の規則が導き出される。 『ソフトウェアシステムの構築過程で考案されたモジュール構造は、それに先立つ問題領域のモデル化の過程で考案された任意のモジュール構造との互換性を維持していなければならない。』 少ないインタフェース 少ないインタフェースという規則により、ソフトウェアアーキテクチャに含まれるモジュール間の通信チャンネルの全体数を限定することができる。 『すべてのモジュールができる限り少ない数のモジュールとの通信で済むようにすべきである。』 通信はモジュールの間でさまざまな方法で発生する。モジュール同士が呼び合う (それらがプロシージャの場合) こともあるし、データ構造を共有することなどもある。少ないインタフェースの規則は、このような接続の数を限定する。

Ruby で自分のための問題を解決していく話 (個人の Wiki を esa に移行した話) の続き。前回は文章とコードでの説明ばかりになってしまったので全体的にやっていることを図にしてみた。 <a href="/images/articles/purkiwiki2esa.svg" rel="noopener" target="_blank">PukiWikiをesaへ移行する流れ</a> 作戦としては、 一連の PukiWiki のファイルはローカルに置いて失敗があれば最初からやりなおせるようにする esa の記事作成以外は繰り返し実行可能にする Markdown の変換で PukiWiki と esa の仕様の差分を吸収できるようにがんばる 最終結果を esa 上で確認し、意図しない表示になっているものは Markdown の変換からやりなおして差分が出た記事について esa へ更新をかける という流れで、実行制限のある esa の API 呼び出しを最小限にしつつ、Wiki 内のページリンクなど PukiWiki 資産を最大限に活かせる形を考えた。実際はここまで全部最初から考えてやったわけではなくて、やりながらやっぱり Wiki 内のページへのリンクも有効にしたいなとか #ls もただ機能をつぶすのじゃなくて活用したいなとか考えては実装し、そして再度手順を実行し、という繰り返しだったのでやりなおせる構成にしたのは正解だった。 ここからは esa への新規投稿による記事 URI 確定と、二度目に Wiki 内リンクを解消した更新をかける流れを説明し、最後に繰り返し修正と更新を繰り返す中でどんな PukiWiki の仕様で引っかかったかとその対処を説明する。

はじめに 遅くても 2008 年ごろから使っている個人の Wiki があって、調べたことや頻繁に探すことをメモしたりして使ってきた。当時職場で使っていたのが PukiWiki で使い慣れていたという理由だけで使い始めた PukiWiki をそろそろさすがに別のものにしたいなと感じていたので esa に移行をした。そのときに考えたことやこうやって移行をしたという記録。移行対象となった PukiWiki のバージョンは 1.5.0 のため、以後の各仕様は v1.5.0 のものになっている。 最初に考えたこと まずなにはなくとも PukiWiki 記法を Markdown にする必要がある。それから自分の用途としてダウンロードした各種スライドを添付していて、中にはすでに WWW 上では見つけられないものもあるので添付ファイルを完全に移行したい。そこまでどうにかできればあとは互換性のない移行をあきらめることでどうにかなるだろう。 と、まあ、あまり細かいことは考えずに始めた。 PukiWiki 記法を解釈して Markdown に変換する 検索すると正規表現を使ってごりごりと変換していくサンプルはいくつか見つかったのだが、自分でこれを修正しながら互換性を上げていく土台としてはきついなというものが多かった。そこで、パーサジェネレータを使ってみたかったという興味もあり、Parslet で PEG スタイルのパーサを書いてみることにした。 Parslet のパース結果はツリーで Array として返され、Hash が入ってる。Hash は Symbol と Parslet::Slice でできてる。Parslet::Slice は出自の位置をもった String みたいなもの。to_s をすると文字列を取り出せる。 {:toc=>"#contents"@0} #=> [Symbol, :toc] [Parslet::Slice, "#contents"@0] 実装進めるにあたっては、他の実装を参考にするのが一番イメージがつかみやすかった。 https://github.com/kschiess/parslet/tree/master/example frsyuki さんの MessagePack パーサの実装 できあがった実装が pukiwiki2md として公開されている。この Gem を使うと、Parslet に則って、Parser#parse でパースし、その結果を Transform#apply で Markdown へと変換することができる。 parser = Pukiwiki2md::Parser.new transform = Pukiwiki2md::Transform.new tree = parser.parse(wiki_text) markdown_text = transform.apply(tree) テストを書きながら、ある程度できあがったところで実際の自分の Wiki のテキストに対して適用して、正しく変換ができなかったものを修正しつつ、という形で開発をしていった。

Pukiwiki2md を公開するときに README.md にバッジを貼りたかったのでよいかんじの Coveralls の導入を調べたのでそのメモ書き。 手元ではすでに SimpleCov を使っているし、あまりプロダクトのコードへ干渉されるのはうれしくない。そこで Ruby on Rails の導入に書いてある Rake task として導入する方法を使ってみる。 今回は gem だったから pukiwiki2md.gemspec へ追加したけれど、通常だと Gemfile へ coveralls gem を追加することになる。 gem 'coveralls', require: false 今回、CI は TravisCI を使う。.converalls.yml ファイルへ次のように記入する。 service_name: travis-ci test_helper を汚したり、普段使わない Coveralls が呼ばれるのは気持ち悪いので Rakefile に Minitest の test タスクへの依存関係を追加して必要なときに明示的に coveralls を使うようにする (Rake task レベルでの依存も気持ち悪ければ別ファイルで用意すればいいのだけど、今回はそこまではしなかった)。 require 'coveralls/rake/task' Coveralls::RakeTask.new task :test_with_coveralls => [:test, 'coveralls:push'] .travis.yml で Travis で CI 時には Coveralls を呼び出すようにする。 script: bundle exec rake test_with_coveralls ちなみに、Rakefile の全体はこんなかんじ。

(時間の)95%は企業がしっかりとその計画を遂行できるようにすること CEO と成長の苦しみ - Sam Altman とのインタビューを読んだ。全体にとても納得感があり、自分の感じるものと近いところの多いインタビューだった。 Sam Altman CEOという役職に求められるのは、企業が何をすべきかを見極めること、そして実際に企業がそれを行動に移すようにすること、基本的にはこの2点です。 (略) Sam Altman この難しい部分は、多くの人たちが最初にやるべき部分、つまり会社が何をすべきなのかを見極めることです。しかし実践において、時間的にはこの仕事は5%に過ぎず、残りの95%は企業がしっかりとその計画を遂行できるようにすることだと思います。ですが、こういう風に計画を確実にこなせるようにするというのは、要するに信じられないほどの繰り返しの作業なので、ほとんどのCEOにとっては面倒で厄介なことです。 そのためには従業員やプレスや取引先と何度も何度も同じやり取りをする必要があります。「私たちは今これをしている、これが理由だ、そしてこれがそのやり方だ」と繰り返し言うことになります。コミュニケーションを取り、企業のビジョンとゴールをエバンジェライズしていくこと。これこそがCEOが一番多くの時間を割いて取り組むべき仕事です。 『経営は「実行」』という本があって、英題はそのものずばり “Execution” というのだけど、今いる会社はこれを非常に重視していて、戦略とその実行というのが経営を支える屋台骨になっている。会社としての仕組みもそれを維持するために設計されていて、全社がそれで動いている。入社して最初に見たときにはこんな会社があるのかと心底驚いた。 今の自分はその会社では経営と近い立場で思考や実行をするべき役割をしていて、ただ一方で「開発は実行」と割りきってスピードと実行力だけを重視するというのは今まで自分が見てきた開発の実情と合わない部分があるなと感じ、じゃあはたしてなにを大切にするのがよいのだろうと考えながら働いてる。 その中で、フローの仕事だと目の前の流れる仕事の成果を最大化することを一番重視すると大体結果と「それははたしてよいことだったのか」というものが相関しやすいのだけど、ソフトウェア開発という仕事は少し特性が違っていて、開発という活動の結果はソフトウェアとして蓄積され、それが良いほうにも悪いほうにも将来に影響を与えるストック型の仕事だという理解が今の自分の理解になっている。 そして、Web のサービスとして提供し続けていくというのは時間の変化の中で提供をし続けていくことで、それをするためのチームやプロセスというのが必要になってくる。ソフトウェアの性質に引っ張られて、このチームやプロセスを維持する活動もストック型の性質になり、ただ「つくる」ということからイメージされるのとはやや違った価値観が必要になってくると考えている。 Talkin’ ‘bout my “Execution” さて、“Execution” だがこの大事さは理解しつつ、自分はこれが非常に苦手だ。「実現とそのための工夫」は好きだ。開発者なのでむしろそこには喜びを感じる。でもこの「実行」ってやつときたら、もっとつまらないもので、率直にいって創造性が少なくただやるべきことをやる 。それだけだ。それだけのことが多くの人ができないので、重要なのだ。 やることを決める。誰がやるか決める。いつまでにやるか決める。やったかどうかを追いかける。やっていなかったら実現するにはなにが必要か、実現されるまでフォローし続ける。 たったこれだけのことではある。でもやれない。人に嫌がられることもあるし、面倒になって手を抜きたくなるときもある。 以前いっしょに働いていた中にこれがとても得意だった同僚がいた。彼らは会議の場でも状況を聞くのだけど、折にふれてあちこちの場面で声をかけていた。席に来て、「あの件なんだけどどうなってる？」「ほんとに？　どうもありがとう」「忙しいところ悪いんだけどさ、でもやっぱりどうしても大事なやつだからさ。よろしくね」「そこで困ってるんだったら協力してもらえないか聞いてみるよ」こんな言葉をかけて嫌らしさを感じさせずに物事を進行させていく名人だった。いつも「いや、ほんと悪いね」と言っていた。 割込されるのは嫌なものだ。だから、アジャイルの開発プロセスではこういったものが解決されるための仕組みというのをいろいろな場面でつくっている。でもあちこちでプロジェクトを見ていて、この “Execution” が弱いなと思う場面が多かった。プロセスの問題ではなくてそこで働く人たちの前提に置いているものだったりに左右される部分が大きいのだろう。同じプロセスで働いていても、この実行をするようにうながす役割を誰かがしてくれるだけで断然結果の出方とスピードが違ってくる。 この実行を支えるための一言はナッジングという呼び名もついているらしい。HIGH OUTPUT MANAGEMENT でアンディ・グローブも nudge することの重要性を書いていた。振る舞い方を間違うと嫌なマネージャーに見えがちな仕事だけれど、かつての同僚を見習って上手に nudge する人でいたい。

文字列からリンクで開いて次のページへ進むというのが必要な場面で文字列が空のためリンクがクリックできず、意図した動作ができないというバグがあった。 実装をそのまま修正すると、 if name.present? link_to name, some_path(object) else link_to another_name, some_path(object) end てなかんじで、起きたバグに対処するように直す。 でも、自分で開発しているときはこういうのは不安があって、そもそも name が空文字や nil だというのも自分が想定してなかったからバグが出ている。 どうせ修正をするなら、ここでけして同じ種類の問題が起きないように直したい。 ということで、こんな風に直す。 name_candidates = [name, another_name, 'fallback name'] visible_name = name_candidates.find {|n| n.to_s.length > 0 } link_to visible_name, some_path(object) ここでの問題は実装上は present? かどうかというものだったけれど、意味上は空文字列だと表示がされずリンクが有効に働かないということ。なので、その問題を解消するようなコードにしておく。 これで、絶対に同種の問題は起きない修正になったと安心できる。 「fallback name となってしまうケースがそのまま表示され次に進めていいのか」というのはまた別の問題としてあって、それをケアするのならまた別のそれに適した場所で対応をしてやるといい。 細かい話ではあるんだけど、わりと「実装上のつじつまはあってる」というコードで push されているコードをよくみるので書いてみた。