リーダーシップ

偉大な人とは並外れた意志を持った普通の人である。
(カルロス･ゴーン)

僕はこの言葉を心から信じている。

僕が出会ったすごい人たちもこういう人だった。
こういう人たちは、厳しい課題を乗り越え、経験を積むことでリーダーになっていった。

僕はこういう人たちに育てられてきた。
だから僕は自分に自信を持ちたい。

優れた本やマネジメント知識体系はとても便利だけど、
リーダーシップは実践でしか学べない。

辛いとき、彼らから学んだことを思い出すと踏み出せる。

混乱するプロジェクト

システム再構築のプロジェクトに参加している。
保守をやっていたという理由で先輩がＰＬに任命されている。

マネジメントを学ぶこともなく、
チームプレー経験も少なく、個人作業がほとんどの人だ。
先輩にとっては大きなチャンスかもしれない。

昔に読んだ記事。
■PM,PLになるために必要な条件
①マネジメントを体系的に学んだことがある
②優れたPM,PLのチームに参加したことがある

なるほど。

若手の教育を目的に①②が無くてもチャンスを与えることが多い。
しかし、要件定義から大混乱。
マネジメントが弱すぎる。

ＰＬは、頑張って建て直したくても、どのようにすればいいのか分からない。
苦痛の日々を送っているだろう。
僕も過去を振り返ればこれが一番辛かった。

辛くて逃げ出したくなることも多い。
そんな自分を救うのは、やり遂げる強い意志。

ＰＬ自身が潰れなければいいが。

そんな中、体制の見直しが検討されはじめた。

懐かしい感動

海外にあるシステムとオンラインで繋ぐ。

通信経路暗号化ソフトとメッセージキュー伝送ソフトを利用。
海外の技術者と電話で確認しながら設定をテスト。

最近は管理、顧客折衝、仕様作成が多い。
このように自分で設定やスクリプトをいじくり回すのは久しぶり。

なかなか上手く行かなかったけど、動いてくれると嬉しい。
懐かしさのあまり感動すら覚えた。

生涯プログラマーを目指す人の気持ちが分かる気もする。
マネジメントが注目される昨今、プログラマー復権の時代がいつか来る！かも。

安心を与える

システムの要求仕様書を作成。
顧客の担当者とレビュー。
レビューのポイント

・要件の曖昧箇所排除
・問題解決方法の提案

顧客に理解してもらえる形式を意識したからか、質問や確認も多く出た。
問題解決のためのロジックを提案。
提案はずーっと頭を悩ませた内容。
それでも、顧客に5分で懸案を指摘される。
悔しい。。。
けど呑める範囲の懸念なので問題なしとのこと。
持ち帰って検討してもらう予定だったが、その場で答えが出た。

すべて了解。
要件を整理できて顧客担当者も安心したようだ。


兎にも角にも、スケジュールがタイト。
納期遅延は業務ストップに繋がるので不可。

顧客担当者は段々と安心してきたようだ。
次は顧客責任者に安心を与えたい。
これも我々の仕事であり、
安定したプロジェクト進行のためでもある。

レビュー後は顧客責任者へ状況報告。

難しい顔していたけど、話すと笑顔。

皆が気持ちよく働けますように。

プロジェクトリーダー研修

今日はプロジェクトリーダー研修。
基礎編は既に受講済みなので応用編受講。
品質と契約を中心に問題を解きながらディスカッションする。

■　品質
リーダーをやってから品質には敏感になった。
自分でチェックしないと怖くて仕方ない。
プロジェクトの現場ではテストが十分でないまま納品物として上がってくる。
テスト方法を考えずに設計するから、テストできずに作りっぱなし。
身の毛もよだつ話です。

■　契約
いつも自分のプロジェクトの契約内容に目を通しているが、法律が絡むと難しい。
難しいというより分からない。。。
契約内容を知らないで仕事することの恐ろしさ改めて感じる。

日経ITプロフェッショナルに「IT関連法律」の記事がある。
これをきっかけに読み返してみようかな。

残業

今日は休日出勤。

プロジェクトで、技術的に不明確な点があるが、海外の技術担当と時差の関係でリアルタイムで答えが出ない。
それに、先週は祝日があり、営業日が少なかった。
これにより、スケジュールが予定よりも少し遅れている。

というのは言い訳。
事前に手を打つことはできたはず。

役割と仕事量が多くて苦労しているが、これも対策を立てらたはず。
作業を人に任せる。僕が厳しくチェックする。
それだけで僕の時間は大幅に節約できる。

仕事の進め方は、いくらでも工夫しようがある。

そもそも残業ができる環境は、社員の仕事の仕方を工夫する意識や、業務時間の能率を下げていると思う。
今やらずに夜にだらだらやることを考えてしまう。
チームプレーが必要なシステム開発の仕事は、一人の作業に影響を受けやすい。
一人の集中力の欠如がチームの作業期限に影響を与える。

解決には、まず、残業ができる環境を無くすと。
労働裁量制だから残業代不支給と言っても、社員は残業してしまうし、会社は労働力泥棒と言われてしまう。
残業させない環境を作ることが大切。

朝型の僕がルールを決めていいなら、
業務時間は9:00～18:00。
18:00以降残業禁止。
禁止なので残業代支給なし。
むしろ電気代を残業者から徴収したい。

一方で朝の6:00～9:00は残業可。
(残業という名前はヘン？）
しかも残業代(業務時間外手当)は多めに支給。

朝なら静かで集中して仕事もできる。
業務が始まる前なら体力もある。
満員電車に乗らなくて済む。
夜の仕事よりも能率が上がる気がする。

細かい法律や規則とかは、その道のプロと相談で、大枠はこんな感じ。
ダメですかね？

タコライス

タコライスは、気軽さといい、ボリュームといい、辛さといい、夏にピッタリの料理。
昨晩は夏に買ったサルサソースが残っているので、タコライスを作る。

僕のタコライスにはアボカドが欠かせない。
挽き肉と辛めのソースによく合う。
サラダ豆も入れたかったけど、欠品なので我慢。



　サルサソース
　挽き肉
　チーズ
　アボカド
　トマト
　レタス
　サラダ豆
　タコスチップ
　タバスコ

やはり美味しい。
ボリューム満点！！
どうだ、参ったか！！
老若男女、みんなのお気に入り！！

夏にピッタリの料理だけど、具をアレンジすれば冬にもいけるかも。

開発のアプローチ

強力な支援 をくれる技術者さんと打ち合わせ。
依頼する作業を説明し、進め方を詰める。

実装を中心にお願いするが、詳細設計から一緒にやりたいと僕の提案も聞いてもらう。
僕の開発の進め方と、技術者の考え方は難なく一致した。

設計書の位置付けについても触れる。

作成するのは必要最小限で十分。

初期段階から仕様策定者と実装担当者の意識合わせを行いながら最小限のドキュメントを作成する。
ここで僕が要求仕様をまとめ基本設計とアーキテクチャを定義。
それから実装担当者と詳細仕様を一緒に詰めながら、実装していく。
実装しながらまた仕様の調整。そして実装。
段々と作っていく。

よく語られる方法だが、これが一番うまくいく。

あと、仕様書は顧客側担当者・承認者にも理解できる通常の日本語表現で詳細に表現することも忘れちゃダメ。
お客さんに分かるドキュメントは、プロジェクト後半に参加した技術者も理解しやすい。
大切なのでメモしておく。

昼のチャイム

12時に鳴る昼休みのチャイム。
チャイムが鳴ると休まなければいけないと反射的に思い、仕事への集中力が途切れる。

しかも、このチャイムで皆が席を一斉に立つ。
仕事モードに入っている時、これをやられるととても嫌な気分。

仕事を止めたくないときもある。
お腹がすいていないときもある。
休みなんていらないときもある。

工場や学生の授業は皆が一斉に休まなくちゃいけないけど、自己裁量で働く場合は、昼休みは各自で好きな時間に取ってもいいルールがいい。

それが無理で、12時から昼休みのルールでもいいけど、せめて12時のチャイムだけは鳴らさないでほしい。

誤字脱字

作成した資料のレビューをお願いした。
事前に資料を配布したら、誤字脱字があることを指摘される。
配布前にチェックを怠った。情けない。。。

基本ミスが目立つ資料は読む気も失せる。

僕が読み返せば気持ちよく皆に参加してもらえる。
僕が読み返さなければ皆の協力を失い、多くの時間を無駄にする。

少しの時間を惜しむことによる代償は大きい。
時間に追われていると忘れやすいようだ。