札幌での住環境がオサレすぎる件

こんにちは。

さっぽろ入りして早3日。

今日は札幌でのウィークリーマンションに大層感激しているのでご紹介します。

 

まーずーは!デデーン!外観!ヒュー!オッサレー♪

さすが、2015年1月に出来た新築物件!!

オートロック玄関&ディンプルキーでセキュリティも万全。

IMG_0284

 

続いてー、テッテレー♪ リビングー!

(あ、この時は電気のつけ方が判んなかったから暗い・・・)

しかし、最近のマンションはUSB充電口が壁コンに埋まってるんですね。スゲー。

IMG_0287

 

そして、個人的には超大事なお風呂と独立洗面所!

洗濯機もHaierじゃなくて、Panasonicだ!ドヤァ

お風呂は自動でお湯はりしてくれるし、追い炊きもあるんだぜ!

IMG_0290 IMG_0289

 

今回はお湯沸かすくらいしかしないつもりだけど、コンロはIH3口だ!

ちゃんとグリルも付いてるよ!(あ、トースト焼けるな、そういや。。。)

IMG_0288

 

というわけで、超オサレ物件で快適な日々を過ごしています。

お忙しいところ、方々当たって手配してくださった総務部の方々には感謝しまくりです!

 

 

食生活もラーメン、エビ、ウニ、牡蠣、山菜、ソバ・・・と着々と制覇中です。

あとはセイコマのちくわパンや。セイコマサイコー。九州にも欲しい。

 

そんな訳で、お仕事の方も成果出さないといけないですね。

はい。頑張ってきます。

 

合同会社説明会に出展しました

先日(5/18(水))に北九州市の西日本総合展示場で開催された

合同会社説明会へ出展しました!!(^^)/

たくさんの学生さんにご来場いただきました(^^)/(^^)/

ありがとうございましたm(_ _)m

P_20160518_142438 P_20160518_131917

 

私は説明会三回目の参加ですがブースの飾り(?)もだんだん進化しています笑

P_20160518_162453

教育・訓練 2015年09月~2016年03

1.「成功」のカギはコミュニケーション
【要点】
激しい議論をしたり,みんなと違う意見を言うメンバーの存在を悪ととらえてはならないということ

・文書化のスキルが不可欠
失敗しているプロジェクトを見ると,文書化のスキルが不足していることが多い
プロジェクトマネジャやチームメンバーはまず,自ら筆まめになるように心掛けたい
ドキュメントを書いているより,行動が先だ」となりがちだが,そうした行動を続けていてはかえって問題が大きくなる。

信頼関係がすべての基本

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070706/276988/?rt=nocnt

【感想】
確かに文書化のスキルは必要不可欠。
初期の開発できちんとしたドキュメントを作らず、後後になってきちんとしたドキュメントを作ろうとする所が初期メンバーから曖昧に引き継いたメンバーが曖昧な言葉でしっかりとした文面にしかならず、結局ソースから設計書を起こすというパターンはよくありますが、こんなパターンにこそ同じ事を繰り返さないためにも文章化のスキルは必要なんだとしみじみ実感致しました。

2.新・リーダーの品格
【要点】
ヒューマンスキルはIT業界での強みに
会社のトップマネジメントは、上に上がれば上がるほど、社内の部門長から報告を受け、それに対して指示を出す直接的なコミュニケーションの時間が増える。
まずは同僚とうまくコミュニケーションできているのかというベースの部分がポイント
次に人を束ねられるか、といったマネジメント力が求められます。

自分の未来を決断する
「優れたリーダー」を目指すのか?何人規模のプロジェクトをまとめられる人材になりたいのか?ずっと現場で活躍し続けたいのか?
エンジニアリングサイドとビジネスサイドのどちらを志向するのか

どう転んでも必要な「人間力」

【URL】
http://news.mynavi.jp/series/Leader_hinkaku/002/

【感想】
どう転んでも必要な「人間力」

どちらかというと「人間力」というか「人心掌握術」のほうが正しい表現では?と思ってしまう記事でした。

3.PM実践体系–重要性増すPM,そのシステム開発での実践体系を知る
【要点】
「いかに予算や納期を守り,バグの少ない高品質のシステムを構築するか。それこそがプロジェクト管理の要諦だ」。日本の多くのITベンダーやソフト開発組織は,今なおこうした“旧態依然”の考え方から抜け出せていない
しかし、「しっかりした体系的知識や方法論に基づいて,プロジェクトの立ち上げから終結までを,統合的にマネジメントする」という考え方をベースにした,新しいマネジメント技法が脚光を浴び始めている。

実質的標準のPMBOK・・・「PMの体系的知識」として国際的なデファクト・スタンダードとなっている。ISO(国際標準化機構)が策定した「プロジェクトマネジメントにおける品質の指針」(ISO10006)のベースにもなっている。
個人の経験や考えではなく,欧米における多くのプロジェクトの経験やノウハウを体系的な知識としてまとめていること。
【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070221/262666/?ST=selfup

【感想】
これはさらに上の管理職の問題だと考えておりますが、「プロジェクトマネジメントにおける品質の指針」(ISO10006)は一度目を通してみようかと思います。

4.プロジェクト計画--システム開発プロジェクトの「計画」を作成する
【要点】
コミットメントを明確にする
「プロジェクト目標の明確化」・・・システムの稼働環境や開発環境を決める
「開発対象と環境の最適化」、「開発方法論と工程の定義」・・・利用する開発方法論や開発手法,適切な開発ツールを選定するとともに,そのプロジェクトに適した開発工程を定義する
「見積もりとリスク査定」・・・開発範囲やシステムの規模,取り扱うデータ項目の多さ,開発生産性などの前提条件に基づいて,開発工数と開発期間を見積もる
「WBS(Work Breakdown Structure)とスケジューリング」・・・プロジェクトマネジメントで計画を立てる際に用いられる手法
「文書化計画」・・・ユーザー企業に納品する要件定義書や設計書,運用マニュアルなどの文書の作成および納品時期,作成者,文書の品質管理方法などを計画する
「組織計画と要員計画」・・・。要員計画では,まずフェーズごとに必要なスキルの定義を行い,直近のフェーズについては具体的なアサイン(誰が担当するか)まで決める
「教育計画」・・・最後に「必要となるスキルの種類」や「そのスキルが必要とされる時期」に応じて,プロジェクト・メンバーの「教育計画」を作成する。

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070314/265142/?ST=selfup

【感想】
上記の点が今の仕事にどれだけ当てはまり、どれだけ当てはまらないのかを明確し、何故当てはまらないのかを分析してみるの良いかなと考えております。
次回の教育ネタ?

5.品質管理計画--プロジェクト全体を通じた品質基準や方針を策定する
【要点】
プロジェクトマネジメントにおいて何を行うべきか。世の中には欠陥を未然に防いでくれる魔法のツールも,エラーを排除できる画期的な設計手法も存在しない。慎重かつ地道な,品質向上活動があるのみである。
プロジェクトのスケジュール遅延とコスト超過を防止し,しかも高い品質を確保するには,自主検査やレビュー,テストなどの「欠陥除去工程(Defect Removal Processes)」,いわゆるバグつぶしを必要なときに適切に実施しなければならない。そのためにはプロジェクトの計画段階で,欠陥除去工程のスケジュールや方法,目的などをまとめた「品質管理計画」を策定しておく必要がある。

システム開発における欠陥除去をテストだけに頼っていると,品質管理のコストは非常に高くついてしまう。多くの欠陥は,要件定義フェーズや設計フェーズといった上流工程で発生しており,その発見時期がテストなどの下流工程にずれ込めばずれ込むほど,修正に時間がかかるからである
事実,大規模なシステム開発における欠陥の45~80%は,要件定義や設計段階における問題に起因することが,全世界のIBMの経験から分かっている

【URL】
http://itpro.nikkeibp.co.jp/article/COLUMN/20070404/267404/?ST=selfup

【感想】
上記の点が今の仕事にどれだけ当てはまり、どれだけ当てはまらないのかを明確し、何故当てはまらないのかを分析してみるの良いかなと考えております。
そもそも品質基準の基準の定義から考えてみるのも面白いかなと考えております。
次回の教育ネタ?

6.初めてのプロジェクトリーダー(1):開発者からリーダーへの視点の切り替え
【要点】
3つの切り口:「価値」「原則」「実践」 ※ 「実践」については(2)を参照。
「価値」・・・私は、リーダーが守るべき価値は3つあると考えています。それは、「チームプレイ」「顧客満足志向」「中庸であること」です。
「原則」・・・何か意思決定をする場合に、まずは、これらの原則を切り口にして考えをまとめ、判断し、行動に移します「シンプルイズベスト」「管理というよりは演出」「チームは一期一会」「目的、課題、アクション」。

【URL】
http://www.itmedia.co.jp/im/articles/0503/09/news104.html

【感想】
「価値」・・・「中庸であること」これについては、少し疑問を持ってしまいますね、極端な思考はあまり良くないと記載されておりますが、極端な思考は決断する上では重要な要素だと個人的には考えております。
この記事は少し組織的すぎる考えたのようですね、悪いとは言いませんが少し違和感を感じてしまいます(「原則」のシンプルイズベストと言っていることが矛盾するのでは?)
「原則」・・・「目的、課題、アクション」の明確にすることやはりこれが一番重要だと思いますね、大抵ろくなPJはこれが明確になっていないから無駄に迷走する形になるんですよね~(遠い目をしている私www)

7.初めてのプロジェクトリーダー(2):なにはともあれ、まずはチームビルディング
【要点】
役割分担・・・バリバリ進めていく必要がある機能は「アタックタイプ」既存の技術を使って、じっくり慎重に進めていく必要がある部分は「ディフェンスタイプ」仕様全体をつかむ「バランスタイプ」

【URL】
http://www.itmedia.co.jp/im/articles/0504/06/news092.html

【感想】
タイプ分けは、確かに良い考えかと・・・今までの仕事を振り返ってみると「ディフェンスタイプ」ばっかの人間が多かったり、「バランスタイプ」の人がいない場合とかあって酷い目にあったことが・・・私としてまずは、この人がどのようなタイプを意識してみます。

8.初めてのプロジェクトリーダー(3):朝会を15分で終わらせるには理由がある

【要点】
[朝会のポイント1] チームの状況を語る
[朝会のポイント2] メンバーの顔色をうかがう
[朝会のポイント3] アクセル&ブレーキ
チームのスピードを上げる(アクセル)、下げる(ブレーキ)

【URL】
http://www.itmedia.co.jp/im/articles/0505/11/news101.html

【感想】
[朝会のポイント2] メンバーの顔色をうかがう
[朝会のポイント3] アクセル&ブレーキ
↑ そんな暇がないと言って、状況だけを語る。
そんな朝会しか見たことない
これは理想論ですね

9.初めてのプロジェクトリーダー(4):開発中、リーダーは何をしている?

【要点】
進ちょくの見える化
運用の注意点
1) タスクの粒度がそろっている
2) メンバーに経験者が多い
3) 期限が比較的長い

【URL】
http://www.itmedia.co.jp/im/articles/0506/15/news112.html

【感想】
リーダーとしてすべき点また状況次第での対処?が書かれておりこの要点を次の教育のキーにして理解を深めるよいものかと考えております。

10.初めてのプロジェクトリーダー(5):リーダーとしての問題解決能力を磨く

【要点】
真実より事実
分類と切り分け
理論と理屈
現実的な解決策
責任の取り方
パフォーマンスが出ない
1. 計測する
2. 目標を設定する
3. 分類し、分析する
4. 解決する

【URL】
http://www.itmedia.co.jp/im/articles/0507/08/news115.html

【感想】
自分や自社にとっての”都合の良い真実”よりも常に”客観的な事実”で物事を見る。
これは、今の現在の大きな課題の一つであり、残念ながら上記のような考えを持つ社会人に出会ったことがあまりありません。
まぁそんな腐った人にならないように”間違わない、正しく見る”力をトライ&エラーを繰り返して模索して行こうと考えております

11.初めてのプロジェクトリーダー(6):「ふりかえり」でプロジェクトを改善する

【要点】
メンバーとKPTする(Keep(良かったので次もやりたいこと)、Problem(問題だったので次はやめたいこと)、Try(次にやってみたいこと))
プロジェクトリーダーにとって貴重な時間
メンバーを導く手段として
お客さまとKPTする
1人でKPTする

次の教育で「KPT」についての詳細記事の読破もしくは現在仕事に対して「KPT」を実行してみます。

【URL】

http://www.itmedia.co.jp/im/articles/0507/29/news110.html
【感想】
作業工程の「ふりかえり」もこのようなやり方があるのですね
機会を作ってKPTを簡単な表にしてみて試してみます。

12.初めてのプロジェクトリーダー(7):リーダーシップは天性ではない

【要点】
リーダーの修行方法
「リーダーになったつもりシミュレーション」
リーダーシップは天性か?
リスクとチャレンジ

【URL】

http://www.itmedia.co.jp/im/articles/0508/26/news117.html

【感想】
やはりリーダーとは、努力の塊であり、天性のものではありません。
今までの記事から様々な知識と経験からなるものがリーダー。
ただし、私がこの記事と現在の自分状況から言いたいのは、リーダーでも”間違ったリーダー”にならないこと。

– 以上 ‐

PJへの道のりはキビシwww

次回へ(半年後)続く

「テストから見えてくる グーグルのソフトウェア開発」を読んで

この本は、グーグルのソフトウェア開発とテストについて解説した本である。

グーグルには主に、以下の職種がある。
・SWE(ソフトウェアエンジニア)
 SWEは、従来のデベロッパーであり、通常のコードを書くがテストコードも大量に書く。
・SET(ソフトウェアエンジニアインテスト)
 SETは、テストインストラクチャの整備など、SWEがテストを進めるためのサポートを行う。
 設計をレビューし、コードの品質とリスクをじっくりとチェックすることも行う。
・TE(テストエンジニア)
 TEは、ユーザの立場となってテストを推進する。
 全体的な品質チェックや、テストの実行を指揮する。

グーグルにテスタは多くない。
グーグルでは開発とテストを融合していて、片方だけはできない。
少しコードを書いたら、そのテストをする。そしてまた少しコードを書いてテストする。
開発者は自分が触れたすべてのコードの品質に対してオーナーとしての責任を持つ。

また、グーグルには「20%ルール」というものがあり、1週間に1日、あるいは
時間全体の20%を自分が選んだプロジェクトのために使える。
さまざまなタイプのプロジェクトの仕事ができ、スキルセットを広げることができる。

一般に、グーグルでは市販ツールを使うことが無いらしく、それは、
上記の20%ルールを利用して、社内ツールの構築に貢献するメンバが多いためであるらしい。

他にテストを自動化するためのツールの話などもあったが、
特に20%ルールなどでテストや仕事の効率化されている点に興味がわいた。
テスト以外のことでもグーグルという会社では、おもしろい取り組みが多いようで
いろいろな点で参考になりそうに思えた。

YCC社員旅行~大分編~

11月21日より一泊二日の社員旅行で大分へ行って参りました!

DSC02915

↑バスが動き出すや否や始まる宴!!仕事は速く全力で!それがYCC(キラッ☆)

DSC02927

↑お昼は日田五葉苑で焼肉。見てください!この素敵なお肉!顎が粉々になるまで噛んでいたい・・・そう思われた方もいたとかいないとか!それがYCC(キラッ☆)

DSC02963

↑昼食の後はサッポロビール工場へ。ビールが出来る工程を見て感心してる風を装いつつも、隠しきれない心の声「いいから早く!!!早くビールを飲ませてくれ!!」それがY(以下省略

DSC02986

↑ビール工場に別れを告げ、由布院へ。そこで待ち受ける途中参加K田さんとの合流ミッション!しかし、探せど探せどK田さんとは合流できず(笑)!由布院恐るべし!!

DSC03025

↑散策時間内には合流できなかったが、無事K田さんと合流し旅館へ

DSC03043

↑楽しいゲーム大会。しかし、決勝に駒を進めたK部長とT部長にこの後とんでもない試練が・・・(笑)

DSC03058

↑K常務の還暦のお祝い!赤いちゃんちゃんこと似顔絵・メッセージが入った色紙をプレゼント!!とても感動的でした!もちろんこの後、赤いちゃんちゃんこ姿のK常務は、カメラの集団に囲まれ激しい写真撮影会がスタート!

 

DSC03077

 

美味しいごはんと楽しいゲーム、K常務の還暦のお祝いで宴会は大盛り上がりでした!!早くも来年の社員旅行が楽しみです!

DSC03069

↑旅行のハイライト!!!

 

「最強のチームビルディング(チーム創りとマネジメント)」を読んで

今回は連載の最終回ということで、今までのおさらいといった内容と実践方法の解説でした。

おさらいをすると、
 ○チーム意識 ・・・ リーダー自身が求心力となる必要がある!
 ○安全な場  ・・・ 「自己開示」「他者受容」
 ○信頼関係  ・・・ 信頼関係は「気づく」ことから!
 ○自信と本気 ・・・ 多様性を成果に変える「アドバイスセッション」
といった内容です。

改めて再確認し、感じてしまってはいけないのでしょうが、自分はどれも弱いなと思ってしまいました。
では、他のプロジェクトはどうだろうか。会社自体はどうだろうか。

自分が出来ていないこと、しなければいけないこと、したほうがよいことがわかったので、本連載を読み進めてきたことには成果があったと感じます。

大事なのは、読んで満足ではなく行動し、チェックし、改善していくことだと思いますので、よいチーム創りを心がけて行動します。

ITシステムはなぜ失敗するのか

「なぜ失敗するか」の原因を多方面から検証するような本を探していたのですが、内容としては「こうすべきだ」という話が多かったです。
原因についての記載は少し少なめで目的とずれてしまったのは残念でした。

主として主張しているのは「要件定義をあいまいに開発を開始しない」ことでした。そのためのアプローチとして
・開発をベンダー任せにしない
・モックアップを作成し、手戻りの少ない要件定義を作成する
・開発を行いたい目的にあった開発を行う
といったことが挙げられていました。

実際の現場でも要件定義が不明確なことが問題になることはどこでも共通の問題だと思います。
以前読んだ本や最近受けたセミナーでもモックアップを使っての要件定義について話題が出ていました。
この部分についての新しい効率の良いアプローチがないか探してみたいです。

知識ゼロから学ぶソフトウェアプロジェクト管理

 本書籍ではソフトウェア開発のポイントとして、以下の4つのTipsを上げ、その説明を中心にプロジェクト管理について書かれている。
 ①一人一人のエンジニアのアウトプットを最大限にする
 ②変更に耐性を持つ開発スタイルにする(しかし変更は最小限にとどめる)
 ③品質第一主義
 ④非機能要求は上流から下流まで特別な扱いをする

 まず、人がすべてであるという話が書かれている。
 一人一人のプロジェクトメンバーが高いモチベーションをもって、良いものを作ろうとする心意気が大事で、与えられたことだけをやればいいというモチベーションの低いエンジニア集団では問題が起こっても不思議ではない。

 また、要求仕様を書くうえで、4つの重要なポイントをあげている。
 ①漠然たるユーザー要求を機能要求に落とし込む
 ②要求に優先順位をつける
 ③テスト可能な要求を書く
 ④非機能要求をちゃんと書く
 要求仕様についてうまく要点を絞った説明がされていて参考になった。

 プロジェクト管理については硬い内容の書籍が多いと思うが、本書は非常に砕けた文章で読みやすかった。
 設計について、アーキテクチャパターンの紹介があったが詳細な説明までは無かったので、今度は設計関係、特にアーキテクチャについて学習したいと思った。

【5分で絶対に分かるプロジェクト管理】感想その2

<前回>:<http://yscc.jp.net/wp/?p=1703>

前回の感想続きです。

ここでは、【問題管理】、【構成管理】、【変更管理】、【リスク管理】、【品質管理】、【設備・環境管理】のポイントとその感想を記載しております。

【問題管理】
・問題管理では、問題点はなく以下の項目を達成する必要がある。
1.何を問題として管理するか決めておく
2.問題管理フローを決めておく
3.問題と担当者をコントロールする
4.問題を見える化する

【構成管理】
・問題点
1.任意のリリースバージョンを取り出せるようにする
例:バージョン管理・ライブラリ管理
2.障害の対処状況を追跡し、修正コードと対応付けられるようにする
例:バグトラッキング

・構成管理の目的を達成するため、以下の点が必要。
1.何を構成管理するかを決めておく
2.構成管理フローを決めておく
3.バージョンを管理する
4.バグと対応状況を管理する

【変更管理】
・変更管理(仕様に対する変更要求)では、以下の項目を達成する必要がある。
1.新しい合意を適切に確立する
2.すべての成果物の整合性を保つ

・上記を踏まえた問題点
1.何を変更管理するかを決めておく
2.変更管理フローを決めておく
3.変更要求と対応者をコントロールする
4.変更要求を見える化する

【リスク管理】
・リスク管理の目的を達成するため、以下の点が必要。
1.何をリスクとするかを決めておく
2.リスク対応方針を検討しておく
3.リスクと対応者をコントロールする
4.リスクを見える化する

【品質管理】
・品質管理の目的を達成するため、以下の点が必要。
1.品質基準を決めておく
2.レビュー方法を決めておく
3.テストの計画を立てる
4.品質レビューを行う

【設備・環境管理】
設備・環境管理では、以下の項目を達成する必要がある。
1.設備・環境をリストアップしておく
2.申請方法を決めておく
3.設備・環境を維持管理する

【感想】

・【設備・環境管理】はPLとしての大事な要素かは少し微妙なところ(むしろこれは管理部側の管轄では?)

・問題監理、構成管理、変更管理、リスク管理については、各要素についてどれだけ明確し、見える化(相互理解、情報共有、明確な資料作り)かがポイントとなるかなと思いました。
これは”当たり前のこと”だと思うことですが、その”当たり前”ができていないのが事実。悲しいけどこれ現実なのよね~~w

今回の記事は、あくまでPLとして基本知識で、この記事で記載されていた各項目もまだ表面的な内容ばかりあり、詳しく掘り下げたものではありません。
今後は、各項目を更に深く掘り下げていきます。

to be continued?