@ledsun blog

無味の味は佳境に入らざればすなわち知れず

Node.jsでつくるNode.js その1

ledsun.hatenablog.com

の続きです。Node.jsで動くJavaScriptインタプリタを実装しようとする試みです。

作戦

  • パーサにはEsprimaを使う
  • TDD的なスモールスタート戦略で進める(最初はセルフホスティングを意識しない)

下調べ

EsprimaがどのようなASTを返すか確認します。

準備

Esprimaをインストールします。

npm init -y
npm install esprima

ASTを見る

REPLでパース結果を確認します。

nodeコマンドでREPLを起動し

~ node
> const esprima = require('esprima')
undefined
> const util = require('util')
undefined
> console.log(util.inspect(esprima.parse('1 + 1'), false, null))
Script {
  type: 'Program',
  body:
   [ ExpressionStatement {
       type: 'ExpressionStatement',
       expression:
        BinaryExpression {
          type: 'BinaryExpression',
          operator: '+',
          left: Literal { type: 'Literal', value: 1, raw: '1' },
          right: Literal { type: 'Literal', value: 1, raw: '1' } } } ],
  sourceType: 'script' }
undefined

木構造JSONが帰ってきます。

1 + 1を実行する

const esprima = require('esprima')
const util = require('util')

console.assert(test('1 + 1') === 2)

function test(expresssion) {
  const parsed = esprima.parse(expresssion)

  console.log(util.inspect(parsed, false, null))

  const body = parsed.body
  for (const statement of body) {
    return evaluate(statement)
  }
}

function evaluate(statement) {
  switch (statement.type) {
    case 'ExpressionStatement':
      switch (statement.expression.type) {
        case 'BinaryExpression':
          switch (statement.expression.operator) {
            case '+':
              let left;
              if (statement.expression.left.type === 'Literal') {
                left = statement.expression.left.value
              } else {
                console.log(`unknown type ${statement.expression.left.type}`);
              }
              let right;
              if (statement.expression.right.type === 'Literal') {
                right = statement.expression.right.value
              } else {
                console.log(`unknown type ${statement.expression.right.type}`);
              }
              return left + right
              break;
            default:
              console.log(`unknown operator ${statement.expression.operator}`);
          }
          break;
        default:
          console.log(`unknown expression ${statement.expression}`);
      }
      break;
    default:
      console.log(`unknown type ${statement.type}`);
  }
}
  • console.assertを使って実行結果を評価
  • ASTを表示(見ながら実装を進めたい)
  • test関数でスクリプトを実行
  • evaluate関数で文を実行(「RubyでつくるRuby」の最終形に引きづられた、evaluateStatementがベター?)
  • for ofもTemplate literalも使う(現時点でセルフホスティングは考えない)
  • 二項分岐なのにswitchを使った(「RubyでつくるRuby」の最終形に引きづられた、ifで十分)
  • ;有無は統一していない(普段は無し派、ESLintの助けが必要)

実行すると

~ node .
Script {
  type: 'Program',
  body:
   [ ExpressionStatement {
       type: 'ExpressionStatement',
       expression:
        BinaryExpression {
          type: 'BinaryExpression',
          operator: '+',
          left: Literal { type: 'Literal', value: 1, raw: '1' },
          right: Literal { type: 'Literal', value: 1, raw: '1' } } } ],
  sourceType: 'script' }

ASTを表示するだけです。 結果が間違っているときは、console.assertで引っかかってAssertionErrorがでます。

とりあえずここまでです。 次は対応するoperator(-, *, /)を増やします。

RubyでつくるRuby 読書感想文

どんな本?

f:id:ledsun:20170908114109p:plain

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門(紙書籍)www.lambdanote.com

言語処理系の実装を体験するための本。 言語処理系の実装はパーサの実装が面倒臭くて、大抵の人はそこで力尽きます。 そこで、パーサは著者の方が用意しておいて、構文木の解釈だけを読者が実装するスタイルです。

ところで著者の方は

の著者で

の訳者で

regional.rubykaigi.org

NESファミコン)のエミュレータruby で書いた、Rubyハッカーの方です。 さらに

『Ruby で学ぶ Ruby』非公式あとがき - まめめも

個人的に盛り上がってきたので、そこから 1 週間で全 8 回(当時)の原稿をすべて書き上げました

130ページの本の第1稿を1週間で書いたとか、ちょっと意味わかんないです・・・(汗

どんな縁?

咳マニアなので、Tochigi RubyKaigi 07 に参加しました。 そこで「RubyでつくるRuby」読書会があったので、読み始めました。

サインももらえました!やったね!!

何をした?

一通り読んだ後に、インタプリタソースコードの最終形を写経して動かしてみました。 120行に満たないRubyソースコードを打ち込んだだけで、インタプリタが動いた!すごい!(そういう趣旨の本です)

淡々と条件分岐を打ち込んでいくのは、正直、面倒臭い作業でした。 パーサ部分を実装していないのに、この面倒臭さ!言語処理系の実装は大変ですね。

既存のRubyソースコードをいくつか試したら、動かないものもありました。 たとえばArray#starts_withを使っているソースコードです。 組み込みライブラリが入っていないので当然ですね。 まともに言語処理系を作るには、パーサ加えて、組み込みライブラリも必要です。 ますます大変ですね。

最終形を写経するだけでは、どういうことを考えながら判断しながら言語処理系を実装していくのかは、あまり理解できませんでした。 もうちょっとゆっくり、手順を守って実装してみたほうが良いかもしれません。

次に何をしてみる?

JavaScriptで同じようなことをしてみようと考えると、JavaScript界ではASTの定義やパーサライブラリは整っています。

efcl.info

Esprimaで作ったASTを使ってJavaScript(のサブセットの)インタプリタを実装すれば、言語処理系実装への理解がもうちょっと進みそうです。

Mac の言語設定を英語にした時のGoogle Chromeのフォント設定

OSの言語設定を英語に

qiita.com

OSの言語設定を英語に変更しましょう

に触発されて、言語設定を英語にします。

Google Chromeの言語設定

Change Chrome languages & translate webpages - Computer - Google Chrome Help

Chrome ブラウザの言語を変更する(WindowsChromebook のみ)

MacGoogle ChromeはOSと異なる言語設定はできません。 これ自体は困りません。

Google Chromeは言語設定が変わるとフォント設定がかわります。 標準フォントがTimesになります。 フォント設定が無いWebページを見ると少し違和感があります。

Google Chromeのフォント設定

requlog.com

を参考にして、日本語のフォントを設定します。

f:id:ledsun:20170629103928p:plain

  • Standard font: Hiragino Kaku Gathic ProN
  • Serif font: Hiragino Mincho ProN
  • Sans-serif font: Hiragino Kaku Gathic ProN
  • Fixed-width font: Osaka

リーダーシップ理論

リーダーシップに関する情報を調べた記録です。

luccafort.hatenablog.com

はてなブックマーク

リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ - おうさまのみみはロバのみみ

これははるか昔に作られたリーダーシップ理論の基礎では。「リーダーシップ理論」でググるといっぱい出るよ

2017/06/12 04:08
b.hatena.ne.jp

というのを見つけました。 ググって

リーダーシップ理論の流れと リーダーシップの実践的開発方法(PDF) を見つけました。

参考図書で

が、上がっていました。 以上です。

失敗プロジェクトの弔い方

プロジェクトを燃やした経験から、どうすれば有効なふりかえりができるのか考えてみました。

要約

  1. 失敗プロジェクト参加者の信用を回復
  2. 失敗プロジェクトの撤退戦術を共有
  3. 失敗プロジェクトの回避方法を検討

背景

を見て考えました。 外野から見たら、確かにまったくこう見えると思います。 なぜ、傷口を抉るようなことをするなと言いたい「気持ち」になるのでしょうか?

失敗プロジェクトの当事者の立場

外野も嫌がらせや、憎くしみででやってはいません。 わかってはいます。 ただ、原則として、デスマ中は前門の客、後門の同僚、両方から打たれている状態です。 その直後に、罰しないから「失敗ポイントを明確にしてふりかえろう」と言われても、信用できません。

外野の方たちは、本当に辛い場面で後ろから殴ってた人たちです。 ふりかえりに参加している特定個人が本当に殴っていたかはあまり関係ありません。 社内の誰か一人でも殴っていれば、「ふりかえりの参加者も殴りに参加していた」と疑うのが人間の心理です。 一度疑えば、「ふりかえりで殴りネタを探している」と疑うのが人間です。

本当に「ふりかえりで殴りネタを探している」かは問題ではありません。 傷ついていて、疑う心理状態にあるのが問題です。

「そんな傷口を抉るようなことするな」と怒られ

は、こうした背景を意識した反応だったようにも思えます。

ご提案

「失敗」とつけない

最初に「失敗プロジェクト」という認識自体を改めましょう。 なぜ「失敗」とつけたのでしょうか? 外野からでも

  • プロジェクトの進行が、当初聞いていた予定より0.5倍以上伸びている
  • プロジェクト参加者の平均残業時間が長い

といった情報が観測できると思います。 もう少し詳しい情報を知っていれば

  • 売上をコストが超過した
  • メンバーが逃亡した
  • 納品できず、損害賠償請求を受けた

という情報を知っているかもしれません。

これらの現象のどの段階で「失敗」とつけるべきでしょうか?

「失敗」と名付けると、プロジェクトとプロジェクト参加者が批判されます。 批判には「正当な批判」もありますが、誤解に基づく「誤った批判」もあります。 批判にはコントロールが必要です。 コントロールされない批判が増えると、吊るし上げになります。 雑談における批判は、多くの場合コントロールできません。 結果として「誤った批判」が増え、「プロジェクト参加者を吊るし上げてよい」空気が生まれます。

私の観測範囲では、吊るし上げられた人間に、批判と自分を分離する圧倒的メンタルタフネスがない場合は、退職することが多いです。 万が一退職された場合、組織を維持するためには、欠員を埋める分の採用コストと教育コストが必要です。 プロジェクトに「失敗」とつけることには退職者を生むリスクがあります。 現実のコストにつながるリスクです。

「失敗」を禁止すると、別の悪い名前がつきます。 「失敗プロジェクト」には別のポジティブな呼び名をつけましょう。

奇跡の生還プロジェクト

(例えば)「奇跡の生還プロジェクト」と呼びましょう。

「奇跡の生還プロジェクト」のふりかえりでは生還方法を学びましょう。

炎上プロジェクトから生還した人は、少なくとも「困難な状況で逃げない」という特性がひとつ以上の事例で証明されています。 どんな過酷な状況でも生き残る「生還者(リターニングマン)」かもしれません。

この特性は、先天的なものでしょうか? 後天的な要素はないでしょうか? もしあるならば共有する価値があります。

同様の、困難であることがわかっていても、やり遂げなければいけない状況では、使いやすい人材です。 また、開発者には、自身の努力と関係ない部分で「奇跡の生還プロジェクト」に巻き込まれるリスクがあります。

「奇跡の生還プロジェクト」に巻き込まれるリスク

「炎上しはじめたプロジェクトからは全力で逃げる」を貫けると個人の幸せは得られるかもしれません。 ただ、そう強い人間ばかりでもありません。

  • 受注時にリスクを低く見積もっていた
  • 受注後に追加要望が現れた、しかし政治力によって拒否できない
  • すでに炎上しているプロジェクトに助けに入った

のような状況では、多くの人は「奇跡の生還プロジェクト」から逃れるのは難しいでしょう。 「奇跡の生還プロジェクト」に巻き込まれたときに、生還するためのプラクティスを聞いておくのは、いつか役に立ってしまうかもしれません。

奇跡の生還プロジェクトに遭わないようにする

もちろん「奇跡の生還プロジェクト」の芽をみつけ、事前に潰して回るのが至上です。 もしかすると多くの開発の現場では、早すぎる願いなのかもしれません。 残念ながら

デメリット

「奇跡の生還プロジェクト」として扱うことにデメリットはないのでしょうか?

アドレナリンジャンキー問題

当然考えるのが、「奇跡の生還プロジェクト」として褒め称えられなら、最初から炎上させようと考える人間が現れることです。 炎上している時に生きている実感を感じる人間もいます。 そういう人は早めに検出して、「奇跡の生還プロジェクト」の助っ人要員にしましょう。 プロジェクトの立ち上げからは外しましょう。 お互いのためです。

潜在的な問題

ところで「失敗プロジェクト」として吊るし上げられて辞めない人間はどのような人でしょうか?

批判を受けても、ものともしない人間です。 このような人物は、ふりかえりで得た改善案を実践するでしょうか?

また、次の仕事にあてがなければ、なかなか辞められません。

とすると「失敗プロジェクト」などのネガティブな名前付けを放置しておくと 「アドバイスを聞かない頑固者」「つぶしの効かない偏った技術者」を選別して 会社に残すバイアスが働きそうな気がします。

10年後にはどうなっているのでしょうか? 興味深い思考実験です。

おまけコンテンツ

後門から刺される例

外野経験

とは言っても、自分が外野だった時は「いつまでやってんの?早く終わらしてよ」と思っていました。 人間、その立場になってみないとわからないことがあるようです。

IoTゲートウェイのモデリング

用語

  • 機器:HTTP/HTTPSな環境から操作する機器
  • 機器種別:機器の種類。例、エアコン、照明、etc。あるいはエアコンもメーカによって異なる機種種別として扱う必要があるかもしれません。

要件

現在のIoTでは機器種別によって、ネットワークを介した操作方法が異なります。 機器種別によっては直接HTTP/HTTPSの世界と接続できないことがあります。

例えば6LoWPANという規格でつながっているかもしれません。 IoT規格 6LoWPANとは? | IoT

IoT機器を制御するWebアプリケーションを作るには、HTTP/HTTPSの世界につなぐゲートウェイが必要です。 RESTful APIでIoT機器を制御できれば、Webアプリケーションエンジニアにアプリケーション作成環境を提供できるでしょう。

モデリング

IoTゲートウェイでは、原則として、機器種別に応じて変わる情報をロジックで実装します。 機器の設定変更に応じて変える情報はDBに保持します。 大きく次の3つのモデルに分けます。

  • Deviceクラス
  • Profileクラス
  • Clientクラス

これらのクラスはWebMVCの分類では、いずれもModelです。 ここではViewやControllerに関する設計は扱いません。

Device

Deviceは機器操作ロジックを担当します。

  • 対象機器と通信相手のマッチング
  • RESTful APIのパラメータを機器向けのパラメータに変換
  • 複数リクエストが必要なシーケンスの管理

操作したい機器と通信相手が1:1とは限りません。 1つの通信相手が複数の機器を管理していることがあります。 この関係性は静的な情報です。ロジックとして実装します。

機器がJSONでのリクエストを受け入れない場合は、JSON以外の異なるフォーマットに変換する必要があります。 ゲートウェイのRESTful APIは、人間が読めるパラメータが望ましいです。 機器が16進数文字列を要求する場合、変換して送る必要があります。

1つのRESTful APIリクエストに対して、機器に複数のリクエストが送る必要がある場合、 それらのシーケンスはここで実装します。

DeviceはProfileとClientを持ち(に依存し)ます。

Profile

Profileクラスは機器の情報を持ちます。 代表的なものに次があります。

  • 名前
  • 機器種別
  • 位置情報
  • 接続情報

ロジックとしては、検索ロジックを担当します。 ProfileクラスはDBのレコードと対応しています。 Active Recordパターンを使うのに適しています。 Ruby on RailsであればActiveRecordやApplicationRecordを継承したクラスとして実装します。

機器種別ごとの拡張が必要な場合は機種別のSubProfileクラスを作ります。 例えば、機器種別ごとに接続方式が異なる場合は次のように情報を持ち分けます。

  • Profile
    • 名前
    • 位置情報
    • 機種種別
  • SubProfile
    • 接続情報

ProfileクラスとSubProfileクラスには継承関係は持たせません。 DeviceがProfileインスタンスとSubProfileインスタンスを持ち、適宜使い分けます。

想定外の新しい機種種別を追加した際に、Proflieには影響を与えたくありません。 1:1関係のテーブルに分けます。

関連付けにはidを使います。 外部との接続性を重視した場合は、idにUcodeを使うかもしれません。 Ucode | IoT

Client

Clientは機器との通信を担当します。 原則として状態は持ちません。 通信状態は持ちますが、通常はHTTPClientなどの別のクラスに移譲しているでしょう。

機器がHTTP/HTTPSで通信できれば、特に難しいことはありません。 リクエス送信先を整形し、リクエストボディを整形し、リクエストを投げるだけです。 ロジックと言っても、せいぜい通信エラーを例外で抽象化するぐらいです。

Clientを別クラスに分ける最大の効果はユニットテストの書きやすさにあります。 Deviceのテストコードを書く際に、ClientのインターフェースにあわせたMockに置き換えることができます。 Deviceは比較的複雑なロジックを持っているので、ユニットテストで品質を確保します。

IoTではエンドツーエンド試験環境を作るために、機器を用意する必要があります。 機器とゲートウェイの製造が並行している場合は、試験が開発期限ギリギリまで行えないことがあります。 事前にユニットテストでテストしておきたいところです

アプリケーションレベルの分割戦術

エアコンと言ってもメーカごとに接続方法や操作方法が異なります。

ここで扱ったHTTP/HTTPS世界とのゲートウェイの他にもう1つ エアコンを抽象化するゲートウェイを用意すると、分業しやすくなるでしょう。

技術書典2にサークル参加しました #技術書典

サマリ

  • 謎のモチベーションの高まりにより技術同人誌を書いた
  • 30部が1.5時間ではけた
  • Re:VIEWで書いた
  • 想定読者が勉強会の発表より広いのはおもしろい

書いたこと

デバッグ最速理論」という薄い本を書きました。 最終的に表紙と奥付、裏表紙等を合わせて16ページになりました。 原稿はこんなです。

当初の野望は

  • カラー表紙
  • 32ページ
  • オフセット(?)印刷

でした。 3月の執筆時間が思っていたより取れなかったので、執筆時間をギリギリまで稼ぐためにコピー本に倒しました。 深夜に、コピー機でガッションガッション印刷して、ホッチキスでバッチンバッチン留めて作りました。 「デバッグ最速理論」自体は、今のところ16ページで十分表現できています。 もうちょっとデバッグ初心者や非技術者に間口を広げようと思ったら、ページ数を増やして 導入章を増やしたり、図表を増やした方がいい気はします。

部数について

30部用意して、一時間半ではけました。

今みたら被チェック数が30を大幅に超えていたので、もっと用意しておけばよかったです。 f:id:ledsun:20170417193415p:plain

営業時間は6時間あったので、単純計算でも100部はけた可能性があります。 一般参加者は3100人だったそうです。1%の人しか手に入れられないのはちょっと寂しい気がします。

雨の中、3100人の参加者って、雨降ってなかったら一体どういうことになっていたのか恐ろしいです・・・

皮算用

次の機会があれば100部用意しても良いかもしれません。 ただ、一人サークルのワンオペなので、100部売るのは体力的に辛いです。

200円だから売れた面もあると思うので、ページ数が増えたり、印刷所使ったりで単価が上がればそんなに部数はいらなさそうです。 加筆&印刷で単価が1000円で60部とか?

Re:VIEWについて

techbookfest.connpass.com

に参加してざっくり把握したので、Re:VIEWで書きました。 記法としてはMarkdownと大差がないので大して苦労はありませんでした。

vvakame/docker-reviewを使って簡単にPDFにできました。 余談:tklx/base使えばコンテナを軽量化できるか試しました。

! LaTeX Error: File `xcolor.sty' not found.

と、エラーが出てダメでした。

自分の書いた文章が技術書っぽい体裁で読めるのはちょっとした感動でした。

一方で組版部分のlatexの知識がなく、手も足も出ないのには苦労しました。 任意の場所で改行を入れたり、フォントサイズを調整したり、ページ繰りを調整したりしたいものです。

フォント埋め込みはtechboosterでGrifleを提供してもらえたのが大変助かりました。

書き終わってわかったこと

技術同人誌は、勉強会の発表より自由なターゲットに対して情報発信して良いようです。

勉強会ではテーマに関連のある発表だと、参加者のニーズにマッチしそうです。 「デバッグ早速理論」のような一般的な話は、テーマが関連する勉強会がありません。 あったとしても16ページ相当では、発表時間は30分以上かかりそうです。 発表枠を確保するのは困難です。

それに対して技術同人誌は、テーマやボリュームの選択の自由度が高いです。 興味があることを好きなように書いて、それに対して「興味があるから」「応援したいから」と買っていく人がいるというのは 個人的には新鮮で不思議な感覚です。

今年の目標

  • 家族を大事に
  • 責任のあるポジションにチャレンジ
  • 技術同人誌を書く
  • プログラミング作法」に現代の視点からツッコミを入れる
  • TOEIC 800点*1
  • 共感能力の向上
  • 自分が使うAndroidアプリケーションを作る*2

回避型愛着スタイル

はじめに

私は

  • 共感能力に低い
  • 他人に共感されることを避ける
  • 「共感されたい」という欲求を過小評価する

性質があります。 世の中では、これを「回避型愛着スタイル」と言うようです。 エンジニアにはこのタイプが多いように思います。

今わかっている範囲の情報を書きます。

愛着障害

精神医学の分野には「愛着障害」という障害があります。 他人との「愛着」を安定して築けないため社会生活に困難がでる障害です。

○○型愛着スタイル

自閉症」や「発達障害」と同じく軽い人もいれば重い人もいます。 軽い人は一見社会生活に全く支障がない人もいます。 そういう人に「○○障害」とつけるのは引っかかるので、ここでは「○○型愛着スタイル」と表現します。

原因

発生する原因は、両親(育成者)との間に「愛着」を上手く築けないから起きるようです。 わかりやすい例は幼い時の親との死別や、一定期間預けられていた場合などです。 他にも親の愛着スタイルが安定していない場合も起きるようです。

不安定型、回避型

大別して不安定型と回避型の二種類があります。

不安定型は十分な愛着が得られなかったために、愛着を過剰に求めたり、愛着を失うことを過剰に恐れます。 回避型は十分な愛着が得られなかったために、愛着を求めることをやめてしまいます。

不安型はラオウ、回避型はサウザーと思えばわかりやすいと思います。

共感

共感されたい

回避型愛着スタイルの人は「共感されたい」という欲求を過小評価します。 これは、以前から自覚がありました。

ずいぶん昔の話ですが、当時お付き合いしていた女性から「相手をしてほしい」アプローチをされたときに逃げ回っていました。 逃げると、相手からの「相手をしてほしい」アプローチが強化され、辟易して破綻しました。

当時の実感としては「めんどうくさい」でした。 今思うと、「相手をしてほしい」感情に共感できていなかったのだと思います。 さらに共感したように振舞うこともできず、どう反応してよいのかわからず戸惑っていたように思います。

共感できない

「相手をしてほしい」感情に共感できないのは、「自分の考えや感情が共感されるわけがない」と思っているからです。 「回避型愛着スタイル」の人が考える、共感される予想確率は限りなく低いです。 例えれば「空から女の子が降ってくる」確率と同レベルです。 このため、「共感されない」不満は「自分のところには空から女の子が降ってこない」不満と同レベルに思えます。 最初から失敗しかないチャレンジに失敗して、何が不満なのかが理解できません。

社会生活

共感能力の低さは、社会生活に影響が出ます。学生時代はあまり上手くいかなかったように思います。 共感できないため、ウェイウェイ出来ません。 ウェイウェイ出来きない人間がスクールカーストの上位に入ることはないので、中学高校は暗黒時代です。 ウェイウェイしなくてもよい仲間が見つかると楽しく生活できます。

社会人になると、社会生活への影響は少ないです。 会議であれば、論理的な説明さえできれば成り立ちます。 飲みニケーションなどで共感を求められることもありますが、拒絶さえしなければ、共感しないからといって迫害されることはありません。

共感能力が低くて、嫌われることもありませんが、特別好かれることもありません。 いわゆる人望に欠けます。ポジションによっては不利になるかもしれません。

個人的な対応

私は外見上は、実際どう見られているのかはわかりませんが、人の感情が読み取れないようには見えないと思います。 せいぜい愛想がないぐらいではないでしょうか?

共感能力がある人がどうやって人の感情を感じているかはわかりません。 私の場合は、心理学のように感情の原因を推測して理解しています。 たくさん本を読んだせいか、脳内にある人間の感情の原因リストは長いです。 そのうちで、現在の状況に一番近いものをパターンマッチして推測しています。

これは有利な面と不利な面があります。 誰かが怒っている時に、「口で言っている怒りの原因と真の原因が違いそうだ」と推測ができることがあります。 問題解決には有効です。 一方で、怒っている人は「とにかく怒っている感情を受け止めてほしい」と思っているようですが、 これに対しては「受け止める is 何?」となります。

おかげさまで対面でのコミュニケーションより、文章でのコミュニケーションの方が得意になりました。

治療?

治療が必要な性質のなのかはわかりませんが、共感能力を育てることはできるようです。

共感能力が低いといってもゼロではありません。 まれに共感出来ることがあるようです。 また「共感された」経験が少ないため、「共感されたい」という欲求を過小評価します。これは他人に共感することを放棄する原因になっています。

自分が他人に「共感する」「共感される」体験を繰り返すことで、共感能力を育てることはできるようです。 *1

典型的な例

1年前に ledsun.hatenablog.com で「生きる技法」を読んだと書きました。

いまの知識で思えば、著者の安冨さんは「強迫性パーソナリティ」でかつ「回避型愛着スタイル」でした。 「回避型愛着スタイル」の人間が感情を論理的に解釈しないと理解できない好例だと思います。

参考文献

愛着障害の克服 「愛着アプローチ」で、人は変われる

愛着障害の克服 「愛着アプローチ」で、人は変われる

愛着障害一般の話です。愛着障害の不安型と回避型を両方取り扱った本です。 過去の文豪や心理学の大家の愛着障害の例がふんだんに載っています。

回避性愛着障害 絆が稀薄な人たち

回避性愛着障害 絆が稀薄な人たち

上の本と同一著者です。回避性愛着障害に焦点を当てています。 回避性愛着障害をいくつかのタイプにわけて説明しています。 心理学の人には回避性愛着障害の人が多いようです。 共感能力の低い回避性愛着障害の人は、心理を論理で整理せずには居られないのかもしれません。

異性の心を上手に透視する方法

異性の心を上手に透視する方法

恋愛をテーマに、回避型愛着スタイルの男性と不安型愛着スタイルの女性がくっつきやすく、かつ上手く行きにくい理由が書いてあります。過去の経験がもろに該当していました。自分以外でも、該当する組み合わせは見かけるので、自分が当てはまるかもしれない人は読んでおくと心の準備ができて良いかもしれません。

タイトルは半分ぐらい詐欺です。特定の組み合わせのカップルが、お互いと心が全く噛み合わない理由を説明しています。

*1:世の中にはもっと良い方法があるでしょう。確実なことは専門家に聞きましょう。

サービス開発チームの拡大期におけるリーダーのレスポンシビリティ移譲に関する1アイデア

開発組織に関するポエムです。

背景

常駐や請負で、サービス開発チームのお手伝いをしたことがあります。 私に依頼がくる時は、サービスは売れていて、開発チームは拡大期にあります。 その時、開発者の人数は増えているが、開発リーダーの負荷は減らず、逆に増え続けるという現象を観測したことがあります。 過去に2件、目撃しました。

課題

開発リーダーはすべての「問い合わせ」と「機能拡張の意思決定」に参加する必要があります。 おまけに自分の実装タスクも持っています。 必然的に労働時間は伸び、「いつ寝てんだこの人?」という働き方をしています。

はたから見ていると、何年も続けられる働き方はないので、いつか破綻しそうな危機感があります。 実際、2件のうち1件の開発リーダーは退職しました。

果たして、我々はこの状況に対して何かできるでしょうか?

経験談

開発メンバーの視点

開発メンバーからはリーダーが大変なことはわかります。 ただ、どんな問題を抱えているのかはわかりません。 この立場でできることは

  • 要件を一度でなるべく細く聞き取る
  • リファクタリングを避けてレビュー工数を減らす
  • 修正点を最小にしてレビュー工数を減らす

などでした。このためには、受け入れるタスクを小さくする必要があります。 タスクが大きいと、リーダーとの相談量が増え、リーダーへの割り込み量が増えます。

アウトプットが少ないと評価されるのを覚悟で、手戻りにリーダーを巻き込まない強い心が必要です。 実際は、これができる人とやっている人は、とても少ないように思います。

開発リーダーの視点

今年の9月から11月に掛けて、炎上プロジェクトのリーダーをやりました。 立場は違いますが、共通する点もあるかもしれません。

炎上中のリーダーは手を止めることができません。 次のいずれをやめても、プロジェクトの進捗止まります。

  • 各機能の仕様や実装方針の意思決定
  • ボトルネックになる機能の実装
  • 進捗の把握
  • 顧客への進捗の報告とスケジュール調整

特に困るのがタスクを切り出す作業です。 タスクとして切り出したものは、開発メンバーにお願いできます。 問題をどのように解決するか、考えタスクに落とす部分は一番負荷が高いです。 一方で、それまでの経緯などコンテキストへの理解が必要であり、簡単に移譲はできない部分です。

また、プロジェクトの遅れに責任を感じているリーダーから、「プロジェクトを一度停止して体制の修正をしたい」とは言い出しづらいです。

方法の一つとして、リソースプランナー役の人に入ってもらって

  • 進捗の把握
  • 顧客への進捗の報告

を巻き取ってもらうと、だいぶ楽になります。 経験するまでリソースプランナーは要らない役職だと思っていました。 実際はすごく頼りになります。 ただし、感覚としては20%ぐらい楽になるぐらいです。 すでに120%以上の稼働に達している場合は、それほど効果がありません。

問題

  • 開発メンバーからはリーダーの本質的な課題が見えない
  • 開発リーダーは作業を止めることができない

開発チームからボトムアップで状況を改善することは難しそうです。

イデア

ワイガヤやったらいいのではないかな?と思います。

この手のコミュニケーションのミスマッチは、「サービスに対する熱意の差」みたいな誤解に基づいている気がします。

  • リーダーは、俺がこんなに頑張っているのにメンバーのやる気が足りない
  • メンバーは、俺も頑張りたいのに、どう頑張ればリーダーの役に立つのかわからない

熱意とかやる気は、見た目に差があっても内部的に差があるかはわかりません。 一方で、サービスに対する興味のある点や価値観は、開発メンバー全員が違うはずです。 今のフェーズに、たまたま価値観が合っている人が「熱意がある」ように見えているだけではないでしょうか?

そんなわけでワイガヤです。 サービスの開発を数日止めて、 二泊三日の合宿でサービスに対する思いを表明しあってはどうでしょうか?

  • 次の施作案
  • 既存の気にくわない点
  • 俺の感じるかっこよさにマッチする点、マッチしない点
  • どんなユーザーに使わせたいか

色々なアイデアがあると思うので、決めるためでなくて、「みんな、そんなこと考えてたのかよ!」と思うための会をとことんやるといいのではないかな?と考えました。

参考:「ホンダ流ワイガヤ」実践のコツと方法を、元ホンダ 本間 日義氏にインタビュー |ビジネス+IT

実践したことはないので、与太話です。

うまくいけば

すくなくとも開発リーダーの気持ち面で時間は稼げそうです。 その隙に、「雑用タスク何でもできるマン」*1を投入して、開発リーダーの持っているタスクまで落ちていない作業をタスク化。 チーム内に振りまいていけばなんとかなるでしょう。 開発リーダーの稼働が80%ぐらいまで落ちれば、もともと優秀な人ですから、あとは自分で改善できるはずです。

*1:例えば、私。ただ、目に見えるアウトプットは、通常の開発者とは違うので、そういうjob descriptionの元でないと怖くてできません。

MacBook Proの代替えWindows PC調査状況報告

背景

  • MacBook Proが望まない方向に進化している
  • いっそのことWindows PCの方が良いのではないか?

要件

  • US配列キーボード
  • 16GB以上のメモリ
  • 256GB以上のSSD
  • 通勤時に利用できるノートPC

結論

の二択

候補

ゲーミングPCは調べていません。

VAIO Z

pur.store.sony.jp

全ての条件がクリアできる唯一の日本製PC

Surface Book

www.microsoftstore.com

Microsoftの誇る最強のWindows PC。日本ではUS配列キーボード モデルが発売されていません。

Intel Core i7 + 16GBメモリ + 512GB SSD + GPU で¥345,384(税込)は勇気がいる価格です。

Panasonic レッツノート

panasonic.jp

Japanが誇るノートPCブランド。光学ドライブなしモデルはメモリが8GBまでしか積めません。

US配列キーボードは選べません。

NEC LAVIE

nec-lavie.jp

軽さに定評のあるLAVIEシリーズ。メモリが8GBまでしか積めません

US配列キーボードは選べません。

ASUS ZENBOOK

ZENBOOKシリーズ | ノートパソコン | ASUS 日本

メモリが8GBしか積めません。US配列キーボードは選べません。

テキストより複雑な構造のデータを扱うWikipediaを作る

モチベーション

専門性を持った不特定多数のユーザに協力してもらい、個人では作り得ない大規模なデータベースを作りたいことがあります。

例えば、Wikipediaは、(記述の正確性や公平性における問題は抱えているかもしれませんが)規模の点で成功しています。

Wikipediaのエディタはオンライン百科事典のエディタとして特化しています。百科事典ではないデータを扱うデータベースの場合、Wikipediaのエディタは機能が合いません。

必要なもの

複雑な構造のデータを扱うたデータベースを作るには何が必要でしょうか?

ブラウザ上で動くビジュアルエディタが必要です。

なぜでしょうか?

インストール不要

インストール不要なため、編集環境を構築するコストが低いです。 編集用のアプリケーションをダウンロードして、個人のPCにインストールするのはボランティアで参加してもらうにはコストが高いです。

エディタの学習コストが低い

編集内容をビジュアルで表現すれば、エディタの操作が直感的になり、操作方法の学習コストが下がります。

データを直接編集する学習コストは高いです。 例えばDBPediaの情報を編集するには、DBPediaのデータフォーマットに関する専門知識が必要です。

つまり

ブラウザで動作するビジュアルエディタを提供することで、不特定多数のユーザーが編集に参加しやすくなります。

先行例

一般消費者向けのアプリケーションも作られるようになりました。

どうやって作ればいいのか?

技術要素は、2005年に公開された、Google Map変わっていません。

ただし、10年間で各要素はそれぞれ高度化しました。 一つのビジュアルエディタのJavaScriptファイルが数千行に達することは珍しくありません。

難しさ

複雑なソフトウェアを、要件に合わせて適切に設計・実装できる、ソフトウェア開発技術者が必要です。

ビジュアルエディタの場合は、次に挙げる難しさがあります。

  • わかりやすい操作方法の設計
  • 選択状態の管理
  • 編集途中状態の管理
  • UNDO/REDO機能
  • データの依存関係に応じた編集
  • パフォーマンス
  • テスト

わかりやすい操作方法の設計

わかりやすい操作方法は、編集したいデータ形式や、想定するユーザーによって変わります。

一般的な指針はあります。例えば、

  1. 編集の敷居を下げるには、ヘルプを参照せずに、マウスまたはタップ操作のみで編集を完了できると良い
  2. PCに慣れたユーザーはキーボードショートカットがあると便利に感じる
  3. ショートカットは世の中の既存のエディタと共通の方が良い

しかし、独自のデータを扱うアプリケーションを作る場合は、アプリケーション毎に試行錯誤が必要な部分は残ります。

選択状態の管理

「マウスまたはタップ操作のみで編集が完了」するには、編集対象のオブジェクトを選択する必要があります。 選択できない場合は、idや座標で編集対象のオブジェクトを指定して編集します。

オブジェクトが選択できると

  • 選択している時だけ編集可能にする(切り取りボタンを有効にするなど)
  • 編集機能やエディタの状態によって選択可能/不可能を切り替える

必要があります。

複数のオブジェクトが選択可能な場合は

  • 複数選択の操作方法の設計(例えばCtrl押しながら、Shiftを押しながら)
  • 編集機能やエディタの状態によって複数選択可能/不可能を切り替える
  • 異なる種類のオブジェクトを選択した場合の動作の設計

が必要です。

オブジェクト生成時に自動選択

オブジェクトの生成後に自動選択したい場合があります。その場合、

  1. データ上のオブジェクト作成
  2. DOM上のオブジェクト作成
  3. データ上のオブジェクト選択
  4. DOM上のオブジェクト選択

の順序を制御する必要があります。 VIrtualDOMで表現できないビューを扱う場合は、モデルの操作とビューの操作が交互に行うため、原始的なMVCでは監視コントローラーパターンが使えません。 監視コントローラーパターンを使うには、MVPパターンを導入し、選択状態の管理をコントローラーから分離します。

編集途中状態の管理

エディタでは編集途中状態を扱います。

たとえば、テキストエディタは編集した文章を保存せずに終了することができます。 エディタを閉じる際に次の動作をしたいことがあります。

  • 未保存データがある旨の警告表示
  • 自動保存
  • 下書き状態として保存

ブラウザのonbeforeunloadを使って、これらの動作を実装します。

UNDO/REDO機能

エディタはUNDO/REDO機能があると便利になります。

VirtualDOMを使っている場合など、ビューがデータの射影として表現できれば、データのスナップショットをとっておくことで実現できます。

次の要件がある場合

  • メモリの消費を減らしたい
  • ビューの更新ロジックが複雑

データ操作を一度コマンドオブジェクトとして生成し、履歴として保存しておく必要があります。 各コマンドで

  • UNDOの実行
  • REDOコマンドの生成

ができれば、UNDO/REDOは実装可能です。

データの依存関係に応じた編集

データ構造によってはデータの依存関係があります。

例えば、ツリー構造の場合は親データを削除した時には子データも削除します。 ビューをDOMのツリー構造として構築していれば、データの親オブジェクトとDOMの親要素を消すことを対応付けることができます。

UNDOがある場合は、親オブジェクトが削除する時は、削除前に持っていた子を保存する必要があります。 UNDO時には保存情報から親オブジェクトと子オブジェクトを両方復元します。

パフォーマンス

DOM操作のパフォーマンスを出すには独特のテクニックが必要です。

DOMへの要素追加のタイミングを気をつける他に、リフローと呼ばれる現象を防ぐ必要があります。

DOM要素の「幅、高さ、位置」を取る場合、ブラウザは描画内容を再計算します。 DOM要素の「幅、高さ、位置」取得と、「幅、高さ、位置」設定を個別に繰り返すと、ブラウザの再描画計算が大量に実行されパフォーマンス低下を招きます。 これとリフローと呼びます。

参照したい全DOM要素の「幅、高さ、位置」取得をまとめて行い。 「幅、高さ、位置」設定をまとめて行うと、リフローが防げます。

テスト

ビジュアルエディタの機能では見た目が重要です。 テストをする際にも見た目の確認が大きなウェイトを占めます。 機能を満たしても、使いにくかったり、使い方が直感的にわからなかったりすれば、要求は満たせません。

一般的な、業務アプリケーションの業務ロジックのテストとは異なるアプローチが必要です。 人間が手と目を使って繰り返しテストすることが、非常に有効です。 テストケースの作成とテスト実施には、忍者式テストというテスト手法が有効です。

実績

作成したビジュアルエディタです。

1on1ミーティングのやり方

1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。

前提条件

弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。

インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。

面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。

やり方

人数

インタビュワーは6人います。ベテランエンジニア5人と営業1人です。

インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。

組み合わせ

もっとも長い期間面談をしていない組み合わせで実施します。

組み合わせは、モンテカルロ法で抽出します。 そのために GitHub - ledsun/interview-lottery: The lottery for interview を作りました。

その他

弊社には遠隔地の拠点があります。 Skype等のビデオ会議で面接を行います。

面談の議事録はインタビュワー間で共有します。

質問内容

面談を円滑に進めるために聞く内容のテンプレートを作ってあります。

  1. 最近うまくいっていること(やっていること)
  2. うまくいっていないこと
  3. (仕事をやりやすくするために)ほしいもの
  4. 個人のビジョン(どうなりたいか?)

KPTを元にしています。

「うまくいっていること」は言いづらいことが多いようです。その場合は、「やっていること」を聞いています。

「ほしいもの」はTeam Geekからパクリました。

「個人のビジョン」は「時々、(自分の)中長期的な将来のことも考えてみてね」ぐらいのノリで聞いています*2

実施方法

各インタビュワーに任せています。統一した方法等はありません*3

個人的には、ほぼKPTです。 インタビュイーに聞いた内容をホワイトボードに書きながら、質問を掘ったり、各項目を関連付けたりして進めます。

若手のエンジニアはメタ認知*4が苦手なので、KPTを一緒にやるとそれなりに効果があると思います。

お互いの負担を減らすために30分という時間制限を設けています。 個人的にはインタビュイーに話したいことがある限り延長しています。 最大で2時間半ぐらいでした*5

やってよかったこと

会社ハックのきっかけに

個人的に一番面白いのは、会社の仕組みをハックするきっかけが得られる点です。 社内の制度に関する質問をもらえると、仕組みを整理するきっかけになります。

ビジョンの時間変化

「個人のビジョン(どうなりたいか?)」に対する答えが、時間とともにに変わることがわかりました。 こまめに面談をしていないと、一年前に聞いたビジョンに今でも同じように興味があると考えてしまいがちです。 経験を重ねるにつれて興味のある分野が変わるのは、ふつうのことだと思います。

若手の成長を実感

ビジョンの変化と一緒です。 課題と思うことや、興味のあることが変化しているのを通して、若手の成長が実感できるのはうれしいです。

やってわるかったこと

エースエンジニアの時間が取られることです。 人によって得意不得意があります。面談が不得意なエンジニアがインタビューするのは負担が大きいようです。

*1:面談やってても辞める人は辞めますね・・・

*2:ビジョンをダシに「もっと頑張らないとダメだ」みたいな話をすると、お互い面倒臭いですよね。

*3:インタビュワーの面談技術向上は課題です

*4:ここでは「自分が知っていることと、自分が知らないことを切り分けて整理すること」の意

*5:経験則ですが、人間には「3時間話を聞いてくれた人を信頼してしまう」習性があるように思えます。

主観でプログラミング言語7種類をあっさり解説

k16's note: 主観でプログラミング言語5種類をあっさり解説を読みました。 なるほど、そういうのもあるのか。

個人的に馴染みがあるプログラミング言語を7つ解説します。

JavaScript

ブラウザで実行できるので、動作を確認しやすい点が良いです。

f:id:ledsun:20160701141331p:plain http://www.modulecounts.com/

圧倒的なライブラリ数です。

一方で、動作環境が多すぎます。

動作環境によって使用可能な文法、APIが違います。 参考資料が、どの環境を対象としているのか、判別するのに苦しむかもしれません。

C#

強力なIDEVisual Studioがある点が良いです。 Visual Studio Communityは無料で使えます。

一つの言語で、いろいろなアプリケーションが作れるのが魅力です。

  • Windowsアプリケーション
  • Webアプリケーション
  • コンソールアプリケーション

C# によるプログラミング入門 | ++C++; // 未確認飛行 Cという強力解説サイトがあるのも心強いです。

開発にWindowsが必要なのが、少し悪い点です。 やろうと思えば、Visual Studio Codeを使って、MacLinuxでも開発可能です。

Ruby

Rubyコミュニティが日本にあることが良い点です。 会いに行ける言語の実装者です。

言語仕様やライブラリ仕様が複雑です。ハードルがちょっと高いです。

VBScript

Windowsでの作業を自動化することができます。

大抵のWindowsに最初から入っています。追加アプリケーションが必要ありません。 他人のPCで動かすスクリプトを作るときに、インストール済みのアプリケーションを気にしなくて済みます。

言語仕様が独特です。他の言語と知識を共有できなく辛いかもしれません。

シェルスクリプト

LinuxUnixでのコマンドライン作業を自動化するのがとても簡単です。 基本的にはコマンドを並べるだけです。

関数を使ったりループを回したり、ちょっと複雑なことをしようとすると、シェルによって文法が変わるのが難点です。

Java

クラスベースオブジェクト指向を知るのに最適です。 オブジェクト指向における再利用のためのデザインパターンをマスターしたいときにおすすめです。

Androidアプリの開発にも使えるらしいです。

C

スタックとポインタを意識してプログラミングしたいときにおすすめです。 実行速度が速い点も良いです。

コンパイラと実行環境によって言語仕様が変わるのが気難しい点です。 gccVisual Studioでは使える文法が変わります。 OSによって使えるAPIが変わります。

日本でアジャイルが流行らない理由

ポジション的なもの

個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。

現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。

キーワード「エンタープライズ」が出てきているので、業務システムの話をします。

情けないぞアジャイルコーチ

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。

サム・グッケンハイマーの一言

サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー

の方が

「ウォータフォールは一切メリットがないので止めておきなさい」

といったそうです。まあ、ポジショントークマイクロソフトは、これから日本で、Azureを使ったDevOpsを売りたいですよね?

自分の本当の心の中

統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている

うしおさんがMicrosoftの中の人である以上、ポジショントークとして扱うのが良いと思います。特に、この画像にde:codeのロゴ入っているのが、ひっかかります。

マイクロソフトの面接での出来事

彼は面接の最初にちょっとびっくりした声で私に聞いた Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か?

DevOpsを売るに当たって、前提として「アジャイルが流行っていない」のどうしようか?みたいな、状況でしょうか? エンタープライズ向けに売ろうと思うと、由々しき事態だと思います。 上司の方の危機感の認識は日本市場に合っているのではないでしょうか?

最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの!そんなの誰もやってないよ!」と本当に驚いていた

なるほどー、そうなのかもしれません。 人類に達成可能である証拠なので、アジャイルを導入したい、自分にとっては朗報です。

ウォータフォールは起源から異なっていた

ウォータフォールの起源はどのようなものか?というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている

私も、そうだと思っていました。久しぶりに見直した日本語のWikipediaに・・・

初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。

まじかよ!本日、最大の驚き!!

ウォータフォールを前提とするのが本当に日本のためだろうか?

1日に10回も100回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が15分で当て終わるような時代だ

1日に10回、本番デプロイする必要がある、業務には、どういう業務を想定されているのでしょうか? 個人的には思いつきません。

個人的な経験では 「1日待ってもいいから、ちゃんとテストして、バグで毎日の業務が止まらないことを保証してから、リリースしてください。」 と要望されることが多いです。

1日に10回、本番デプロイできる環境では、業務システムを使って業務を行う方たちも

  1. バグったらシステム管理者に連絡
  2. 再リリースまで休憩

な、やり方に慣れるのでしょうか? 米国に、そういう事例があるのであれば、是非知りたいです。

開発する立場としては、「とりあえず勘で直してリリースした。直ったかどうか、確認して」と言えたら、とても気楽だなと、思います。 正しいやり方かはわかりませんが、緊急回避手段が増えるのはありがたいことです。

自分の恥ずかしい体験談 私はインターナショナルでは無価値である

彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか?みたいな話をしてくれた

これは、うしおさん個人が、アジャイルな現場での開発技術についていけていない話な気がします。 現場で手を動かすのをやめるのが早すぎたのではないでしょうか?

アジャイルコーチのジョークに「もう何年もプログラムを書いていない」みたいな話があった記憶があります。 そのイメージです。元ネタを失念しました。

最も深刻なことは、「経験」を積めないこと

2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった

私は外資系、できれば海外に住むことをターゲットに仕事を探していた

という目的に対しては、残念とは思います。

だけど、あなたの積んだ「経験」は、絶対に他人が詰んだ経験とは異なります。 異なる経験は異なる状況では価値があります。普遍的に無価値ではありえません。

「自分の経験は無駄だった」はただの思い込みです。無駄なのでやめましょう。

日本はソフトウェア開発の後進国

ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた

これは間違いないです。日本人のGithubリポジトリをWatchしたことがありません。 本場で自分の力を試してみたい人は行けばいいと思います。 個人的には食の面で、移住には魅力を感じません。

海の近くで魚介が美味しくて、山の近くで水が美味しいと、食べ物は美味しいです。 シリコンバレーは割と食べ物がおいしいかもしれません。

自分が目指すビジョン

私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ

なぜでしょう?

Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい

遅れていると言われるのが嫌だからでしょうか?

うーんと・・・「ファッションアジャイル野郎が!」と言ってみたいですね(汗

エバンジェリストに期待すること

「遅れている」や「遅れがもっと広がる」という、脅しは必要はありません。 FUDは嫌いです。

  • アジャイルやDevOpsを取り入れた米国や英国の業務システムが、どうすばらしいのか
  • アジャイルやDevOpsが、日本の業務システムが抱えている問題を解決し得るのか

を伝えて欲しいです。

事例さえあげてもらえれば、あとは我々SIerが発注者に売りこみます。

日本でアジャイルが流行らない理由

個人の考えです。

  1. 予算確保にシステムの仕様が必要
  2. システムの発注が請負契約
  3. 発注企業のシステム担当者が、一つのシステムに専任していない
  4. 発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
  5. 発注企業の業務担当者が、システム開発に専任していない

予算確保にシステムの仕様が必要

95%の会社がアジャイル開発やっているなら、これ教えて下さい。本当に。 システム開発を始める際に、会社内でプロジェクトの期間と目的と予算は決めているはずです。

どういう風にプロジェクトを初めて、どういうときに中止するのか。 リスク管理のやり方が真似できれは、日本の企業もアジャイルな発注ができるはずです。

公共案件の予算管理にも適用できると、大手SIerアジャイルに移行できるのではないでしょうか?

システムの発注が請負契約

よく言われます。これは分割納品にすれば割と回避できます。

ただし、最終納品では揉めることがあります。 発注時の仕様と違うものを納品するには、発注会社のシステム担当者が社内を説得する必要があります。 できなかった場合に、納品のためのごちゃごちゃした作業が必要になります。 プロジェクトは炎上します。

社内を説得できる人は、とっくに「アジャイルのようなこと」をやっています。

「予算確保にシステムの仕様が必要」と同根です。 発注会社(のシステム担当者の上司)はアジャイルなプロジェクト管理をする方法がわからないのです。 開発側の技術や環境の問題ではありません。

発注企業のシステム担当者が、一つのシステムに専任していない

  アジャイルなプロジェクトで1週間に1回リリースすると、発注企業のシステム担当者の時間が足りなくなります。 毎周、検収して次の週のストーリーを考えるのは無理です。

これは、発注企業のシステム担当者が、一つのシステムに専任していないからです。 他の業務に追われています。

この状況では「1日に10回本番デプロイ」魅力にはなりません。 DevOpsを使いこなすためには、発注企業は、システム開発の費用にシステム担当者の人件費をもっと増やす必要があります。

検証環境に「1日に10回本番デプロイ」できると、ソフトウェア開発者にとっては便利です。 手で受け入れ試験を回せるので、システムの理解が捗ります。

発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない

  • ディスクは遅くて、ネットワークはもっと遅くて、メモリはちょっぱや
  • 1万レコードは問題ない。10万レコードはちょっとおもい。100万レコードは重い。1億レコードは色々頑張らないと無理

みたいな感覚を持っていてもらえると、コスト感が通じやすくて嬉しいです。愚痴です。

端から見ていると、業務システムのプロダクトマネージャーは、とても難しい仕事に思えます。

  • 商売の理解。システムをどう活用すればもっと儲かるのか
  • 業務の理解。どういうシステムなら業務がまわるのか
  • コンピュータサイエンスの理解。どういうシステムなら低いコストで作れるのか

すべての知識を持ったプロダクトマネージャーは、非常に稀有に思えます。 数千万円程度の投資をして、外部から登用するか、社内で育てる必要があるように思えます。

それで商売上の価値があるのかは、私にはわかりません。

発注企業の業務担当者が、システム開発に専任していない

日本では当たり前です。業務担当者は、

  • 開発初期のインタビュー
  • 開発終盤の受け入れ試験での確認

ぐらいに参加。システムが稼働し始めてから、本格的に使って混乱します。 慣れてくると、本当の要望が出てきます*1

米国では、「業務設計担当者とアジャイルに開発して、現場の人はマニュアルにしたがって操作するだけ」なのでしょうか? 気になるところです。

「システムを段階的に導入して、現場の業務担当者のフィードバックを生かして、システムを育てていきたい」 と、常々思います。 受託開発では、納品後はシステムはソフトウェア開発者の手を離れます。 「現場の業務担当者のフィードバック」を受ける機会はあまりありません*2

*1:出てこなかったり、謎の思い込みから、明後日の要望がでてきたりするることもあります

*2:プロトタイプを触ってもらってフィードバックを受けることはあります。ただ、本気の要望かというと違う気はします。システム導入への恐怖感は減ります。業務担当者にプロトタイプを触ってもらうことは、システム担当者にはメリットがあると思います