読者です 読者をやめる 読者になる 読者になる

Meblog

このブログ記事は個人の見解であり、所属する組織の公式見解ではありません

アジャイルとハイプ

たまには会社のことも差障りのない程度に書いてみようと思う。

今、業務では、試験工程の真っ只中。全体の工程にウォーターフォールモデルを採用したプロセスでWebアプリを開発している。

全体の工程は、設計・製造工程(プログラミング工程だ)のあと、何段階かの試験工程がある。現在の工程ではブラックボックステストを多分に含み、ユーザテストのようなものも含む。そうすると、当然設計に関わるような不満も噴出する。こういった機能がほしいだの、ボタンはこういう配置がいいだの、そういう要望だ。

こういった意見はくだらないものもあるが、耳が痛いことが多い。当然対応すべきだった事を指摘されることもあり、エンジニアとしては是非対応したい。しかし、請負会社の契約も切れてしまった今、残ったリソースで修正するのは並々ならぬことであり、またウォーターフォールの概念から言っても、禁じ手でもあるのだ。なぜなら、ウォーターフォールにおける各工程の終了とは、完璧な品質の担保を意味しているため、要望による修正は、全ての工程をやりなおしを意味するからだ。幾度となく言われていることであるが、これがウォーターフォールの最大の欠点である。

すると当然、アジャイルを導入するか、という話が持ち上がってくる。

simplearchitect.hatenablog.com

アジャイルであれば、途中の要件変更に強くなるはずだ、という目論見である。アジャイル自体もう新しい技術でなくなっているし、コンサバティブな僕の会社でも幾度となく検討している。しかしこれも何度となく挫折を味わっている。今回、製造工程で行ったアジャイル開発も例外ではなかった。この失敗は、組織の問題や企業風土の問題も確かに少なからずある。しかし、今回言及したいのは、それ以外の部分、「ハイプ」だ。

        • -

ウォータフォールでは全ての機能を完全な仕様書におとしこみ、それを開発が順次実装していく。仕様書は開発工程開始時点では完璧であるはずなので、これをどれだけ忠実に実装していくかが問われるわけだ。しかしひとたびこれを「アジャイル」にしてみると、企画からしてみると、開発開始時点で仕様書は完成してなくてもよい、という解釈になる。企画からの要望はずるずると開発終盤まで変更される。開発終了時には、なんとか動くものはできるものの、色々なところに悔いがのこる中途半端なものが完成する上、開発途中の仕様変更により、工数も大きく膨らんでしまう。ここで開発を振り返ってみよう。企画が開発完了した製品を実際にテストしてみることを想定する。すると、「ここはこういう機能って言いましたよね?」という言った言わない論争が勃発する。しかし、開発途中には様々なバージョンの要求仕様書があり、どれが結論かも全く判然としないのだ(企画側はいまだにバージョン管理には相当疎いことに留意しなければならない)。本来、いかなる開発においても、企画と開発が一体になっていない以上、ドキュメントは残すべきである。しかし、「アジャイル」という言葉を導入した途端、多大なコミュニケーションにより仕様を担保できると考えてしまい、完成したドキュメントはなくなってしまう。

簡単にいうならば

「なぜドキュメンテーションしなかったの?」
「アジャイル開発だったからです」

ということになる。アジャイルに過度に期待をよせてしまった「ハイプ」だ。

このハイプは、昨今の開発で、多く見られる現象のひとつのように感じる。例えばAIにしても中身や特徴、処理方法は別にして、とにかく「データ処理をうまくやってくれるもの」、VMは「サーバ上の処理をうまくやっていくれるもの」、先程のアジャイル開発はとにかく「開発工程をうまくやってくれるもの」、といった様にだ。ここでの教訓は肝心なのはハイプであるのは開発だけでなく、企画を始めとする間接部門にとってもハイプだということだ。開発には銀の弾などないということは、プロフェッショナルにとっては常識になっている。どれだけ便利な手法でもプラクティスを誤れば、全くうまくいかないアンチパターンになるリスクを孕んでいる。特に昨今の手法はこれさえやっておけばうまくいく、といった簡単なものではなくなっている。自分たちの状況に合わせたプラクティスの選択・構築が何より重大な命題になっていくだろう。この問題は、技術面に疎い人に説明するのは相当難しい。例えばアジャイルにとっても開発時のステークホルダーのスコープはどれだけか、開発規模はどの程度か、どの仕様が最低限必要なのか(これが一番むずかしい。少ない機能を実装しようとすると普通の人はサボっているとか生産性が低いなどと思ってしまうだろう)、などなど、様々なパラメータがあるが、これらが開発に影響にどのように影響するか。おそらく完全に理解してもらうのは不可能だろう。

        • -

そんなわけで、僕の周りのアジャイルだとかAIとかのバズワードの信頼度は下がるばかりだ。実際にはそれら自体ではなく、その言葉を誤用している僕らやステークホルダーが悪いのだけども。こういったことで時代の潮流に遅れないようにしたいと願うばかりだ。

ソフトウェアとビジネスの狭間

Hackernewsみてたらこんな記事が。

news.distrokid.com

ソフトウェア書きとしては気持ちのいい話だ。特にこのご時世、JASRACの話とも相まって、相乗効果的にその印象が強まってくる。

    • -

まあ、音楽面の話はさておき、ソフトウェアを書くことの価値とはなんだろうかと思うことがある。実際会社でソフトウェアは書いているけれども、それを責任もって事業化し、売上げてくれるのは別の部署の人たちだ。我々開発者がそのソフトウェアについての価値について直接考える機会はほとんど失われてしまっている。逆に我々に求められているのは品質やコスト、納期であり、いかにバグのないソフトを安く早く作るかということに主眼をおいている。それはそれで開発に集中できるのでいいのだけれど、ときには俯瞰して考えたい。

そもそもソフトウェアの価値とはなんだろうか。

古来、というより、欧米でよく言われる「ドットコムバブル」の時代、あるいはさらにその前時代、ソフトウェアの価値は複製の容易性にあった。一度ソフトウェアを書いてしまえば、ほとんどコストの無視できるメディア代だけで価値を増幅することができたのだ。それまで存在いたあらゆる製品は、生産に大規模な設備を要し、流通経路を確保し、顧客に届けなければならなかった。これがソフトウェアではほとんど無視することができたのだ。

さらに現代、更にその仕組は強化され、ほとんど物理的な物流に依存することなく、ソフトウェアの価値を顧客に提供することが出来るようになった。顧客にはプラットフォームとなるハードウェアすら準備する必要がなくなったのだ。そのため、顧客はほとんど設備投資する必要なく、ソフトウェアを手に入れることができるようになった。

しかし、おそらくソフトウェアを開発する総コストは根本的に変わってないというところに注目しなければならない。

あらゆる技術の革新でより早く高機能なものを顧客に提供できるようにはなってきている。しかしそこに投入するエンジニアのリソースは変わっていないように思える。顧客の要望も技術的革新に追従し、ハイレベルなものになってきているためだ。結果として、ソフトウェアをビジネス化するには、より少ない生産量で、より多くの顧客をかかえることが重要度を増すようになってきたのだ。

ここで僕は自分を振り返りたい。自分は開発としてこのソフトウェアの優位性を理解し、仕事をしているだろうか。誰か特定の顧客のためだけに愚直に価値を提供してやいないだろうか。

  • -

上記記事では、ほとんどの定形業務を自動化することにより極端に少ない人数での業務のオペレーションに成功している。言葉でいえば単純だが、自動化はソフトウェアの得意とする一分野であり、さらにそれをうまくスケールするところまで成功している。また、他のサービスと異なるのは、これが既存産業をおびやかしにかかっているところだ。強力な既得権を置き換えにかかるその様は、きっと開発者本人も予想しなかったことだろう。

EmacsでSMTPの設定を変更をする

Emacs

メールアカウントのパスワードを変更したんだけど、EmacsSMTPの設定の方法がわからずうなってた。IMAP側はmu4e使ってるから、すぐわかったんだけどね。。SMTPはinit.elみてもパスワードの設定なんて書いてなかった。

EmacsWiki: Sending Mail

ここには、設定するときにプロンプトが出ますよ、ってなことが書いてあったが、一度設定してしまうともう出てこないので、うーん、と悩んでいた。ちゃんと読むと、

$(HOME)/.authinfo or $(HOME)/.authinfo.gpg

に設定ファイルが書き込まれている、とのことだったので、ここを参照して変更したら、解決。

    • -

最近Emacsの話ばっかり書いてるな。ちょっとでも仕事の話が絡むと記事にできないんだけど、Emacsはその点直接は関係ないから、書きやすいのだ。

バグ

雑記

Hacker Newsみてたらこんな記事が。

The Mark I Computer at Harvard

昔、「バグっていうのは、機械が動かなくなったときに原因を調べたら、虫がはさまってたっていう話が起源なんだよ」ってのを聞いた気がしていて、それをなんとなく信じていた。でも、この記事読む限り、それ以前から電気機械の故障を「バグ」って呼んでたみたい。

そうすると、逆にその「バグ」は一体何由来のものか気になるが..

こういう黎明期のコンピュータは何かそそられるものがあるねえ。当時の最先端の技術が垣間見れるからなんだけど、実際にリレー式のコンピュータがガチャガチャと音を立てて動く様は感動するものがある。動作としては一個一個のからくりはわかるんだけど、それで計算結果が出力される不思議といったら。

今のCPUは完全にブラックボックス化されているから、それを感じることすらなかなかないんだな。

Windows8にVMWare PlayerつっこんでCentOS 7.2 を入れた話

開発

掲題のとおりなんだけど、うまくいかなくて、無理やり解決させたので、メモ

前座

VMWare Workstation Playerなるものがあって、これをWindows8につっこんで、Cent OS 7.2を入れようとした。んで、割りと途中まではうまくいっていて、Windows側からVMディレクトリ共有して、マウントしようと思ったら、ハマった。なぜか解決策がなかなか出なかった、

エラー詳細

ディレクトリを共有させるんだけど、要はvmware-install.plを動作させる。以下がまとまっていて、わかりやすい。

VM上のCentOSとホストOS(Windows7)とでファイル共有したメモ - MofuMofuFarm

色々むにゃむにゃ動くんだけど、ここで以下エラー。

/tmp/modconfig-CXZXGV/vmhgfs-only/page.c:1649:23: エラー: 関数 ‘wait_on_bit’ への引数が多すぎます
                       TASK_UNINTERRUPTIBLE);
                       ^
In file included from include/linux/mmzone.h:9:0,
                 from include/linux/gfp.h:5,
                 from include/linux/mm.h:9,
                 from include/linux/pagemap.h:7,
                 from /tmp/modconfig-CXZXGV/vmhgfs-only/page.c:28:
include/linux/wait.h:1044:1: 備考: ここで宣言されています
 wait_on_bit(void *word, int bit, unsigned mode)
 ^
make[2]: *** [/tmp/modconfig-CXZXGV/vmhgfs-only/page.o] エラー 1

なんかライブラリの生成に失敗しているようだ。

同様のエラーは以下記事でも報告されている。
CentOS 7.3 & VMware Tools でファイル共有機能の不具合 « minor tranquilizer

解決

で、自分は上記記事でなくて、こちらを参考にした。

CentOS 7 安装 vmware-tools-懂客-dongcoder.com

中国語なので、超訳(原文は何言っているかわからないが、試行錯誤した結果)。

ソースを取得する。

以下を解凍する。

vmware-tools-distrib/lib/modules/source/vmhgfs.tar

すると、vmhgfs-onlyを入手できる。

ソース修正

vmhgfs-only/page.cの1639行付近を以下のように修正

-    #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
+   #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 10, 0)

保存しておく。

もとの場所にもどす。

vmhgfs-onlyをvmhgfs.tarに固め(ファイル名に注意)、lib/modules/source/vmhgfs.tarに上書きする。

スクリプト再実行

vmware-install.plを再実行。

あとがき

普段Windowsに寄生するタイプの仮想環境なんて使わないから、ビビりながら使ってたが、こんなところでハマるとは。。あんまり日本語の情報でてこないってことはVMware自体のユーザが少ないってことなのかなあ。みんなVirtualBoxにうつったのか、もしくはクラウドなんかをホームコンピューティングの目的で借りちゃったりしてるのかもしれないな。

Team Geakを読んだ。

雑記

Team Geek - Googleのエンジニアたちはいかにしてチームを作るのか
を読んだ。

www.oreilly.co.jp

内容をざっと把握するなら、以下の投稿参照。客観的にうまくまとまっている。

『Team Geek』を読んだメモ - Qiita

『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』まとめ - Qiita

Team Geekを読んだ - Web就活日記


この本で一貫して主張されているのは、謙虚、尊敬、信頼のHRTを重んじろということだった。というと、かなり当たり前にように聞こえるが(実際当たり前でもあるが)、この本の根底には、昨今の規模の開発では個人プレイをあまり重視を重視すべきでないということがあるように感じる。

冒頭にある天才の神話が興味深く、ドキリとするエンジニアは多いのではないだろうか。

最高のギークファンタジーがあればこんな感じだ。最初に素晴らしいコンセプトを思いつく。そして、バットケイブに数週間~数か月こもり、アイデアを完ぺきな形で実装する。それから、そのソフトウェアを「大放出」する。誰もが君の天才っぷりに衝撃を受ける。同僚たちは君の頭のよさに感服する。誰もが君のソフトウェアを使うようになる。自然と富と名声が集まってくる。

これはエンジニアを目指す人間なら、あてはまる願望ではないかと思う。幼少からコンピュータや勉強が好きな子どもたちというのは、得てして人とのコミュニケーションが苦手であったり、軽視しがちだったりするものだ。また、自尊心が高い傾向があるかもしれない。そういった人たちにとっては、個人プレイによって得ることのできる富や名声は非常に抑えがたい衝動だ。

自分の好きなようにやればいいじゃん。そう思っているかもしれない。

それが違うんだ。ここでは君が間違っている。その間違いこそが大きな問題だ。

オープンコミュニティであれ、企業内の仕事であれ、ソフトウェアエンジニアリングにコミュニケーションやコラボレーションが必須であるのはもはや歴然たる事実である。世にでている「プロジェクトマネジメント」や「ソフトウェアエンジニアリング」と名のつく教科書は、だいたい人同士のコミュニケーションをどう定量的に扱うかについての議論に多くの紙面を割いている。ソフトウェア開発における最大の課題はコミュニケーションそのものなのだ。

多くの天才をかかえるGoogleがそのような考えを持っていることに多少の驚きを感じつつ、また共感を覚えた本だった。

  • -

ところで、最近こういったチーム運用の本を読むと、採用の話が頻繁に出てくる。いかに能力が高い人材を確保するかに多くの紙面を割いているし、この本でも同じ文化をもつ人材をどう採用するかの記述があった。新卒一括採用をしている企業ではあまり馴染みはなく、採用した集団の中央値がより大きくなるよう、また、最小値がある一定以下にならないように採用しているように思う。これは、採用後に配属をきめるという風習に起因していると考えられる。どこへ配属しても文句の出ない人材を採用する必要があるためだ。極端にコミュニケーション能力を欠いていてもだめだし、極端に礼儀がなっていなくても不採用だ。すべてが平均か、それ以上であればいい。逆に、例えば数理モデルに相当精通していて、たとえ担当部署がそれを必要としていても、あまり魅力的ではない。

Googleの採用方法は当初は奇抜さにフォーカスがあたっており、当時としてはその過剰ともいえる福利厚生や労働環境の厚遇が注目されていた。しかし、最近日
本であっても、スタートアップ等では、エンジニアは財産と考え、出来る限り厚遇するという企業はもはや珍しくなくなっている。

一方日本古来の企業や多重請負い構造をとる企業は、内部のエンジニアは人月をとるための人材でしかない。現場で日々強く感じることだが、彼らはプログラマというより、もはやコーダに近いのではないかとおもう。

彼らの技術力の高さというのは生産性が高いということなのであるが、これは、単に行数が多くかけるということであったりする。一見すると悪くないし、取引先や上司にも定量的に説明しやすい。だが、本当に優秀なコードというものは行数は少ないものになるはずだし、もはや行数ではなにも語れないであろう。一時間に多くの行数
がかけるからといって、必ずしも生産性が高いとはいいがたいし、ましてや技術力の高さを測るバロメータとしては明らかに不適切であろう。

採用の話では、採用後の教育のコストなどを考えた場合に、優秀な人材を逃すより、下手な人材を誤って入社させたほうがコストが大きく、リスクになるということが議論される。似たような話はJoel on Software日本語版記事でもあった。一旦採用した人材を教育し解雇するとなると非常にコストが高くつくためだ。日本の社会構造だと、更に解雇しづらい環境になるわけで、すると、より現場にあった人材を厳しく試験したうえで入社させるべきなんでないかと思った。

Windows 7でVPNを接続すると、Emacsが遅くなる

Emacs

背景

出張中、VPNで社内LANに繋いで作業していると、WindowsEmacsが非常に低速になってしまった。VPNを有効にした途端、やたら重くなってしまうのだ。とくにdiredやファイル読み出し、書き込みなど、ファイルI/O関連で遅くなってしまっているように思える。よくある問題だと思うんだけど、何故か日本語解説が全く出なかったのでメモ。
(特に外に出て行くSEなんかは、WindowsVPN使ってるなんてよくある状況に思えるんだけど、なんでほとんど情報が出なかったのか、不思議だ。。)

解決法

recentf-auto-cleanup

(setq recentf-auto-cleanup 'never)

を init.elもしくは .emacsに書き込んで 、eval-buffer。が、パフォーマンス改善せず。

w32-get-true-file-attributes

(setq w32-get-true-file-attributes nil)

を評価。すると、パフォーマンスがもとにもどって、これでヨシ。

コレは何か

GNU Emacs Manual: Windows Files

ここに解説があるように、Windowsファイルシステムに対して、権限の制御などをうまくやってくれる設定のようだ。これを有効にしておくと、理由はわからないけど、VPNでのパフォーマンスに問題が出るようだ。これにnilを設定した場合、上記の制御がきかないので、UNIXDOSファイルシステム差分をうまく制御できなくなるはずなんだけど。。ido-modeやdiredはきちんと動いているように見えた。逆にこれを設定するメリットがわからないほどなんだけど、僕は基本内勤で、VPNは頻繁には使わないので、VPN使うときだけ手動でOFFに設定にするようにしよう。