TypeScriptネットワークプログラミング

本書はもともと、TypeScriptを勉強するつもりで読み始めたが、TypeScriptの説明よりも、サーバ/クライアント形式のアプリ開発手法について重点が置かれている感じがした。
しかし、ネットワークアプリの開発にも興味があったのでそちらの方が勉強になった。

TypeScriptについてだが、いくつもあるaltJSの中でTypeScriptはJavaScriptの上位互換となっているため、部分的にTypeScriptの機能を使えることが特徴的である。
取り合えず使いたい機能だけを使っていくということで入りやすいと思えた。

ネットワークアプリの開発については、クライアント/サーバモデルの他、P2Pモデルの説明もあり、TypeScriptを使ったネットワークプログラミングについて、その基本的なところにポイントを絞って詳しく説明されていてわかりやすかった。

また、Node.jsの使い方についても説明があって、ネットワークアプリの入門書としても読みやすかった。

2017/11/1 道路サポーター清掃活動を行いました

今年2回目の道路サポーター清掃活動を行いました(*^^*)

投稿が遅くなりました!ごめんなさいm(__)m

夏に行うと暑い(-_-;)ので季節を避けて秋での作業を実施となります。

落ち葉が結構あった模様です。皆さん黙々と作業中。

ほら!大量!大量!!とアピールするTさん。

最後は参加者全員で集合写真です。

次回はいつだったかな・・・冬場なので寒いと思いますががんばりますよ~

以上、ここまで当日欠席だったSさんがお送りしました!

教育計画_日経システム6月号

●TREND:軌道に乗り始めた定額制SI コストに厳しい中小企業に響く

■ジョイゾーの定額制SI「システム39」

■■特徴
・システム開発を「定額制」(39万円)で請け負う
・開発基盤に、ドラッグ&ドロップで画面作成できる
サイボウズのPaaS「kintone」を利用
・顧客との責任分担を明確化
→初回2回の無料相談と、顧客対面での
アプリケーション開発を1回2時間で3回実施
→要求整理は顧客の責任とし、4回目の打合せは行わない
・画面カスタマイズ中心でExcelで実施していた業務のWeb化

■上位プラン 2017/02に追加
・システム59 システム109 システム190 システム390
→カスタマイズ範囲の拡大

■定額制SIが続々
定額制SIのビジネスモデルが普及してきている

→kintomeを使った定額制SI実施企業、
・フトバンク・テクノロジーズ子会社のM-SOULUTIONS
・アールスリーインスティテュート(大阪)
・ラジカルブリッジ(北海道)

●特集:どうするJava

■2017年はJavaの変革年

■■JavaSE9の登場(2017/07/27)

■■■特徴
・ライブラリのモジュール化
ライブラリの分割導入が可能に
→jarファイルの管理が簡素化

・JShell
コードを記述しながらテストできる
「REPL(READ Eval Print Loop)環境」

・内部APIが利用不可に
原則として内部APIにアクセス不能となる

■■JavaEE8の登場(2017/07/XX)
クラウド使用開発を見据えた機能追加

■■OSSフレームワークの開発進行
・「Spring FrameWork」
「Spring Boot」
ライブラリの設定などを自動化

「Spring Cloud」
クラウドサービス上でのマイクロサービス構築支援

■■進化の一方で問題点も

■■■セキュリティへの課題
ex.OSSのJavaフレームワーク「Struts2」の
脆弱性をついた情報漏洩が2013年ごろから増加傾向

■■■EOL(End of Life サポート終了)
2000年代に開発されたJavaシステムのサポート終了
ex1.「Strutsl」
ex2.「Seasar2」
→Java標準自体のEOLも

教育計画:日経システム5月号

■「ビルコミュニケーションシステム」竹中工務店

■■概要
ビルの各種設定をクラウド上のアプリケーションか自動制御する

■■問題
従来のオンプレの設備管理システムは個別でクローズドなシステム
であり、サーバ能力も不足していた

■■対応
・オンプレの照明システムや空調システムをクラウド化
・クラウドならでは実現できる機能を模索
→照明や空調などのセンサーから情報所得し、クラウドで自動判断、
センサーの制御を返却
→Machine to Machineを実現

■■情報システム構築と異なる難しい点
・各社の照明、電気システムをコーディネート
→通信プロトコルの検証、どのようにデータをやり取りするか?

・ビルに実装するIT化は”一品生産”
→「工事」の一括契約に対応してもらえるか?
→保守をワンストップで請け負えるITベンダーが望ましい
→パートナー選定が鍵

——————-
■カタログを使った要件定義

■問題
・要件定義工程の難化
→デバイスやUIの表現の多様化
→次々と現れる新技術

■■対応
・カタログを使った要件定義
→要求機能の実現方法を「カタログ」化
→カタログから部品を選んで組み合わせる形式

■■要件定義難化の背景
・外部からの調達前提の従来の受託型開発が時代遅れに

・従来
→発注から納品までのリードタイムは年単位の比較的長期間が許容されてきた

・近年
→技術の変化スピードの加速
→長い発注プロセスの間により洗練された技術が出現する

■■エンジニアの役割
・「誰かの要件を定義する」ことから
「自分たちの実現したいことを理解し、適合する技術を自分たちで選び、
自分たちでシステムを作っていく」ことに変化している

——————-

教育計画:日経システム4月号

●ERPで進む「AI」活用 使いながら精度を高める。
AIを取り入れた基幹システム向けのEPR(統合基幹業務パッケージ)やSaaSが相次いで登場している
・Microsoft 「 Dynamics 365」
→機械学習を中心としたAIを活用する機能を搭載
「リレーションシップインサイト」「需要予測」等の機能の精度向上
・Salesforce.com 「Salesforse Einstein」
→営業支援やマーケティングなど8領域のアプリケーション
2017年春の新版からAIを取り入れた機能の提供を開始

■AIを利用して実現しようとしている機能
①AIを使用しないと実現できない機能
ex.
・Salesforse.com 「リードスコアリング」
→営業中や資料請求があった潜在的な顧客になりうる取引先に対して
実際にどの程度、商談が成立するか確率を予測
過去の電子メールを取り込み、分析し、過去の商談が決定したパターンに当てはまるか
点数付け
②既存のERPやSaaSが持つ機能の進化
ex.
・ワークスアプリケーションズ 「HUE」の「Magic Paste」機能
→請求書などの帳票類をHUEの入力画面にドラッグアンドドロップ
すると、帳票の中から入力画面に必要な要素を抜き出し自動的に入力する

■ERPやSaaSのAI活用に重要なこと
・データの量、精度の確保
→ERPやSaaSの継続利用によってデータの蓄積が必要
・AIに詳しいITエンジニア
→ERPのパラメータ設定の知識、データサイエンティスト

2017年度上期キックオフ

2017年4月21日(金)にわが社のキックオフが行われました。

簡単ですがレポートさせていただきます。

こうやって書いているとはるか昔、2013年度のキックオフのレポートを書いていたのを思い出します。

興味のある方は見てみてください。

当時まだ会社に慣れていないこともあり言葉を選び選び書いていることがわかると思います。

 

さて、本編に入ります。

まず今年のキックオフですが我が社が入っている北九州センタービル8階で行われました。

名物司会者による軽妙?な進行で進んでゆきます。

軽妙な司会

内容については社外秘なので明かせませんが、淡々と進んでいきます。

プレゼンの表現の仕方によって各部の色が濃く出ている風に感じました。

 

そしてキックオフの最後には恒例の掛け声をあげての決起。

なんという掛け声だったかはあまりにアレだったのでここでは書けません。

やる気まんまん

キックオフが終わったら行きつけの韓国料理屋での懇親会です。

なんとなくですがいつもより盛り上がっていた気がします。

飲み会

下は今年の新人と前年の新人による挨拶の光景。

まるで出てきたての芸人の様ですが立派なプログラマー候補生です。

頼もしい若手

最後は恒例となったウルトラソウルで締めが行われました。

やはりこれをやると気合が入ります。

 

気合を入れなおした今年度のワイズ・コンピュータ・クリエイツにご期待ください。

教育・訓練 2016年10月~2017年03月

できるPMの決め手は「リスクマネジメント」
http://www.atmarkit.co.jp/ait/articles/0505/25/news114.html

【要点】
コミュニケーションに問題があるといわれるプロジェクトには、2つの共通点がある。
 ・「自分からいわない」点・・・「気付いているけれど自分からはいわない」こと
 ・「自分からあえて気付かないようにする」点・・・「自分からやっかいなことを見つけてしまわないようにする」こと
つまり、「責任回避」「不要な遠慮」「無責任・無関心」という事
⇒これには何かしらの原因がある。
原因の一例)
プロジェクトの運営方法についての小さな不満がきっかけとなり、不満が積もりに積もったことが原因

問題の発生を未然に防ぐことができるか、それとも、何か問題が起こってから対処するのか。プロジェクトマネージャの力量の差は、この点に集約されるといっても過言ではない

PMBOKはプロジェクトマネジメントの専門用語とガイドラインを提供する書籍である。
国際的に標準とされているプロジェクトマネジメントの知識体系(ガイド、手法、メソドロジー、ベストプラクティス)であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供している。

 1.リスクマネジメント計画
 「リスクマネジメント計画書」は、個別のリスクに対する計画書ではなく、プロジェクトの計画時点で、プロジェクトで発生するリスクをどのようにマネジメントしていくかを決めること。例えば、リスクを認識したら、誰がどういうシートに何を記述するか、また、そのリスクをどう評価し優先順位付けるかを定めておくこと。

 2.リスク識別
 関係者からの話や、成果物のレビューなどを基にプロジェクトのリスク事象を把握する。ささいな気掛かりがリスクの芽であるケースも多く、これを「トリガー」(リスク兆候)として認識することも重要である。

 2.定性的リスク分析
 認識されたリスクを「現実のものとなった場合の影響度」と「発生確率」の2つの観点から評価する。この評価を基に取り組むべきリスクの優先順位付けを実施する。

 3.定量的リスク分析
 優先順位付けされたリスクを数量的に分析し、おのおののリスクがプロジェクトに与える影響を考慮し、どのリスクにどの程度注力するかを決める。場合によっては必要となるコスト・スケジュールのコンティンジェンシー予備の規模を決める。

 4.リスク対応計画
 個別のリスクへの対応策である。負の要因については、発生しないような対処、あるいは、発生した場合の影響を最小限にする施策を「リスク対応計画書」として取りまとめる。

 5.リスクの監視・コントロール
 いったん識別されたリスクは、必要がなくなるまでプロジェクト期間を通じてモニタし続ける必要がある。これは、プロジェクトの状況が変われば発生確率や影響度が変わるケースがあるためである

実際のプロジェクトは、上記のプロセスではなく「頭の中でのリスクマネジメント」が多いのではないだろうか。

リスクの洗い出しに必要なものは?
⇒リスクへ対応する際は、リスクの大きさ(影響と発生確度)と投入する資源とのバランスを取る。過度に資源に頼らず、対話や折衝、知恵と工夫で対処することが望ましい。

【感想】
「自分からいわない」点と「自分からあえて気付かないようにする」点これに立場や各個人の関係性などが加わればプロジェクトはスムーズには進まないのではとふいに頭を過ってしまった。
このような原因に「責任回避」「不要な遠慮」「無責任・無関心」など上げられている。
私の個人的な経験からスムーズに実施されたプロジェクトは”一つもなかった”と断言できます。
つまり、突き詰めれば世の中の人全て「無責任・無関心」なのかなと考えれるかもしれません。
悲しい現実ですね

また、リスク管理については、リスクの種別、リスクの大きさ、投入する工数などをバランスに取るという事が一番大事だという事。
そのバランスを取るためにリンクの分析力、リンクの予想する力(リスクの兆候、懸念事項の明確性、システムの理解)などを強化する必要があると実感しました。

即活用!企業システムにおけるプロジェクト管理
https://thinkit.co.jp/free/project/1/8/1.html

【要点】

・業務フロー – 担当部門(ロケーション)
 業務担当者の役割分担が明確にわかるようにすること
 →業務処理の行われる場所を欄で分け、業務の流れに沿って記載すること

・業務フロー – 主なデータ
 ”データを書く派”と”データを書かない派”がいる
 →”デーユーザ自身が業務フローを書くような場合は、データを書かないケースが多いでしょうタを書く派”と”データを書かない派”が多い
 →我々のような開発サイドが業務フローを作成する場合は、主なデータを記載した方がわかりやすい
 業務の流れをデータの流れと対比させて見る目的さえ達成できれば十分である。

・業務システム開発の各工程におけるドキュメント成果物の種類について、弊社の開発ドキュメント標準DUNGEONをベースに説明。
 システム化の対象となる画面や帳票を業務フローに漏れなく記述すること、記述するデータ(テーブル)については理解を深めるための主要なものでかまわないということを覚えておくこと。

【感想】
この記事を見て感じたのは、全てドキュメントは一度フロー図にしたほうが良いのでは?
人は言葉だけのものを完璧に理解するということはできません。だから、言葉を”自分が理解した形”つまりフローにして見せる
そして、そのフローを第三者に見せ、その第三者が理解した時、初めて自分も理解しているという証明となります。
どのドキュメントも”まずは図解”という考えと持った方が良いのかもしれません。

忘年会を開催しました!

12月9日八幡東区の大谷会館にて、弊社忘年会が開催されました!

 

dsc_0365_r

司会は入社一年目とは思えない落ち着きぶりのT君です。

 

dsc_0383_r

 

 

 

来年度入社予定のN君も参加してくれました。

挨拶は緊張してますとのことでしたが、まったくそんな感じはしなかったです。

来年度の司会は私がやります!とのことでしたので忘れないようにここに記録しておきますヽ(^o^)丿

dsc_0402_r

一年間を振り返るスライドショーが上映されました。

あまりのハイクオリティさに感動してしまい写真を撮るのを忘れかけました。dsc_0426_r

 

 

ビンゴ大会も盛り上がりました。

食事に没頭している人が多いのは

気のせいです!

 

dsc_0470_r

 

最後は恒例になっているウルトラソウルの合唱です。

向こう50年はこれでいきましょう!

 

 

 

それでは来年もがんばりましょう!!!ヽ(^o^)丿ヽ(^o^)丿ヽ(^o^)丿

dsc_0471_r

 

 

教育・訓練 2016年04月~2016年09

1.記事[プロジェクト・マネージャの「やってはいけない」]
問題を課題と勘違いしてはいけない
⇒課題管理の方法(How)ではなく、管理すべき課題(What)に誤りがある
管理する「課題」の定義が正しく行われていない
⇒課題ではなく、現場で発生している事象である「問題」を管理していることがとても多い。

課題の定義とは、「目的を達成するために解決すべき事柄」である。
⇒つまり課題管理で扱うのは、プロジェクトのメンバーが「次にどのような手を打つべきか」を検討したり実施したりできる内容になっていなければならない。

課題かどうかは「アクションを起こせるか」でチェック
⇒多くの現場では、問題を課題に変換する必要があるだろう。そのためにはまず、発生している事象である「問題」と、解決に向けた行動を促す「課題」は別物であるという認識を、現場に浸透させる必要がある。
⇒確かに記録することに意義はあるが、プロジェクトを推進し成功させるには、解決するための行動も管理する必要がある

最初に課題と問題を分類する段階を設ける
⇒課題管理では、プロジェクトチーム内やユーザーとの間で、課題とその対応策を共有することが大切
⇒課題や対応策が抽象的で曖昧な記述をしてしまうと、解釈にブレが発生し思わぬトラブルを招く原因になる。

課題管理の第1段階として、問題と課題の分類を行う
⇒課題管理表に「大分類」や「小分類」といった欄を設け、定型的な分析を行う。
⇒内部検討の必要がある問題は、具体的にどのように検討するかをまず書く。
⇒検討した後は、どう解決するのかを踏まえて次のアクションが分かるように表に書くようにする。

ビジネス、プロジェクトといったレベルで管理
⇒書き込む課題のレベルを分けること

【感想】
課題と問題の違い、それを正しく分析し、段階を踏みアクションを取る。
冷静に考えればできる事できることですが、人は簡単には理想の行動を取ることはできません。
ただ、この記事は基本を見直す良い記事という印象を受けました。

2.記事[休暇中に仕事との接触を絶たない方がよい理由]
人事担当者向けの会員制サイトWorkplaceTrends.comが行った調査「2015 Workplace Flexibility Study」の結果
⇒会社側の67%は、社員のワークライフバランスが整っていると思っているのに対し、社員側の45%は、プライベートな活動への時間が取れていないと感じている。

「従来の捉え方は、仕事(ワーク)と生活(ライフ)は相反する活動で、時間を互いに奪い合っているという認識
⇒仕事とは別立てで『自由な時間』がある、つまり仕事は自由ではないという認識。しかも、『バランス』という言葉が付いているからには、仕事が増えると必然的に生活は減るという意味になる
⇒我々の生活は1つであり、たまたま、その一部を仕事に使い、一部を他の活動に使っている

近頃のワークライフバランスの概念は、いつどこでも仕事ができる柔軟性を社員に提供する
⇒プライベートの生活と仕事の生活が重なり合うことになるので、社員の側は、仕事との接触を持つ機会と断つ機会をいつどのように設けるかについて、答えを見つけ出す必要がある

【感想】
仕事とプライベートの重なり合いをよく考え、必要だと思う事には積極的に接触し、そうでない事にはきっぱりと断つ事。
物事をきちんと判別し、”これはこれ”、”それはそれ”という判断は大変大切な事だと思います。
あとは、物事の重要性を判断基準などが記載してあれば、大変面白いかなと思った記事でした。

3.[マインドマップ化:プロジェクトリーダーについて Ver0.00]
過去の読破した記事の内容(プロジェクトリーダーに関する記事)を独自に分析
私個人がプロジェクトリーダーとして、必要な要素・姿勢・問題点をマインドマップ化
※ これはあくまで私の個人的解釈であることをご了承ください。
※ これは今後も内容を随時更新し、ブログにUPする予定。
※ マインドマップについて知りたい方は[こちら]
pl%e3%81%a8%e3%81%af%ef%bc%9f-%e3%80%90%e5%a4%a7%e5%89%8d%e6%8f%90%e3%80%91-%e3%83%aa%e3%83%bc%e3%83%80%e3%83%bc%e3%81%a8%e3%81%97%e3%81%a6%e3%81%ae-%e5%94%af%e4%b8%80%e3%81%ae%e8%b3%87%e8%b3%aa

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

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

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

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

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

P_20160518_142438 P_20160518_131917

 

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

P_20160518_162453