やまぐ雑記。

SIerからこんにちは、それ以外の話はよそでやってます

SIerで3つの現場にWikiを導入した話。

SlackをSIerに導入した話 が羨ましくて、同僚や上司に「こんな話があって―」と宣伝しまくっている今日この頃です。

これまでに3つの現場でWikiを導入しましたが、それぞれ使われ方に違いがあって面白かったのでまとめてみます。

1: 暗黙知が多いプロジェクト。

Wiki導入前

  • テスト用サーバのアドレスはもちろん、各工程の成果物さえも暗黙知
  • 「知っている人が隠し持っている(聞けば出てくる)」ということが多かった。

Wiki導入後

  • サーバのアドレス情報やシステムの用語集などが徐々に記述されていった。
    • 「ここに載ってる」と言えた。
  • コメント欄を活用して、システムトラブル時の状況がつぶやかれるようになった。
    • 朝出社して「昨晩トラブってたんだ…」と何となく把握できるようになった。

多少は効果があった。

2: 数百人規模なプロジェクト。

Wiki導入前

  • 決定事項が「メール」か「2017mmdd_打ち合わせ」フォルダのどちらかに埋まっていて、聞いた記憶はあっても資料に辿り着かない。
  • 手順書が不完全で、例えば開発のためにチェックアウトすべきプロジェクトが分からない。

Wiki導入後

  • 誰も書いてくれなかった。ので、自らコンテンツをモリモリ作成した。
    • 「手順はWikiに書いたから見て」と言えるようになって手間が減った。
    • たまに「Wikiの内容間違ってませんか」と聞かれた。みんな修正してええんやで。
  • コメント欄だけは活発で、顔も知らない人との交流の場になった。
    • 担当していない部分の情報をちょくちょく知ることができた。
    • プロジェクトが炎上しだすと荒れ出した。

3: 開発プロセスの改善がきちんと行われているプロジェクト。

Wiki導入前

  • 資料はほとんど揃っていて、困ることが少なかった。
  • 開発サイクルごとに、手順やツールはきちんとメンテナンスされていた。

Wiki導入後

  • Wikiはほとんど使われなかった。
  • 最近になってコメント欄がちょっとした息抜きの場みたいになった。

振り返ってみて、感じたこと

Wikiは「補完」的な位置付けなのかなと感じました。私自身もそういった使い方をしました。

プロジェクトで用意されている資料だけでは足りないから、Wikiで補完する。ひょっとすると、Wikiが活発なのはあまり良くない兆候で、寂れているほうが良いのかも? とすら思ってしまいました。

余談

各現場ともWikiは勝手に導入しました。Demo or Die(SI現場でいろいろ作った話) でも書きましたが、実際に動かして「ほら」と見せたほうが早い、という考えからでした。

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日は欲しいです」
リーダ「わかった。ただ、今後も遅れると危ないから、改善できるところがないか一緒に考えたい。あとで相談に乗って」

判断してくれる

メンバ「別の設計書にバグを見つけたんですが」
リーダ「そのバグは危ない。バグの修正お願いできる?」
メンバ「今の作業はどうしますか?」
リーダ「止めていいよ。タスクとスケジュールは見直しておく」

責任を持ってくれる

メンバ「すみません、修正ミスでした」
リーダ「いいよ。私がレビューしたんだから、私の責任だよ」

※新人だった私には衝撃的な言葉でした。と同時に、「リーダに迷惑を掛けないよう、自分自身で改善できることは積極的に改善しよう」とか「こんなリーダになろう」と思うきっかけになりました。


私もサブリーダの立場として、極力「エスカレしたい」で挙げた行動が出来るよう意識しています。

あとは、「作業が残ってても、『ベストを尽くした!』と思ったら帰っていいよ!」と言い続けています。

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日の生産性」は上がるのか?

blog.tinect.jp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

channel9.msdn.com

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

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


形骸化する品質分析

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

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

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

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

想定

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

1. 自己暗示

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

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

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

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

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

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

3. 早朝出社

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

邪悪なコードたち

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

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:言っている方は非常に多いですが…