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

やまぐ雑記。

SIerからこんにちは

Raspberry Pi@職場

Raspberry Pi テクノロジー

ときには楽しい話題も。

今更ですがRaspberry Piを買って職場に置きました。

本体: Raspberry Pi 3 Model B

f:id:yamaguchi-39:20170309232527j:plain

名刺サイズのちっちゃいコンピュータです。
詳しいスペックは Raspberry Pi - Wikipedia にありますが、USB 2.0x4ポートからGPIOまで遊べる要素が揃っています。

ACアダプタ付きで5,000円ちょっとです(KSY。Amazon.co.jpより安い)。

材料: HDMI 5インチモニタ(タッチパネル)

f:id:yamaguchi-39:20170309232534j:plain

今回は、組み合わせに小さなモニタを買いました。Amazon.co.jpで4,800円。

電源はmicroUSBかGPIO。GPIO接続時のみタッチパネル使用可です。

f:id:yamaguchi-39:20170309232541j:plain

モニタのほうが大きいですね。

OS: Raspbian Jessie with PIXEL (Debianベース)

f:id:yamaguchi-39:20170309232546j:plain

「ただのLinuxマシンじゃねーか!」というのが正直な感想です。あっさり動きます。
日本語化&日本語入力の環境も簡単。apt-get強い。

ソフトウェア: Cairo-Clock + 自作(Ruby+C#)

f:id:yamaguchi-39:20170309232554j:plain

職場の時計が平置きで見えない(壁の釘が短すぎて掛けられない)、そして開発用PCはインターネット接続不可、ということで、時計と天気などを表示させるようにしました。

天気の表示部分は自作。ページのスクレイピングRubyとNokogiriライブラリで、GUIアプリケーションはC#で(Monoランタイムで実行)。

あ、Flickr猫写真をランダム表示させる機能もついています。癒し。


余談になりますが、.NET互換環境であるところのMono、最初の頃はWindows.Forms未サポートだったのですが、 Compatibility | Mono を見るとWindows.FormsどころかC# 6.0まで対応しているんですね。LinuxでもC#でゴリゴリ動かせる場面が増えるのは嬉しいです。

残業で「1日の生産性」は上がるのか?

SE 読み物

blog.tinect.jp

ジェリー・ワインバーグは、プログラマにとってのデスマーチがどのようなものかを端的に説明している。

人は、期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ。 *1

この考え方は、その通りだと思う。

トム・デマルコ著「ゆとりの法則 (Slack)」を読んでなるほどと思ったのが、残業にまつわる話だった。

  • ごく短期間だけ全力ダッシュで作業をすすめる「スプリント」と、そうでない「だらだらとした時間外労働」は別物。前者はその瞬間だけ作業量を増やせるが、後者はそうはいかない
  • 知識労働の生産性は、時間ではなく日数による。つまり、1日の労働時間を増やしても1日あたりの生産性は上がらない

デスマーチに馴染んでしまっていると、この考え方はなかなか理解し難いのかもしれない。

「12時間かかる? じゃあ4時間残業すれば1日で終わるね」とか、そういう感じだ。

こうなると、品質は下がっていき、あるいは未完成の部分が隠されて、プロジェクトは進んでいく。

時間外労働と生産性や品質との関係について、計測していたり、教育していたりするところは、あるだろうか? 少なくとも私が担当したプロジェクトでは一切なかった。

エドワード・ヨードン著「デスマーチ」によれば、システム開発プロジェクトに携わる以上、政治的ないざこざは避けられないという。「残業」も、体を張った政治的なパフォーマンスなのだろうか。

一次請け・二次請けSIerに「技術力」が足りない気がする (品質分析編)

SE 読み物

配属されたプロジェクトが炎上していく過程を見ていくと、弊社や親会社(広く言うと一次請け・二次請けSIer)に「技術力」が足りないように思います。

いくつかテーマがありそうですが、まずは品質分析を考えてみようと思います。

バグの根本原因に辿り着かない品質分析

正しい根本原因に辿り着いていない品質分析、とても多いです。

私が観測した範囲では、2パターンありました。

パターン1: 品質分析を下請けに丸投げ

この場合、立場の問題などもあって反省文じみた空気感が強くなります。

となると、もれなく「レビューでの見落としでした。今後レビューを強化します」といった、根本原因に辿り着いていない内容が出来上がってしまうのです。これでは改善は見込めません。

バグの根本原因は、開発プロセスにあることがほとんどです。つまり、開発プロセスがバグを生み出してしまっていて、だから開発プロセスを改善して防ぐ、という考え方が必要なのです。

まずは、お互いがこの認識をしっかり持たなくてはなりません。 …とは言っても、本来は開発プロセスを作った会社がきちんと品質分析をすべきだと思います。

パターン2: アーキテクチャ開発プロセスを知らずに品質分析

それでもバグ票の必須入力欄は埋まる。最低だ。

残念なことに、 ”開発プロセスを作った会社” つまり我々や親会社が品質分析しようとすると、このパターンに陥ることが多いです。なぜか? 管理ばかりしていて、アーキテクチャ開発プロセスなんて知らない人ばかりだからです。

channel9.msdn.com

「作れなくてもよいが、勘所は知らないとダメ」

これが実践できている人は、ほとんどいません。管理ばかりしている場合ではありません。


形骸化する品質分析

「品質報告会(偉い人を説得させる会)があるから」とか「バグ票に必要だから」とか、形だけを義務的にこなして、品質分析が形骸化してしまっているように感じます。

形式的に品質分析をこなしている状態を放置するのではなく、品質分析・品質管理の体系的な知識・技術を持って「どんな品質分析をすべきか」「どこまでなら出来るか」を考える機会がないと、品質分析はお荷物のままなんだろうな… と思います。

デスマーチ気味の現場で倒れないために実践していたこと

SE 読み物

4年目くらいまでのみなさん向け。

想定

  • サブリーダや作業担当者
  • 残業時間は月単位で100時間以下、年単位だと700時間くらい

1. 自己暗示

自分が出来ることはすべてやった
悪いのは無茶振りするリーダだ
倒れたり死んだりしても会社は守ってくれない

「他のメンバが頑張っているのに…」などと罪悪感・無力感が湧いてきても、
とにかく「出来ることはやった」と思い込む。

2. 自分ルール「22時退社」

「ここは譲らない」という線を引き、それを守る。

自分の場合は
「ご飯食べて風呂入って1時間ぼーっとして*1、5時間寝る」
という生活リズムを守るため、いつも22時には退社するようにしていた。

仕事が終わっていなくても、他のメンバが終電や徹夜でも、
そのまま居続けて生産性は上がるか? 上がらないなら帰ったほうが良い。

3. 早朝出社

  • 午前中のほうが集中出来る
  • 人が少ないほうが集中出来る

というタイプにオススメ。
始業時間までに早くも達成感が得られるので、ネガティブ感情が和らぐ。

サブリーダにとっては、作業が中断されない、というのも大きなメリット。

4. 例外が起きたらプラスマイナスゼロにする

緊急会議が24時に終わった、というふうに例外が起きると、
生活リズム(自分ルール)が崩れ、限界だと思っていたラインを超えてしまう。

その時に「今日だけは仕方ない」と思わず、
数日中にプラスマイナスゼロにすること。絶対に。

自分の場合、午後出社をキメることが多かったかな。

5. 平日に小さな楽しみを作る

休日に遊べる気力など、滅多に湧いてこない!

例えば通勤時にコミックやネットラジオや動画などでなんとかする。


以上、よく考えたら大した話じゃなかった。

結局、「自分にとってココが限度」と思うラインを超えないのが大事。
「ちょっとくらい」と思うと、それが常態化してしまうので、そこは許さないように。

これまでの経験では、このスタイルで責任を問われることはまずありません。

*1:何故かは分からないけれど、1時間ほどPCに向かって無駄な時間を過ごさないと寝れなかった

SIerで、どうすれば邪悪なコードを減らせるのか?

SE 読み物

※多少ぼかしていますが実話です。

邪悪なコードたち

こういうコードに遭遇することがあります。

private boolean customerName() {
    boolean returnValue = false;
    // 姓がnullでない かつ 名がnullでない のとき、trueとする
    // 当てはまらない場合、falseとする
    if (this.SEI != null && this.MEI != null) {
        returnValue = true;
    } else {
        returnValue = false;
    }
    return returnValue;
}
  • customerNameというメソッド名で処理が想像できない。
  • returnValue変数の存在意義がよくわからない。
  • コメントは必要だろうか。条件式を日本語化しただけのように見える。
  • SEI, MEIは定数なのだろうか。
  • else節でfalseを代入する必要はあるだろうか。

頭が痛くなります。

あるいは、こんなコードに遭遇することもあります。

public String 顧客情報を登録する(
    String 姓,
    String 名,
    String 姓カナ,
    String 名カナ,
    SeibetsuEnum 性別区分,
    String 生年月日,
    String 郵便番号,
    String 都道府県,
    String 住所_1,
    TelEnum 電話番号_1_種類,
    String 電話番号_1,
    TelEnum 電話番号_2_種類,
    String 電話番号_2,
    …
    (あんまり長いので省略)
    …
    String 勤務先名称,
    String 勤務先所属,
    String 勤務先役職,
    String 勤務先郵便番号,
    String 勤務先住所
    ) {
    // 引数の情報を使ってDBにデータを登録する
    (以下省略)

引数を贅沢に使った美味しいスパゲティです。私は食べませんが。

ストレス、ストレス、ああストレス!!

ああ、思い返すだけでもストレスが溜まってしまうようなコードたちです。

炎上しているプロジェクトほど、こうした邪悪なコードを見かけます。

どうすれば、炎上したままこうしたコードを減らせるでしょうか?

まだ、完璧な答えは持っていません。悪い答えと、ちょっとマシな答えはあります。

悪い答え

  • コーディングチェックリストを運用する。
    • だいたい形骸化してやらなくなるか、やったことにする
  • きちんとレビューをする。
    • そんな余裕があったらとっくにやっている。

ちょっとマシな答え

  • 機械的なチェック、例えばcheckstyleFindBugsを使う。
    • 完璧ではないが、レビューするよりは大分コストが小さく済む。
      (個人的には「Javaの一般的な命名規約だとか、"参照型変数"くらいは知っててよ…!」という思いではある)
  • チェックリストをほんの数項目だけ用意する。
    • 頻出部分を厳選して用意して、まず60点を目指す。
  • レビューは諦めるが、たまにコードを見て直接本人と話す
    • 「本人のスキル向上(教育)」という側面で、レビューまではいかないけどちょっとでもやる。
  • リーダブルコード(オライリー本)をそっと置いておく。
    • 「この本で読んだ内容なんですけど」と言うとすんなり受け入れてくれたり、興味を持ってくれたりする。

完璧な答え

あったら教えろください。


余談: 「三現主義」

富士通の行動指針には、こういうセクションがあります。

三現主義 … 現場・現物・現実を直視して行動します

「レビューをちゃんとしろ」「チェックリストをちゃんと運用しろ」「ちゃんと」「ちゃんと」…
…現場を見ていれば、こんなセリフはとてもじゃありませんが言えません*1

作業量を増やさずに、品質を上げる。
または、品質を維持したまま、作業量を減らす。

こういう考えをもって、じゃあ、何ができるだろうか? と考えるようにしないと、いつまでも溝は埋まらないままです。

*1:言っている方は非常に多いですが…

Demo or Die(SI現場でいろいろ作った話) - Fujitsu Advent Calendar 2016 13日目

SE 読み物

Fujitsu Advent Calendar 2016 13日目の記事です。

ワクワクする夢の技術ではなく、ドロドロした現実の現場での話。

Demo or Die

Demo or Die ―デモを見せられないアイディアは、死んでいるのと同じ。
MITって大学のメディアラボのスローガンだ。うちの研究室はこの文化でやってるよ。

大学教授の言葉がずっと印象に残っています。動かさなければ意味は無い、と。
小学生の頃からプログラミングが楽しくて、社会に出てもその道で人を幸せにしたいと考えていました。

入社して

配属、そして疑問

いわゆる"客先常駐型"の、開発プロジェクトごとに人が集まる現場に配属。

言語はJava、人数は約60人。既に稼働し、改修や保守を行うフェーズでした。
たくさんの人の役に立てるシステムに携われるんだ、とワクワクしていました。

ほどなくして、不思議に思うことが出てきます。

  • 配属初日、偉い人に「SEは体力だからな!」と言われる。
  • "自動化できそうな手作業"がたくさんあって、しかし手作業のまま続けている。
  • 問題が起きると、解決せずに"避ける"ための面倒なルールを作る。
  • Software Designオライリー本を出すと、値段を見てびっくりされる*1

…ここは本当にIT企業なのか?
まずは、自らがITをもっと活用すべきでは? と思うくらい、"泥臭さ"の漂う現場でした。

葛藤、のち行動

嫌だ、どうにかしたい。でも、新人に何が出来るのか。
入ったばかりの新人の意見など取り合ってくれません。そもそも誰に意見をすればいいのやら。

そんなとき、『Demo or Die』を思い出しました。
そうだ。つべこべ言わずに実際に動かして、見せつけてやろう。よりよく出来ることを証明してやる。そんな意気込みだったと思います。

Demo 1: Alt+Tabキーの早打ちをやめる ~試験結果の一覧表示~

ユニットテストは、実行結果を1ファイルずつ開いて確認する面倒なものでした*2

テスト仕様書(Excel)、エクスプローラ、それにテキストエディタを素早く操作するスキルが求められました。皆、フルHDに満たない解像度のディスプレイでAlt+Tabキーを酷使していました。

違うやり方を作ってしまう

実行結果を下記のような表形式にまとめて出す、というGUIツールを作りました。

テストNo 実行日時 終了ステータス エラー情報
test-01 12/13 9:45:15 00 (正常) -
test-02 12/12 9:45:17 91 (システムエラー) (例外発生)
test-03 12/12 9:45:18 11 (チェックエラー) 項目: ID, NAME

言語はJavaGUIツールキットはSWT。起動すれば表示は自動更新。
テストを実行したら、あとは表示が更新されるのを待つだけになりました。

反響

幸いだったのは、OJTのトレーナーがいたことと、新しいものに抵抗を示さない人が一定数いたことでした。

「新人がこんなの作った」「なにこれ、めっちゃ楽じゃん。ちょうだい」
ツールは徐々に浸透し、プロジェクトの便利ツールフォルダにめでたく入りました。

Demo 2: ビルド、ビルド、ビルド! ~自動ビルド~

2年目にして製造サブリーダという謎の立場になりましたが、
ソースコードの管理やビルドにあたって、いくつか問題が起きていました。

  • コミット漏れなどでリポジトリ上のソースがビルド出来なくなっても気づかず、別の誰かが困ってようやく発覚する。
  • テスト用サーバへデプロイする資産をPCでビルドするのに10分掛かる。
  • 誰かが時折古いソースでビルドしたものをデプロイしてしまい、別の誰かのテストが突然失敗しはじめる。

これらの問題を"回避"するために設けられたルールは窮屈なものでした。

「フォルダ全体でリポジトリと差分チェックし、コミット対象を洗い出すこと」
「PCでビルドする前に、リポジトリとの差分チェックを必ずやること」

たった1行、条件式の不等号を逆に修正するだけでも大変な作業量でした。

どうしてこんなことになってしまったのか。

そもそもデプロイ資産のビルドって各自でやる必要あるっけ?

答え:ない。まっっっったくない。

継続的インテグレーション」が外で叫ばれる*3中、テスト用サーバで自動ビルドさせようと考えました。
が、常駐先PCはネットワーク的に外と隔離されており、Jenkins等は導入できません。

しかし、幸いなことにテスト用Linuxサーバにrubyが入っていました。
WEBrickという標準ライブラリを使用して、Webサービスを立ち上げられるのです。

メールを全員に出しました。
「自動ビルド、はじめました。もうPCでビルドする必要はありません」
ビルド結果のメール通知機能も備え、失敗にすぐ気付けるようになりました。

f:id:yamaguchi-39:20161210203521p:plain
(※再現イメージ)

自動ビルドの利用はスムーズに進みました。誰だって楽をしたいですからね。

Demo 3: 探し回るのをやめる ~ファイル名検索エンジン~

複数のファイルサーバに数十万ファイルが散らばっていました。
当然、Windowsのファイル検索機能は役に立ちません。

「手順書、探しても見つからなくて。どこにあるんですか?」
「えっとね、このフォルダじゃないな… ここ…でもないか。じゃああっちかな… ああ、あった、ここだよ。フォルダのパス、メールで送るね」

こんなやり取りもしばしば。
表面上は「1分のロス」ですが、作業の中断(コンテキストスイッチ)は集中が途切れてしまうので、実質1分じゃ済まないのでは… と思っていました。

ファイル"名"検索エンジン

Namazuのような全文検索システム*4がほしい。
そうでなくとも、単にファイル名を検索できるだけでも、便利になるのでは?

レビューに飽きてコーディング欲が限界に達し、土曜日に出社して
再びRubyWEBrickライブラリを使ったWebサービスを作成しました。

ファイルサーバへの接続はmount.cifs、ファイル名のインデックス化はfind。
Excelファイルに限って、JavaApache POIライブラリ*5全文検索に対応。

ひと目でどんなサービスか分かるよう、ロゴはGoogleそっくりに。

f:id:yamaguchi-39:20161210202655p:plain
(※再現イメージ)

「すごいね。別のファイルサーバも検索対象にできる?」
これまでと違い、製造工程以外の方からも好評でした。

季節ごとにロゴを変えたり、いいね!に相当する"ハラショー!"ボタン*6を追加したりと、ちょっとした遊び心を付け加えました。

波及

これらの"Demo"は、最小限のメンテナンス手順を記して引き継ぎました。
私がプロジェクトを離れてからも使われていると聞いています。

嬉しかったのは、こんな言葉でした。

「私もツールを作ってみようと思って書いてるんだけど、ここどうしたらいい?」
「影響調査は機械的な方法、例えば全文検索でやろう」

私のやってきたことが、ちょっとだけ周囲に"響いて"いるようでした。

プログラミングで人を幸せに出来ているか?
少なくとも、現場はちょっとだけ幸せになったはずだ、と思っています。

別のプロジェクトに移ると、前のプロジェクトでお世話になった方がいました。
「前のプロジェクトで動かしてたアレ、ここでも動かさないの?」

or Die (限界)

と、偉そうに書きましたが、すべて順調かというとそうではありません。

失敗したDemoは倍以上ありますし、そもそも変化はとても小さなものです。
大きな変化を起こすには… おそらく、面倒なプロセスが山ほど。

このまま現場に居続けて、現場を変えることにこだわる必要はあるのだろうか。
そういう考えがあるのも確かです。

いいアイディアなら、さっさとやってしまえ

私は名言を都合よく使うことが大好きです。

Step Back and Automate, Automate, Automate
面倒でも自動化できることは自動化する
Cay Horstmann (ケイ・ホルストマン)

Kevlin Henney編 (2010)『プログラマが知るべき97のこと』
和田卓人監修, 夏目大訳, オライリー・ジャパン

プログラマの三大美徳は「怠惰」「短気」「傲慢」です。
目の前の機械を活用して、楽になる。そのための手間は惜しみません。

If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
いいアイディアなら、さっさとやってしまえ。許可を得るよりも謝るほうがずっと簡単だから。
COBOL開発者 Grace Hopper (グレース・ホッパー)

やってみたいことがあるなら、とりあえず、やってみませんか?

*1:技術書に縁のない方も少なくありませんでした

*2:JUnitテストは書くのが大変だから」とのこと

*3:「知ってますか?」と聞くと皆だんまりです

*4:脱線するけどNamazuしか思い浮かばないのが悔しい

*5:Microsoft Office形式のファイルを読み書き出来るライブラリ。ただしバージョンが古かったので、xlsx形式の解析はオレオレライブラリを作成

*6:通じたの1割くらいだった

SEになる新人さんに言っている3つのこと

SE 読み物

SEといっても、新人さんには極力プログラミング・単体試験を最初にやってもらっています。

そんな新人さんに呪文のように言っていることが3つあります。

エラーメッセージはお友達

エラーメッセージ読んだ?
エラーメッセージはお友達。原因を教えてくれているのに、見ないなんて勿体無いよ?

プログラムがうまく動かないことなんて日常茶飯事です。
そういう時は、まずエラーメッセージを読む。

「エラーメッセージ」なんて嫌な名前が付いていますが、実際は「ヒント」です。
もう大ヒント。そこに答えがあると言っても過言じゃないくらい。

"よくわからんけど適当に直したら動いた"だけは、ご法度。
知識にならないので、後で苦労します。

定時だよ、さあ帰ろう

定時だよ。終わってない? 終わってなくても帰ろう。
でも、きちんと今日を振り返って、明日は今日よりちょっとだけ上手く出来るようになろう。

「終わらないので残業します」という新人さんもいますが、「ダメ」って言います。
単位時間あたりの生産性を高め、定時で終わらせる、ということにこだわります。

難しい。残業をするよりも定時で帰るほうが遥かに難しい。工夫のしどころです。

現場はとにかく"残業は当たり前"という空気で満ちています。
そういう空気を少しでも変えていきたい、という思いもあります。

(私の場合、そうしたところで給料や評価に結びつくことはほとんどありませんでしたが… それが一番問題かもしれません)

それキーボードでやってみよう

ちょっと待って。戻して。キーボードでやってみよう。
Excelで次のシートに進むには、Ctrl+PageDownキー。はい、やってみて。

新人さんの一挙手一投足はとにかくよく見ます。
横で普通に作業をしているフリをしますが、視界にきっちり入っているので見ています。

「キーボードで操作したほうが早いかも」と思ってもらえるまで、
申し訳ないけれど、キーボードで出来そうなマウス操作はじゃんじゃん止めます。

1年もするとキーボード操作が当たり前になっていて、
私の知らないショートカットを使うようになっています。結構焦ります。


ということで、私が新人さんに言っている3つの呪文でした。
もっと良い呪文があればお待ちしています。